Server-Sent Events: an alternative to WebSockets • Hacker News Board

Re: Server-Sent Events: an alternative to WebSockets

#221

Post by hishamp » Sun, Feb 13, 2022, 5:10 AM UTC

DaiPlusPlus wrote: post #180

hishamp wrote: post #179

We moved away from WebSockets to SSE, realised it wasn't makings thing any better. In fact, it made things worse, so we switched back to WebSockets again and worked on scaling WebSockets. SSE will work much better for other cases, just didn't work out for our case. First reason was that it was an array of connections you loop through to broadcast some data. We had around 2000 active connections and needed a less than…

Your write-up sounds like your issues with SSE stemmed from the framework/platform/server-stack you're using rather than of any problems inherent in SSE. I haven't observed any latency or scaling issues with SSE - on the contrary: in my ASP.NET Core projects, running behind IIS (with QUIC enabled), I get better scaling and throughput with SSE compared to raw WebSockets (and still-better when compared to SignalR), tho…

Yes, that might be the case, it might be due to the implementation issues from my part. And in that case, instead of taking too much time configuring SSE, we decided to move back to WS which already had resources in place to easily get things done, which worked well for us. Not against SSE, just saying it didn’t work out for us for our specific requirements with our team size and expertise. Just a heads up, that’s all.

Re: Server-Sent Events: an alternative to WebSockets

#222

Post by rndgermandude » Sun, Feb 13, 2022, 5:44 AM UTC

coder543 wrote: post #79

rawoke083600 wrote: post #9

I like them, they surprisingly easy to use.. One example where i found it to be not the perfect solution was with a web turn-based game. The SSE was perfect to update gamestate to all clients, but to have great latency from the players point of view whenever the player had to do something, it was via a normal ajax-http call. Eventually I had to switch to uglier websockets and keep connection open. Http-keep-alive was…

With HTTP/2, the browser holds a TCP connection open that has various streams multiplexed on top. One of those streams would be your SSE stream. When the client makes an AJAX call to the server, it would be sent through the already-open HTTP/2 connection, so the latency is very comparable to websocket — no new connection is needed, no costly handshakes. With the downsides of HTTP/1.1 being used with SSE, websockets a…

>no new connection is needed, no costly handshakes.

No new connection and no low-level connection (TCP, TLS) handshakes, but the server still has to parse and validate the http headers, route the request, and you'd probably still have to authenticate each request somehow (some auth cookie probably), which actually may start using a non-trivial amount of compute when you have tons of client->server messages per client and tons of clients.

Re: Server-Sent Events: an alternative to WebSockets

#223

Post by klabb3 » Sun, Feb 13, 2022, 6:53 AM UTC

homarp wrote: post #188

klabb3 wrote: post #149

Earlier quoted context omitted.

> HTTP/3 is E2E encrypted Please elaborate.

https://www.youtube.com/watch?v=J4fR5aztSwQ - Securing the Next Version of HTTP: How QUIC and HTTP/3 Compare to HTTP/2 "QUIC is a new always-encrypted general-purpose transport protocol being standardized at the IETF designed for multiplexing multiple streams of data on a single connection. HTTP/3 runs over QUIC and roughly replaces HTTP/2 over TLS and TCP. QUIC combines the cryptographic and transport handshakes in…

I think the common definition of e2e encryption covers user-to-user communication, so I'm confused how a transport protocol can offer e2e encryption at all (it would only do so if Quic is used over p2p between users, but that's a property of the application).

But even if the definition were different, http+tls would also be e2e encrypted (if used in conjunction which it pretty much always is).

I appreciate Quic but from a security perspective I don't see how it's different to what we've had for at least a decade.

Re: Server-Sent Events: an alternative to WebSockets

#224

Post by bullen » Sun, Feb 13, 2022, 7:52 AM UTC

dnautics wrote: post #220

bullen wrote: post #197

Earlier quoted context omitted.

I think it might be your ISP. For example one of my ISPs cut off my SSH connections no matter what I do. They simply dislike hanging SSH connections. It's just random that your ISP like WebSockets more than long HTTP responses, and it can change in a heartbeat and for most people it will be different. As I said before 99,6% successful networking is an unheard of number for real-time multiplayer games. I only care abo…

It's not random. Having limited timeouts for http is policy set at often time several layers to prevent certain types of security regressions.

Ok, what security regressions?

Re: Server-Sent Events: an alternative to WebSockets

#225

Post by chrismorgan » Sun, Feb 13, 2022, 1:17 PM UTC

mmcclimon wrote: post #61

SSEs are one of the standard push mechanisms in JMAP [1], and they're part of what make the Fastmail UI so fast. They're straightforward to implement, for both server and client, and the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug. 1. https://jmap.io/spec-core.html#event-source

