Hacker News Reader

Comment by rdtsc | Hacker News Reader

There seems to be a semantic overlap between streaming data with HTTP/2 vs streaming websocket frames back and forth.

Does this have a distinct advantage over websockets, does it supersede it or is completely different?

To put it another way, could gRPC have worked via websockets (or maybe some long-polling fallback mode).

HTTP2 is superior to WebSocket at the transport layer because it adds explicit framing support and other things. Websocket-over-HTTP2 is coming, but it's not here now.

While HTTP/1.1 was a poor transport for high-perf RPC there are many parts of it that make sense semantically (headers, trailers, mime-types, virtual-hosting, content-encoding specification etc). HTTP2 lets you continue to use those in a form everyone is familiar with, with Websocket you would have to invent them again.

> WebSocket at the transport layer because it adds explicit framing support and other things.

Websockets also have frames, binary or text.

Websocket does framing at the application layer, not the transport layer. Its probably more accurate to say that websocket lets you send binary or text messages.

More specifically this means that multiple WebSockets are not multiplexed over a single TCP/IP socket. One physical connection per-Websocket is a real scalability issue for servers and proxies.

WebSocket-over-HTTP would address that. See the options being discussed here http://tools.ietf.org/html/draft-hirano-httpbis-websocket-ov...

I don't think you would lose much in real world applications with the way websockets work:

You want to multiplex websockets (for RPC) with normal HTTP requests -> Works through different URLs.

If you want to multiplex different websocket RPC services on a single websocket endpoint it's easy to do this on application level with some kind of service identifiers. You will probably want those anyway for some purposes - even if your transport layer also provides multiplexing.

Want to multiplex different websocket connections -> Works through different URLs. Yes, each will require a seperate IP connection. However I don't see a lot of applications that will go and utilize this scenario. They will either use gRpc OR WAMP OR SignalR OR etc, because that will make the maintainability much better then with a very mixed technology stack.

Multiplexing RPCs onto a single WebSocket has some serious downsides. For one you now have an entirely custom protocol that standard proxies will not understand and cannot route. GRPC is very careful to be valid HTTP/2 for this reason.

One of the major reasons for the existence of WebSocket is to support duplex streaming. HTTP/2 explicitly states

"A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received"

With better HTTP APIs (particularly in the browser) you would get full-duplex and the need for WebSocket would diminsh.

Presuming you've done the research here: will Websocket-over-HTTP2 make websockets cheaper, to the point that e.g. it'd be performant to use individual websockets for each channel of a pub-sub system, rather than multiplexing them all over a single channel that is statefully subscribed on the server?

Or, now that I think of it, would the modern recommendation for this lean more toward opening multiple parallel Server-Sent-Events streams, with each channel being its own HTTP resource? That seems more idiomatic, at least.

That is certainly a goal for Websocket-over-HTTP2, though in truth it would be no cheaper than long-poll-over-HTTP2 and more expensive if you invented your own metadata mechanism rather than using HTTP2 headers. And as you say, less idiomatic.

Using separately addressable resources and having HTTP2 do the connection multiplexing for you seems like a good pattern to me.

Does HTTP2 have guarantees that the connection is really reused for multiple requests or could a user agent (or HTTP library) silently use multiple connections for different requests?

I think this makes a major difference for RPC applications, because with a single connection you have a guarantee that all messages will be retrieved in the same order that they were sent.

E.g. with a persistent websocket connection I have the guarantee that all messages will be in order. With mulitple HTTP/1.1 requests I don't have it. Don't know about HTTP/2.

And of course the requirements about such a thing depend on how you design your RPC API (stateless or not).

HTTP/2 has the concept of streams. Each stream is independent, but within a stream data and headers are ordered. Each HTTP request would be on a new stream.

gRPC maps calls to streams so calls can proceed at different rates, but you still receive the information on a particular call in order. So conceptually each call is completely separate, but we can use a single HTTP/2 connection for all the calls to a particular destination.

HTTP/2 gives you more than just a stream of frames (matching of requests to responses, some structure around headers and bodies, flow control, etc). gRPC could have been built on websockets but it would have been more work (almost as much work as building on plain TCP sockets - websockets add very little except the ability to work from a browser)

You are correct in assuming that, technically, gRPC could be built on top of WebSockets. Building directly over HTTP/2 allows for a leaner protocol stack.

I like to think of it the other way 'round: WebSockets can now be thought of as merely a weird polyfill for when you want to use HTTP streaming to emulate a stateful protocol. For anything else, just use plain HTTP/2.

Reply on news.ycombinator.com