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

61–70 of 112 posts

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#61

Post by RussianCow »

peterwwillis wrote: post #45
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.

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.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#62

Post by copperx »

dagenix wrote: post #58
dana321 wrote: post #40

Earlier quoted context omitted.

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.

A proposed solution shouldn't be required to complain about something. Just as submitting a patch isn't required when filing a bug report.

A justification for the complaint is necessary to be taken seriously, though. And the OP didn't provide one.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#63

Post by irrational »

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.

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. Then again on prod. It would probably require a bunch of all nighters. I wish I was joking.)

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#64

Post by otabdeveloper2 »

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

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

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#65

Post by jayd16 »

otabdeveloper2 wrote: post #64
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...

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

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#66

Post by peterwwillis »

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.

I haven't implemented it myself, but here's some example scenarios:

Policy: What is allowed architecturally and what isn't? Are there regulatory requirements? Do you have strict enforcement mechanisms?

Instrumentation: Do you need to watch traffic going over the wire? Will your network filters flag it? Do you have application proxies that route traffic based on payload? How is it going to handle multiplexing if existing solutions don't take it into account? Are you using any proprietary stuff?

QA: Every client, server and intermediary may be using different implementations, and that means bugs. Have you certified all the devices in the chain to make sure they operate correctly? (It doesn't matter, until it really matters)

Operation: Each implementation needs to be upgraded one at a time, so the extent of your technology will determine how long and potentially error-prone all this will be. It will be different for each org, but definitely take a long time for really big ones.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#67

Post by appleflaxen »

otabdeveloper2 wrote: post #64
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...

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

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#68

Post by jeffsmith82 »

Twirrim wrote: post #57
dcbadacd wrote: post #43

Earlier quoted context omitted.

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

nginx is not shipped by RHEL so you are probably pulling from epel. you can also pull the latest stable version directly from nginx's repo http://nginx.org/en/linux_packages.html#RHEL-CentOS which has supported http2 since RHEL 7.4 when they released alpn support in openssl.

https://ma.ttias.be/centos-7-4-ship-tls-1-2-alpn/

you can also install the latest version of apache from red hats software collections repo that supports http2 but it throws everything into /opt/rh/rh-httpd24/ which is a bit weird.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#69

Post by ori_b »

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 also a huge amount of complexity.

Re: Stop Wasting Connections, Use HTTP Keep-Alive

#70

Post by berkut »

pvg wrote: post #59
berkut wrote: post #55

Earlier quoted context omitted.

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…

Thanks, but I've done this (although used Nginx instead).

The web server I've written is now serving several websites I'm hosting, some of which have thousands of images, so there's plenty of scope for connection re-use.

Each connection ID is different within dev tools in Chrome - although errors have 0 - (often sequential, sometimes there are huge gaps). And this is the same with HTTP websites on the net (just tried www.briscoes.co.nz and am still seeing the same thing in Chrome 72).

Using Wireshark I can see that Firefox is doing the correct thing, so I'm not sure why you think what I'm looking at is too low-level: I think it's pretty clearly something the client's doing at the TCP level to close the connection its end after its received the content length.

It may well be that I'm not sending a header Chrome's looking for, but I'm not sure what it is, as in its request it's sending "Connection: keep-alive", and the response has the same, and Firefox works fine.

It's almost like it's a client configuration or something, but I don't know what that would be, as I've tried on several machines.

Post reply on HN