24 ms·

WebSockets: caution required

216 points by strzalek 11y ago

k__ 11y ago
Aren't full duplex connections normal outside of the web? I mean, this isn't really a new kind of tech. It reads a bit like someone who rode horse his whole life and found out that there are cars and now fears about all the dangers they could bring.
- shurcooL 11y ago
  The difference is in scale. Full duplex connections are powerful and heavyweight. When there's one per page visitor, it can be overwhelming for your servers. Cars are fine on the highway. But not inside a house.
  - spoiler 11y ago
    This is a very nice analogy! I might borrow that in the future. :-) It got me thinking: it's quite easy to come up with effective car/garage/road analogies.
  - nly 11y ago
    Horses aren't great in houses either. (Unfortunately, this is still a perfect analogy for HTTP.)
mchahn 11y ago
I've used websockets in several projects now. They are more problematic than I originally thought they would be. On my current project I'm using server-sent-events (SSE) for single-duplex pushing to the client. I'm using AJAX calls for the other direction. So far the experience has been awesome. Very light-weight and performant. Just a dozen lines of code on the client with no framework. Caveat: Doesn't work with IE. A polyfill is required. I am very lucky on this project that I don't need to support IE.
- xjia 11y ago
  So what were the problems you've encountered?
  - mchahn 11y ago
    See the article (grin). It was mostly due to connection problems. I had to add yet another layer on top of the frameworks I used. Also I effectively had three channels. The two in the websockets and the ajax which I needed for historical reasons. Just an overall feeling of heavy weight compared to the very light SSE.
    - xjia 11y ago
      I see.. Do you think it would be better for a project starting from scratch? i.e. without that two "old" channels
      - mchahn 11y ago
        > Do you think it would be better for a project starting from scratch? At this moment, yes. Now that I know you can use SSE with any browser, I'm not sure what advantage there is with websockets. Maybe someone can explain.
- nailer 11y ago
  +1 HTML5 SSE. They fit in with REST, aren't an extra protocol, and are way easier to debug when compared to websockets. An important addition to your recommendations: make sure you disable gzip on the SSE route, or at least flush the gzip otherwise it won't send.
  - tehbeard 11y ago
    Why do I have the feeling this is why I encountered weird delays with data when we tried SSE.
    - 11y ago