It is, however, interesting to note that Fastmail’s webmail doesn’t use EventSource, but instead implements it atop fetch or XMLHttpRequest. An implementation atop XMLHttpRequest was required in the past because IE lacked EventSource, but had that been the only reason, it’d just have been done polyfill style; but it’s not. My foggy recollection from 4–5 years ago (in casual discussion while I worked for Fastmail) is that it had to do with getting (better?) control over timeout/disconnect/reconnect, probably handling Last-Event-ID, plus maybe skipping browser bugs in some older (now positively ancient and definitely unsupported) browsers. The source for that stuff is the three *EventSource.js files in https://github.com/fastmail/overture/tree/master/source/io.

Re: Server-Sent Events: an alternative to WebSockets

#226

Post by dkersten » Sun, Feb 13, 2022, 4:20 PM UTC

bullen wrote: post #195

dkersten wrote: post #169

Earlier quoted context omitted.

While I get and support the intent, I don't like this usage of the name of the MIT license. I personally like the license because it tells me at a glance that I can use it for any purpose, commercial or otherwise, as long as the copyright and license is included and that there is no warranty. That's it, no complications, no other demands, no "if it makes X money or not", just I include the copyright and license terms…

Ok, I agree but then I also have less time to work on real things and honestly I feel the whole legal/money part of our civilization is a huge waste of time in the face of energy problems that can't go away (2nd law of thermodynamics and sunlight + photosyntesis) and that my platform tries to help with elegantly by being the most efficient solution for MMO networking. I'm also sad that nobody has solved this license…

> then I also have less time to work on real things

What? To keep your existing license you copy the text of the MIT license, add the statement about requiring a logo and remove the parts about being able to use the code commercially, and add an extra paragraph that has the text you already have: to use commercially you have to sponsor. It’s not about changing your terms, it’s about being clear about what license applies. Hybrid with MIT and other implies that the MIT license somehow applies yet it does not since your “other” invalidates a chunk of what the MIT license allows. Just removing those bits and not calling it MIT is enough.

If that significantly cuts into your time to do other stuff then I don’t know what to say.

> if somebody who is willing to pay approaches me with the same concerns

I’m not concerned about the license per se. It wouldn’t stop me from paying if I wanted to use your software. It’s just that to everyone looking, before even evaluating it, you’re sending a dishonest message, that somehow the MIT license applies when it clearly does not.

I would create a license.txt file that contains a copy of the MIT license text with the commercial use phrasing removed, the need for displaying logo added a second paragraph before the warranty disclaimer stating that you may use the software commercially so long as you sponsor (same text you already have). Then I would link it from the readme with an explanation: proprietary license that is similar to the MIT license except with the conditions of logo and for commercial use requiring sponsorship (existing text more or less). Clear, simple and should take you no more than ten minutes to fix.

My objection is that you are claiming it’s under MIT license and using the MIT licenses name recognition, while applying changes that very clearly make it not MIT license at all.

Re: Server-Sent Events: an alternative to WebSockets

#227

Post by xg15 » Sun, Feb 13, 2022, 4:23 PM UTC

leeoniya wrote: post #111

coder543 wrote: post #103

Earlier quoted context omitted.

This isn’t a problem with HTTP/2. You can have as many SSE connections as you want across as many tabs as the user wants to use. Browsers multiplex the streams over a handful of shared HTTP/2 connections. If you’re still using HTTP/1.1, then yes, this would be a problem.

hmmm, you might be right. i wonder what steered me away. maybe each SSE response re-sends headers, which can be larger than the message itself? maybe it was inability to do broadcast to multiple open sse sockets from nodejs. i should revisit. https://medium.com/blogging-greymatter-io/server-sent-events...

> maybe each SSE response re-sends headers, which can be larger than the message itself?

That's (long) polling, not SSE. The only overhead for SSE are the "data", "event", etc pseudo header names and possibly some chunked-encoding markers. Both are tiny though.

Re: Server-Sent Events: an alternative to WebSockets

#228

Post by xg15 » Sun, Feb 13, 2022, 4:32 PM UTC

coder543 wrote: post #79

rawoke083600 wrote: post #9

I like them, they surprisingly easy to use.. One example where i found it to be not the perfect solution was with a web turn-based game. The SSE was perfect to update gamestate to all clients, but to have great latency from the players point of view whenever the player had to do something, it was via a normal ajax-http call. Eventually I had to switch to uglier websockets and keep connection open. Http-keep-alive was…

With HTTP/2, the browser holds a TCP connection open that has various streams multiplexed on top. One of those streams would be your SSE stream. When the client makes an AJAX call to the server, it would be sent through the already-open HTTP/2 connection, so the latency is very comparable to websocket — no new connection is needed, no costly handshakes. With the downsides of HTTP/1.1 being used with SSE, websockets a…

I wonder if websockets "accidentally" circumvented HTTP2's head-of-line blocking problem and therefore appeared to have better latency:

