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:
|Headers||Binary + compression||Binary, lightweight|
|Content||Mostly text + compression||Binary or text|
|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