mchahn 11y ago
I've used websockets in several projects now. They are more problematic than I originally thought they would be. On my current project I'm using server-sent-events (SSE) for single-duplex pushing to the client. I'm using AJAX calls for the other direction. So far the experience has been awesome. Very light-weight and performant. Just a dozen lines of code on the client with no framework. Caveat: Doesn't work with IE. A polyfill is required. I am very lucky on this project that I don't need to support IE.
Matthias247 11y ago
As a quite heavy user of websockets, and having done a few implementations of them, I agree only partly with it: Yes, Websockets are hard to implement, and most implementations that are floating around (e.g. on github are horribly broken). But the same probably applies to good HTTP and especially HTTP/2 implementations too! I also totally agree that web sockets make load balancing and proxying more complicated than stateless HTTP requests. But I still think that Websockets have their place. They are some kind of more basic building block (like TCP), on which you can build your own protocol with totally different semantics. If you only build some request/response protocol on top of it you probably have not gained much - but still it would be different from HTTP in the way that message ordering is guaranteed. If you only need events from the server to the client you could use SSE, but if you need to add some dynamic subscribe/unsubscribe functionality you would need some additional HTTP [POST] calls. You could get the idea that you use one SSE endpoint per topic and treat the stream disconnect as an unsubscribe, but as long as you can't rule out that you have any non HTTP/2 clients it won't work because of the connection limit in browsers. I also benchmarked that approach with node and golang http/2 against my websocket based protocol and achieved only a throughput of about 10% of the websocket based solution. All in all I currently think that currently one should favor pure HTTP if scaling is a big issue and if most state is anyway persisted in some distributed databases. If only a single server is the remote peer, the state is not necessarily persisted per client, a combination of RPC and event distribution semantics is needed, message ordering guarantees are necessary or high realtime characteristics are needed then websockets are a very powerful option seriously needs to be considered. My personal use-case is forwarding data from automotive realtime bus systems into web-based user interfaces and I had great success with using websockets to achieve this. Although I'm still also looking into HTTP/2, because it really has some interesting properties. One other thing I would like to add: One comment in the article mentions to always prefer websocket frameworks like socket.io or signalR. What you should take into account is that by using one of those frameworks you are also binding yourself to a specific technology stack (node, C#, ...), if you are not willing to reimplement the protocols. If you use your own well-specified protocol or another well-specified higher level protocol (like WAMP), then you are not bound to specific technologies for your client and server applications. Therefore I always opt to go that way if long maintenance, open APIs or good interoperability are desired.
andyhoff 11y ago
WebSockets are a tool like any other and as usual, picking the wrong tool for the job is a great way to shoot yourself in the foot. Agree with the author that they aren't suited to replace HTTP but I don't see the need for this apocalyptic tone. WebSockets have been available in many tech stacks for a while now and we don't see much abuse. Developers disciplined enough to stick to Rails don't seem overly prone to jump on the new shiny toy without thinking. Web Sockets are great to bring some of the more heavy duty apps from Desktop/TCP to the web. PubNub, Pusher and the likes show it is possible to achieve reasonable scale.
atemerev 11y ago
I disagree. I am currently all in for Websocket in web apps. HTTP is only used for static resources and scripts loading. In all webapps, there are buttons. In some cases, clicking a button requires an action on the server, and therefore a roundtrip. If Websocket connection is established (you don't need more than one for everything), there is no overhead. With HTTP, you need to build a request every time. Websocket plays nice with modern reactive streaming architectures. You send stream of events, you receive stream of updates. Everything is transparent and immutable and asynchronous. If there is a connection loss, you are immediately notified and can move your app to offline mode. This is problematic with HTTP. Websocket enable web apps comparable with native apps. HTTP apps will always feel less responsive to user actions.
- rahimnathwani 11y ago
  Would you mind sharing details of your preferred stack(s)?
  - atemerev 11y ago
    React or Riot.js on the frontend, Scala/Akka on the backend, Sockoweb as the dedicated WS server.
    - gkfasdfasdf 11y ago
      I'm just curious, why did you use sockoweb instead of spray.io ? We have similar needs for a webserver that supports websockets and akka - spray.io seems like it would fit the bill.
      - atemerev 11y ago
        A little too overengineered for my taste. I tried akka-http which is essentially Spray 2.0 and succeeded, but with twice the amount of code that I had with Sockoweb.
jzwinck 11y ago
The complaint that the server side of web sockets requires using epoll is strange. Of course we have known for years that select has scalability problems, but we have moved on. That this implementer says they normally use select in 2015 for networked services is worrying. If using epoll and kqueue directly is not your cup of tea, just use libuv or one of the other wrappers. It's not hard then. I know because I'm a native epoll user but recently helped someone on Stack Overflow and it took me maybe fifteen minutes to write a working libuv server having never used libuv before.
wolframhempel 11y ago
Arguing that "WebSockets are bad, because the principals we use for HTTP scalability are not applicable to them" is not wrong, but feels short sighted. Yes: Scaling numerous persistent connections is hard, seeing that most of the available infrastructure is geared towards short-lived HTTP request/response requirements. But there are realtime specific alternatives. You wouldn't want to build your realtime backend from scratch, but rather use something like http://deepstream.io http://deepstream.io which takes care of the heavy lifting.
legulere 11y ago
Similarly to WebGL it will become just another technology that gets abused. Safari has an option to ask before enabling WebGL for a website. I had to turn it off after a while because basically every website was asking for WebGL. I don't mean websites with fancy 3D graphics or even 2D graphics like Google Maps. It's normal news websites that just show text and maybe some pictures.
- JoshTriplett 11y ago
  > I had to turn it off after a while because basically every website was asking for WebGL. I think part of that comes from frameworks like modernizr probing for WebGL, without actually using it.
Maarten88 11y ago
I'm also a heavy websocket user, and agree with most points. I have previously used websockets on top of a traditional web app, and have been disappointed with the results. My opinion now is that websockets are an all-or-nothing proposition. And I have gone all-in. My latest project has: - websockets-only api (except a some image uploads and oauth/login) - https-only - single page app, central store with observable data, using a single connection servicing the whole application - using SignalR (supports fallbacks for IE9 and old Android) - Actor-based backend (Orleans) This stack feels like the future to me, but I've had to learn a lot of new things. It's quite different from the web development that I've done over the past 15 years. Overcoming the connectivity issues mentioned in the article is only the first step. Websockets need another type of backend to make sense: Actors. I've had many challenges with the async realtime behaviour of the system, deadlocks, etc. But now that everything is working and I have some grip on it, I can't imagine going back to a rest/database/cache web architecture.
- skrebbel 11y ago
  > My opinion now is that websockets are an all-or-nothing proposition. Interesting. Why? Why can't you get some not-so-realtime data via a classic REST API?
  - Maarten88 11y ago
    Of course you can mix two styles, but it makes little sense as websockets does all the things REST can do, only faster and with state on the server. Clientside there is little difference between $.ajax(api, data) and conn.send(api, data). And it's just nicer to keep the api together serverside in (in my case) one SignalR controller instead of putting some parts in a Nancy module. I do have some REST endpoints, i.e. for image upload and oauth, I did not know how to make that work otherwise on IE9.
- orf 11y ago
  > My latest project has... Taken you a long time to get started. What does it do? I hope the time investment is worth it and you're not trying to make a blog or some CRUD app.
spoiler 11y ago
It feels to me like the author used WebSockets for the wrong thing. I don't think WebSockets belong on a website (even an interactive one as discourse, it is still a website based on my criteria). They'd be more apt in web applications. So, to me it feels like the 1-connection-per-tab feels like saying "someone launched 50 instances of an executable and it opened 50 TCP connections". Examples of where I think it's acceptable/recommended to use Web Sockets include /(video|audio)?/ chats, multiplayer games, collaboration tools, etc. Stuff that requires real-time notifications. Does a discussion platform require that time precision? I doubt it (frankly, I think WebSockets would give a too high "temporal resolution" unless there were proper delays in place which just complicates the implementation, but that is actually irrelevant here).
- endriju 11y ago
  I don't think WebSockets belong on a website (even an interactive one as discourse... From the article "Discourse does not use WebSockets. Discourse docker ships with HTTP/2 templates." The whole article is worth reading. It looks like the author is well aware the WebSockets limitations.
  - ronjouch 11y ago
    The author is indeed well aware of WebSockets limitations, and OP's "Examples of where it's acceptable/recommended to use WebSockets" seem sound. The problem is that the appeal of oooh-shiny is so strong that some (many?) developers and influencers do end up "using WebSockets for the wrong thing". Last case I met: a tutorial for a client+server js app using React & Redux [1], building... a CRUD voting application. Quoting the article on why choosing WebSockets for this, "This is an app that benefits from real-time communication, since it's fun for voters to see their own actions and those of others immediately when they occur. For that reason, we're going to use WebSockets to communicate." Well yes, WebSockets work here (modulo problems and missed benefits/tooling that are the whole point of this article), and socket.io seems like a nice library, but a good old long poll would have done just as well :) [1] http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial...
fideloper 11y ago
Summary of comments here seem to suggest that those with more extensive experience with them agree and see issues with websockets. Those still in favor / find themselves disagreeing, while not necessarily always saying explicitly, seem to be those just starting out on their websocket journey. At least, that's how it seems to me.
- jaegerpicker 11y ago
  I'd disagree with that. I have a lot of experience with web sockets and I'd say the blog post is short sighted in a bunch of ways. Having done a large amount of TCP socket programming in other environments outside of web apps, I don't really have the same issues with debugging that other seem to complain about.
  - fideloper 11y ago
    Cool, you have more experience than most I'd gather. Sounds like info that should be shared :D
bradgessler 11y ago
I agree with most of the points in this essay. I wrote http://firehose.io/ http://firehose.io/ a few years ago for Poll Everywhere and we've successfully scaled WebSockets in a production environment. We don't use it for 2-way communications though; it's HTTP requests in and WebSocket pushes out with long-polling as a backup for non-WS clients. Check out the sourcecode if you want to see an implementation of all the "hard lesions won" in this essay. I also gave a talk about it at RailsConf (http://www.bradgessler.com/talks/streaming-rest/ http://www.bradgessler.com/talks/streaming-rest/) and learned that RabbitMQ as a backend isn't a great idea. Feel free to ask questions if you want me to dive into more specific points.
- bphogan 11y ago
  I have a question - if you're only using sockets for push, why not use SSE instead? Or did you encounter serious issues with that?
  - jessaustin 11y ago
    I've had good results with SSE in just the situation that GP describes: client actions come in as POSTs and the results of those are communicated to everyone via SSE. In most cases we don't even care about the 204 or whatever. If it's not on SSE then it didn't happen. b^)
  - bradgessler 11y ago
    SSE is fine except stupid Internet Explorer doesn't support it: http://caniuse.com/#feat=eventsource http://caniuse.com/#feat=eventsource A goal of Firehose is to have the fewest number of transports possible so the client doesn't have to spend much time negotiating the transport. I found WebSockets was more widely supported (http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets) and HTTP long polling could take care of the rest. Before I built Firehose I looked at socket.io, which had a ton of transports, but found that it was too slow, flakey, and unpredictable for our needs.
