QUIC and HTTP/3, QUIC versus TCP and encrypted TLS ClientHello
The web is moving towards HTTP/3 above the QUIC protocol that replaces the traditional HTTP over TLS over TLS stack with a new protocol that runs directly above UDP and can be deployed inside applications. Robin Marx explains in a blog post Why HTTP/3 is eating the world.
A recent study compares the performance of different TCP extensions and QUIC to download files from CDN servers. The measurements first looked at the deployment of TCP extensions. They studied TCP SACK, Windows Scale and Explicit Congestion Notification. Surprisingly, 5.3% of the domains in the Top 1M list did not support any extension. This is very strange for Window Scale that was defined in RFC1323 published 31 years ago. ECN is only supported by 85.8% of the domains, but for ECN, the main problem remains that congested routers rarely mark packets using ECN. For TCP, the measurements reveal that Window Scale improves throughput, which is not a surprise. More interesting is that the quiche implementation of QUIC seems to outperform TCP for 70% of the samples. Unfortunately, the paper does not try to explain why QUIC performs better than TCP in these measurements.
In parallel with the deployment of QUIC, TLS continues to be improved. A TLS session starts with a ClientHello message that is sent in clear text. Some middleboxes and firewalls use this to extract the Server Name Indication and detect the target of the TLS session. This will change with the deployment of Encrypted Client Hello that allows to encrypt the ClientHello message using the server’s public key. On the client side, this extension is enabled in Chrome 117 and will in Firefox. Wireshark has accepted a patch adding supporting for dissesting ECH.