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

31–40 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#31

Post by IgorPartola »

subtra3t wrote: post #29
IgorPartola wrote: post #26

> the UDP protocol wasn't optimized by routers and operating systems over the last decades due to its low usage, making it comparatively slower than TCP What exactly does this mean?

I haven't read the article yet but I think that means that UDP was used less than TCP and so routers/operating systems didn't optimize for it as much as they did for TCP. Hope this helps.

Right that’s all it says on this subject. I am curious about what optimizations TCP has benefitted from that we’re not but could be applied to UDP.

Re: HTTP/2 and HTTP/3 explained

#32

Post by aerfio »

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

Earlier quoted context omitted.

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…

Then HTTP[23] are significantly more costly to implement, they are a mistake then. Nothing to brag about then.

I don't really see how one leads to another, could you elaborate? Looking at these protocols, it seems to me that later versions of HTTP attempt to address errors resulting from the overly simplistic design of HTTP/1.1.

Re: HTTP/2 and HTTP/3 explained

#33

Post by jchw »

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…

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 of resources per origin.

While it's true that HTTP/2 can be worse than HTTP/1.1, I don't think it usually is; it's pretty easy to demonstrate just how much better HTTP/2 is over a typical Internet connection. SPDY and HTTP/2 were clearly better and rarely worse, whereas HTTP/3 is almost never worse (maybe when interplay with TCP rate control is poor?) On very unreliable and very high latency connections it can definitely go the other way, but statistically my experience is that a large majority of cases see an improvement on plain-old HTTP/2.

That said, for all of the complexity HTTP/2 adds, it is kind of a nice protocol. I like that all of the "special" parts of the HTTP/1.1 request and response were just turned into header fields. HPACK is a minor pain in the ass, but it is pretty efficient. You get multiple concurrent bidirectional streams per connection and they can each send headers/trailers. There's even the MASQUE protocol, which enables unreliable datagrams with HTTP/3. Put together this makes HTTP/2 and HTTP/3 amazingly versatile protocols that you can really use for all kinds of shit, which makes sense given the legacy of HTTP/1.1.

There are some pitfalls even still. For example, all of this added complexity has made life a bit harder for load balancing and middleboxes. TCP level load balancing or round robin is basically defeated by using HTTP/2 multiplexing, without the client being explicitly cautious of this.

Re: HTTP/2 and HTTP/3 explained

#34

Post by GoblinSlayer »

ghusbands wrote: post #15
GoblinSlayer wrote: post #2

>In the diagram below, request 2 cannot be sent until response 1 arrives, considering that only one TCP connection is used. That's wrong, request 2 can be sent before response 1 arrives. Blocking is inability to receive response 2 until response 1 arrives. With HTTP/2 responses can be unordered.

To be very clear/direct, the HTTP pipelining you're referring to never fully worked and was always hit with problems with middleboxes, problems with servers, significant security vulnerabilities around request smuggling and more besides. Every project I've been involved with that tried to use them eventually turned them off. So the quote is true in practise.

AIU request smuggling, it can't be prevented by disabling pipelining, only by validation.

Re: HTTP/2 and HTTP/3 explained

#35

Post by jsnell »

IgorPartola wrote: post #31
subtra3t wrote: post #29

Earlier quoted context omitted.

I haven't read the article yet but I think that means that UDP was used less than TCP and so routers/operating systems didn't optimize for it as much as they did for TCP. Hope this helps.

Right that’s all it says on this subject. I am curious about what optimizations TCP has benefitted from that we’re not but could be applied to UDP.

For example various kinds of hardware TCP offload, like:

1. Handing the NIC a single blob of data (> MSS) in a single operation, and having the NIC do the segmentation into multiple packets.

2. Having the NIC detect multiple exactly consecutive TCP packets on the same flow, and merging them to a single receive operation.

Hardware offload is impossible to do for UDP, since neither the NIC or OS can assume anything about the payload semantics.

Re: HTTP/2 and HTTP/3 explained

#36

Post by richardwhiuk »

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…

> That's not really head of line blocking, because in HTTP1.1 you'd just open up another connection.

All browsers cap the number of connections which are opened to a single domain (I think on IE this was 4, and has increased to 10, but it's not a large number).

Re: HTTP/2 and HTTP/3 explained

#37

Post by WhitneyLand »

pi-e-sigma wrote: post #25
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…

[flagged]

It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise.

You can choose to start out with skepticism or cynicism if you like but there’s no defect in people who don’t.

Re: HTTP/2 and HTTP/3 explained

#38

Post by MrBuddyCasino »

WhitneyLand wrote: post #37
pi-e-sigma wrote: post #25

Earlier quoted context omitted.

[flagged]

It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise. You can choose to start out with skepticism or cynicism if you like but there’s no defect in people who don’t.

People react to incentives. Windows got PowerShell instead of an improved cmd.exe because improving or fixing existing things does not matter in the yearly promotion package talks, but new stuff does.

Re: HTTP/2 and HTTP/3 explained

#39

Post by pi-e-sigma »

WhitneyLand wrote: post #37
pi-e-sigma wrote: post #25

Earlier quoted context omitted.

[flagged]

It’s not an error in thinking to assume a good faith basis for someone’s efforts until there’s some reason to think otherwise. You can choose to start out with skepticism or cynicism if you like but there’s no defect in people who don’t.

[flagged]

Re: HTTP/2 and HTTP/3 explained

#40

Post by jsnell »

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

Earlier quoted context omitted.

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…

Then HTTP[23] are significantly more costly to implement, they are a mistake then. Nothing to brag about then.

That's a pretty silly take. You're basically asserting that implementation difficulty is always the main priority, and there can never be any worthwhile tradeoffs that could offset that complexity.

But in reality, the world probably only needs a few dozen H3 implementations, just like there are only tens of production TCP stacks. But those implementations will be used by billions of people, hundreds of billions of machines, and handle effectively all data transmission of the entire humanity.

The leverage is massive, even the most minor improvements will be able to pay off any level of engineering effort.

Post reply on HN