6 ms·

> As an aside, HTTP/2 is technically superior to WebSockets. HTTP/2 keeps the semantics of the web, while WS does not. WTF is this? Those are different layer p

by remram 4y ago

> As an aside, HTTP/2 is technically superior to WebSockets. HTTP/2 keeps the semantics of the web, while WS does not. WTF is this? Those are different layer protocols. WebSocket can run on top of HTTP/2. It's like saying TLS is technically superior to TCP, or IP is superior to copper cables. Reference: https://www.rfc-editor.org/rfc/rfc8441.html https://www.rfc-editor.org/rfc/rfc8441.html

anyfoo 4y ago
I’m not a web developer, but that RFC, which talks about bootstrapping, talks about using the CONNECT method to “transition” to the WebSockets protocol. Which matches what I thought the CONNECT method does: Switch to a protocol that is not HTTP? But I only skimmed the introduction, did I miss something?
- blibble 4y ago
  normally uses GET and the Upgrade header, not CONNECT
  - sveiss 4y ago
    That’s for HTTP/1.1, where WebSockets are really a completely different protocol which “hijacks” the underlying TCP or TCP+TLS stream from HTTP via the Upgrade request. HTTP/2 has its own concept of streams, so WebSockets can run over a single HTTP/2 stream, and the linked RFC describes extending the CONNECT method to take over a single stream.
deleted 4y ago
[deleted]
jjtheblunt 4y ago
> WebSocket can run on top of HTTP/2 Isn't "websocket" just a standard tcp socket, whose specification to instantiate it was born in a comparatively ephemeral HTTP (of whatever version) request, and which outlives the request, so isn't on top of anything other than tcp?
- wmf 4y ago
  No, despite the name WebSockets are not plain TCP.
  - jjtheblunt 4y ago
    They're an http protocol for setting one up, you mean? First sentence at this article: https://en.wikipedia.org/wiki/WebSocket https://en.wikipedia.org/wiki/WebSocket
    - jhugo 4y ago
      No, they're more than that. After you upgrade to WebSocket you still have to speak the WebSocket protocol over TCP. It includes message framing — with different defined message types, masking, ping/pong, an extension system (including for example optional per-message compression), ...
    - deleted 4y ago
      [deleted]
- aaaaaaaaaaab 4y ago
  TCP is a stream of bytes. WebSockets are message-based.
rektide 4y ago
For sure there are good reasons to abandon or find alternative resourceful protocols! But in general, http is & could be the de-facto really good resourceful protocol. It's already 90% there. Alas, the browser has been a major point of obstruction & difficulty & tension in making the most obvious most successful most clearly winning resourceful protocol at all better. The browser has sat on it's haunches & pissed around & prevented obvious & straightforward incremental growth that has happened everywhere else except the browser, such as with http trailers, such as with http2+ push. The browser has kept the de-facto resouceful protocol from developing. You dont have to believe in http as the way to see what an oppressive & stupid shitshow this is. Being able to enhance the de-facto protocol of the web better should be in everyones interest, in a way that doesnt prevent alternatives/offshoots. But right now only alternatives & offshoots have any traction, because the browsers have all shot doen & rejected doing anything to support modern http 2+ in any real capacity. Their http inplementations are all frozen in time.
deleted 4y ago
[deleted]
jayd16 4y ago
HTTP/2 provides features that websockets don't. Even if you were to use websockets over HTTP/2, you'd lose features like being able to multiplex requests _because_ it's a higher level protocol. Why is it wrong to say its better to use a more feature full and lower level protocol?
- Thorrez 4y ago
  They provide different APIs. Websockets provide a bidirectional stream of messages. The messages in a given direction are always delivered in order. If they were to be suddenly reordered that would cause a lot of headaches. While the individual messages can't be multiplexed, different websocket streams over a single HTTP/2 connection can be multiplexed. I think websockets also provides a feature that HTTP/2 doesn't: the ability to easily push data from the server to browser javascript.
  - yesbabyyes 4y ago
    > I think websockets also provides a feature that HTTP/2 doesn't: the ability to easily push data from the server to browser javascript. I will never stop beating this drum: Server-Sent Events and EventSource! Simple to implement, scale, support. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource
    - phoboslab 4y ago
      Pardon my ignorance: Are messages sent through this guaranteed to arrive in order?
      - roblabla 4y ago
        Yes. SSEs are just an infinite-length HTTP body formatted in a particular way. And like all HTTP bodies, they are guaranteed to arrive in the same order the bytes were sent.
Matthias247 4y ago
The idea here is that http provides something like request/response semantics, methods, path, status code, etc - which are all also useful for gRPC. Websockets provide none of that - they are just message streams. Websockets over http/2 are a new thing, and haven’t even been available at the time gRPC incepted.
- stefan_ 4y ago
  That is their whole point. That is why they exist. Dumb reliable pipe, please keep your silly semantics away.
  - latch 4y ago
    Hardly dumb. They include a variable length, payload masking, their own layer of fragmentation, different message type, validation (txt vs bin) and an extension framework.
- the_mitsuhiko 4y ago
  I'm not sure if websockets over HTTP/2 are actually a new thing. Firefox implemented support years ago but it was disabled almost immediately afterwards because it doesn't work with proxies and has been disabled still. I think the only engine implementing it is Chrome. As far as I know for HTTP/3 there is no way to use websockets yet.
