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

HTTP/2 and HTTP/3 explained

alexandrehtrb.github.io

Post reply on HN
Print view View original

71–80 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#71

Post by liveoneggs »

ithkuil wrote: post #18
KaiserPro wrote: post #13

> This is called head-of-line blocking. In the diagram below, request 2 cannot be sent until response 1 arrives, considering that only one TCP connection is used. Thats not really head of line blocking, because in HTTP1.1 you'd just open up another connection. The issue with HTTP1.1 is that opening up lots of connections can introduce lots of latency, especially if you are doing Encryption. HTTP1.1 performs much much…

I find it difficult to believe that the team that built the prototype for http/2 (SPDY), implemented it for chrome, tested it on gazillions of customers around the world, wasn't bothered to talk to anyone who did networking. Sure you can argue that the tradeoffs they selected were the wrong tradeoffs and that they may have been biased by their narrow domain specific goals (reducing latency to render an average web pa…

Seeing early QUIC development not account for the DDoS potential of choosing UDP makes it pretty clear that networking is not top-of-mind.

Re: HTTP/2 and HTTP/3 explained

#72

Post by avianlyric »

pi-e-sigma wrote: post #60
jchw wrote: post #33

Earlier quoted context omitted.

HTTP/1.1 (RFC2616) specified a limit of two connections per server, which most browsers initially interpreted to mean per-origin, which still lead to quite a lot of unnecessary blocking. I think browsers eventually decided to increase that to 6, but as evidenced by viewing the "Network" tab of the Developer Tools on a lot of modern pages, it is in fact not very uncommon anymore to have a substantially larger number o…

This limit is completely artificial. Let's limit HTTP/2 to maximum 6 multiplexed streams per connection and see how it fares with HTTP1.1 with 6 TCP connections to the server. All of sudden HTTP1.1 wins :)

Have you got any data to backup that claim?

It’s also a specious argument anyway. The six connection limit isn’t purely artificial, opening and tracking TCP connection state is expensive, and happens entirely in the kernel. There’s a very real cap on how many TCP connections a machine can serve before the kernel starts barfing, and that cap is substantially lower than the number of multiplexed streams you can push over a single TCP connection.

You’re also completely ignoring TCP slow start process, which you can bet your bottom dollar will prevent six TCP streams beating six multiplexed streams over a single TCP stream when measuring latency from first connection.

Re: HTTP/2 and HTTP/3 explained

#73

Post by avianlyric »

golebiewsky wrote: post #16
pi-e-sigma wrote: post #14

Earlier quoted context omitted.

[flagged]

I was actually curious why SACK's don't resolve issue, but according to https://stackoverflow.com/questions/67773211/why-do-tcp-sele... > Even with selective ACK it is still necessary to get the missing data before forwarding the data stream to the application.

Yes, TCP provides the guarantee that your application will always receive data in the same order it was sent. Your kernel will do the necessary buffering and packet reordering to provide that guarantee.

So SACK might reduce packet resends, but it doesn’t prevent the latency hit that comes for having to waiting for the data went missing. Even if your application is capable of either handling out-of-order data, or is simply capable of handling missing data.

Re: HTTP/2 and HTTP/3 explained

#74

Post by jillesvangurp »

GuB-42 wrote: post #22
sylware wrote: post #12

If HTTP[23] are more complex than HTTP1.1, it is a mistake.

Most of the complexity actually comes from encryption. If you don't need encryption, HTTP/1.1 is great. Especially since unencrypted HTTP/2 and 3 are usually not supported. HTTP/2 is sometimes considered a mistake. HTTP/3 is certainly more complex than HTTP/1.1, but that's in large part because it is actually several protocols in one. It replaces TCP with QUIC and therefore implements its features. It also has encryp…

It's more complex for server builders and client library builders (libcurl, netty, etc.). For web application developers, it's essentially zero effort if you use decent cloud based hosting.

