
WebSockets – A Conceptual Deep-Dive - yannikyeo
https://www.ably.io/concepts/websockets
======
JangoSteve
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/#/](https://os.alfajango.com/websockets-slides/#/)

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

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

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

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

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

------
voidlogic
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?

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

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

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

~~~
Matthias247
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
upgrades in the application layer.

