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

21–30 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#21

Post by blueflow »

ghusbands wrote: post #17
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…

> entirely predictable had the HTTP2 team bothered to talk to anyone who did networking I think it's good that things have evolved rather than being stuck behind naysaying. Sure, there were pitfalls/hurdles that could have been avoided, but it's not clear that maintaining perfection every step of the way would have got us to QUIC.

This is not some pitfall. This is a major problem in tech and IMHO totally unacceptable. The same things are re-invented all over again and again without actually making much of an improvement.

The result of this is that we get constant upgrades and "improvements", but overall reliability, UI usability, latency and performance in general are actually worsening every year.

Re: HTTP/2 and HTTP/3 explained

#22

Post by GuB-42 »

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 encryption built-in, so it also provides some of TLS features.

It is based on UDP, but ideally it should QUIC/IP, the only reason why UDP is in the middle is to facilitate adoption.

So if you consider HTTP/3 with builtin TLS vs HTTP/1.1+TLS+TCP, I don't think there is much of a difference in complexity.

Re: HTTP/2 and HTTP/3 explained

#23

Post by [deleted] »

blueflow wrote: post #21
ghusbands wrote: post #17

Earlier quoted context omitted.

> entirely predictable had the HTTP2 team bothered to talk to anyone who did networking I think it's good that things have evolved rather than being stuck behind naysaying. Sure, there were pitfalls/hurdles that could have been avoided, but it's not clear that maintaining perfection every step of the way would have got us to QUIC.

This is not some pitfall. This is a major problem in tech and IMHO totally unacceptable. The same things are re-invented all over again and again without actually making much of an improvement. The result of this is that we get constant upgrades and "improvements", but overall reliability, UI usability, latency and performance in general are actually worsening every year.

[deleted]

Re: HTTP/2 and HTTP/3 explained

#24

Post by sylware »

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…

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

Nothing to brag about then.

Re: HTTP/2 and HTTP/3 explained

#25

Post by pi-e-sigma »

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…

[flagged]

Re: HTTP/2 and HTTP/3 explained

#27

Post by goodburb »

When loading many images [0] different browsers load the image in a different order and parallelism[1], especially HTTP/3 with Firefox [2]:

[0] https://github.com/TalalMash/100-Image-Load-Test

[1] https://imgur.com/a/b8P3XvB

[2] https://forum.openwrt.org/uploads/default/original/3X/b/c/bc...

Re: HTTP/2 and HTTP/3 explained

#28

Post by jeltz »

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]

That HTTP2 is the worst of the bunch is a given. But HTTP3 should on paper be able to handle packets loss better than HTTP1.1 and way better than HTTP2.

And SACK does not seem to help under my real life workloads. Maybe poor implementations. I don't know.

Re: HTTP/2 and HTTP/3 explained

#29

Post by subtra3t »

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.

Re: HTTP/2 and HTTP/3 explained

#30

Post by pi-e-sigma »

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

Earlier quoted context omitted.

[flagged]

That HTTP2 is the worst of the bunch is a given. But HTTP3 should on paper be able to handle packets loss better than HTTP1.1 and way better than HTTP2. And SACK does not seem to help under my real life workloads. Maybe poor implementations. I don't know.

Just a few years ago HTTP2 was the best thing since sliced bread and any criticism was silenced. This begs the question if HTTP2 was so great then why did they come up with HTTP3? SACK is not a silver bullet because when you have high latency high loss link then nothing really helps. The difference is that HTTP2/3 folks like to deny reality and claim that they can do better when in fact they can't
Post reply on HN