I believed keep alive was enabled by default on browsers with HTTP1.1
Stop Wasting Connections, Use HTTP Keep-Alive
41–50 of 112 posts
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#42Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...
Its amazing that not everyone is on http2 yet when its basically free speed.
Not when you consider that the majority of linux distributions haven't picked up support for it yet in their versions of nginx, apache et al.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#43Re: Stop Wasting Connections, Use HTTP Keep-Alive
#44Earlier quoted context omitted.
I’m not amazed. While many stacks support it, most organizations still have lift on their end to implement this behind the other “priority” customer change requests.
Of all the micro-optimizations I could think of for web apps, the one with the highest cost and the least benefit would probably be supporting http2 (or *quic). In almost all cases, there is a fix that will speed up http1.1 to acceptable levels.
What's the "cost" to supporting HTTP 2 as an app developer, though? As far as I know, adding support to nginx requires changing one line of code. That's about as close to free as you can get.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#45Earlier quoted context omitted.
Of all the micro-optimizations I could think of for web apps, the one with the highest cost and the least benefit would probably be supporting http2 (or *quic). In almost all cases, there is a fix that will speed up http1.1 to acceptable levels.
What's the "cost" to supporting HTTP 2 as an app developer, though? As far as I know, adding support to nginx requires changing one line of code. That's about as close to free as you can get.
For a tiny startup, you might be able to just add http2 support in 10 minutes and everything might be fine, but most of the time it's more complicated. It's a bit like if I said, can I change your app libraries to bleeding edge? It's just a one line change.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#46Or better yet, use gzip and inline all images as base64 encoded. The file size is very similar to raw data, and the number of requests with associated http headers is reduced.
Might be a good idea for statically generated pages, or the statically generated parts of pages, but I’d be wary of adding any more load to dynamic pages.
Do any static site generators rewrite image links as data URIs?
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#47Earlier quoted context omitted.
Its amazing that not everyone is on http2 yet when its basically free speed.
It's hardly a surprise. It takes time for people to migrate to new protocols. Not everyone can just leave 20 years of engineering effort behind and switch to HTTP2 because it's a bit faster in some situations.
HTTP2 has multiple optimisations e.g. I only just realised it compresses XMLHTTPRequest requests, not just responses.
We use CloudFlare, so most of our users get HTTP2 even though our own infrastructure is still HTTP1.1 (however some corporate customers have proxies, which usually downgrade the browser connection to HTTP1.1).
We log whether HTTP2 or HTTP1.1 is used by the browser by JavaScript reading `window.performance.getEntries()[0].nextHopProtocol` which is supported by most modern browsers.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#48Earlier quoted context omitted.
These tickets talk about pipelining, not keep-alive. The chrome link specifically points out why they decided to disable it. Chrome and Firefox still support regular keep-alive and do reuse connections on http 1.1
Fair point, however I've seen no evidence Chrome is doing keep-alive on Linux or Mac OS - it always seems to send a FIN ACK after the response from the server to close the connection. Firefox most definitely is utilising it fully, and obeys the Keep-Alive params specified, which I can't see any of the other browsers doing.
I've seen no evidence Chrome is doing keep-alive on Linux or Mac OS
That sounds like a bug with your server implementation. The web would melt down if Chrome's keep-alive support didn't work.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#49My understanding was that with http/1.1 all connections are kept alive until a close is emitted. How is this different?
Although the keep alive periods may vary:
https://fastmail.blog/2011/06/28/http-keep-alive-connection-...
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#50The hidden danger, mentioned in the article, is if the client sends a second request while the server closes an idle connection. Until http/2, the client can't tell if the server closed the connection before or after it received the request. Many servers send a hint about the idle time out, but few client libraries process it (that I've seen). The larger the latency between server and client, the bigger deal this is.
This is always an issue: you send an HYTP POST request (even on http/0.9) - and connection closes before you saw a response. Did the server receive it? You don’t know. Pipelining might amplify it, but it is always there, especially with unreliable mobile connections.
I wonder if it might be a minor performance issue in the worst case.
Without keepalive, you create a new connection and pay the latency costs of doing so. With keepalive, there's a chance you try to reuse an old connection, and it fails, which requires round trips to learn about, and you still have the latency of creating a new connection. So more total latency in that case.
It seems it would improve the average case but make the worst case slightly worse. If your keepalive timeout is short, maybe it would come up often enough to matter.