11 ms·
There isn't much point to HTTP/2 past the load balancer
- awinter-py 2y agoplus in my experience some h2 features behave oddly with load balancers I don't understand this super well, but could not get keepalives to cross the LB boundary w/ GCP
- _ache_ 2y agoHTTP keepalive it a feature from HTTP 1.1, not HTTP2.
- awinter-py 2y agoping frames?
- chucky_z 2y agogRPC?
- agf 2y agoSurprised not to see this mentioned in the article. Lots of places (including a former employer) have done tons of work to upgrade internal infrastructure to support HTTP/2 just so they could use gRPC. The performance difference from JSON-over-HTTP APIs was meaningful for us. I realize there are other solutions but this is a common one.
- 0x457 2y agoProbably because it only works correctly outside of browser. Browsers don't support "native" grpc. You normally use something with specifically gRPC support rather than just h2 in a spherical vacuum.
- nosequel 2y agoThis entirely. When I first read the title, I thought, lets see what they say about gRPC. gRPC is so much nicer working across applications compared to simple REST servers/clients.
- Animats 2y agoThe amusing thing is that HTTP/2 is mostly useful for sites that download vast numbers of tiny Javascript files for no really good reason. Like Google's sites.
- paulddraper 2y agoOr small icon/image files. Anyone remember those sprite files?
- cyberpunk 2y agoYou ever had to host map tiles? Those are the worst!
- SahAssar 2y agoIndeed, there is a reason most mapping libraries still support specifying multiple domains for tiles. It used to be common practice to setup a.tileserver.test, b.tileserver.test, c.tileserver.test even if they all pointed to the same IP/server just to get around the concurrent request limit in browsers.
- theandrewbailey 2y agoI've seen noticeable, meaningful speed improvements with HTTP/2 on pages with only 1 Javascript file. But I'd like to introduce you/them to tight mode: https://docs.google.com/document/d/1bCDuq9H1ih9iNjgzyAL0gpwNFiEP4TZS-YLRp_RuMlc https://docs.google.com/document/d/1bCDuq9H1ih9iNjgzyAL0gpwN... https://www.smashingmagazine.com/2025/01/tight-mode-why-browsers-produce-different-performance-results/ https://www.smashingmagazine.com/2025/01/tight-mode-why-brow...
- youngtaff 2y agoThat’s not quite true… lots of small files still have the overhead of IPC in the browser
- lmm 2y agoI think this post gets the complexity situation backwards. Sure, you can use a different protocol between your load balancer and your application and it won't do too much harm. But you're adding an extra protocol that you have to understand, for no real benefit. (Also, why do you even want a load balancer/reverse proxy, unless your application language sucks? The article says it "will also take care of serving static assets, normalize inbound requests, and also probably fend off at least some malicious actors", but frankly your HTTP library should already be doing all of those. Adding that extra piece means more points of failure, more potential security vulnerabilities, and for what benefit?)
- pixelesque 2y ago> Sure, you can use a different protocol between your load balancer and your application and it won't do too much harm. But you're adding an extra protocol that you have to understand, for no real benefit. Well, that depends... At a certain scale (and arguably, not too many people will ever need to think about this), using UNIX sockets (instead of HTTP TCP) between the application and load balancer can be faster in some cases, as you don't go through the TCP stack... > Also, why do you even want a load balancer/reverse proxy, unless your application language sucks? Erm... failover... ability to do upgrades without any downtime... it's extra complexity yes, but it does have some benefits...
- lmm 2y ago> At a certain scale (and arguably, not too many people will ever need to think about this), using UNIX sockets (instead of HTTP TCP) between the application and load balancer can be faster in some cases, as you don't go through the TCP stack... Sure (although as far as I can see there's no reason you can't keep using HTTP for that). You can go even further and use shared memory (I work for a company that used Apache with Jk back in the day). But that's an argument for using a faster protocol because you're seeing a benefit from it, not an argument for using a slower protocol because you can't be bothered to implement the latest standard.
- tuukkah 2y ago
- treve 2y agoFirst 80% of the article was great, but it ends a bit handwavey when it gets to its conclusion. One thing the article gets wrong is that non-encrypted HTTP/2 exists. Not between browsers, but great between a load balancer and your application.
- fragmede 2y agoNot according to Edward Snowden, if you're Yahoo and Google.
- ChocolateGod 2y agoYou can just add encryption to your backend private network (e.g. Wireguard) Which has the benefit of encrypting everything and avoids the overhead of starting a TLS socket for every http connection.
- jeroenhd 2y agoIf you're going that route, you may as well just do HTTPS again. If you configure your TLS cookies and session resumption right, you'll get all of the advantages of fancy post-quantum crypto without having to go back to the days of manually setting up encrypted tunnels like when IPSec did the rounds.
- soraminazuki 2y agoWait, are some people actively downvoting advice encouraging the use of encryption in internal networks? I sure hope those people don't go anywhere near the software industry because that's utterly reckless in the post-Snowden world.
- fragmede 2y agoPeople are all over the place. I had to talk someone into SSH over VPN being double encrypted isn’t a waste.
- tuukkah 2y ago
- feyman_r 2y agoCDNs like Akamai still don’t support H2 back to origins. That’s likely not because of the wisdom in the article per se, but because of rising complexity in managing streams and connections downstream.
- wczekalski 2y agoIt is very useful for long lived (bidirectional) streams.
- m00x 2y agoOnly if you're constrained on connections. The reason that HTTP2 is much better for websites is because of the slow starts of TCP connections. If you're already connected, you don't suffer those losses, and you benefit from kernel muxing.
- 0x457 2y agoYou've missed the bidirectional part.
- nightpool 2y agoHow is http2 bidirectional streams better than websockets? I thought they were pretty much equivalent.
- 0x457 2y agoWell, IMO h2 streams are more flushed out and offer better control than websockets, but that's just my opinion. In fact, websockets are your only "proper" option if you want hat bidirectional stream be binary - browsers don't expose that portion of h2 to JS. Here is a silly thing that is possible with h2 over a single connection, but not with websockets: Multiple page components (Islands) each have their own stream of events over a single h2 connection. With websockets, you will need to roll your own multiplexing[1]. [1]: I think you can multiplex multiple websockets over a single h2 connection tho, but don't quote me on this.
- nightpool 2y agoMultiplexing websockets has always seemed trivial to me. Curious to learn more about h2 streams though! Support is coming to JS and has already landed on Firefox and Chrome: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API https://developer.mozilla.org/en-US/docs/Web/API/WebTranspor...
- LAC-Tech 2y agoPersonally, this lack of support doesn’t bother me much, because the only use case I can see for it, is wanting to expose your Ruby HTTP directly to the internet without any sort of load balancer or reverse proxy, which I understand may seem tempting, as it’s “one less moving piece”, but not really worth the trouble in my opinion. That seems like a massive benefit to me.
- miyuru 2y agoThe TLS requirement from HTTP2 also hindered http2 origin uptake. The TLS handshake adds latency and is unnecessary on some instances. (This is mentioned in heading "Extra Complexity" in the article)
- tankenmate 2y agoFor HTTP/3 you get 0-RTT however which largely mitigates this.
- stavros 2y ago0-RTT resumption (unless I'm mistaken), which doesn't help with the first connection (but that might be OK).
- rochacon 2y agoCorrect, to achieve 0-RTT the application need to perform the handshake/certificate exchange at least once, otherwise, how would it encrypt the payload? This could be cached preemptively iirc, but it is not worth it. The problem will be that QUIC uses more userland code and UDP is not as optimized as TCP inside kernels. So far, the extra CPU penalty has discouraged me from adopting QUIC everywhere, I've kept it mostly on the edge-out where the network is far less reliable.
- bawolff 2y agoUmm dont you get 0-RTT resumption in all versions of http? Its a TLS feature not an http feature. It does not require QUIC
- deleted 2y ago[deleted]
- Guthur 2y agoThe RFC said "SHOULD not" not "MUST not" couldn't we have just ignored the 2 connection limit?
- KingMob 2y agoThat's what browsers actually did.
- petee 2y agoCame here to say the same thing; had they read the RFC they'd realize it's not actually a limit, just a suggestion - thats why its in the "Practical Considerations" section too. Whomever downvoted you is probably unaware words like SHOULD have specific meaning in RFCs
- youngtaff 2y agoBrowsers started ignoring the 2 connection limit on H/1.x long before H2 came along
- jchw 2y agoPersonally, I'd like to see more HTTP/2 support. I think HTTP/2's duplex streams would be useful, just like SSE. In theory, WebSockets do cover the same ground, and there's also a way to use WebSockets over HTTP/2 although I'm not 100% sure how that works. HTTP/2 though, elegantly handles all of it, and although it's a bit complicated compared to HTTP/1.1, it's actually simpler than WebSockets, at least in some ways, and follows the usual conventions for CORS/etc. The problem? Well, browsers don't have a JS API for bidirectional HTTP/2 streaming, and many don't see the point, like this article expresses. NGINX doesn't support end-to-end HTTP/2. Feels like a bit of a shame, as the streaming aspect of HTTP/2 is a more natural evolution of the HTTP/1 request/response cycle versus things like WebSockets and WebRTC data channels. Oh well.
- withinboredom 2y ago[flagged]
- evalijnyi 2y agoIs it just me or did anyone else completely miss Caddy for it's opening sentence? >Caddy is a powerful, extensible platform to serve your sites, services, and apps, written in Go. To me it reads that if your application is not written in Go, don't bother
- unification_fan 2y agoWhy should a reverse proxy give a single shit about what your lang application is written in
- evalijnyi 2y agoIt shouldn't, which is why I think wording there is strange. Nginx doesen't market itself as "platform to serve your sites, services, and apps, written in C". Reading the first sentence I don't even know what Caddy is, what does a platform mean in this context? Arriving on Nginx's site the first sentence visible to me is >nginx ("engine x") is an HTTP web server, reverse proxy, content cache, load balancer, TCP/UDP proxy server, and mail proxy server. Which is perfect
- a-dub 2y agoi think it probably varies from workload to workload. reducing handshake time and header compression can have substantial effects. it's a shame server side hunting/push never caught on. that was always one of the more interesting features.
- KingMob 2y agoIt didn't catch on because it was hard to see the benefits, and if done incorrectly, could actually make things slightly slower. Essentially, the server had to do things like compute RTT and understand the status of the browser's cache to do optimal push.
- a-dub 2y agohmm, maybe the client could include a same origin cache state bloom filter in the request. although i suppose it's a solved problem these days.
- KingMob 2y agoBloom filters are small relative to the amount of data they can hash, but aren't realistic bloom filters still tens of kB at minimum? Might be too heavyweight to send up.
- hiAndrewQuinn 2y agoThe maximum number of connections thing in HTTP/1 always makes me think of queuing theory, which gives surprising conclusions like how adding a single extra teller at a one-teller bank can cut wait times by 50 times, not just by 2. However, I think the problem is the Poisson process isn't really the right process to assume. Most websites which would run afoul of the 2/6/8/etc connections being opened are probably trying to open up a lot of connections at the same time. That's very different from situations where only 1 new person arrives every 6 minutes on average, and 2 new people arriving within 1 second of each other is a considerably rarer event. [1]: https://www.johndcook.com/blog/2008/10/21/what-happens-when-you-add-a-new-teller/ https://www.johndcook.com/blog/2008/10/21/what-happens-when-...
- amluto 2y ago[flagged]
- timewizard 2y ago[flagged]
- efdee 2y ago[flagged]
- arjie 2y agoAlmost every web forum enters a phase where participants bring in their pet politics into unrelated discussions. Whether they last or not depends entirely on whether the flamebait/troll creates a large reply structure or a non-existent one. This is why shadowbans are more effective than large groups of people responding angrily. Or, to cite the Deep Magic: "don't feed the trolls".
- timewizard 2y agoIt's hacker news. If you cared about the plight of these people why not organize to do something about it? Or is this just finding suffering in the world and then personally capitalizing on it? I get the dynamic. I find it disgusting here, in particular.
- _ache_ 2y agoI remember been bashed on HN saying that HTTP is hard. Yet, I saw non-sens here in the comment about HTTP. The whole article is good but: > HTTP/2 is fully encrypted, so you need all your application servers to have a key and certificate Nope. h2c is a thing and is official. But the article is right, the value HTTP/2 provides isn't for LAN, so HTTP 1.1 or HTTP/2 it doesn't matter much. HTTP/3 however, is fully encrypted. h3c doesn't exists. So yeah, HTTP3 slower you connection, it isn't suited for LAN and should not be used. BUT if you actually want to encrypt even in you LAN, use HTTP/3, not HTTP/2 encrypted. You will have a small but not negligible gain from 0-RTT.
- gmokki 2y agoI would not use http/3 for lan. Even the latest Linux kernels struggle with it. Http/1 aka TCP has fully supported encryption and other offload support. UDP consumes still much more CPU for same amount of traffic.
- _ache_ 2y agoDo you have source for that? I'm very interested. There is no technical reason for UDP to be slower than TCP (at CPU level). The only field that is computed in UDP is checksum and the same exists in TCP and it must be recomputed each time someone actually re-route the packet (eg: bridge to VM) since TTL is decreased. So I doubt your assertion. _____ Writing my comment I understood what your are talking about. There is a bunch of encryption done at user mode in HTTP/3 that doesn't need to be done in user mode. In HTTP/2 it was sometime done in kernel mode (kTTL), so was quicker. The slowness comes for the CPU needed it to be copied out of kernel mode. I didn't follow the whole story so I trust you on this.
- 0x457 2y agohttps://docs.kernel.org/networking/tls-offload.html https://docs.kernel.org/networking/tls-offload.html
- SahAssar 2y agoEncryption is one thing (if you run kTLS which is still not done in most manual setups) but the much bigger IIRC is how much of the networking stack needs to run in userspace and has not been given the optimization love of TCP. If you compared non-kTLS h2 with non-kTLS h3 over a low-latency link the h2 connection could handle a lot more traffic compared to h3. That is not to say that h3 does not have its place, but the networking stacks are not optimized for it yet.
- kam1kazer 2y agonah, I'm using HTTP/3 everywhere
- kittikitti 2y agoIf we ever get to adopting this, I will send every byte to a separate IPv6 address. Big Tech surveillance wouldn't work so many don't see a point like the author.
- fulafel 2y agoThere's a security angle: Load balancers have big problems with request smuggling. HTTP/2 does something to the picture, maybe someone is more up to date if it's currently better or worse? ref: https://portswigger.net/web-security/request-smuggling https://portswigger.net/web-security/request-smuggling
- nitely 2y agoIn theory request smuggling is not possible with end-to-end HTTP/2. It's only possible if there is a downgrade to HTTP/1 at some point.
- SahAssar 2y agoA h2 proxy usually wouldn't proxy through the http2 connection, it would instead accept h2, load-balance each request to a backend over a h2 (or h1) connection. The difference is that you have a h2 connection to the proxy, but everything past that point is up to the proxies routing. End-to-end h2 would be more like a websocket (which runs over HTTP CONNECT) where the proxy is just proxying a socket (often with TLS unwrapping).
- nitely 2y ago> A h2 proxy usually wouldn't proxy through the http2 connection, it would instead accept h2, load-balance each request to a backend over a h2 (or h1) connection. Each connection need to keep state of all processed requests (the HPACK dynamic headers table), so all request for a given connection need to be proxied through the same connection. Not sure I got what you meant, though. Apart from that, I think the second sentence of my comment makes clear there is no smuggling as long as the connection before/past proxy is http2, and it's not downgraded to http1. That's all that I meant.
- albinowax_ 2y agoYes HTTP/2 is much less prone to exploitable request smuggling vulnerabilities. Downgrading to H/1 at the load balancer is risky.
- 2y ago
- deleted 2y ago[deleted]
- spintin 2y ago[dead]
- sluongng 2y agoHmm it’s weird that this submission and comments are being shown to me as “hours ago” while they are all 2 days old
- wiggidy 2y agoYeah yeah, whatever, just make it work in the browser so I can do gRPC duplex streams, thank you very much.
- nitwit005 2y agoI'd agree it's not critical, but discard the assumption that requests within the data center will be fast. People have to send requests to third parties, which will often be slow. Hopefully not as slow as across the Atlantic, but still magnitudes worse than an internal query. You will often be in the state where the client uses HTTP2, and the apps use HTTP2 to talk to the third party, but inside the data center things are HTTP1.1, fastcgi, or similar.
- nightpool 2y agoWhy does HTTP2 help with this? Load balancers use one keepalive connection per request and don't experience head of line blocking. And they have slow start disabled. So even if the latency of the final request is high, why would HTTP2 improve the situation?
- nitwit005 2y agoIf every request is quick, you can easily re-use connections, file handles, threads, etc. If requests are slow, you will often need to spin up new connections, as you don't want to wait for the response that might take hundreds of milliseconds. But I did start by saying it's not important. It's a small difference, unless you hit a connection limit.
- najmlion 2y agoHttp2 is needed for a GRPC route on OpenShift.
- jiggawatts 2y agoGoogle measured their bandwidth usage and discovered that something like half was just HTTP headers! Most RPC calls have small payloads for both requests and responses. HTTP/2 compresses headers, and that alone can make it worthwhile to use throughout a service fabric.
- gwbas1c 2y ago> So the main motivation for HTTP/2 is multiplexing, and over the Internet ... it can have a massive impact. > But in the data center, not so much. That's a very bold claim. I'd like to see some data that shows little difference with and without HTTP/2 in the datacenter before I believe that claim.
- 0xbadcafebee 2y agoDatacenters don't typically have high latency, low bandwidth, and varying availability issues. If you have a saturated http/1.1 network (or high CPU use) within a DC you can usually just add capacity.
- gwbas1c 2y agoWell, when you assume you make an ass out of u and me! (I get that this probably isn't a high-priority area to study.) > If you have a saturated http/1.1 network (or high CPU use) within a DC you can usually just add capacity. Then I'd be curious how much a lack of HTTP/2 support in the application layer costs. It might be small change for an early stage startup, but when companies get large, these corner cases end up paying peoples' salaries.
- immibis 2y agoIf your load balancer is converting between HTTP/2 and HTTP/1.1, it's a reverse proxy. Past the reverse proxy, is there a point to HTTP at all? We could also use SCGI or FastCGI past the reverse proxy. It does a better job of passing through information that's gathered at the first point of entry, such as the client IP address.
- SJC_Hacker 2y agoKeeping everything HTTP makes testing a bit easier.
- monus 2y ago> bringing HTTP/2 all the way to the Ruby app server is significantly complexifying your infrastructure for little benefit. I think the author wrote it with encryption-is-a-must in the mind and after he corrected those parts, the article just ended up with these weird statements. What complexity is introduced apart from changing the serving library in your main file?
- byroot 2y agoYou are correct about the first assumption, but even without encryption dealing with multiplexing significantly complexify things, so I still stand by that statement. If you assume no multiplexing, you can write a much simpler server.
- nitely 2y agoIn reality you would build your application server on top of the HTTP/2 server, so you'd not have to deal with multiplexing, the server will hide that from you, so it's the same as an HTTP/1 server (ex: you pass some callback that gets called to handle the request). If you implement HTTP/2 from scratch, multiplexing is not even the most complex part... It's rather the sum of all parts: HPACK, flow-control, stream state, frames, settings, the large amount of validations, and so on.
- byroot 2y agoThis may be true with some stacks, but my answer has to be understood in the context of Ruby where the only real source of parallelism is `fork(2)`, hence the natural way to write server is an `accept` loop, which fits HTTP/1 very well, but not HTTP/2.
- nitely 2y agoThere is a gem that implements lightweight threads[0], and there is an HTTP/2 server that seems to abstract things out[1]. Your point probably still holds in the context of ruby + async + http/2; but then it's not http/2 fault, but rather ruby for not having a better concurrency story, like say golang. [0]: https://github.com/socketry/async https://github.com/socketry/async [1]: https://github.com/socketry/falcon https://github.com/socketry/falcon
- vasilvv 2y agoThe article seems to make an assumption that the application backend is in the same datacenter as the load balancer, which is not necessarily true: people often put their load balancers at the network edge (which helps reduce latency when the response is cached), or just outsource those to a CDN vendor. > In addition to the low roundtrip time, the connections between your load balancer and application server likely have a very long lifetime, hence don’t suffer from TCP slow start as much, and that’s assuming your operating system hasn’t been tuned to disable slow start entirely, which is very common on servers. A single HTTP/1.1 connection can only process one request at a time (unless you attempt HTTP pipelining), so if you have N persistent TCP connections to the backend, you can only handle N concurrent requests. Since all of those connections are long-lived and are sending at the same time, if you make N very large, you will eventually run into TCP congestion control convergence issues. Also, I don't understand why the author believes HTTP/2 is less debuggable than HTTP/1; curl and Wireshark work equally well with both.
- dgoldstein0 2y agoI think the more common architecture is for edge network to terminate SSL, and then transmit to the load balancer which is actually in the final data center? In which case you can http2 or 3 on both those hops without requiring it on the application server. That said I still disagree with the article's conclusion: more connections means more memory so even within the same dc, there should be benefits of http2. And if the app server supports async processing, there's value in hitting it with concurrent requests to make the most of its hardware, and http1.1 head of line blocking really destroys a lot of possible perf gains when the response time is variable. I suppose I haven't had a true bake off here though - so it's possible the effect of http2 in the data center is a bit more marginal than I'm imagining.
- hansvm 2y agoHTTP2 isn't free though. You don't have as many connections, but you do have to track each stream of data, making RAM a wash if TLS is non-existent or terminated outside your application. Moreover, on top of the branches the kernel is doing to route traffic to the right connections, you need an extra layer of branching in your application code and have to apply it per-frame since request fragments can be interleaved.
- dangoodmanUT 2y agoYet in experience I see massive speedups on my LOCALHOST going from 1.1 to 2, where are the numbers and tests OP?
- littlecranky67 2y agoOne overlooked point is ephemeral source port exhaustion. If a load balancer forwards a HTTP connection to a backend system, it needs a TCP source port for the duration of that connection (not destination port, which is probably 80 or 443). That limits the number of outgoing connections to less than 65535. A common workaround is to use more outgoing IP addresses to the backends as source IPs, thus multiplying the available number of source ports to 65535 times number_of_ips. HTTP/2 solves this, as you can multiplex requests to backend servers over a single TCP socket. So there is actually a point of using HTTP/2 for load_balancer <-> backend_system connections.
- mike_d 2y agoThis has been solved for 10+ years. Properly configure your load balancer with HTTP keep alive and piplining.
- littlecranky67 2y agoHTTP keep-alive still limits the number of outgoing connections to 65535. Pipelining suffers from the known same issues addressed in the article. But I agree, it is a solved problem unless you really have a lot of incoming connections. When you use multiple outgoing ip addresses that fixes that even for very busy load balancers, and since IPv6 is common today you will likely have a /64 to draw addresses from.
- mike_d 2y agoOn modern systems you have about 28k ephemeral ports available. 65,535 is the total number of ports (good luck trying to use them all). Either way, if you have more than 20k connections open to a single backend (remember linux does connection tracking using the 4 tuple, so you can reuse a source port to different destinations) you are doing something seriously wrong and should hire competent network engineering folks.
- littlecranky67 2y ago