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

81–90 of 112 posts

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#81

Post by pizza »

h1d wrote: post #80
irrational wrote: post #63

Earlier quoted context omitted.

I imagine its more bureaucratic complexity than technical. This change would require lots of committee meetings, reviews, meetings, discussions, etc. at my company. It would probably take a year to decide to do it and 5 days to actually do it (Get all IT groups into a large war room, make the change on dev servers and then everyone has to completely test all their apps and sign off on it. Then do it again on staging.…

How do you get your work done when 1 line change takes so long.

Changing a version number is a special type of one line change because it only appears to be a one line change. In reality, that could end up being potentially millions of lines of code being changed in dependencies.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#82

Post by youngtaff »

cm2187 wrote: post #71
RussianCow wrote: post #44

Earlier quoted context omitted.

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.

Server push can’t be free. You need the web server to somehow know what resources will be required by the page and I still don’t understand how it doesn’t defeat browser caching but I presume it must involve some non trivial configuration.

Pretty sure server push is being deprecated - current implementation is 'only half a feature', as clients lack the ability to tell the server what's already in cache.

In theory the client can cancel the response for a resource it's already got but by the time the response bytes reach the client it's really too late

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#83

Post by adev_ »

manigandham wrote: post #39
merb wrote: post #26

Earlier quoted context omitted.

of course, because http2 is stateful and whenever the server or client whishes, they can send a close message. but stateful connection management comes with a cost, especially on tcp.

HTTP2 is stateless. It follows the same semantics as HTTP to be a generic stateless protocol. TCP has stateful connections, but both HTTP versions are being sent over TCP anyway so in that sense the transport was always stateful.

> HTTP2 is stateless. It follows the same semantics as HTTP to be a generic stateless protocol.

It is not currently. HTTP/2 header compression is stateful.

HTTP/2 is a protocol that appear stateless to the end user.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#84

Post by cm2187 »

youngtaff wrote: post #82
cm2187 wrote: post #71

Earlier quoted context omitted.

Server push can’t be free. You need the web server to somehow know what resources will be required by the page and I still don’t understand how it doesn’t defeat browser caching but I presume it must involve some non trivial configuration.

Pretty sure server push is being deprecated - current implementation is 'only half a feature', as clients lack the ability to tell the server what's already in cache. In theory the client can cancel the response for a resource it's already got but by the time the response bytes reach the client it's really too late

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.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#85

Post by fps_doug »

berkut wrote: post #34
iforgotpassword wrote: post #16

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

Just checked with Chromium 71 on Linux against lighttpd - keepalive works just fine, seeing html, css and js requested using the same connection. I'd also suspect something's up with your server's implementation.

FWIW, this is the reply header lighttpd sends:

    HTTP/1.1 200 OK
    Vary: Accept-Encoding
    Content-Encoding: gzip
    Last-Modified: Wed, 16 Sep 2015 08:50:41 GMT
    ETag: "713114043"
    Content-Type: application/javascript
    Accept-Ranges: bytes
    Content-Length: 9743
    Date: Fri, 08 Mar 2019 10:34:12 GMT
    Server: lighttpd/1.4.35

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#86

Post by beagle3 »

toast0 wrote: post #52
beagle3 wrote: post #37

Earlier quoted context omitted.

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 t…

“Reasonable” to a human, maybe.

If you are trying to build a robust system, in which requests don’t get lost, the difference is in quantity but not in quality - you must robustly handle the uncertainty in both cases.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#87

Post by noselasd »

RussianCow wrote: post #61
peterwwillis wrote: post #45

Earlier quoted context omitted.

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.

Could you be more specific, though? What's more complicated? I'm legitimately curious because I know very little about HTTP 2, but at work (not a tiny startup) we recently enabled it and it turned out to be a trivial change. Unless you're implementing the networking layer of your backend yourself, it seems like a change with practically no cost or tradeoff, as long as your server software supports it.

We had nginx running as a proxy for one of the apps. It runs on RHEL 7 because that's the standard for the enterprise. The stock nginx available in nginx did not support http/2.

* There is no chance someone will approve this server to run a nginx instance someone compiled themselves

* There is no chance someone will approve this server to run anything but nginx as that's the company standard for proxy servers.

* There is no chance someone will approve this server to install software from a 3. party yum repository. (And that's even a much bigger chance than someone allowing the firewall in front of that server to allow outgoing connections to the internet, so installing form 3. party repos could even be performed)

In the end there was likely 2 ways to get http/2 support for that service: * Pay some 3.d party to make it happen and be responsible for that server. * Wait until nginx in RHEL (the epel repository, which was approved and mirrored internally) supported http/2.

We did the latter, which happened many months later.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#88

Post by flomei »

mr_toad wrote: post #46
dana321 wrote: post #38

Or 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?

> Do any static site generators rewrite image links as data URIs?

I'm using Hugo and this is at least no default behaviour, not sure though if there is a switch for that.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#89

Post by VBprogrammer »

cm2187 wrote: post #84
youngtaff wrote: post #82

Earlier quoted context omitted.

Pretty sure server push is being deprecated - current implementation is 'only half a feature', as clients lack the ability to tell the server what's already in cache. In theory the client can cancel the response for a resource it's already got but by the time the response bytes reach the client it's really too late

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?
Post reply on HN