证书大小和握手性能

🌐 Certificate size and handshake performance

QUIC 包含一个防放大限制（RFC 9000 第 8.1 节），限制服务器在验证客户端地址之前，最多只能发送客户端发送数据的三倍。由于客户端的 Initial 包通常大约 1200 字节，服务器最多可以发送大约 3600 字节，然后必须等待客户端确认。

🌐 QUIC includes an anti-amplification limit (RFC 9000 Section 8.1) that restricts the server to sending at most three times the data received from the client before the client's address is validated. Because the client's Initial packet is typically around 1200 bytes, the server can send at most approximately 3600 bytes before it must wait for the client to acknowledge.

服务器的初始响应主要受到它的 TLS 证书链的影响。如果证书链超过了放大限制，握手就需要增加一次往返——服务器必须暂停，等待客户端的确认，然后才能继续发送剩下的证书。这会消除 QUIC 相比 TCP+TLS 的 1-RTT 握手优势，并且根据网络路径，在第一次连接时可能会增加 50–100 毫秒甚至更多的延迟。

🌐 The server's initial response is dominated by its TLS certificate chain. If the certificate chain exceeds the amplification limit, the handshake requires an additional round trip — the server must pause, wait for the client's acknowledgement, and then continue sending the remainder of the certificate. This eliminates QUIC's 1-RTT handshake advantage over TCP+TLS and can add 50–100 ms or more of latency on the first connection, depending on the network path.

为了避免这种情况，服务器应该使用紧凑的证书链：

🌐 To avoid this, servers should use compact certificate chains:

• 使用 ECDSA 证书（P-256 或 P-384）而不是 RSA。ECDSA 的密钥和签名要小得多。一个带有一个中间证书的典型 ECDSA P-256 证书链大约 1.5–2 KB，非常适合放在放大限制范围内。相同的 RSA-2048 证书链通常在 3–5 KB，可能会超出限制。
• 最小化证书链。 只包含叶子证书和必要的中间证书。不要包含根证书（客户端的信任库里已经有了）。当自签名根证书已经被广泛信任时，避免使用交叉签名的中间证书。
• 尽量选择链短的证书颁发机构（CA）。 有些 CA 发的证书只带一个小型中间证书，而有些则需要多个大型 RSA 中间证书。选择 CA 会直接影响握手延迟。

证书压缩（RFC 8879）也可以通过在握手期间压缩证书链来解决这个问题，通常可以将服务器的证书消息控制在放大限制内，从而避免额外的往返。证书压缩是通过 certificateCompression TLS 选项选择启用的，默认情况下是关闭的。启用后，它既适用于服务器的证书，也适用于双向 TLS 的客户端证书。

🌐 Certificate compression (RFC 8879) can also address this issue by compressing the certificate chain during the handshake, often keeping the server's Certificate message within the amplification limit and avoiding the extra round trip. Certificate compression is opt-in via the certificateCompression TLS option and is disabled by default. When enabled, it applies to both the server's certificate and, for mutual TLS, the client's certificate.