- boggzPit 11y ago
  Why was RabbitMQ not great as a backend? I am curious because we use it for a not launched chat application (+websockets) currently and we are not sure if it will hold big amounts of users.
amelius 11y ago
FYI, there is a bug in Chrome that causes WebSockets to be slow [1]. For small messages, the transfer rate seems to be sufficient in most cases. But for larger messages (say, uploads), don't place your bets on WebSockets just yet. [1] https://productforums.google.com/forum/#!msg/chrome/-NVlnMqx6Xg/Z0nMvWZ6IyYJ https://productforums.google.com/forum/#!msg/chrome/-NVlnMqx...
- orf 11y ago
  Why would you want to upload a file through websockets anyway?
  - geocar 11y ago
    I made an upload tool that needed to handle very large files, and I used WebSockets to do it. The strategy I used was to parse the MOV/MP4 locally, consider between 2-60 frames of data, hash it, then stream up the hashes to the server. Any hash the server didn't have got a reply to push those bytes. The two-way nature of this dialog made WebSockets a good fit, although it certainly could have been emulated using other methods, it would have been much more code.
    - Bognar 11y ago
      It seems like it wouldn't be much more code to just use an AJAX POST for the hash and have the server reply whether it has the hash or not, followed by the chunk upload again over AJAX. It would probably be slower and less data efficient, but I don't see how it would be much more code.
      - amelius 11y ago
        Perhaps it would require more code to get it equally fast and data efficient :)
      - geocar 11y ago
        The whole point of uploading a file this way is that it is more data efficient and faster in my use case. That means that slowness is a bug; inefficiency is a bug. For what reason would you put bugs in your code on purpose? We also probably have different ideas about how much "much" is.
mstade 11y ago
This is a good article, albeit a bit long-winded. In my experience, whether or not WS can be beneficial essentially comes down to whether or not you truly need low latency duplex communication. A chat application, which seems to be the canonical WS example, probably doesn't; a twitch-style multiplayer game, probably does. Server-sent events are a great tool for streaming server-to-client data where other more specific media types (i.e. audio/video) doesn't fit the bill.
- andybak 11y ago
  Shame about IE - even Edge is red: http://caniuse.com/#feat=eventsource http://caniuse.com/#feat=eventsource
  - mstade 11y ago
    Indeed, but thankfully it's easily polyfilled.
xorcist 11y ago
If you deploy websockets in your application, either make your application can use some fallback like long polling or make sure you don't have any enterprise customers. They tend to have pesky proxies that mess with traffic. Sometimes websockets simply doesn't work, but sometimes they initialize correctly but no data passes through(!). It's a mess.
mmaunder 11y ago
Jeez web sockets really aren't that hard. We've used them for a long time on our production site for a live attack map: https://www.wordfence.com/ https://www.wordfence.com/ and we regularly have over 1000 concurrent visitors on the site when we promote a blog post or do something similar. I can't think of any reason why I wouldn't use node.js on the server-side for web sockets. It obviously uses epoll() and you really need an event language to be comfortable writing an application that manages a large number of concurrent connections. Ruby for this makes me shudder - sorry it just feels like a square peg forced into a round hole that's late to the party.
- icebraining 11y ago
  I'm hardly a Ruby fan - nothing against it, I just prefer Python - but what makes it such a bad choice vis-a-vis JavaScript? Sure, Rails isn't built with this in mind, but why would Ruby with some kind of libuv-based framework be such a terrible choice?
  - cdelsolar 11y ago
    It's not meant for it. Python is similar, there are hacks (such as eventlet) that have their own downsides. Use the right tool for the job. We are currently rewriting an eventlet-based part of our stack in Go with much better results.
    - rubiquity 11y ago
      You might want to read or watch this presentation before doing that: https://docs.google.com/presentation/d/1LO_WI3N-3p2Wp9PDWyv5B6EGFZ8XTOTNJ7Hd40WOUHo https://docs.google.com/presentation/d/1LO_WI3N-3p2Wp9PDWyv5... Mozilla went from Python to Go and then back again for reasons I think you would also run into.
    - icebraining 11y ago
      Yeah, I can see how Go has some built-in advantages over Ruby and Python in this regard, but I was really looking to understand why mmaunder considers JavaScript a much better choice than Ruby.
et1337 11y ago
1. Ditch Ruby. Node or Python with asyncio work fantastic with WebSockets. Use a greenlet-enabled database connection pool. 2. Use HTTP for traditional request/response tasks. Use WebSockets to push realtime notifications to clients. 3. Have your clients auto-retry their WebSocket connections in the background. Show an indicator of degraded service when this happens. When a new WebSocket connects, blast a complete state update to it to take care of any missed messages. Now you can easily load-balance your clients. (my two cents, YMMV, etc.)
- jkarneges 11y ago
  We created a WebSocket client wrapper library to make your third point easier to deal with. It handles only the connection freshness judo and nothing else, and doesn't require a special server or anything. Maybe people here find it interesting: https://github.com/fanout/websockhop https://github.com/fanout/websockhop
  - matt2000 11y ago
    I've just started using this too, not much real world experience but in case it's useful to someone: https://github.com/joewalnes/reconnecting-websocket https://github.com/joewalnes/reconnecting-websocket
