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.

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

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.

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…

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.”

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.

Ohh, well, looking forward to the next step: QUIC -> (D)TLS/1.3.