4 ms·

HTTP/3 prioritization demystified

105 points by eatonphil 4y ago

ape4 4y ago
TIL about fetchpriority="high". Seems like it has a good chance of being abused. I can imagine tutorials and stackoverflow posts telling you to routinely add it.
- supertrope 4y ago
  Priority can’t be self-declared unless there’s an economic cost attached to it. FedEx envelopes cost a lot more than regular mail. People who classify an email as high priority aren’t gaining much of an advantage as recipients are already jaded by people who mark every single outgoing email as high priority. Emergency vehicles can only make up a tiny fraction of total road traffic. Microsoft Windows and ISPs reset packet DSCP bits to 0, otherwise every program would request EF handling.
avianlyric 4y ago
Enlightening article, but I did get a little hung up on this statement. > I hate it when people say that H2 and H3 allow you to send multiple resources in parallel, as it’s not really parallel at all! H1 is much more parallel than H2/3, as there you do have 6 independent connections. At best, the H2/3 data is interleaved or multiplexed on the wire More TCP connections doesn’t mean that stuff is happening in parallel, after all, it’s all going down the same wire. You’re just letting a different layer to the multiplexing. So saying > H1 is much more parallel than H2/3 Is just wrong. It’s no more or less parallel than H2/3, if we’re being pedantic. It’s just that H1 leaves the interleaving to your kernel, as it chooses which TCP packet to send next. Where as H2/3 implement their own interleaving within a single TCP connection, allowing the application to use higher level context to decide how to multiplex the resources together. Also with H2/3 there’s the additional benefit of not having to pay the TCP slow start cost for every “parallel” resource you request. And the ability to multiplex and unlimited number of resources streams, without either the client or server kernel complaining about socket/file descriptor exhaustion.
- ilyt 4y ago
  > It’s just that H1 leaves the interleaving to your kernel, You've made assumption that bandwidth is the limit. That's pretty much false assumption on most residental and many mobile connections. The concurrency hitting the target server does matter as then site can process them in parallel (either using multiple cores on same machine or multiple servers, depending on site size). So it isn't "kernel choosing which packet out of bunch H1 connections to send", it near always have enough bandwidth to have all of them on the wire, it's "just" slow start making it slower
  - deleted 4y ago
    [deleted]
  - positr0n 4y ago
    What is stopping the server from processing them in parallel when using H3? What OP said seems accurate to me.
    - Matthias247 4y ago
      Nothing. It would be a property of the webserver whether multiple requests can be processed in parallel. And a HTTP/3 server which can't would most likely be broken. It it would not process other QUIC packets while handling one request, it could not even process ACKs and keepalive packets, and thereby would just timeout the connection.
  - bastawhiz 4y ago
    > it's "just" slow start making it slower Six connections with H1 means waiting for the server to process only up to six responses at a time. You also can't send any additional requests until one of those six ongoing requests has finished. So at the very least, you're paying a full round trip cost per request where no useful work is happening. Let's say the server makes a 250ms request to an auth service on each request. For every six requests, you're sitting and waiting a quarter second for the server to sit and wait. With H2, you essentially pay that 250ms cost once, because ~every request happens concurrently. With H1, you pay it once per request on each connection. It's also the case that many servers stream their responses. If I make 12 requests and the storage that the server pulls the data from responds more slowly than the server can send it to the client, H2 means that I get twelve half finished requests instead of six half finished requests and six requests that never even got sent. For content that doesn't require the full file to be loaded, that's a win. H2 also has header compression. Sending HTTP requests on H1 often takes multiple packets, especially if you have more than one cookie. HPACK can basically eliminate much of the overhead of actually sending the request, eliminating multiple TCP round trips. Which means the server is able to start processing more requests in parallel sooner because it's not waiting for the requests to arrive as long. H3 eliminates many of the problems caused by head of line blocking. If you have packet loss on one of your connections, whatever was being transmitted is now blocked until TCP sorts out the missing packet. H3 limits the congestion only to the individual request impacted by the lost packet rather than all of the requests being made over that connection. In any case, it's not "just" TCP slow start that makes H2/H3 better than H1 in regards to concurrency.
pledess 4y ago
All of this complexity (with "browsers also differ quite a bit in the importance they assign to different types of resources and loading methods," etc.) suggests one take-home message. It is very expensive to architect your web services with the optimal combination of performance across browsers. Unless you have a huge budget, your most practical option is to be performant only for the browser with the largest market share. (Or hope that you can outsource to someone who understands all of this and yet remains affordable.)
djha-skin 4y ago
I don't understand why HTTP/3 is better than HTTP/1. Are there real benchmarks that show that it's better? It seems like an awful lot of reimplementation and potential security flaws just so that multiple TCP connections don't have to be made. And all over UDP which is blocked on a lot of firewalls.
- supertrope 4y ago
  The difference is apparent when latency is high or packet loss is high. Bypassing poorly designed middle boxes is one of the goals of QUIC.