- Dr_tldr 11y ago
  Yes, yes, and yes, you nailed it. The author of the article seems to have difficulty separating "problems specific to WebSockets" and "specific problems I have." People who say "REST is dead, AJAX is dead, HTTP headers are dead, all hail the new sockets" are wide-eyed fanatics and this article is a useful corrective to them, but it's definitely not an even-handed analysis. There are too many problems with the article to do a line-by-line rebuttal, but the one that was most silly for me was "what if a user has multiple tabs open, oh noes!" It's trivial to implement a session id then disconnect the inactive tab(s), and has been for a long time. On the other hand, his recommendations in the comments are pretty solid, so he's not completely off...
- shams93 11y ago
colmmacc 11y ago
Not mentioned is a common pitfall with serving web sockets: it is very easy to end up in a situation where you may not recover from disruptions. The problem is that establishing a web socket, especially when using SPDY or HTTPS (which is typical), is much more expensive than maintaining a connected one. So a service will typically see a steady creep up in the number of connections, with a relatively low number of new connections per second, and it's probably been tuned for massive levels of concurrency, and that's all manageable. But then the service has a blip of some kind all of a sudden all of those web socket clients try to connect at the same time; disaster. At that point the service is incredibly overloaded, so many connections fail, which results in retries, which makes matters even worse still and fuels a vicious cycle. That situation might self-stabilize if browsers implemented exponential back off, but that's not typical either. So the service remains hosed until some kind of blood letting can be done to let clients back in at a manageable rate. Extremely pernicious, and something I've seen several times. When scaling web-sockets, it's important to ask: can I handle all of these clients reconnecting at the same time?
- clarkmoody 11y ago
  > browsers implemented exponential back off Browsers do not have any native reconnect behavior for WebSockets. You have to implement reconnect in your application, which usually means exponential falloff. There are a few open-source implementations of this very feature. Since you control the reconnect behavior, you could have clients wait a random amount of time from 1-5s before attempting the first connection. That way your reconnect storm is spread uniformly over a broader time frame.
- CyberDildonics 11y ago
  Sounds like web programming might end up becoming closer to real programming.
- Can_Not 11y ago
  Is there a formal term for this websocket reconnect stampede? What serverside stack and language were you using? What clientside language and libraries? How many users were active and how many CPU cores were dedicated to the websockets? Were you load balancing with or without sticky sessions? Was your websockets a public broadcast or did you do authentication checks for rooms/channels? Have you considered doing a formal writeup over this pitfal and how it was resolved for your project?
ashearer 11y ago
I agree with the approach indicated by the title ("caution required"), but the tone of the article veers toward being alarmist. Takedown articles tend to share similar characteristics. Many are on a mission that emphasizes the negatives of their subject, even minor ones, while overlooking the positives and handwaving away problems with the alternatives. They set the bar higher for the subject by finding issues that it shares equally with its alternatives, and presenting them as damning evidence against it (since users may expect it to be better and be disappointed). The specific alternative that's held up as superior to the subject varies from point to point--no one alternative is actually superior in all points. They may even acknowledge that many of their arguments are weak, but make up for it in volume. In its favor compared to such articles, this one does make some attempts to be evenhanded, but they're overpowered by the dramatic language used to make the opposing points. (For example, the brief acknowledgement that point 1 is the "weakest argument against WebSockets" is surrounded by phrases like "wreak havoc", "weird stuff will definitely happen", "rogue proxies will break you"). This article puts itself squarely in the category of "the case against". A more balanced article might discuss: 1. The situations where you might want to avoid WebSockets (no HTTPS, IE 8 & 9 compatibility, a server platform without good support, or where they don't provide actual usability benefits). 2. Pitfalls that both long-polling and WebSockets share (you have to handle reconnections and synchronize state, be mindful of the open connections when reconfiguring a load balancer, account for server load, and use a server platform with good support for long connections). 3. Differences that can be viewed just as reasonably in WebSockets' favor, which the article counts as negatives. Example 1: Resynchronizing state after a network interruption is necessary with both long-polling and WebSockets, though the article notes it as a WebSockets disadvantage. The reconnection process is explicit with WebSockets, but some long-polling libraries make it very easy to ignore these events, leaving the client out of sync. Example 2: WebSockets aren't limited to 6 connections, unlike long-polling, so you won't get a silent connectivity roadblock on some tabs when the user has several of them open. 4. Advantages unique to WebSockets: responsiveness is improved due to not needing to send HTTP headers with every request and response, and the underlying TCP connection is already warmed up; load balancing and redundancy may be simplified by no longer requiring a session affinity mechanism (because the connection itself preserves short-term state, which can be re-established by the client transparently to the user in the rarer event of reconnection); less overhead than long-polling; a whole class of problems resulting from cookies as the sole mechanism of state transfer is avoided; the same protocol can be implemented simply and efficiently by native mobile apps.
jkarneges 11y ago
If you're interested in implementing reliable long-polling as described in the article, you might check out Pushpin (http://pushpin.org http://pushpin.org). It's a proxy server that you put in front of your API backend and it makes this sort of thing really easy. Pushpin also supports WebSockets, but the long-polling capability is first class and not an afterthought.
warfangle 11y ago
Probably difficult to do in a non-event-driven non-asynchronous environment where every i/o blocks like Ruby............
Rauchg 11y ago
Most of this gotchas (and others not mentioned) can be avoided if you treat WebSocket for what it is: a low-level transport that can be swapped out. This is how we treat it in Socket.IO and Engine.IO. Most people that implement WebSocket directly end up re-inventing a protocol on top of it. This is necessary because the "onmessage" handler of WS is not something you can really build an application on. And then you'll have to add reconnection and exponential delays after that. If you just want to use HTTP polling, which as the author suggests is perfect for most applications (perhaps not games), you can simply do: `io('http://myhost' http://myhost', { transports: ['xhr-polling'] })`.
iamleppert 11y ago
Can't stand the cargo cult thinking/writing here. The author seems to think websockets are dangerous like handling a piece of glass. It's a technology like anything else. See if it meets your requirements, if it does, great, go for it and learn along the way. If not, stick to regular connections. Case closed.
geoffroy 11y ago
A very good article comparing SSE, Websockets, polling, long polling was posted a few months ago, still relevant : https://www.nateberkopec.com/2015/09/30/action-cable.html https://www.nateberkopec.com/2015/09/30/action-cable.html

216 points by strzalek 11y ago

k__ 11y ago

Aren't full duplex connections normal outside of the web? I mean, this isn't really a new kind of tech. It reads a bit like someone who rode horse his whole life and found out that there are cars and now fears about all the dangers they could bring.

shurcooL 11y ago
The difference is in scale. Full duplex connections are powerful and heavyweight. When there's one per page visitor, it can be overwhelming for your servers. Cars are fine on the highway. But not inside a house.
- spoiler 11y ago
  This is a very nice analogy! I might borrow that in the future. :-) It got me thinking: it's quite easy to come up with effective car/garage/road analogies.
