14 KiB
- HTTP3 & QUIC Protocols
HTTP3 & QUIC Protocols
http3旨在通过QUIC（下一代传输层协议）来令网站更快、更安全。
在协议高层，http3提供了和http2相同的功能，例如header compression和stream优先级控制。然而，在协议底层，QUIC传输层协议彻底修改了web传输数据的方式。
What is HTTP3
HTTP是一个应用层的网络传输协议，定义了client和server之间的request-reponse机制，允许client/server发送和接收HTML文档和其他文本、meidia files。
http3最初被称为HTTP-over-QUIC，其主要目标是令http语法及现存的http/2功能能够和QUIC传输协议兼容。
故而，HTTP/3的所有新特性都来源于QUIC层，包括内置加密、新型加密握手、对先前的连接进行zero round-trip恢复，消除头部阻塞问题以及原生多路复用。
TCP/IP模型中HTTP3 vs QUIC
通过internet传输信息是复杂的操作，涉及到软件和硬件层面。由于不同的设备、工具、软件都拥有不同的特性，故而单一协议无法描述完整的通信流程。
故而，网络通信是已于通信的协议栈实现的，协议栈中每一层职责都不同。为了使用网络系统来通信，host必须实现构成互联网协议套件的一系列分层协议集。通常，主机至少为每层实现一个协议。
而HTTP则是应用层协议，令web server和web browser之间可以相互通信。http消息（request/reponse）在互联网中则是通过传输层协议来进行传递：
- 在http/2和http/1.1中，通过TCP协议来进行传递
- 在
http/3中，则是通过QUIC协议来进行传递
QUIC为http/3新基于的传输层协议，之前http都基于tcp协议进行传输
QUIC Protocol
QUIC协议是一个通用的传输层协议，其可以和任意兼容的应用层协议来一起使用，HTTP/3是QUIC的最新用例。
QUIC协议基于UDP协议构建，其负责server和client之间应用数据的物理传输。UDP协议是一个简单、轻量的协议，其传输速度高但是缺失可靠性、安全性等特性。QUIC实现了这些高层的传输特性，故而可以用于优化http数据通过网络的传输。
在HTTP/3中，HTTP的连接从TCP-based迁移到了UDP-based，底层的网络通信结构都发生了变化。
What is QUIC Used For
QUIC其创建是同于代替TCP协议的，QUIC作为传输层协议，相比于TCP更加灵活，性能问题更少。QUIC协议继承了安全传输的特性，并且拥有更快的adoption rate。
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协议外，还存在其他改动，具体如图所示：
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
- 而在QUIC中，则将该
- 在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在建立连接时的区别：
- 当使用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应用层复用的区别：
如上图所示，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
在网络状况较差的场景下，不同的拥塞控制算法性能可能存在较大差异。