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

11–20 of 155 posts

Re: HTTP/2 and HTTP/3 explained

#11

Post by GoblinSlayer »

anonymoushn wrote: post #10
tialaramex wrote: post #5

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/HTTP_pipelining In practice it's not wrong. HTTP 1.x servers, and especially "middleboxes" get this badly enough wrong that when you ship this feature ("HTTP 1 pipelining") your users will report a low but persistent error rate. Oops the password request and image download were kinda sorta fused together. You can (and some very minor browsers do) just insist it's not your bug and then pa…

Do you get a mostly eliminated error rate if you only use pipelining over TLS, or have server operators situated their defective middleboxes behind their TLS termination?

I guess, it's about things like UserGate, they generate MITM certificates on the fly and decrypt traffic. On the other hand, if they can't handle http1, why they would handle http2?

Re: HTTP/2 and HTTP/3 explained

#13

Post by KaiserPro »

> 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 better over high latency or lossy links than http2

> With HTTP/2, this problem is solved with streams, each stream corresponds to a message. Many streams can be interleaved in a single TCP packet. If a stream can't emit its data for some reason, other streams can take its place in the TCP packet.

This is where HTTP2 failed. It shoved everything into one single TCP connection which works fine on LAN and LAN like networks, and sucks balls in the real world. This is Top of line blocking and was entirely predictable had the HTTP2 team bothered to talk to anyone who did networking.

Its part of the reason why I was greatly suspicious of QUIC, because it appeared like it was designed by the same people that thought http2 was a good idea.

However QUIC seems to be actually reasonable. I've yet to fully test it in real world scenarios, but it does offer promise for highspeed latency resistant data streaming. One day I'll re-write my TCP multiplexor to compare the performance.

Re: HTTP/2 and HTTP/3 explained

#14

Post by pi-e-sigma »

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

Earlier quoted context omitted.

[flagged]

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]

Re: HTTP/2 and HTTP/3 explained

#15

Post by ghusbands »

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.

Re: HTTP/2 and HTTP/3 explained

#16

Post by golebiewsky »

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]

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.

Re: HTTP/2 and HTTP/3 explained

#17

Post by ghusbands »

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.

Re: HTTP/2 and HTTP/3 explained

#18

Post by ithkuil »

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 page). Perhaps they thought that people with really horrible packet loss will just fallback to http or use amp or whatever.

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

Re: HTTP/2 and HTTP/3 explained

#19

Post by pi-e-sigma »

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.

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

Re: HTTP/2 and HTTP/3 explained

#20

Post by vasilvv »

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.

It's possible to build something similar on top of TCP, see Minion [0] for an example. There are multiple reasons why this is less practical than building on top of UDP, the main two being, from my perspective: (1) this requires cooperation from the OS (either in form of giving you advanced API or having high enough privilege level to write TCP manually), and (2) this falls apart in presence of TCP middleboxes.

[0] https://dedis.cs.yale.edu/2009/tng/papers/nsdi12-abs/

Post reply on HN