- nly 11y ago
  Horses aren't great in houses either. (Unfortunately, this is still a perfect analogy for HTTP.)

mchahn 11y ago

I've used websockets in several projects now. They are more problematic than I originally thought they would be. On my current project I'm using server-sent-events (SSE) for single-duplex pushing to the client. I'm using AJAX calls for the other direction. So far the experience has been awesome. Very light-weight and performant. Just a dozen lines of code on the client with no framework. Caveat: Doesn't work with IE. A polyfill is required. I am very lucky on this project that I don't need to support IE.

xjia 11y ago
So what were the problems you've encountered?
- mchahn 11y ago
  See the article (grin). It was mostly due to connection problems. I had to add yet another layer on top of the frameworks I used. Also I effectively had three channels. The two in the websockets and the ajax which I needed for historical reasons. Just an overall feeling of heavy weight compared to the very light SSE.
  - xjia 11y ago
    I see.. Do you think it would be better for a project starting from scratch? i.e. without that two "old" channels
    - mchahn 11y ago
      > Do you think it would be better for a project starting from scratch? At this moment, yes. Now that I know you can use SSE with any browser, I'm not sure what advantage there is with websockets. Maybe someone can explain.
nailer 11y ago
+1 HTML5 SSE. They fit in with REST, aren't an extra protocol, and are way easier to debug when compared to websockets. An important addition to your recommendations: make sure you disable gzip on the SSE route, or at least flush the gzip otherwise it won't send.
- tehbeard 11y ago
  Why do I have the feeling this is why I encountered weird delays with data when we tried SSE.
  - 11y ago

mchahn 11y ago

Matthias247 11y ago

As a quite heavy user of websockets, and having done a few implementations of them, I agree only partly with it: Yes, Websockets are hard to implement, and most implementations that are floating around (e.g. on github are horribly broken). But the same probably applies to good HTTP and especially HTTP/2 implementations too! I also totally agree that web sockets make load balancing and proxying more complicated than stateless HTTP requests. But I still think that Websockets have their place. They are some kind of more basic building block (like TCP), on which you can build your own protocol with totally different semantics. If you only build some request/response protocol on top of it you probably have not gained much - but still it would be different from HTTP in the way that message ordering is guaranteed. If you only need events from the server to the client you could use SSE, but if you need to add some dynamic subscribe/unsubscribe functionality you would need some additional HTTP [POST] calls. You could get the idea that you use one SSE endpoint per topic and treat the stream disconnect as an unsubscribe, but as long as you can't rule out that you have any non HTTP/2 clients it won't work because of the connection limit in browsers. I also benchmarked that approach with node and golang http/2 against my websocket based protocol and achieved only a throughput of about 10% of the websocket based solution. All in all I currently think that currently one should favor pure HTTP if scaling is a big issue and if most state is anyway persisted in some distributed databases. If only a single server is the remote peer, the state is not necessarily persisted per client, a combination of RPC and event distribution semantics is needed, message ordering guarantees are necessary or high realtime characteristics are needed then websockets are a very powerful option seriously needs to be considered. My personal use-case is forwarding data from automotive realtime bus systems into web-based user interfaces and I had great success with using websockets to achieve this. Although I'm still also looking into HTTP/2, because it really has some interesting properties. One other thing I would like to add: One comment in the article mentions to always prefer websocket frameworks like socket.io or signalR. What you should take into account is that by using one of those frameworks you are also binding yourself to a specific technology stack (node, C#, ...), if you are not willing to reimplement the protocols. If you use your own well-specified protocol or another well-specified higher level protocol (like WAMP), then you are not bound to specific technologies for your client and server applications. Therefore I always opt to go that way if long maintenance, open APIs or good interoperability are desired.

andyhoff 11y ago

WebSockets are a tool like any other and as usual, picking the wrong tool for the job is a great way to shoot yourself in the foot. Agree with the author that they aren't suited to replace HTTP but I don't see the need for this apocalyptic tone. WebSockets have been available in many tech stacks for a while now and we don't see much abuse. Developers disciplined enough to stick to Rails don't seem overly prone to jump on the new shiny toy without thinking. Web Sockets are great to bring some of the more heavy duty apps from Desktop/TCP to the web. PubNub, Pusher and the likes show it is possible to achieve reasonable scale.

atemerev 11y ago

