6 ms·

Tangentially related.. like HTTP, Websockets currently operate over TCP. Is there plans to port them to QUIC as well? It's been many years since my networking

Tangentially related.. like HTTP, Websockets currently operate over TCP. Is there plans to port them to QUIC as well? It's been many years since my networking class but I'd assume Websockets would stand to gain quite a bit as well.

denormalfloat 8y ago
Websockets (the protocol) are mostly defunct in comparison to HTTP/2 and QUIC. Porting websocket based code should mean converting it to HTTP{2,3}. The main reason that's not possible today is due to large existing library support for websockets on both the server side and directly in browsers.
- gizzlon 8y ago
  I disagree. Websockets sweet-spot is still the "server wants to send messages to the client" usecase. This does not work (as well) with http/2. Dunno about /3, but it's really a fundamentally different model than the reques/reply of http.
est31 8y ago
Websockets are largely obsolete because nowadays, if you create a HTTP/2 fetch request, any existing keepalive connection to that server is used, so the overhead that pre-HTTP/2 XHR connections needed is lost and with it the advantage of Websockets.
- crgwbr 8y ago
  Honestly curious: how would you use HTTP{2,3} to push a real-time message from server to client without a WebSocket? Are we back to just long polling?
  - Matthias247 8y ago
    You can use server-sent-events or use do some custom streaming format inside the response body. The latter might not work well, due to the fact that arbitrary streaming APIs might not yet be exposed by all browsers (ReadableStream on fetch API: https://caniuse.com/#feat=streams https://caniuse.com/#feat=streams).
    - cryptonector 8y ago
      I thought all XHRs support streaming, and they should run over HTTP/{2,3}. Is that not right?
      - Matthias247 8y ago
        Afaik XHR allows you to access received data in a streaming fashion, but the XHR type will always buffer the full received payload internally. So if you try to stream a large amount of data over it you will eventually run out of memory. If you want to consume a potentially endless stream with custom encoding you need the fetch API with streaming support for that (https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams#Consuming_a_fetch_as_a_stream https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...), as far as I understood. Or websockets. That is one reason that e.g. gRPC streaming support doesn't work trivially in browsers.
  - jungturk 8y ago
    Server-sent events (SSE) is an option. https://blog.sessionstack.com/how-javascript-works-deep-dive-into-websockets-and-http-2-with-sse-how-to-pick-the-right-path-584e6b8e3bf7 https://blog.sessionstack.com/how-javascript-works-deep-dive...
  - jrockway 8y ago
    gRPC is already HTTP/2.0 and has bidirectional streams. I imagine it would work like that. Browsers are almost at the point where they can just talk gRPC to the backend, but gRPC uses HTTP trailers which browsers do not support. I don't think, from a networking standpoint, that websockets was really necessary. A browser and a web server already have a socket open that they send messages in either direction on. It's just so much of the web was designed around "client asks for something, server sends the result and closes the connection" that some transition period was necessary to distinguish between the two cases. (You didn't necessarily provision your web server for maintaining hundreds of thousands of open connections.) But now that people are used to the idea of connections sticking around in the context of HTTP, it's no big deal to send arbitrary data over that connection.
    - icebraining 8y ago
      But can the client in HTTP/2 send more data to the server after it has received something, without having to send a full HTTP request? If not, I don't see how something like agar.io, which requires constant updates to the server on every mouse movement, can work without tremendous header overhead.
    - gizzlon 8y ago
      Not really, it's rpc and websocket is not. I looked into this for a project and neither http/2 or gRPC does the same thing : fully bidirectional, long-lived stream with no weird semantics or hacks.
  - seabrookmx 8y ago
    Exactly. I think most people didn't use Websockets due to the theoretical performance improvement over HTTP 1.1, but because it's a different programming model. I think it's very shortsighted to assume people should (or want) to roll their own streaming protocol when Websocket is already a great fit for many applications.
- deleted 8y ago
  [deleted]
- Matthias247 8y ago
  It's true that HTTP/2 could eventually replace lots of websocket use-cases, and integrate better with other HTTP code (e.g. frameworks, authentication, etc). However currently if you need streaming and message ordering guarantees in both direction, you are currently still limited to websockets. HTTP might become more useful once body streaming APIs in both directions are available in browsers.
- lucaspardue 8y ago
  There is still a place for WebSockets in HTTP/2. The fairly recent RFC 8441 defines a mechanism to reserve a single HTTP/2 stream for bidirectional WebSockets. It is feasible for a similar mechanism for also work for HTTP/3, just no-one has gone to the effort yet. https://tools.ietf.org/html/rfc8441 https://tools.ietf.org/html/rfc8441
  - seabrookmx 8y ago
    Thanks, this is basically what I was looking for. With quic I'm guessing you could have multiple Websocket and http3 streams within one connection and have them not block eachother on packet loss, which is pretty neat.

denormalfloat 8y ago

Websockets (the protocol) are mostly defunct in comparison to HTTP/2 and QUIC. Porting websocket based code should mean converting it to HTTP{2,3}. The main reason that's not possible today is due to large existing library support for websockets on both the server side and directly in browsers.

gizzlon 8y ago
I disagree. Websockets sweet-spot is still the "server wants to send messages to the client" usecase. This does not work (as well) with http/2. Dunno about /3, but it's really a fundamentally different model than the reques/reply of http.

est31 8y ago

Websockets are largely obsolete because nowadays, if you create a HTTP/2 fetch request, any existing keepalive connection to that server is used, so the overhead that pre-HTTP/2 XHR connections needed is lost and with it the advantage of Websockets.

crgwbr 8y ago
Honestly curious: how would you use HTTP{2,3} to push a real-time message from server to client without a WebSocket? Are we back to just long polling?
- Matthias247 8y ago
  You can use server-sent-events or use do some custom streaming format inside the response body. The latter might not work well, due to the fact that arbitrary streaming APIs might not yet be exposed by all browsers (ReadableStream on fetch API: https://caniuse.com/#feat=streams https://caniuse.com/#feat=streams).
  - cryptonector 8y ago
    I thought all XHRs support streaming, and they should run over HTTP/{2,3}. Is that not right?
    - Matthias247 8y ago
      Afaik XHR allows you to access received data in a streaming fashion, but the XHR type will always buffer the full received payload internally. So if you try to stream a large amount of data over it you will eventually run out of memory. If you want to consume a potentially endless stream with custom encoding you need the fetch API with streaming support for that (https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams#Consuming_a_fetch_as_a_stream https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...), as far as I understood. Or websockets. That is one reason that e.g. gRPC streaming support doesn't work trivially in browsers.
- jungturk 8y ago
  Server-sent events (SSE) is an option. https://blog.sessionstack.com/how-javascript-works-deep-dive-into-websockets-and-http-2-with-sse-how-to-pick-the-right-path-584e6b8e3bf7 https://blog.sessionstack.com/how-javascript-works-deep-dive...
- jrockway 8y ago
  gRPC is already HTTP/2.0 and has bidirectional streams. I imagine it would work like that. Browsers are almost at the point where they can just talk gRPC to the backend, but gRPC uses HTTP trailers which browsers do not support. I don't think, from a networking standpoint, that websockets was really necessary. A browser and a web server already have a socket open that they send messages in either direction on. It's just so much of the web was designed around "client asks for something, server sends the result and closes the connection" that some transition period was necessary to distinguish between the two cases. (You didn't necessarily provision your web server for maintaining hundreds of thousands of open connections.) But now that people are used to the idea of connections sticking around in the context of HTTP, it's no big deal to send arbitrary data over that connection.
  - icebraining 8y ago
    But can the client in HTTP/2 send more data to the server after it has received something, without having to send a full HTTP request? If not, I don't see how something like agar.io, which requires constant updates to the server on every mouse movement, can work without tremendous header overhead.
  - gizzlon 8y ago
    Not really, it's rpc and websocket is not. I looked into this for a project and neither http/2 or gRPC does the same thing : fully bidirectional, long-lived stream with no weird semantics or hacks.
- seabrookmx 8y ago
  Exactly. I think most people didn't use Websockets due to the theoretical performance improvement over HTTP 1.1, but because it's a different programming model. I think it's very shortsighted to assume people should (or want) to roll their own streaming protocol when Websocket is already a great fit for many applications.
deleted 8y ago
[deleted]
Matthias247 8y ago
It's true that HTTP/2 could eventually replace lots of websocket use-cases, and integrate better with other HTTP code (e.g. frameworks, authentication, etc). However currently if you need streaming and message ordering guarantees in both direction, you are currently still limited to websockets. HTTP might become more useful once body streaming APIs in both directions are available in browsers.
lucaspardue 8y ago
There is still a place for WebSockets in HTTP/2. The fairly recent RFC 8441 defines a mechanism to reserve a single HTTP/2 stream for bidirectional WebSockets. It is feasible for a similar mechanism for also work for HTTP/3, just no-one has gone to the effort yet. https://tools.ietf.org/html/rfc8441 https://tools.ietf.org/html/rfc8441
- seabrookmx 8y ago
  Thanks, this is basically what I was looking for. With quic I'm guessing you could have multiple Websocket and http3 streams within one connection and have them not block eachother on packet loss, which is pretty neat.