2 ms·

--- WebSockets cannot benefit from any HTTP feature. That is: No support for compression No support for HTTP/2 multiplexing Potential issues with p

• __s 5y ago
  WebSockets support compression (ofc, the article goes on to detail this & point out flaws. I'd argue that compression is not generally useful in web sockets in the context of many small messages, so it makes sense to be default-off for servers as it's something which should be enabled explicitly when necessary, but the client should be default-on since the server is where the resource usage decision matters) I don't see why WebSockets should benefit from HTTP. Besides the handshake to setup the bidirectional channel, they're a separate protocol. I'll agree that servers should think twice about using them: they necessitate a lack of statelessness & HTTP has plenty of benefits for most web usecases Still, this is a good article. SSE looks interesting. I host an online card game openEtG, which is far enough from real time that SSE could potentially be a way to reduce having a connection to every user on the site
• bullen 5y ago
  The problem with WebSockets is that hey are: 1) More complex and binary so you cannot debug them as easily, specially on live and specially if you use HTTPS. 2) The implementations don't parallelize the processing, with Comet-Stream + SSE you just need to find a application server that has concurrency and you are set to scale on the entire machines cores. 3) WebSockets still have more problems with Firewalls.