feat: 阅读QUIC文档

2025-10-29 16:15:38 +08:00
parent 02d33f437a
commit b166eaf5e6
1 changed files with 130 additions and 0 deletions
--- a/http/http3.md
+++ b/http/http3.md
@@ -3,6 +3,16 @@
  - [TCP/IP模型中HTTP3 vs QUIC](#tcpip模型中http3-vs-quic)
  - [QUIC Protocol](#quic-protocol)
    - [What is QUIC Used For](#what-is-quic-used-for)
+  - [HTTP/1.1 vs HTTP/2 vs HTTP/3: Main differences](#http11-vs-http2-vs-http3-main-differences)
+  - [Best Features of HTTP/3 and QUIC](#best-features-of-http3-and-quic)
+    - [QUIC handshake](#quic-handshake)
+    - [0-RTT on Prior Connections](#0-rtt-on-prior-connections)
+    - [Head-of-Line Blocking Removal](#head-of-line-blocking-removal)
+      - [HOL blocking术语](#hol-blocking术语)
+      - [How does QUIC remove head-of-line blocking](#how-does-quic-remove-head-of-line-blocking)
+      - [Flexible Bandwidth Management](#flexible-bandwidth-management)
+        - [Pre-Stream Flow Control](#pre-stream-flow-control)
+        - [拥塞控制算法](#拥塞控制算法)


 # HTTP3 & QUIC Protocols
@@ -40,4 +50,124 @@ QUIC其创建是同于代替`TCP`协议的，QUIC作为传输层协议，相比

 QUIC协议底层基于UDP协议的原因是`大多数设备只支持TCP和UDP的端口号`。

+除此之外，`QUIC`还利用了UDP的如下特性：
+- UDP的connectionless特性可以使其将多路复用下移到传输层，并且基于UDP的QUIC实现并不会和TCP协议一样存在头部阻塞的问题
+- UDP的间接性能够令QUIC重新实现TCP的可靠性和贷款管理功能
+
+基于QUIC协议的传输和TCP相比是完全不同的方案：
+- 在底层，其是无连接的，其底层基于UDP协议
+- 在高层，其是`connection-oriented`的，其在高层重新实现了TCP协议中连接建立、loss detection等特性，从而确保了数据的可靠传输
+
+综上，QUIC协议结合了UDP和TCP两种协议的优点。
+
+除了上述优点外，QUIC还`在传输层实现了高级别的安全性`。QUIC集成了`TLS 1.3`协议中的大部分特性，令其和自身的传输机制相兼容。在`HTTP/3` stack中，encryption并非是可选的，而是内置特性。
+
+TCP， UDP， QUIC协议的相互比较如下：
+| | TCP | UDP | QUIC |
+| :-: | :-: | :-: | :-: |
+Layer in the TCP/IP model | transport | transport | transport | 
+| place in the TCP/IP model | on top of ipv4/ipv6 | on top of ipv4/ipv6 | on top of UDP |
+| connection type | connection-oriented | connectionless | connection-oriented |
+| order of delivery | in-order delivery | out-of-order delivery | out-of-order delivery between streams, in order delivery within stremas |
+| guarantee of delivery | guaranteed | no guarantee of delivery | guaranteed |
+| security | unencrypted | unencrypted | encrypted |
+| data identification | knows nothing about the data it transports | knows nothing about the data it transports | use stream IDs to identify the independent streams it transports |
+
+## HTTP/1.1 vs HTTP/2 vs HTTP/3: Main differences
+H3除了在底层协议栈传输层中引入QUIC和UDP协议外，还存在其他改动，具体如图所示：
+<img loading="lazy" alt="Comparison of the HTTP/1.1 vs HTTP/2 vs HTTP/3 protocol stacks" src="https://www.debugbear.com/assets/images/http11-2-3-comparison-88d3a12d6cc3f5422c3700a7f2f8c76b.jpg" width="1526" height="926" style="border-radius:4px" data-abc="true" class="img_CujE">
+
+HTTP/3-QUIC-UDP stack和TCP-based版本的HTTP最重要的区别如下：
+- QUIC集成了TLS 1.3协议中绝大部分特性，encryption从应用层移动到了传输层
+- HTTP/3在不同的streams间并不会对连接进行多路复用，多路复用的特性是由QUIC在传输层执行的
+  - 传输层的多路复用移解决了HTTP/2中TCP中头部阻塞的问题（HTTP/1.1中并不存在头部阻塞问题，因为其会开启多个TCP连接，并且会提供pipelining选项，后来该方案被发现拥有严重实现缺陷，被替换为了HTTP/2中应用层的多路复用）
+
+## Best Features of HTTP/3 and QUIC
+HTTP/3和QUIC的新特性能够令server connections速度更快、传输更安全、可靠性更高。
+
+### QUIC handshake
+在HTTP2中，client和server在执行handshake的过程中，至少需要2次round-trips：
+- tcp handshake需要一次round-trip
+- tls handleshake至少需要一次round-trip
+
+和QUIC则将上述两次handshakes整合成了一个，HTTP3仅需一次round-trip就可以在client和server之间建立一个secure connection。`QUIC可以带来更快的连接建立和更低的延迟。`
+
+QUIC集成了`TLS1.3`中的绝大多数特性，`TLS1.3`是目前最新版本的`Transport Layer Security`协议，其代表：
+- HTTP/3中，消息的加密是强制的，并不像HTTP/1.1和HTTP/2中一样是可选的。在使用HTTP/3时，所有的消息都默认通过encrypted connection来进行发送。
+- TLS 1.3引入了一个`improved cryptographic handshake`，在client和server间仅需要一次round-trip；而TLS 1.2中则需要两次round-trips用于认证
+  - 而在QUIC中，则将该`improved cryptographic handshake`和其本身用于连接创建的handshake进行了整合，并替代了TCP的handshake
+- 在HTTP/3中，消息都是在传输层加密的，故而加密的信息比HTTP/1.1和HTTP/2中都更多
+  - 在HTTP/1.1和HTTP/2协议栈中，TLS都运行在应用层，故而HTTP data是加密的，但是，TCP header则是明文发送的，TCP header的明文可能会带来一些安全问题
+  - 在HTTP/3 stack中，TLS运行在传输层，故而不仅http message被加密，大多数QUIC packet header也是被加密的
+
+简单来说，HTTP/3使用的传输机制相比于TCP-based HTTP版本来说要更加安全。（传输层协议本身的header也被加密）
+
+### 0-RTT on Prior Connections
+对于先前存在的connections，QUIC利用了TLS 1.3的`0-RTT`特性。
+
+`0-RTT`代表zero round-trip time resumption，是TLS 1.3中引入的一个新特性。
+
+TLS session resumption通过复用先前建立的安全参数，减少建立secure connection所花费的时间。当client和server频繁建立连接并断开时，这将带来性能改善。
+
+通过0-RTT resumption，client可以在连接的第一个round-trip中发送http请求，复用先前建立的cryptographic keys。
+
+下面展示了H2和H3 stack在建立连接时的区别：
+
+<img loading="lazy" alt="Connection setup in the HTTP/2 vs HTTP/3 stacks" src="https://www.debugbear.com/assets/images/http2-vs-http3-roundtrips-1b14a7c6b6f7badbd345f67895dbf142.jpg" width="2063" height="1406" style="border-radius:4px" data-abc="true" class="img_CujE">
+
+- 当使用HTTP2和TLS 1.2时，client发送第一个http request需要4个round-trip
+- 在使用HTTP2和TLS 1.3时，client发送第一个http equest需要2、3个round-trip（根据是否使用0-rtt有所不同）
+- 在使用HTTP3和QUIC时，其默认包含TLS 1.3，其可以在1、2个round-trip内发送第一个http请求（根据是否复用先前连接的加密信息）
+
+### Head-of-Line Blocking Removal
+HTTP/3协议栈和HTTP/2协议栈的结构不同，其解决了HTTP/2中最大的性能问题：`head-of-line`阻塞。
+- 该问题主要发生在HTTP/2中packet丢失的场景下，直到丢失的包被重传前，整个的数据传输过程都会停止，所有packets都必须在网络上等待，这将会导致页面的加载时间延长
+
+在HTTP/3中，行首阻塞通过原生的多路复用解决了。这是QUIC最重要的特性之一。
+
+#### HOL blocking术语
+如下是HOL问题涉及到的概念：
+- byte stream：是通过网络发送的字节序列。bytes作为不同大小的packets被传输。byte stream本质上是单个资源（file）的物理表现形式，通过网络来发送
+- 复用：通过复用，可以在一个connection上传输多个byte streams，这将代表浏览器可以在同一个连接上同时加载多个文件
+  - 在HTTP/1.1中，并不支持复用，其会未每个byte stream新开一个tcp连接。HTTP/2中引入了应用层的复用，其只会建立一个TCP连接，并通过其传输所有byte streams。故而，仅有HTTP/2会存在HOL问题
+- HOL blocking：这是由tcp byte stream抽象造成的性能问题。TCP并不知晓其所传输的数据，并将其所传输的所有数据都看作一个byte stream。故而，如果在网络传输过程中，任意位置的packet发生的丢失，所有在复用连接中的其他packets都会停止传输，并等待丢失的packets被重传
+  - 这代表，复用的连接中，所有byte streams都会被TCP协议看作是一个byte stream，故而stream A中的packet丢失也会造成stream B的传输被阻塞，直至丢失packet被重传
+  - 并且，TCP使用了in-order传输，如果发生packet丢失，那么将阻塞整个的传输过程。在高丢包率的环境下，这将极大程度上影响传输速度。即使在HTTP/2中已经引入了性能优化特性，在2%丢包率的场景下，也会比HTTP/1.1的传输速度更慢
+- native multiplexing：在HTTP/3协议栈中，复用被移动到了传输层，实现了原生复用。QUIC通过stream ID来表示每个byte stream，并不像TCP一样将所有byte streams都看作是一个。
+
+#### How does QUIC remove head-of-line blocking
+QUIC基于UDP实现，其使用了out-of-order delivery，故而每个byte stream都通过网络独立的进行传输。然而，为了可靠性，QUIC确保了在同一byte stream内packets的in-order delivery，故而相同请求中关联的数据到达的顺序是一致的。
+
+QUIC标识了所有byte stream，并且streams是独立进行传输的，如果发生packet丢失，其他byte streams并不会停止并等待重传。
+
+下图中展示了QUIC原生复用和HTTP2应用层复用的区别：
+<img loading="lazy" alt="HTTP/2 vs QUIC multiplexing diagrams" src="https://www.debugbear.com/assets/images/http2-vs-quic-multiplexing-36d594c1c356cae410fe60cfc2945d91.jpg" width="900" height="532" style="border-radius:4px" data-abc="true" class="img_CujE">
+
+如上图所示，HTTP/2和HTTP/3在传输多个资源时，都只创建了一个连接。但是，QUIC中不同byte streams是独立传输的，拥有不同的传输路径，并且不同byte streams之间不会彼此阻塞。
+
+即使QUIC解决了HTTP/2中引入的HOL问题，乱序传输也会存在弊端：byte streams并不会按照其被发送的顺序到达。例如，在使用乱序传输时，最不重要的资源可能会最先到达。
+
+#### Flexible Bandwidth Management
+带宽管理用于在packets和streams之间按照最优的方式对网络带宽进行分配。这是至关重要的功能，发送方和接收方的机器以及二者之间的网络节点处理packets的速度都有所不同，并且速度也会动态变化。
+
+带宽管理有助于避免网络中的数据溢出和拥塞，这些问题可能会导致server响应速度变慢，同时也可能会带来安全问题。
+
+UDP中并没有内置带宽控制，QUIC则是在HTTP3协议栈中负责该功能，其对TCP带宽管理中的两大部分进行了重新实现：
+- 流控制: 其在接收方限制了数据发送的速率，用于避免发送方造成接收方过载
+- 拥塞控制：其限制了发送方和接收方之间的路径中每一个节点的发送速率，用于避免网络拥塞
+
+##### Pre-Stream Flow Control
+为了支持独立的stream，QUIC采用了per-stream based flow control。其在两个级别控制了stream data的带宽消耗：
+- 对于每个独立的流，都设置了一个可分配给其的最大数据数量
+- 在整个连接范的围内，设置了active streams最大的累积数量
+
+通过per-stream flow control，QUIC限制了同时可以发送的数据数量，用于避免接收方过载，并且在多个streams间大致公平的分配网络容量。
+
+##### 拥塞控制算法
+QUIC允许实现选择不同的拥塞控制算法，使用最广泛的算法如下：
+- NewReno：TCP使用的拥塞控制算法
+- CUBIC: 和NewReno类似，但是使用了cubic function而不是linear function
+- BBR
+
+在网络状况较差的场景下，不同的拥塞控制算法性能可能存在较大差异。