10 ms·
It doesn’t mention the big drawback of SSE as spelled out in the MDN docs: “Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum nu
by dugmartin 2y ago
It doesn’t mention the big drawback of SSE as spelled out in the MDN docs:
“Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6).”
- k__ 2y agoAnd over HTTP/2 and 3 they are efficient?
- RadiozRadioz 2y agoThat is a very low number. I can think of many reasons why one would end up with more. Does anyone know why it is so low?
- apitman 2y agoHistorical reasons. The HTTP/1.1 spec actually recommends limited to 2 connections per domain. That said, I'm not sure why it's still so low. I would guess mostly to avoid unintended side effects of changing it.
- gsnedders 2y ago> The HTTP/1.1 spec actually recommends limited to 2 connections per domain. This is no longer true. From RFC 9112 § 9.4 (https://httpwg.org/specs/rfc9112.html#rfc.section.9.4 https://httpwg.org/specs/rfc9112.html#rfc.section.9.4): > Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections.
- apitman 2y agoIf this was a MUST would it have required a bump from 1.1?
- dontchooseanick 2y agoBecause you're supposed to use a single connection with HTTP Pipelining for all your ressources [1] When index.html loads 4 CSS and 5 JS : 10 ressources in HTTP 1.0 needed 10 connections, with 10 TLS negociations (unless one ressource loaded fast and you could reuse it's released connection) With HTTP1.1 Pipelining you open only one connection, including a single TLS nego, and ask 10 ressources. Why not only 1 per domain so ? IIRC it's because the 1st ressource index.html may take a lot of Time to complete and well race conditions suggest you use another one that the 'main thread' more or less. So basically 2 are sufficient. [1] https://en.m.wikipedia.org/wiki/HTTP_pipelining https://en.m.wikipedia.org/wiki/HTTP_pipelining
- immibis 2y agoHTTP pipelining isn't used by clients.
- foota 2y agoProbably because without http/2 each would require a TCP connection, which could get expensive.
- raggi 2y agoThe number was set while Apache was dominant and common deployments would get completely tanked by a decent number of clients opening more conns than this. c10k was a thing once, these days c10m is relatively trivial
- giantrobot 2y agoBecause 30 years ago server processes often (enough) used inetd or served a request with a forked process. A browser hitting a server with a bunch of connections, especially over slow network links where the connection would be long lived, could swamp a server. Process launches were expensive and could use a lot of memory. While server capacity in every dimension has increased the low connection count for browsers has remained. But even today it's still a bit of a courtesy to not spam a server with a hundred simultaneous connections. If the server implicitly supports tons of connects with HTTP/2 support that's one thing but it's not polite to abuse HTTP/1.1 servers.
- SahAssar 2y agoThere is little reason to not use HTTP/2 these days unless you are not doing TLS. I can understand not doing HTTP/3 and QUIC, but HTTP/2?
- jiggawatts 2y agoCorporate proxy servers often downgrade connections to HTTP 1.1 because inertia and lazy vendors.
- SahAssar 2y agoTo do that they need to MITM and tamper with the inner protocol. In my experience this is quite rare. Some MITM proxies analyze the traffic, restrict which ciphers can be used, block non-dns udp (and therefore HTTP/3), but they don't usually downgrade the protocol from HTTP/2 to HTTP/1.
- arccy 2y ago"tamper" sounds much more involved than what they (their implementation) probably do: the proxy decodes the http request, potentially modifies it, and uses the decoded form to send a new request using their client, which only speaks http/1
- mrngm 2y agoThat is already tampering with the request. It's not simply forwarded to the requested destination, but intercepted, interpreted, and resent... with a different client than the original source.
- geoffeg 2y agoThat hasn't been my experience at large corporations. They usually have a corporate proxy which only speaks HTTP 1.1, intercepts all HTTPS, and doesn't support websockets (unless you ask for an exception) and other more modern HTTP features.
- dilyevsky 2y ago
- jesprenj 2y agoYou can easily multiplex data over one connection/event stream. You can design your app so that it only uses one eventstream for all events it needs to receive.
- raggi 2y agoThis, it works well in a service worker for example.
- nikeee 2y agoHow does this work with a service worker? I've only managed to do this via SharedWorker (which is not available on Chrome on Android).
- raggi 2y agoYou can just open a stream in the service worker and push events via postMessage and friends. Another nice thing to do is to wire up a simple filesystem monitor for all your cached assets that pushes path & timestamp events to the service worker whenever they change, then the service worker can refresh affected clients too (with only a little work this is endgame livereload if you’re not constrained by your environment)
- tomsmeding 2y agoThe caniuse link in the OP, under Known Issues, notes that Firefox currently does not support EventSource in a service worker. https://caniuse.com/?search=EventSource https://caniuse.com/?search=EventSource
- atombender 2y agoOne of my company's APIs uses SSE, and it's been a big support headache for us, because many people are being corporate firewalls that don't do HTTP/2 or HTTP/3, and people often open many tabs at the same time. It's unfortunately not possible to detect client-side whether the limit has been reached. Another drawback of SSE is lack of authorization header support. There are a few polyfills (like this one [1]) that simulate SSE over fetch/XHR, but it would be nice to not need to add the bloat. [1] https://github.com/EventSource/eventsource https://github.com/EventSource/eventsource
- robocat 2y agoPresumably you try SSE, and on failure fallback to something else like WebSockets? Push seems to require supporting multiple communication protocols to avoid failure modes specific to one protocol - and libraries are complex because of that.
- mardifoufs 2y agoBut then why not just use websockets?
- virtue3 2y agoFrom what I understand websockets are great until you have to load balance them. And then you learn why they aren’t so great.
- com2kid 2y agoI've scaled websockets before, it isn't that hard. You need to scale up before your servers become overloaded, and basically new connections go north to the newly brought up server. It is a different mentality than scaling stateless services but it isn't super duper hard.
- hooli_gan 2y agoCan you suggest some resources to learn more about Websocket scaling? Seems like an interesting topic
- deleted 2y ago[deleted]
- nhumrich 2y agoHttp2 is controllable by you, since it's supposed in every browser. So, the way to fix this limitation is to use http2
- jillesvangurp 2y agoYes, use a proper load balancer that can do that. And use Http3 which is also supported by all relevant browsers at this point. There's no good reason to build new things on top of old things.
- lolinder 2y agoThis was already suggested and someone pointed out that some corporate networks MITM everything without HTTP/2 support: https://news.ycombinator.com/item?id=42512072 https://news.ycombinator.com/item?id=42512072