I disagree. I am currently all in for Websocket in web apps. HTTP is only used for static resources and scripts loading. In all webapps, there are buttons. In some cases, clicking a button requires an action on the server, and therefore a roundtrip. If Websocket connection is established (you don't need more than one for everything), there is no overhead. With HTTP, you need to build a request every time. Websocket plays nice with modern reactive streaming architectures. You send stream of events, you receive stream of updates. Everything is transparent and immutable and asynchronous. If there is a connection loss, you are immediately notified and can move your app to offline mode. This is problematic with HTTP. Websocket enable web apps comparable with native apps. HTTP apps will always feel less responsive to user actions.

rahimnathwani 11y ago
Would you mind sharing details of your preferred stack(s)?
- atemerev 11y ago
  React or Riot.js on the frontend, Scala/Akka on the backend, Sockoweb as the dedicated WS server.
  - gkfasdfasdf 11y ago
    I'm just curious, why did you use sockoweb instead of spray.io ? We have similar needs for a webserver that supports websockets and akka - spray.io seems like it would fit the bill.
    - atemerev 11y ago
      A little too overengineered for my taste. I tried akka-http which is essentially Spray 2.0 and succeeded, but with twice the amount of code that I had with Sockoweb.

jzwinck 11y ago

The complaint that the server side of web sockets requires using epoll is strange. Of course we have known for years that select has scalability problems, but we have moved on. That this implementer says they normally use select in 2015 for networked services is worrying. If using epoll and kqueue directly is not your cup of tea, just use libuv or one of the other wrappers. It's not hard then. I know because I'm a native epoll user but recently helped someone on Stack Overflow and it took me maybe fifteen minutes to write a working libuv server having never used libuv before.

wolframhempel 11y ago

Arguing that "WebSockets are bad, because the principals we use for HTTP scalability are not applicable to them" is not wrong, but feels short sighted. Yes: Scaling numerous persistent connections is hard, seeing that most of the available infrastructure is geared towards short-lived HTTP request/response requirements. But there are realtime specific alternatives. You wouldn't want to build your realtime backend from scratch, but rather use something like http://deepstream.io http://deepstream.io which takes care of the heavy lifting.

legulere 11y ago

Similarly to WebGL it will become just another technology that gets abused. Safari has an option to ask before enabling WebGL for a website. I had to turn it off after a while because basically every website was asking for WebGL. I don't mean websites with fancy 3D graphics or even 2D graphics like Google Maps. It's normal news websites that just show text and maybe some pictures.

JoshTriplett 11y ago
> I had to turn it off after a while because basically every website was asking for WebGL. I think part of that comes from frameworks like modernizr probing for WebGL, without actually using it.

Maarten88 11y ago

I'm also a heavy websocket user, and agree with most points. I have previously used websockets on top of a traditional web app, and have been disappointed with the results. My opinion now is that websockets are an all-or-nothing proposition. And I have gone all-in. My latest project has: - websockets-only api (except a some image uploads and oauth/login) - https-only - single page app, central store with observable data, using a single connection servicing the whole application - using SignalR (supports fallbacks for IE9 and old Android) - Actor-based backend (Orleans) This stack feels like the future to me, but I've had to learn a lot of new things. It's quite different from the web development that I've done over the past 15 years. Overcoming the connectivity issues mentioned in the article is only the first step. Websockets need another type of backend to make sense: Actors. I've had many challenges with the async realtime behaviour of the system, deadlocks, etc. But now that everything is working and I have some grip on it, I can't imagine going back to a rest/database/cache web architecture.

skrebbel 11y ago
> My opinion now is that websockets are an all-or-nothing proposition. Interesting. Why? Why can't you get some not-so-realtime data via a classic REST API?
- Maarten88 11y ago
  Of course you can mix two styles, but it makes little sense as websockets does all the things REST can do, only faster and with state on the server. Clientside there is little difference between $.ajax(api, data) and conn.send(api, data). And it's just nicer to keep the api together serverside in (in my case) one SignalR controller instead of putting some parts in a Nancy module. I do have some REST endpoints, i.e. for image upload and oauth, I did not know how to make that work otherwise on IE9.
orf 11y ago
> My latest project has... Taken you a long time to get started. What does it do? I hope the time investment is worth it and you're not trying to make a blog or some CRUD app.

spoiler 11y ago

It feels to me like the author used WebSockets for the wrong thing. I don't think WebSockets belong on a website (even an interactive one as discourse, it is still a website based on my criteria). They'd be more apt in web applications. So, to me it feels like the 1-connection-per-tab feels like saying "someone launched 50 instances of an executable and it opened 50 TCP connections". Examples of where I think it's acceptable/recommended to use Web Sockets include /(video|audio)?/ chats, multiplayer games, collaboration tools, etc. Stuff that requires real-time notifications. Does a discussion platform require that time precision? I doubt it (frankly, I think WebSockets would give a too high "temporal resolution" unless there were proper delays in place which just complicates the implementation, but that is actually irrelevant here).

endriju 11y ago
I don't think WebSockets belong on a website (even an interactive one as discourse... From the article "Discourse does not use WebSockets. Discourse docker ships with HTTP/2 templates." The whole article is worth reading. It looks like the author is well aware the WebSockets limitations.
- ronjouch 11y ago
  The author is indeed well aware of WebSockets limitations, and OP's "Examples of where it's acceptable/recommended to use WebSockets" seem sound. The problem is that the appeal of oooh-shiny is so strong that some (many?) developers and influencers do end up "using WebSockets for the wrong thing". Last case I met: a tutorial for a client+server js app using React & Redux [1], building... a CRUD voting application. Quoting the article on why choosing WebSockets for this, "This is an app that benefits from real-time communication, since it's fun for voters to see their own actions and those of others immediately when they occur. For that reason, we're going to use WebSockets to communicate." Well yes, WebSockets work here (modulo problems and missed benefits/tooling that are the whole point of this article), and socket.io seems like a nice library, but a good old long poll would have done just as well :) [1] http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial...

fideloper 11y ago

Summary of comments here seem to suggest that those with more extensive experience with them agree and see issues with websockets. Those still in favor / find themselves disagreeing, while not necessarily always saying explicitly, seem to be those just starting out on their websocket journey. At least, that's how it seems to me.

jaegerpicker 11y ago
I'd disagree with that. I have a lot of experience with web sockets and I'd say the blog post is short sighted in a bunch of ways. Having done a large amount of TCP socket programming in other environments outside of web apps, I don't really have the same issues with debugging that other seem to complain about.
- fideloper 11y ago
  Cool, you have more experience than most I'd gather. Sounds like info that should be shared :D

bradgessler 11y ago

I agree with most of the points in this essay. I wrote http://firehose.io/ http://firehose.io/ a few years ago for Poll Everywhere and we've successfully scaled WebSockets in a production environment. We don't use it for 2-way communications though; it's HTTP requests in and WebSocket pushes out with long-polling as a backup for non-WS clients. Check out the sourcecode if you want to see an implementation of all the "hard lesions won" in this essay. I also gave a talk about it at RailsConf (http://www.bradgessler.com/talks/streaming-rest/ http://www.bradgessler.com/talks/streaming-rest/) and learned that RabbitMQ as a backend isn't a great idea. Feel free to ask questions if you want me to dive into more specific points.

bphogan 11y ago
I have a question - if you're only using sockets for push, why not use SSE instead? Or did you encounter serious issues with that?
- jessaustin 11y ago
  I've had good results with SSE in just the situation that GP describes: client actions come in as POSTs and the results of those are communicated to everyone via SSE. In most cases we don't even care about the 204 or whatever. If it's not on SSE then it didn't happen. b^)
