Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Wasting Connections, Use HTTP Keep-Alive

lob.com

Post reply on HN
Print view View original

91–100 of 112 posts

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#91

Post by nvarsj »

toast0 wrote: post #3

The 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 only partially true. http/1.1 has well defined semantics for persistent connections. The server can send the header "Connection: Close" to indicate to the client it is closing the idle connection. All http/1.1 clients should respect that since it's in the RFC.

The problem is many servers don't send this header when closing idle connections. nginx is a notorious example. But well behaving servers should be sending that header if they intend to close the connection after a request.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#92

Post by youngtaff »

VBprogrammer wrote: post #89
cm2187 wrote: post #84

Earlier quoted context omitted.

Yeah and if the client volunteers the list of all it has in cache it would result in some massive requests and a kind of quasi-cookie. I always found this feature interesting but weird.

Random thought. But isn't this a potential use for a bloom filter?

Yes bloom filters were a potential for Cache Digests, original prototype for Cache Digests used Golomb coded set as memory representation is smaller than Bloom filter

https://github.com/h2o/h2o/issues/421

But then Cache Digests moved onto Cuckoo Filters - https://github.com/httpwg/http-extensions/pull/413

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#93

Post by rjmunro »

RussianCow wrote: post #44
0xbadcafebee wrote: post #32

Earlier 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.

Supporting http2 at an nginx reverse proxy doesn't help the problem in the original post, which is mostly about internal connections between microservices, e.g. going from your nginx proxy to your node or rails server.

Putting http2 here is a pain because you probably don't want https. You'd have to have nginx decrypt and reencrypt all the traffic, and you'd have to deal with certificates etc.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#94

Post by tyingq »

nvarsj wrote: post #90

People seem to always get confused by this - http/1.1 is persistent by default and the vast majority of servers/clients use it. The "Keep-Alive" header was something tacked onto http/1.0 and doesn't really mean anything these days.

Unfortunately, depends on the server. Node says this:

"Sending a 'Connection: keep-alive' will notify Node.js that the connection to the server should be persisted until the next request."

The article seems to confirm this behavior.

So clients have to account for non RFC compliant servers.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#95

Post by JdeBP »

cetra3 wrote: post #4

Sure, if Apple have fixed their issues with Keep-Alive for Safari: https://stackoverflow.com/questions/25372318/error-domain-ns...

You and eridius are talking about the Keep-Alive: header. The article at hand appears to be talking about the Connection: header.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#96

Post by chrismorgan »

baroffoos wrote: post #18
hkolk wrote: post #5

Better 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.

It’s not quite; HTTP/2 is not in fact uniformly superior to HTTP/1.1. Search around and you’ll find the reasons; all I’ll mention here is the two biggest keywords: WebSockets and head-of-line blocking.

The end result is that HTTP/2 is an improvement for most common workloads, but not all; especially in app-type scenarios with lots of mobile users with suboptimal connections and comparatively few requests (e.g. because you already do batching rather than sending zillions of requests), HTTP/2 can regress typical performance.

WebSockets over HTTP/2 is now specified in RFC 8441; not sure what the implementation status of that is. That solves one of the main problems.

My understanding is that HTTP/3 (with UDP-based QUIC instead of TCP) then resolves all remaining known systemic regressions between HTTP/1.1 and HTTP/2. So yeah, HTTP/1.1 to HTTP/3 should be pretty close to “free speed”.

But even then, it changes performance and load characteristics, and requires the appropriate software support, and that means that many users will need to be very careful about the upgrade, so that they don’t break things. So it’s not quite free after all.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#98

Post by chrisweekly »

chrismorgan wrote: post #96
baroffoos wrote: post #18

Earlier quoted context omitted.

Its amazing that not everyone is on http2 yet when its basically free speed.

It’s not quite; HTTP/2 is not in fact uniformly superior to HTTP/1.1. Search around and you’ll find the reasons; all I’ll mention here is the two biggest keywords: WebSockets and head-of-line blocking. The end result is that HTTP/2 is an improvement for most common workloads, but not all; especially in app-type scenarios with lots of mobile users with suboptimal connections and comparatively few requests (e.g. becaus…

H2 is nearly always better than HTTP/1, BUT it also turns some H1-specific perf optimization techniques (eg sharding, sprites...) into anti-patterns.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#99

Post by otabdeveloper2 »

appleflaxen wrote: post #67
otabdeveloper2 wrote: post #64

Earlier quoted context omitted.

> Better No, http2 is not better. We actually did the tests. We're not quite Google-scale, but having to handle tens of thousands of requests per second put us in the 'high load' camp.

this is not a useful statement without context or data.

Neither is the parent comment.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#100

Post by otabdeveloper2 »

jayd16 wrote: post #65
otabdeveloper2 wrote: post #64

Earlier quoted context omitted.

> Better No, http2 is not better. We actually did the tests. We're not quite Google-scale, but having to handle tens of thousands of requests per second put us in the 'high load' camp.

What was the issue? Why was it worse?

The extra CPU load for our balancers (nginx) didn't translate into any benefits for the user in performance or user experience. We ended up spending CPU cycles for no benefit.

Basically, HTTP/2 is tuned for a very specific case of Google traffic which pretty much never happens in places that aren't Google.

Post reply on HN