> WebSocket at the transport layer because it adds explicit framing support and other things.
Websockets also have frames, binary or text.
Websockets also have frames, binary or text.
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...
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.
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.