kevinmgranger 4y ago
That's in a section specifically about picking the right transport. Per your example, it's like saying "TLS is technically superior to TCP, because it means our protocol can offload encryption and authentication to it".

by remram 4y ago

anyfoo 4y ago

I’m not a web developer, but that RFC, which talks about bootstrapping, talks about using the CONNECT method to “transition” to the WebSockets protocol. Which matches what I thought the CONNECT method does: Switch to a protocol that is not HTTP? But I only skimmed the introduction, did I miss something?

blibble 4y ago
normally uses GET and the Upgrade header, not CONNECT
- sveiss 4y ago
  That’s for HTTP/1.1, where WebSockets are really a completely different protocol which “hijacks” the underlying TCP or TCP+TLS stream from HTTP via the Upgrade request. HTTP/2 has its own concept of streams, so WebSockets can run over a single HTTP/2 stream, and the linked RFC describes extending the CONNECT method to take over a single stream.

deleted 4y ago

[deleted]

jjtheblunt 4y ago

> WebSocket can run on top of HTTP/2 Isn't "websocket" just a standard tcp socket, whose specification to instantiate it was born in a comparatively ephemeral HTTP (of whatever version) request, and which outlives the request, so isn't on top of anything other than tcp?

wmf 4y ago
No, despite the name WebSockets are not plain TCP.
- jjtheblunt 4y ago
  They're an http protocol for setting one up, you mean? First sentence at this article: https://en.wikipedia.org/wiki/WebSocket https://en.wikipedia.org/wiki/WebSocket
  - jhugo 4y ago
    No, they're more than that. After you upgrade to WebSocket you still have to speak the WebSocket protocol over TCP. It includes message framing — with different defined message types, masking, ping/pong, an extension system (including for example optional per-message compression), ...
  - deleted 4y ago
    [deleted]
aaaaaaaaaaab 4y ago
TCP is a stream of bytes. WebSockets are message-based.

rektide 4y ago

For sure there are good reasons to abandon or find alternative resourceful protocols! But in general, http is & could be the de-facto really good resourceful protocol. It's already 90% there. Alas, the browser has been a major point of obstruction & difficulty & tension in making the most obvious most successful most clearly winning resourceful protocol at all better. The browser has sat on it's haunches & pissed around & prevented obvious & straightforward incremental growth that has happened everywhere else except the browser, such as with http trailers, such as with http2+ push. The browser has kept the de-facto resouceful protocol from developing. You dont have to believe in http as the way to see what an oppressive & stupid shitshow this is. Being able to enhance the de-facto protocol of the web better should be in everyones interest, in a way that doesnt prevent alternatives/offshoots. But right now only alternatives & offshoots have any traction, because the browsers have all shot doen & rejected doing anything to support modern http 2+ in any real capacity. Their http inplementations are all frozen in time.

deleted 4y ago

[deleted]

jayd16 4y ago

HTTP/2 provides features that websockets don't. Even if you were to use websockets over HTTP/2, you'd lose features like being able to multiplex requests _because_ it's a higher level protocol. Why is it wrong to say its better to use a more feature full and lower level protocol?

Thorrez 4y ago
They provide different APIs. Websockets provide a bidirectional stream of messages. The messages in a given direction are always delivered in order. If they were to be suddenly reordered that would cause a lot of headaches. While the individual messages can't be multiplexed, different websocket streams over a single HTTP/2 connection can be multiplexed. I think websockets also provides a feature that HTTP/2 doesn't: the ability to easily push data from the server to browser javascript.
- yesbabyyes 4y ago
  > I think websockets also provides a feature that HTTP/2 doesn't: the ability to easily push data from the server to browser javascript. I will never stop beating this drum: Server-Sent Events and EventSource! Simple to implement, scale, support. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events https://developer.mozilla.org/en-US/docs/Web/API/Server-sent... https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource
  - phoboslab 4y ago
    Pardon my ignorance: Are messages sent through this guaranteed to arrive in order?
    - roblabla 4y ago
      Yes. SSEs are just an infinite-length HTTP body formatted in a particular way. And like all HTTP bodies, they are guaranteed to arrive in the same order the bytes were sent.

Matthias247 4y ago

The idea here is that http provides something like request/response semantics, methods, path, status code, etc - which are all also useful for gRPC. Websockets provide none of that - they are just message streams. Websockets over http/2 are a new thing, and haven’t even been available at the time gRPC incepted.

stefan_ 4y ago
That is their whole point. That is why they exist. Dumb reliable pipe, please keep your silly semantics away.
- latch 4y ago
  Hardly dumb. They include a variable length, payload masking, their own layer of fragmentation, different message type, validation (txt vs bin) and an extension framework.
the_mitsuhiko 4y ago
I'm not sure if websockets over HTTP/2 are actually a new thing. Firefox implemented support years ago but it was disabled almost immediately afterwards because it doesn't work with proxies and has been disabled still. I think the only engine implementing it is Chrome. As far as I know for HTTP/3 there is no way to use websockets yet.

kevinmgranger 4y ago

That's in a section specifically about picking the right transport. Per your example, it's like saying "TLS is technically superior to TCP, because it means our protocol can offload encryption and authentication to it".