I don’t know the answer to this one…
I attended an interesting meetup last month. Sergei Koren, Product Architect at LivePerson explained about HTTP/2 and what it means for those deploying services. The video is available online:
One thing that really interest me is how these various transports are going to be used. We essentially now have both HTTP/2 and WebSocket capable of pretty much the same things:
| HTTP/2 | WebSocket | |
|---|---|---|
| Headers | Binary + compression | Binary, lightweight |
| Content | Mostly text + compression | Binary or text |
| Multiplexed sessions | Supported | Supported |
| Direction | Client to server & server push | Bidirectional |
What HTTP/2 lacks in binary content, it provides in compression.
Assuming you needed to send messages back and forth between your server and its browser clients, you’ve probably been considering using HTTP based technologies – XHR, SSE, etc. A recent addition was WebSocket. While the other alternatives are mostly hacks and workarounds on top of HTTP, a WebSocket essentially hijacks an HTTP connection transforming it into a WebSocket – something defined specifically for the task of sending messages back and forth. It made WebSocket optimized for the task and a lot more scalable than other alternatives.
With HTTP/2, most of the restrictions that existed in HTTP that required these hacks will be gone. This opens up the opportunity for some to skip WebSockets and stay on board with HTTP based signaling.
Last year I wrote about the need for WebSockets for realtime and WebRTC use cases. I am now wondering if that is still true with HTTP/2.
Why is it important?
- BOSH, Comet, XHR, SSE – these hacks can now be considered legacy. When you try to build a new service, you should think hard before adopting them
- WebSocket is what people use today. HTTP/2 is an interesting alternative
- When architecting a solution or picking a vendor, my suggestion would be to understand what transports they use today and what’s in their short-term and mid-term roadmap. These will end up affecting the performance of your service
For a long time I kept wondering what is taking them so long for specifying WebSocket over HTTP/2-transport. Seems after HTTP/2 had been spec’d they found out, hey WebSocket doesn’t actually fit in anymore: https://webtide.com/http2-last-call/
Ohh, well, looking forward to the next step: QUIC -> (D)TLS/1.3.
Can’t do it all in one shot Lennie 🙂
Anyway, I think that HTTP/2 will be good enough for many to just skip WebSocket altogether – even when it is added to HTTP.
Judging by what I linked I doubt WebSocket will ever be part of HTTP/2. :-/
“While a websocket over http2 draft has been written, some of the features that draft referenced have subsequently been removed from HTTP/2 and the protocol is primarily focused on providing HTTP semantics.
The proposed protocol does not have a clear separation between a framing layer and the HTTP semantics that can be carried by that layer. I was expecting to see a clear multiplexed, flow controlled framing layer that could be used for many different semantics including HTTP and webSocket. Instead we have a framing protocol aimed primarily at HTTP which to quote the drafts editor:
“What we’ve actually done here is conflate some of the stream control functions with the application semantics functions in the interests of efficiency” — Martin Thomson 8/May/2014
I’m dubious there are significant efficiencies from conflating layers, but even it there are, I believe that such a design will make it much harder to carry WebSocket or other new web semantics over the http2 framing layer. HTTP semantics are hard baked into the framing so intermediaries (routers, hubs, load balancers, firewalls etc.) will be deployed that will have HTTP semantic hard wired. The only way that any future web semantic will be able to be transported over future networks will be to use the trick of pretending to be HTTP, which is exactly the kind of misuse of the underlying transport, that HTTP/2 was intended to address. I know it is difficult to generalise from one example, but today we have both HTTP and WebSocket semantics widely used on the web, so it would have been sensible to consider both examples equally when designing the next generation web framing layer.”
Note that you can run WebSocket over HTTP/2 if the client and server supports RFC 8441: datatracker.ietf.org/doc/html/rfc8441 – I think this would allow message compression and multiplexing multiple WebSocket connections into single TCP/IP stream which should reduce overhead even more.
I don’t understand what are the downfall with SSE. Is this really a hack ? Is it less performant than Websockets ?
It is a lot less performant that SSE. It is also one sided in nature.
Browser sends a request. Server sends an endless reply.
What happens if browser has another request? I needs to open another TCP connection and send his request there.
I call that a hack…
I guess the overhead of an extra ‘stream’ (not connection) in HTTP/2 or SPDY for SSE would be minimal. Wouldn’t call it a hack.
Only IE doesn’t support it:
http://caniuse.com/#feat=eventsource
And they have it in ‘Under Consideration’:
http://dev.modern.ie/platform/status/serversenteventseventsource/?search=eventsource
It’s a simple stupid protocol:
http://www.howopensource.com/2014/12/introduction-to-server-sent-events/
It seems like not that bad of a choice.
Was just looking at somthing in the HTTP/2 spec and I didn’t notice it before…
Why they didn’t make websocket work exactly like the proxy CONNECT method ? CONNECT is already part of the spec:
https://tools.ietf.org/html/rfc7540#section-8.3