- bradgessler 11y ago
  SSE is fine except stupid Internet Explorer doesn't support it: http://caniuse.com/#feat=eventsource http://caniuse.com/#feat=eventsource A goal of Firehose is to have the fewest number of transports possible so the client doesn't have to spend much time negotiating the transport. I found WebSockets was more widely supported (http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets) and HTTP long polling could take care of the rest. Before I built Firehose I looked at socket.io, which had a ton of transports, but found that it was too slow, flakey, and unpredictable for our needs.
boggzPit 11y ago
Why was RabbitMQ not great as a backend? I am curious because we use it for a not launched chat application (+websockets) currently and we are not sure if it will hold big amounts of users.

amelius 11y ago

FYI, there is a bug in Chrome that causes WebSockets to be slow [1]. For small messages, the transfer rate seems to be sufficient in most cases. But for larger messages (say, uploads), don't place your bets on WebSockets just yet. [1] https://productforums.google.com/forum/#!msg/chrome/-NVlnMqx6Xg/Z0nMvWZ6IyYJ https://productforums.google.com/forum/#!msg/chrome/-NVlnMqx...

orf 11y ago
Why would you want to upload a file through websockets anyway?
- geocar 11y ago
  I made an upload tool that needed to handle very large files, and I used WebSockets to do it. The strategy I used was to parse the MOV/MP4 locally, consider between 2-60 frames of data, hash it, then stream up the hashes to the server. Any hash the server didn't have got a reply to push those bytes. The two-way nature of this dialog made WebSockets a good fit, although it certainly could have been emulated using other methods, it would have been much more code.
  - Bognar 11y ago
    It seems like it wouldn't be much more code to just use an AJAX POST for the hash and have the server reply whether it has the hash or not, followed by the chunk upload again over AJAX. It would probably be slower and less data efficient, but I don't see how it would be much more code.
    - amelius 11y ago
      Perhaps it would require more code to get it equally fast and data efficient :)
    - geocar 11y ago
      The whole point of uploading a file this way is that it is more data efficient and faster in my use case. That means that slowness is a bug; inefficiency is a bug. For what reason would you put bugs in your code on purpose? We also probably have different ideas about how much "much" is.

mstade 11y ago

This is a good article, albeit a bit long-winded. In my experience, whether or not WS can be beneficial essentially comes down to whether or not you truly need low latency duplex communication. A chat application, which seems to be the canonical WS example, probably doesn't; a twitch-style multiplayer game, probably does. Server-sent events are a great tool for streaming server-to-client data where other more specific media types (i.e. audio/video) doesn't fit the bill.

andybak 11y ago
Shame about IE - even Edge is red: http://caniuse.com/#feat=eventsource http://caniuse.com/#feat=eventsource
- mstade 11y ago
  Indeed, but thankfully it's easily polyfilled.

xorcist 11y ago

If you deploy websockets in your application, either make your application can use some fallback like long polling or make sure you don't have any enterprise customers. They tend to have pesky proxies that mess with traffic. Sometimes websockets simply doesn't work, but sometimes they initialize correctly but no data passes through(!). It's a mess.

mmaunder 11y ago

Jeez web sockets really aren't that hard. We've used them for a long time on our production site for a live attack map: https://www.wordfence.com/ https://www.wordfence.com/ and we regularly have over 1000 concurrent visitors on the site when we promote a blog post or do something similar. I can't think of any reason why I wouldn't use node.js on the server-side for web sockets. It obviously uses epoll() and you really need an event language to be comfortable writing an application that manages a large number of concurrent connections. Ruby for this makes me shudder - sorry it just feels like a square peg forced into a round hole that's late to the party.

icebraining 11y ago
I'm hardly a Ruby fan - nothing against it, I just prefer Python - but what makes it such a bad choice vis-a-vis JavaScript? Sure, Rails isn't built with this in mind, but why would Ruby with some kind of libuv-based framework be such a terrible choice?
- cdelsolar 11y ago
  It's not meant for it. Python is similar, there are hacks (such as eventlet) that have their own downsides. Use the right tool for the job. We are currently rewriting an eventlet-based part of our stack in Go with much better results.
  - rubiquity 11y ago
    You might want to read or watch this presentation before doing that: https://docs.google.com/presentation/d/1LO_WI3N-3p2Wp9PDWyv5B6EGFZ8XTOTNJ7Hd40WOUHo https://docs.google.com/presentation/d/1LO_WI3N-3p2Wp9PDWyv5... Mozilla went from Python to Go and then back again for reasons I think you would also run into.
  - icebraining 11y ago
    Yeah, I can see how Go has some built-in advantages over Ruby and Python in this regard, but I was really looking to understand why mmaunder considers JavaScript a much better choice than Ruby.

et1337 11y ago

1. Ditch Ruby. Node or Python with asyncio work fantastic with WebSockets. Use a greenlet-enabled database connection pool. 2. Use HTTP for traditional request/response tasks. Use WebSockets to push realtime notifications to clients. 3. Have your clients auto-retry their WebSocket connections in the background. Show an indicator of degraded service when this happens. When a new WebSocket connects, blast a complete state update to it to take care of any missed messages. Now you can easily load-balance your clients. (my two cents, YMMV, etc.)

jkarneges 11y ago
We created a WebSocket client wrapper library to make your third point easier to deal with. It handles only the connection freshness judo and nothing else, and doesn't require a special server or anything. Maybe people here find it interesting: https://github.com/fanout/websockhop https://github.com/fanout/websockhop
- matt2000 11y ago
  I've just started using this too, not much real world experience but in case it's useful to someone: https://github.com/joewalnes/reconnecting-websocket https://github.com/joewalnes/reconnecting-websocket
