too bad 99% of routers drop keepalives
You send heartbeats! There might be a max-connection-time but I haven't run into it, my connections being dropped through amazon infrastructure was solved by sending a few bytes (': ') every 5 seconds or so.
Stop Wasting Connections, Use HTTP Keep-Alive
51–60 of 112 posts
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#52The 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.
If it's the first request on a connection, and it appears that the server closes the connection, I have a reasonable expectation that the server doesn't care for my request. When the request times out, who knows -- most tcp stacks won't tell me it the server acked it, but many networks will fake acks these days anyway.
On pipelined requests it's not too bad, you're not supposed to pipeline requests that aren't safe to retry. But pipelining ends up being somewhat rare in practice. Reusing an inactive connection is actually pretty risky, the server may be able to shut it down, your network may have silently dropped the connection already (some NAT timeouts are really short, I've seen cases in real mobile networks where the timeout was under a minute!).
I'm not thrilled with multiplexing in http/2, but the sensible stream closure would be really nice to have. If you see a goaway, you know it it saw your request or not, so you can resend it with a clear concensce.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#53What's the advice these days for when things are behind a reverse proxy or a load balancer, or both? I ran into issues where things end up balancing unevenly when multiple things are mixed.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#54too bad 99% of routers drop keepalives
You send heartbeats! There might be a max-connection-time but I haven't run into it, my connections being dropped through amazon infrastructure was solved by sending a few bytes (': ') every 5 seconds or so.
TCP keepalive should solve the problem too. Rather than HTTP keepalive.
(i.e. To handle the case of "HTTP-Request", "huge delay", "final response". Rather than a streaming/chunking reply that is very long/slow.)
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#55Earlier quoted context omitted.
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.
Possibly, and that's what I assumed at first, but I don't really see how: after sending the response the socket waits for more data in the form of another request from the user agent (I've tried with and without a poll / socket timeout).
Firefox does this perfectly. Chrome sends a FIN ACK in response to the response from the server, and it closes the connection its side, triggering the next recv() within the server to return 0 (or poll() to fail, depending on how I do it). But then it opens another connection after that with another request which could have been within the previous connection.
I also can't see Chrome doing it on non HTTPS websites in general when monitoring through wireguard, which is why I don't believe it's an issue with my server's implementation: I haven't actually observed Chrome utilise it at all on several computers on both Linux and Mac OS.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#56Or 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.
That has some major downsides. No caching, so any shared images need to be re-downloaded on every page. And the size of base64 if about 40% larger in my experience.
Request count is really not a big deal with HTTP/2 multiplexing.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#57Earlier quoted context omitted.
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.
Like which?
RHEL7/CentOS 7 is one of the more significant distributions out there, you can yum install version 1.12 of nginx. It wasn't until 1.13 shipped that nginx picked up any support for http/2.
On the Apache front, mod_http2 didn't ship until 2.4.17, again CentOS 7 and other RHEL7 based distributions lags behind on 2.4.6.
Sure, that doesn't mean you couldn't compile / install your own version, but for a lot of people that's just not likely to happen. Sticking with the distribution version keeps you within any support contracts, gets you security patches etc. and all the information you need to keep auditors and the like happy.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#58Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...
We don't need http, we need a better way of distributing and caching data.
Do you have a concrete suggestion? Or, a link to a page with a concrete suggestion?
It's easy to complain about almost anything - it tends to be a lot harder to make a proposal for its replacement.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#59Earlier quoted context omitted.
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.
Possibly, and that's what I assumed at first, but I don't really see how: after sending the response the socket waits for more data in the form of another request from the user agent (I've tried with and without a poll / socket timeout). Firefox does this perfectly. Chrome sends a FIN ACK in response to the response from the server, and it closes the connection its side, triggering the next recv() within the server t…
I don't know why you're seeing what you're seeing but your testing/monitoring setup sounds like it's at a bit too low level for the thing you're trying to figure out. A few basic things you might want (or should, really, if you're implementing HTTP from scratch) to try:
- Serve real content, say, a basic HTML page with a couple of external resources.
- Serve same and monitor (turn on all teh logs) with apache.
- Use the Chrome dev tools. In the network tab, right click on the column headers in the request list and enable the 'Connection ID' column. Keep in mind any modern browser will open concurrent connections in the base HTTP 1.1 case.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#60The 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.
Why do you think so? The server should report a Status Code for your 2nd request.
What header would carry this keepalive hint?