又快又好自助建站系统python网站建设

首先我们要知道TCP存在什么样的痛点问题

• TCP的升级很困难
• TCP建立连接的延迟
• 网络迁移需要重新建立连接
• TCP存在队头阻塞问题

QUIC就是为了解决以上的问题而诞生了, 下面我会介绍QUIC的一些特性和原理

QUIC对比TCP优势:

握手建连更快

QUIC内部包含了TLS, 它在自己的帧会携带TLS里的记录, 再加上QUIC使用的是TLS1.3, 因此仅需1个RTT就可以同时完成建立与密钥协商, 甚至第二次连接的时候, 应用数据包和QUIC握手信息一起发送, 达到0-RTT的效果. 

而HTTP/1和HTTP/2协议, TCP和TLS都是分层的, 分别在内核的传输层和openssl的表示层, 所以要先进行TCP握手(1-RTT), 在进行TLS握手(2RTT), 所以需要3-RTT的延迟才能传输数据. 

QUIC建连时间大约0~1 RTT，在两方面做了优化：

1）传输层使用了UDP，减少了1个RTT三次握手的延迟。

2）加密协议采用了TLS 协议的最新版本TLS 1.3，相对之前的TLS 1.1-1.2，TLS1.3允许客户端无需等待TLS握手完成就开始发送应用程序数据的操作，可以支持1 RTT和0RTT。

对于QUIC协议，客户端第一次建连的握手协商需1-RTT，而已建连的客户端重新建连可以使用之前协商好的缓存信息来恢复TLS连接，仅需0-RTT时间。因此QUIC建连时间大部分0-RTT、极少部分1-RTT，相比HTTPS的3-RTT的建连，具有极大的优势。

避免队首阻塞的多路复用

QUIC同样支持多路复用，QUIC的流与流之间完全隔离的，互相没有时序依赖。如果某个流出现丢包，不会阻塞其他流数据的传输和应用层处理，所以这个方案并不会造成队首阻塞。

支持连接迁移

什么是连接迁移？举个例子，当你用手机使用蜂窝网络参加远程会议，当你把网络切换到WLAN时，会议客户端会立马重连，视频同时出现一瞬间的卡顿。这是因为，TCP采用四元组（包括源IP、源端口、目标地址、目标端口）标识一个连接，在网络切换时，客户端的IP发生变化，TCP连接被瞬间切断然后重连。连接迁移就是当四元组中任一值发生变化时，连接依旧能保持，不中断业务。QUIC支持连接迁移，它用一个（一般是64位随机数）ConnectionID标识连接，这样即使源的IP或端口发生变化，只要ConnectionID一致，连接都可以保持，不会发生切断重连。

可插拔的拥塞控制

QUIC是应用层协议，用户可以插拔式选择像Cubic、BBR、Reno等拥塞控制算法，也可以根据具体的场景定制私有算法。

Quic使用可插拔的拥塞控制，相较于TCP，它能提供更丰富的拥塞控制信息。比如对于每一个包，不管是原始包还是重传包，都带有一个新的序列号(seq)，这使得Quic能够区分ACK是重传包还是原始包，从而避免了TCP重传模糊的问题。Quic同时还带有收到数据包与发出ACK之间的时延信息。这些信息能够帮助更精确的计算RTT。此外，Quic的ACK Frame 支持256个NACK 区间，相比于TCP的SACK(Selective Acknowledgment)更弹性化，更丰富的信息会让client和server 哪些包已经被对方收到。

QUIC 的传输控制不再依赖内核的拥塞控制算法，而是实现在应用层上，这意味着我们根据不同的业务场景，实现和配置不同的拥塞控制算法以及参数。GOOGLE 提出的 BBR 拥塞控制算法与 CUBIC 是思路完全不一样的算法，在弱网和一定丢包场景，BBR 比 CUBIC 更不敏感，性能也更好。在 QUIC 下我们可以根据业务随意指定拥塞控制算法和参数，甚至同一个业务的不同连接也可以使用不同的拥塞控制算法。

前向纠错（FEC: Fowrard Error Correcting）

QUIC支持前向纠错，弱网丢包环境下，动态的增加一些FEC数据包，可以减少重传次数，提升传输效率。

如果接收端出现少量（不超过FEC的纠错能力）的丢包或错包，可以借助冗余纠错码恢复丢失或损坏的数据包，这就不需要再重传该数据包了，降低了丢包重传概率，自然就减少了拥塞控制机制的触发次数，可以维持较高的网络利用效率。

QUIC连接

QUIC也是需要三次握手来建立连接的, 目的是为了协商连接ID. 协商好连接ID后, 后续双方都只需要连接ID,就可以实现连接迁移的问题了. 并且QUIC传输过程中的Packet Number是每个报文独一无二的编号, 它是严格递增的. 

为什么要这样设计?

这个设计是为了解决TCP重传的一个歧义问题. 例如下图所示, 当TCP发生超时重传的时候, 客户端发起了重传, 客户端发起了重传, 然后收到了来自服务器的确认ACK. 但是客户端原始报文和重传报文序号都是一样的, 所以服务器回复的都是相同的ACK.

所以, 客户端是无法知道哪个是原始的报文, 哪个是重传的报文的. 这样RTT就会有误,

• 如果计算为原始的报文, 但是实际上是重传的响应, 那么RTT会变大
• 如果计算为重传的报文, 但是实际上是原始的响应, 那么RTT会变小

RTO(超时时间)是通过RTT来计算的, 如果RTP不准, 那么重传的概率也会变大.

所以, QUIC这样的传输方式可以准确的计算出RTT, RTO的计算也是准确的. 如下图所示

QUIC解决TCP队头阻塞问题

TCP的队头阻塞问题其实就是出现在接收窗口的队头阻塞问题

当接收方收到的是有序数据时, 接收窗口才会滑动, 然后那些已经接收并且被确认的有序数据可以被应用层读取.

但是, 如果接收窗口收到的数据不是有序的, 那么就会阻塞住, 一直等待数据的到达. 这时候就出现了队头阻塞问题.  所以可以的出一个结论: TCP是为了保证数据的有序性

上图所示, QUIC借鉴了HTTP/2里的Stream的概念, 在一个QUIC连接中可以并发发送多个请求

每一个steam都分配了一个独立的滑动窗口, 这样使得一个连接上的多个Stream之间没有任何依赖关系, 都是独立的, 各自控制滑动窗口.