Re:Chrome is deploying HTTP/3 and IETF QUIC
by Animats on Monday October 12, 2020 @04:44AM
(#24752530)
> The real motivation is probably to merge ads into the same stream as the content.
I was thinking of Google-hosted content, with Google ads. About 25% of web traffic now comes from Google, although that includes YouTube. Google serves some (most?) ads from "doubleclick.com", which can be blocked at the domain level. But if they slip the ads into the same encrypted connection as the content, it's no longer possible to block them from outside the browser.
As for traffic issues, I've seen a few papers where people compare QUIC and TCP.[1][2] But nobody seems to be looking at what QUIC-type traffic is doing to other traffic on the same path. Not that I have, either. You can boost your throughput a bit by being more aggressive about sending packets. If the nodes in the middle are all FIFO queues (the cause of "bufferbloat"), the one who sends the most wins. This creates a perverse incentive and a way to game the results of such comparisons. Fair queuing can help.
Still, it's probably a win to speed up all the handshaking involved in setting up a TLS connection. The crypto setup is a big cost for small requests.
I was thinking of Google-hosted content, with Google ads. About 25% of web traffic now comes from Google, although that includes YouTube. Google serves some (most?) ads from "doubleclick.com", which can be blocked at the domain level. But if they slip the ads into the same encrypted connection as the content, it's no longer possible to block them from outside the browser.
As for traffic issues, I've seen a few papers where people compare QUIC and TCP.[1][2] But nobody seems to be looking at what QUIC-type traffic is doing to other traffic on the same path. Not that I have, either. You can boost your throughput a bit by being more aggressive about sending packets. If the nodes in the middle are all FIFO queues (the cause of "bufferbloat"), the one who sends the most wins. This creates a perverse incentive and a way to game the results of such comparisons. Fair queuing can help.
Still, it's probably a win to speed up all the handshaking involved in setting up a TLS connection. The crypto setup is a big cost for small requests.
[1] https://blog.codavel.com/quic-vs-tcptls-and-why-quic-is-not-...
[2] https://github.com/Shenggan/quic_vs_tcp