SSE streams are multiplexed into a HTTP2 stream, so they can suffer from congestion issues caused by unrelated requests.

In contrast, HTTP2 does not support websockets, so each websocket connection always has its own TCP connection. Wasteful, but ensures that no head-of-line blocking can occur.

So it might be that switching from SSE to websockets gave better latency behaviour, even though it had nothing to do with the actual technologies.

Of course, this issue should be solved anyway with HTTP3.

Re: Server-Sent Events: an alternative to WebSockets

#229

Post by coder543 » Sun, Feb 13, 2022, 4:47 PM UTC

xg15 wrote: post #228

coder543 wrote: post #79

Earlier quoted context omitted.

With HTTP/2, the browser holds a TCP connection open that has various streams multiplexed on top. One of those streams would be your SSE stream. When the client makes an AJAX call to the server, it would be sent through the already-open HTTP/2 connection, so the latency is very comparable to websocket — no new connection is needed, no costly handshakes. With the downsides of HTTP/1.1 being used with SSE, websockets a…

I wonder if websockets "accidentally" circumvented HTTP2's head-of-line blocking problem and therefore appeared to have better latency: SSE streams are multiplexed into a HTTP2 stream, so they can suffer from congestion issues caused by unrelated requests. In contrast, HTTP2 does not support websockets, so each websocket connection always has its own TCP connection. Wasteful, but ensures that no head-of-line blocking…

> Wasteful, but ensures that no head-of-line blocking can occur.

That’s not how head-of-line blocking works. Just having a single stream doesn’t guarantee no blocking. It’s not really about unrelated requests getting in the way and sucking up bandwidth (that’s a separate issue, and arguably applies regardless of how many TCP connections you have), head-of-line blocking is about how TCP handles retransmission of lost packets. Websocket suffers from head-of-line blocking too, which is a reason that WebTransport is being developed.

Certainly, if you have other requests in flight, you could have head-of-line blocking because of a packet that was dropped in a response stream that isn’t related to your SSE stream, but this only applies if there’s packet loss, and the packets that were lost could just as easily be SSE’s or websocket’s.

I agree that HTTP/3 should solve the issue of head-of-line blocking being caused by packets lost from an unrelated stream, but it doesn’t prevent it from occurring entirely.

My understanding (which could be wrong) is that WebTransport is supposed to offer the ability to send and receive datagrams with closer to UDP-level guarantees, allowing the application to continue receiving packets even when some go missing, and then the application can decide how to handle those missing packets, such as asking for retransmission. Getting an incomplete stream at the application level is what it takes to entirely avoid head-of-line blocking.

As alluded to earlier, there is zero head-of-line blocking if there is no packet loss. Outside of congested networks or the lossy fringes of cell service, I really wonder how much of an issue this is. I’m skeptical that it adds any latency for SSE vs websocket in the average benchmark or use case. The latency should be nearly identical. Your comment seems predicated on it definitely being worse, but based on what numbers? I admit it’s been a couple of years since I measured this myself, but I came away with the conclusion that websockets are massively overrated. There are definitely a handful of use cases for websockets, but… it shouldn’t be the tool everyone reaches for.

HTTP/3 is really meant to be an improvement for a small percentage of connections, which is a huge number of people at the scale that Google operates at. I don’t think there are really any big downsides to HTTP/3, so I look forward to seeing it mature, become more common, and become easier to find production grade libraries for.

Re: Server-Sent Events: an alternative to WebSockets

#230

Post by xg15 » Sun, Feb 13, 2022, 4:55 PM UTC

coder543 wrote: post #229

xg15 wrote: post #228

Earlier quoted context omitted.

I wonder if websockets "accidentally" circumvented HTTP2's head-of-line blocking problem and therefore appeared to have better latency: SSE streams are multiplexed into a HTTP2 stream, so they can suffer from congestion issues caused by unrelated requests. In contrast, HTTP2 does not support websockets, so each websocket connection always has its own TCP connection. Wasteful, but ensures that no head-of-line blocking…

> Wasteful, but ensures that no head-of-line blocking can occur. That’s not how head-of-line blocking works. Just having a single stream doesn’t guarantee no blocking. It’s not really about unrelated requests getting in the way and sucking up bandwidth (that’s a separate issue, and arguably applies regardless of how many TCP connections you have), head-of-line blocking is about how TCP handles retransmission of lost…

> Certainly, if you have other requests in flight, you could have head-of-line blocking because of a packet that was dropped in a response stream that isn’t related to your SSE stream, but this only applies if there’s packet loss, and the packets that were lost could just as easily be SSE’s or websocket’s.

That was what I meant. Yes, head-of-line blocking can occur everywhere there is TCP, but with HTTP2, the impact is larger due to the (otherwise very reasonable) multiplexing: When a HTTP2 packet is lost, this will stall all requests that are multiplexed into this connection, whereas with websocket, it will only stall the websocket connection itself.