| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
1 parent 42aa3f6 commit 97c8a96
1 file changed
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -104,6 +104,42 @@ to negotiate the application protocol (via ALPN), authenticate the server (and | |||
| 104 | 104 | optionally the client), exchange transport parameters, and establish shared keys | |
| 105 | 105 | for encryption. | |
| 106 | 106 | ||
| 107 | + #### Certificate size and handshake performance | ||
| 108 | + | ||
| 109 | + QUIC includes an anti-amplification limit ([RFC 9000 Section 8.1][]) that | ||
| 110 | + restricts the server to sending at most three times the data received from | ||
| 111 | + the client before the client's address is validated. Because the client's | ||
| 112 | + Initial packet is typically around 1200 bytes, the server can send at most | ||
| 113 | + approximately 3600 bytes before it must wait for the client to acknowledge. | ||
| 114 | + | ||
| 115 | + The server's initial response is dominated by its TLS certificate chain. If | ||
| 116 | + the certificate chain exceeds the amplification limit, the handshake requires | ||
| 117 | + an additional round trip — the server must pause, wait for the client's | ||
| 118 | + acknowledgement, and then continue sending the remainder of the certificate. | ||
| 119 | + This eliminates QUIC's 1-RTT handshake advantage over TCP+TLS and can add | ||
| 120 | + 50–100 ms or more of latency on the first connection, depending on the network | ||
| 121 | + path. | ||
| 122 | + | ||
| 123 | + To avoid this, servers should use compact certificate chains: | ||
| 124 | + | ||
| 125 | + * **Use ECDSA certificates** (P-256 or P-384) rather than RSA. ECDSA keys and | ||
| 126 | + signatures are significantly smaller. A typical ECDSA P-256 certificate chain | ||
| 127 | + with one intermediate is approximately 1.5–2 KB, well within the amplification | ||
| 128 | + limit. An equivalent RSA-2048 chain is often 3–5 KB, which may exceed it. | ||
| 129 | + | ||
| 130 | + * **Minimize the certificate chain.** Include only the leaf certificate and | ||
| 131 | + the necessary intermediate(s). Do not include the root certificate (clients | ||
| 132 | + already have it in their trust store). Avoid cross-signed intermediates when | ||
| 133 | + the self-signed root is already widely trusted. | ||
| 134 | + | ||
| 135 | + * **Prefer certificate authorities with short chains.** Some CAs issue | ||
| 136 | + certificates with a single small intermediate, while others require multiple | ||
| 137 | + large RSA intermediates. The choice of CA directly affects handshake latency. | ||
| 138 | + | ||
| 139 | + Certificate compression ([RFC 8879][]) can also address this issue by | ||
| 140 | + compressing the certificate chain during the handshake. However, Node.js does | ||
| 141 | + not currently support TLS certificate compression. | ||
| 142 | + | ||
| 107 | 143 | ### Applications | |
| 108 | 144 | ||
| 109 | 145 | Every `QuicSession` is associated with a single application protocol, negotiated | |
@@ -4036,8 +4072,10 @@ throughput issues caused by flow control. | |||
| 4036 | 4072 | [Callback error handling]: #callback-error-handling | |
| 4037 | 4073 | [JSON-SEQ]: https://www.rfc-editor.org/rfc/rfc7464 | |
| 4038 | 4074 | [NSS Key Log Format]: https://udn.realityripple.com/docs/Mozilla/Projects/NSS/Key_Log_Format | |
| 4075 | + [RFC 8879]: https://www.rfc-editor.org/rfc/rfc8879 | ||
| 4039 | 4076 | [RFC 8999]: https://www.rfc-editor.org/rfc/rfc8999 | |
| 4040 | 4077 | [RFC 9000]: https://www.rfc-editor.org/rfc/rfc9000 | |
| 4078 | + [RFC 9000 Section 8.1]: https://www.rfc-editor.org/rfc/rfc9000#section-8.1 | ||
| 4041 | 4079 | [RFC 9001]: https://www.rfc-editor.org/rfc/rfc9001 | |
| 4042 | 4080 | [RFC 9002]: https://www.rfc-editor.org/rfc/rfc9002 | |
| 4043 | 4081 | [RFC 9114]: https://www.rfc-editor.org/rfc/rfc9114 | |
| Back | FazBrowse Home | New Git URL |
0 commit comments