We have our stuff in Google cloud. I just launched a website (while spaceX was launching a rocket) there. Simple bucket behind our load balancer. It serves http3 if your browser can handle it. If you check with curl (which can't) it falls back to http2. Our API runs there as well and a few other things. Just works. It's not even a configuration option. It's just part of the package.

Most of this stuff is either necessary complexity or useful complexity. Running without TLS is not really something you should be doing over a public network. And some people would argue even on a private network. So that's necessary complexity.

UDP vs. TCP is a no-brainer as well for mobile and roaming type use cases. Just a lot easier to deal with via UDP. With TCP you have to deal with connections timing out, connection overhead, etc. With UDP, which is connection less, switching networks is a lot less dramatic.

And then there's the notion of not needing multiple connections to download/stream multiple things. Since UDP has no connections, HTTP3 multiplexes it's own notion of "connections" on top of that. So, you are not constrained by browsers limiting you to just 4 or 8 connections per website (or whatever the number is these days). A bit more complex to implement but useful.

Re: HTTP/2 and HTTP/3 explained

#75

Post by azinman2 »

KaiserPro wrote: post #65
ithkuil wrote: post #18

Earlier quoted context omitted.

I find it difficult to believe that the team that built the prototype for http/2 (SPDY), implemented it for chrome, tested it on gazillions of customers around the world, wasn't bothered to talk to anyone who did networking. Sure you can argue that the tradeoffs they selected were the wrong tradeoffs and that they may have been biased by their narrow domain specific goals (reducing latency to render an average web pa…

> But I cannot believe that the mistakes were caused by them just not being aware of how networks work or, worse, failing to talk with somebody that did As someone who was part of the rollout of HTTP2 for a $large_website, I can confirm that "this will harm mobile performance" was outright and flatly rejected. This included people who were our reps on the w3c. I just had to sit there and wait for the real world metri…

So what was that real world effect?

Re: HTTP/2 and HTTP/3 explained

#76

Post by pi-e-sigma »

avianlyric wrote: post #72
pi-e-sigma wrote: post #60

Earlier quoted context omitted.

This limit is completely artificial. Let's limit HTTP/2 to maximum 6 multiplexed streams per connection and see how it fares with HTTP1.1 with 6 TCP connections to the server. All of sudden HTTP1.1 wins :)

Have you got any data to backup that claim? It’s also a specious argument anyway. The six connection limit isn’t purely artificial, opening and tracking TCP connection state is expensive, and happens entirely in the kernel. There’s a very real cap on how many TCP connections a machine can serve before the kernel starts barfing, and that cap is substantially lower than the number of multiplexed streams you can push ov…

Yes I do have data. You can have that data, too. Just do the testing yourself.

Re: HTTP/2 and HTTP/3 explained

#77

Post by brickteacup »

pi-e-sigma wrote: post #19
golebiewsky wrote: post #16

Earlier quoted context omitted.

I was actually curious why SACK's don't resolve issue, but according to https://stackoverflow.com/questions/67773211/why-do-tcp-sele... > Even with selective ACK it is still necessary to get the missing data before forwarding the data stream to the application.

Which is exactly the same in HTTP2/3. You can't forward a stream when it's missing some data.

Yes, bytes from a *logical* stream need to be delivered in order. But in HTTP2 (3) multiple logical streams are multiplexed on top of one physical TCP (QUIC) connection. In the HTTP2 case this means that a dropped segment from logical stream A will block delivery of subsequent segments from an different logical stream B (which is bad for obvious reasons). QUIC doesn't have this problem, which is a large part of its value proposition.

Re: HTTP/2 and HTTP/3 explained

#78

Post by pi-e-sigma »

jsnell wrote: post #64
pi-e-sigma wrote: post #54

Earlier quoted context omitted.

So again, why HTTP3 is pushed when HTTP2 was meant to be the holy grail? Seems that even Google doesn't consider HTTP2 to be so great.

Umm... Like, pretty clearly H2 wasn't meant to be the Holy Grail? Not sure where you're getting that from. (Though as an aside, it feels like you've now backtracked from "H2 is a failure that's worse than H1" through "H2 was a marginal improvement" to "H2 wasn't the holy grail".) It didn't need to be the Holy Grail to be worth creating. It just needed to be better than H1 was, or better than what H1 could be evolved…

Oh so typical moving goal posts. Once your little project failed to deliver you claim that it wasn't really meant to provide revolutionary improvement.

Re: HTTP/2 and HTTP/3 explained

#79

Post by kstrauser »

pi-e-sigma wrote: post #14
jeltz wrote: post #7

Earlier quoted context omitted.

You will need to back up that accusation, because now you are accusing Daniel Stenberg of being a liar. On paper HTTP shouldperform much better than HTTP 1.1 and especially HTTP 2 on links with high packet loss since TCP handles packet loss very poorly. https://http3-explained.haxx.se/en/why-quic

[flagged]

> you folks just don't even bother to learn TCP first before shitting on it.

Let me stop you right there. I promise you you're not the only person who really knows how TCP works. The people who made HTTP2 and HTTP3 are clearly smart, knowledge folks who have a different perspective than you do. It's OK to disagree with them, but it's a bad look for you to assume that they're ignorant on the subject.

Re: HTTP/2 and HTTP/3 explained

#80

Post by pi-e-sigma »

brickteacup wrote: post #77
pi-e-sigma wrote: post #19

Earlier quoted context omitted.

Which is exactly the same in HTTP2/3. You can't forward a stream when it's missing some data.

Yes, bytes from a *logical* stream need to be delivered in order. But in HTTP2 (3) multiple logical streams are multiplexed on top of one physical TCP (QUIC) connection. In the HTTP2 case this means that a dropped segment from logical stream A will block delivery of subsequent segments from an different logical stream B (which is bad for obvious reasons). QUIC doesn't have this problem, which is a large part of its v…

Except it doesn't work in practice and real world data proves it. Multiplexing streams inside of a single TCP connection don't magically make your data link less prone to dropped packets or high latency.
Post reply on HN