5 ms·

WebSockets – A Conceptual Deep-Dive

178 points by yannikyeo 8y ago

JangoSteve 8y ago
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/
rijoja 8y ago
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 8y ago
  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 8y ago
    Thank you your comment have been very helpful! Especially the PubSub part as I'm not that interested in RPC actually.
- sametmax 8y ago
  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.
voidlogic 8y ago
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 8y ago
  Do you have any resources that go into this? I'm interested in learning more.
  - Matthias247 8y ago
    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 8y ago
      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.
est 8y ago
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.

178 points by yannikyeo 8y ago

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/

rijoja 8y ago

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 8y ago
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 8y ago
  Thank you your comment have been very helpful! Especially the PubSub part as I'm not that interested in RPC actually.
sametmax 8y ago
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.

voidlogic 8y ago

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 8y ago
Do you have any resources that go into this? I'm interested in learning more.
- Matthias247 8y ago
  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 8y ago
    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.

est 8y ago

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.