HTTP/2 and HTTP/3 explained
alexandrehtrb.github.io
HTTP/2 and HTTP/3 explained
1–10 of 155 posts
Re: HTTP/2 and HTTP/3 explained
#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.
Re: HTTP/2 and HTTP/3 explained
#3> HTTP/3 was designed for unstable connections, such as cellphone and satellite networks.
Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.
Re: HTTP/2 and HTTP/3 explained
#4Enjoyed these books on the same topic:
Re: HTTP/2 and HTTP/3 explained
#5>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.
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 painstakingly reject every incident where this is implicated, or you can just accept that this was never going to work in practice as the document you're disparaging does.
Re: HTTP/2 and HTTP/3 explained
#6> HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.
[flagged]
Re: HTTP/2 and HTTP/3 explained
#7> HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.
[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.
Re: HTTP/2 and HTTP/3 explained
#8> HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.
The specific thing they’re talking about connection migration (and resumption) through multiple disconnection events — HTTP/1 and 2 do not offer a similar feature.
Re: HTTP/2 and HTTP/3 explained
#9> HTTP/3 was designed for unstable connections, such as cellphone and satellite networks. Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.
[deleted]
Re: HTTP/2 and HTTP/3 explained
#10>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.
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?