Re:HTTP/3 Is Fast
by benmmurphy on Wednesday December 15, 2021 @03:44PM
(#29571384)
Weirdly enough I think QUIC often does something that is not much better because of address validation. It is not safe for the QUIC server to send a bunch of large packets back to the client source address without being confident the client controls the address. We run QUIC in production so I’ll grab an example conversation to show how many round trips connection setup takes. I guess we might not be optimising connection setup correctly because we are using long running QUIC connections to transport our own protocol and I don’t care how long the connection setup takes.
so we are using a slightly older version of QUIC than the RFC and using go-quic on server and client. and this is what i see when creating a connection:
Client: Initial (1284 bytes) includes client hello
Server: Retry (166 bytes) includes retry token
Client: Initial (1284 bytes) including retry token and client hello
Server: Server Hello/Encrypted Extensions/Cert
Request/Certificate/Certificate Verify/Finished (1284 bytes)
Client: Certificate/Certificate Verify/Finished (1284 bytes)
https://datatracker.ietf.org/doc/html/rfc9000#section-8.1
probably what go-quic does is not optimal because you don't always have to validate the address.
Prior to validating the client address, servers MUST NOT send more
than three times as many bytes as the number of bytes they have
received. This limits the magnitude of any amplification attack that
can be mounted using spoofed source addresses. For the purposes of
avoiding amplification prior to address validation, servers MUST
count all of the payload bytes received in datagrams that are
uniquely attributed to a single connection. This includes datagrams
that contain packets that are successfully processed and datagrams
that contain packets that are all discarded.
A server might wish to validate the client address before starting
the cryptographic handshake. QUIC uses a token in the Initial packet
to provide address validation prior to completing the handshake.
This token is delivered to the client during connection establishment
with a Retry packet (see Section 8.1.2) or in a previous connection
using the NEW_TOKEN frame (see Section 8.1.3).
HTTP over QUIC will probably do a similar number of round-trips compared to HTTP over TCP, but it will do much fewer than HTTP over TLS over TCP. There's no getting away from SYN/SYN-ACK/ACK for a reliable protocol, but QUIC can put certificate negotiation information directly here, instead of the TLSoTCP approach of SYN/SYN-ACK/ACK/ClientHello/ServerHello/ClientKeyExchange/ServerKeyExchange.
Additionally, QUIC supports multiple streams over a single physical connection, and correctly implements packet ordering constraints and retries for them. TCP supports a single stream over a connection: any delayed packet will delay the entire stream. In QUIC, a delayed packet will only delay packets from the same logical stream, packets from other streams can still be received successfully on the same connection.
This feature is heavily used by HTTP/3: HTTP/2 introduced a concept of HTTP streams, but all HTTP streams were run over the same TCP connection, so over a single TCP stream: a slow packet on HTTP/2 stream 1 will delay all packets from HTTP/2 streams 2, 3 etc. With QUIC, an HTTP/3 stream is a QUIC stream, so a single slow request will not blkc other packets from other requests from being received.