WebSockets – A Conceptual Deep-Dive | Hacker News Reader

WebSockets – A Conceptual Deep-Dive

ably.io

178 pointsyannikyeo11 comments

Well written. I did a very similar deep-dive Websockets presentation at a local JavaScript user group [1]. The presentation culminated in a live demo [2] I hosted on my laptop over the local wi-fi, allowing everyone in the audience connected to the wi-fi to connect with each other in the app. Of course, it only took the audience about 2 minutes to discover some cross-site scripting vulnerabilities in my not-meant-for-production demo app, which allowed them to start showing videos and playing embedded videos on each others' computers.

[1] https://os.alfajango.com/websockets-slides/#/

[2] https://os.alfajango.com/websockets-demo/

I'd like to see a deployment deep-dive

How do you hold half a million connection open? How do you handle graceful failover?

How to design a such effecient server side architecture.

A simple nginx+roundrobin is not enough.

Interesting I recently implemented a websocket subset for a server in C from scratch for a hobby project and everything seem to check out.

The author mentioned mqtt and wamp. Has anybody here have any experience of using these?

It might be interesting to know that I'm doing user input from the browser, which makes latency a high priority. To get to the APIs that I can't access via the browser I have a C server relying on these messages to the server.

I used WAMP extensively in a desktop app a few years ago.

Ironically, we only used it only for IPC, not communication to a remote web service. Why?

* It provided "routed RPC", which made IPC between many heterogeneous desktop apps easy (a service, a tray icon process, main UI process, a couple of others etc).

* It supports PubSub as well as RPC.

* It works over TCP, rather than e.g. unix domain sockets, which means it's portable and interoperable (I didn't use the WebSocket transport because the library I used supported raw TCP, but you can mix and match). We bound to loopback.

* Because it was built for JavaScript, it was all dynamic, which meant no code generation. The only viable alternatives, and their dependencies, were going to be a pita to build and integrate in to our build system on all 3 major platforms and were going to result in terrible code.

* The protocol is JSON which made debugging issues very easy.

Thank you your comment have been very helpful! Especially the PubSub part as I'm not that interested in RPC actually.

Wamp user here. Config sucks, but usage rocks. Very versatile yet easy to use. No auto reconnect with asyncio though, and no django integration, so i had to code that part.

It seems like a glaring omission that this doesn't discuss the compatibility issues using websockets with HTTP/2, RFC8441 and Websockets vs SSE... Maybe this is an older article?

Do you have any resources that go into this? I'm interested in learning more.

There's actually not too much to it:

Websockets and HTTP/2 have not much to do with each other. Both are established on top of a TCP connection (which might have been used to speak HTTP/1.1 before, until an upgrade occurred). Websockets allow sending unsolicited websocket frames in both directions, HTTP/2 multiplexes several HTTP streams on top of a single TCP stream.

There is no websockets over HTTP/2 specification- at least the last time I had looked. It wouldn't really yield much benefit, one would just have the 2 layers of framing (web socket framing on top of HTTP/2 framing). With the current approach one would typically just have 2 TCP connections established from a browser to servers, if websockets are needed: One for websockets, and one for HTTP[/2].

Regarding SSE: Use it when single directional communication is good enough, when HTTP based authentication is required, for integration with other HTTP infrastructure (load balancing, proxies, etc), or when no websocket library is available. Websockets might be mostly preferable when stateful "realtime" communication in both directions is required.

The kicker is if a client connects to you via HTTP/2, you can't upgrade/hijack that session to be a websocket stream since the underlying TCP connection could be being shared by(used to multiplex) multiple HTTP requests/sessions. You have to take care to make sure the request ingress path from the client to the app is HTTP/1.1 end to end. That is something that is getting harder to do. Browsers use H/2 by default, more and more CDN do, more and more middle-ware does etc. The draft RFC I mentioned is a websocket upgrade mechanism for HTTP/2.

I don't see an issue. If a browser wants to create a websocket connection, it will always create a fresh connection and do a HTTP/1.1 upgrade. Because that's the only way how websockets are specified.

On the server side most things are handled in the low-level HTTP handlers. There (e.g. in Netty/Jetty and Co) one needs to care about ALPN negotiation, websocket upgrades and Co. But higher up (J2EE, express, etc) things are mostly about HTTP semantics, and there isn't any handling about "upgrade" or even the "Connection" field in general anymore.

Yes, the line between HTTP application semantics and HTTP/1.1 transport is very thing and nobody exactly knows where things start and end. But I'm still not convinced we need web sockets over HTTP/2, e.g. in order to allow upgrades in the application layer.

Reply on news.ycombinator.com