Dr_tldr 11y ago
Yes, yes, and yes, you nailed it. The author of the article seems to have difficulty separating "problems specific to WebSockets" and "specific problems I have." People who say "REST is dead, AJAX is dead, HTTP headers are dead, all hail the new sockets" are wide-eyed fanatics and this article is a useful corrective to them, but it's definitely not an even-handed analysis. There are too many problems with the article to do a line-by-line rebuttal, but the one that was most silly for me was "what if a user has multiple tabs open, oh noes!" It's trivial to implement a session id then disconnect the inactive tab(s), and has been for a long time. On the other hand, his recommendations in the comments are pretty solid, so he's not completely off...
shams93 11y ago

colmmacc 11y ago

Not mentioned is a common pitfall with serving web sockets: it is very easy to end up in a situation where you may not recover from disruptions. The problem is that establishing a web socket, especially when using SPDY or HTTPS (which is typical), is much more expensive than maintaining a connected one. So a service will typically see a steady creep up in the number of connections, with a relatively low number of new connections per second, and it's probably been tuned for massive levels of concurrency, and that's all manageable. But then the service has a blip of some kind all of a sudden all of those web socket clients try to connect at the same time; disaster. At that point the service is incredibly overloaded, so many connections fail, which results in retries, which makes matters even worse still and fuels a vicious cycle. That situation might self-stabilize if browsers implemented exponential back off, but that's not typical either. So the service remains hosed until some kind of blood letting can be done to let clients back in at a manageable rate. Extremely pernicious, and something I've seen several times. When scaling web-sockets, it's important to ask: can I handle all of these clients reconnecting at the same time?

clarkmoody 11y ago
> browsers implemented exponential back off Browsers do not have any native reconnect behavior for WebSockets. You have to implement reconnect in your application, which usually means exponential falloff. There are a few open-source implementations of this very feature. Since you control the reconnect behavior, you could have clients wait a random amount of time from 1-5s before attempting the first connection. That way your reconnect storm is spread uniformly over a broader time frame.
CyberDildonics 11y ago
Sounds like web programming might end up becoming closer to real programming.
Can_Not 11y ago
Is there a formal term for this websocket reconnect stampede? What serverside stack and language were you using? What clientside language and libraries? How many users were active and how many CPU cores were dedicated to the websockets? Were you load balancing with or without sticky sessions? Was your websockets a public broadcast or did you do authentication checks for rooms/channels? Have you considered doing a formal writeup over this pitfal and how it was resolved for your project?

ashearer 11y ago

I agree with the approach indicated by the title ("caution required"), but the tone of the article veers toward being alarmist. Takedown articles tend to share similar characteristics. Many are on a mission that emphasizes the negatives of their subject, even minor ones, while overlooking the positives and handwaving away problems with the alternatives. They set the bar higher for the subject by finding issues that it shares equally with its alternatives, and presenting them as damning evidence against it (since users may expect it to be better and be disappointed). The specific alternative that's held up as superior to the subject varies from point to point--no one alternative is actually superior in all points. They may even acknowledge that many of their arguments are weak, but make up for it in volume. In its favor compared to such articles, this one does make some attempts to be evenhanded, but they're overpowered by the dramatic language used to make the opposing points. (For example, the brief acknowledgement that point 1 is the "weakest argument against WebSockets" is surrounded by phrases like "wreak havoc", "weird stuff will definitely happen", "rogue proxies will break you"). This article puts itself squarely in the category of "the case against". A more balanced article might discuss: 1. The situations where you might want to avoid WebSockets (no HTTPS, IE 8 & 9 compatibility, a server platform without good support, or where they don't provide actual usability benefits). 2. Pitfalls that both long-polling and WebSockets share (you have to handle reconnections and synchronize state, be mindful of the open connections when reconfiguring a load balancer, account for server load, and use a server platform with good support for long connections). 3. Differences that can be viewed just as reasonably in WebSockets' favor, which the article counts as negatives. Example 1: Resynchronizing state after a network interruption is necessary with both long-polling and WebSockets, though the article notes it as a WebSockets disadvantage. The reconnection process is explicit with WebSockets, but some long-polling libraries make it very easy to ignore these events, leaving the client out of sync. Example 2: WebSockets aren't limited to 6 connections, unlike long-polling, so you won't get a silent connectivity roadblock on some tabs when the user has several of them open. 4. Advantages unique to WebSockets: responsiveness is improved due to not needing to send HTTP headers with every request and response, and the underlying TCP connection is already warmed up; load balancing and redundancy may be simplified by no longer requiring a session affinity mechanism (because the connection itself preserves short-term state, which can be re-established by the client transparently to the user in the rarer event of reconnection); less overhead than long-polling; a whole class of problems resulting from cookies as the sole mechanism of state transfer is avoided; the same protocol can be implemented simply and efficiently by native mobile apps.

jkarneges 11y ago

If you're interested in implementing reliable long-polling as described in the article, you might check out Pushpin (http://pushpin.org http://pushpin.org). It's a proxy server that you put in front of your API backend and it makes this sort of thing really easy. Pushpin also supports WebSockets, but the long-polling capability is first class and not an afterthought.

warfangle 11y ago

Probably difficult to do in a non-event-driven non-asynchronous environment where every i/o blocks like Ruby............

Rauchg 11y ago

Most of this gotchas (and others not mentioned) can be avoided if you treat WebSocket for what it is: a low-level transport that can be swapped out. This is how we treat it in Socket.IO and Engine.IO. Most people that implement WebSocket directly end up re-inventing a protocol on top of it. This is necessary because the "onmessage" handler of WS is not something you can really build an application on. And then you'll have to add reconnection and exponential delays after that. If you just want to use HTTP polling, which as the author suggests is perfect for most applications (perhaps not games), you can simply do: `io('http://myhost' http://myhost', { transports: ['xhr-polling'] })`.

iamleppert 11y ago

Can't stand the cargo cult thinking/writing here. The author seems to think websockets are dangerous like handling a piece of glass. It's a technology like anything else. See if it meets your requirements, if it does, great, go for it and learn along the way. If not, stick to regular connections. Case closed.

geoffroy 11y ago

A very good article comparing SSE, Websockets, polling, long polling was posted a few months ago, still relevant : https://www.nateberkopec.com/2015/09/30/action-cable.html https://www.nateberkopec.com/2015/09/30/action-cable.html