105 points by eatonphil 4y ago

ape4 4y ago

TIL about fetchpriority="high". Seems like it has a good chance of being abused. I can imagine tutorials and stackoverflow posts telling you to routinely add it.

supertrope 4y ago
Priority can’t be self-declared unless there’s an economic cost attached to it. FedEx envelopes cost a lot more than regular mail. People who classify an email as high priority aren’t gaining much of an advantage as recipients are already jaded by people who mark every single outgoing email as high priority. Emergency vehicles can only make up a tiny fraction of total road traffic. Microsoft Windows and ISPs reset packet DSCP bits to 0, otherwise every program would request EF handling.

avianlyric 4y ago

Enlightening article, but I did get a little hung up on this statement. > I hate it when people say that H2 and H3 allow you to send multiple resources in parallel, as it’s not really parallel at all! H1 is much more parallel than H2/3, as there you do have 6 independent connections. At best, the H2/3 data is interleaved or multiplexed on the wire More TCP connections doesn’t mean that stuff is happening in parallel, after all, it’s all going down the same wire. You’re just letting a different layer to the multiplexing. So saying > H1 is much more parallel than H2/3 Is just wrong. It’s no more or less parallel than H2/3, if we’re being pedantic. It’s just that H1 leaves the interleaving to your kernel, as it chooses which TCP packet to send next. Where as H2/3 implement their own interleaving within a single TCP connection, allowing the application to use higher level context to decide how to multiplex the resources together. Also with H2/3 there’s the additional benefit of not having to pay the TCP slow start cost for every “parallel” resource you request. And the ability to multiplex and unlimited number of resources streams, without either the client or server kernel complaining about socket/file descriptor exhaustion.

ilyt 4y ago
> It’s just that H1 leaves the interleaving to your kernel, You've made assumption that bandwidth is the limit. That's pretty much false assumption on most residental and many mobile connections. The concurrency hitting the target server does matter as then site can process them in parallel (either using multiple cores on same machine or multiple servers, depending on site size). So it isn't "kernel choosing which packet out of bunch H1 connections to send", it near always have enough bandwidth to have all of them on the wire, it's "just" slow start making it slower
- deleted 4y ago
  [deleted]
- positr0n 4y ago
  What is stopping the server from processing them in parallel when using H3? What OP said seems accurate to me.
  - Matthias247 4y ago
    Nothing. It would be a property of the webserver whether multiple requests can be processed in parallel. And a HTTP/3 server which can't would most likely be broken. It it would not process other QUIC packets while handling one request, it could not even process ACKs and keepalive packets, and thereby would just timeout the connection.
- bastawhiz 4y ago
  > it's "just" slow start making it slower Six connections with H1 means waiting for the server to process only up to six responses at a time. You also can't send any additional requests until one of those six ongoing requests has finished. So at the very least, you're paying a full round trip cost per request where no useful work is happening. Let's say the server makes a 250ms request to an auth service on each request. For every six requests, you're sitting and waiting a quarter second for the server to sit and wait. With H2, you essentially pay that 250ms cost once, because ~every request happens concurrently. With H1, you pay it once per request on each connection. It's also the case that many servers stream their responses. If I make 12 requests and the storage that the server pulls the data from responds more slowly than the server can send it to the client, H2 means that I get twelve half finished requests instead of six half finished requests and six requests that never even got sent. For content that doesn't require the full file to be loaded, that's a win. H2 also has header compression. Sending HTTP requests on H1 often takes multiple packets, especially if you have more than one cookie. HPACK can basically eliminate much of the overhead of actually sending the request, eliminating multiple TCP round trips. Which means the server is able to start processing more requests in parallel sooner because it's not waiting for the requests to arrive as long. H3 eliminates many of the problems caused by head of line blocking. If you have packet loss on one of your connections, whatever was being transmitted is now blocked until TCP sorts out the missing packet. H3 limits the congestion only to the individual request impacted by the lost packet rather than all of the requests being made over that connection. In any case, it's not "just" TCP slow start that makes H2/H3 better than H1 in regards to concurrency.

pledess 4y ago

All of this complexity (with "browsers also differ quite a bit in the importance they assign to different types of resources and loading methods," etc.) suggests one take-home message. It is very expensive to architect your web services with the optimal combination of performance across browsers. Unless you have a huge budget, your most practical option is to be performant only for the browser with the largest market share. (Or hope that you can outsource to someone who understands all of this and yet remains affordable.)

djha-skin 4y ago

I don't understand why HTTP/3 is better than HTTP/1. Are there real benchmarks that show that it's better? It seems like an awful lot of reimplementation and potential security flaws just so that multiple TCP connections don't have to be made. And all over UDP which is blocked on a lot of firewalls.

supertrope 4y ago
The difference is apparent when latency is high or packet loss is high. Bypassing poorly designed middle boxes is one of the goals of QUIC.