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.

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.

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