一文读懂QUIC 协议：更快、更稳、更高效的网络通

除了在建连进行竞速以外还可以对网络QUIC和TCP的传输延时进行实时监控和对比如果有链路对UDP进行了限速可以动态从QUIC切换到TCP，面对新的协议我们总是有着各种各样的担忧诚然QUIC协议在稳定性上在成熟度上的确还不如TCP协议但是经过近几年的发展成熟度已经相当不错了Nginx近期也发布了1.25.0版本支持了QUIC协议。

注意在握手完成之后服务端会发送一个New Session Ticket报文给客户端这个包非常重要这是0-RTT实现的基础， 流量控制要解决的问题是接收方控制发送方的数据发送的速度就是我的接收能力就那么大点你别发太快了你发太快了我承受不住会给你丢掉 你还得重新发，简单来说假设你访问某个网站需要请求10个资源你使用HTTP1.1协议只能串行地发请求资源1请求成功之后才能发送资源2的请求以此类推这个过程是非常耗时的，TCP需要QUIC也同样需要， 二QUIC协议的优秀特性   2.1 建连快   数据的发送和接收要想保证安全和可靠一定是需要连接的， 连接ID的主要功能是确保底层协议UDP、IP及更底层的协议栈发生地址变更比如IP地址变了或者端口号变了时不会导致一个QUIC连接的数据包被传输到错误的QUIC终端客户端和服务端统称为终端上， 3.数据在传输过程中可以将一轮中所有的ACK解析后再同时进行处理避免处理大量的ACK， 1-RTT的握手主要包含两个过程 1.客户端发送Client Hello给服务端 2.服务端回复Server Hello给客户端 我们通过下图中图5和图6来看Client Hello和Server Hello具体都做了啥 第一次握手Client Hello报文     图5-Client Hello报文 首先Client Hello在扩展字段里标明了支持的TLS版本Supported VersionTLS1.3，首先你干不掉内核里的TCPTCP太古老了全世界的服务器的TCP都固化在内核里了，对此我们可以采用多路竞速的方式使用TCP和QUIC同时建连，如图1所示传统HTTPS请求流程图     图1-传统HTTPS请求流程图 对于一个小请求用户数据量较小而言传输数据只需要1个RTT但是光建连就花掉了3个RTT这是非常不划算的这里建连包括两个过程TCP建连需要1个RTTTLS建连需要2个RTT，     图4-QUIC的1-RTT握手流程 我们通过图4可以看到整个握手过程需要 2次握手第三次握手是带了数据的所以整个握手过程只需要1-RTTRTT是指数据包在网络上的一个来回的时间，HTTP/2的多路复用解决了这一问题能使多条请求并发，如下图所示每个流都有自己的可用窗口可用窗口的大小取决于最大窗口数减去发送出去的最大偏移数跟中间已经发送出去的数据包是否按顺序收到了对端的ACK 无关。

如果终端的缓存区不够用了则其可以通过暂时扩大缓存空间确保握手完成， 我们经常需要在WiFi和4G之间进行切换比如我们在家里时使用WiFi出门在路上切换到4G或5G到了商场又连上了商场的WiFi到了餐厅又切换到了餐厅的WiFi所以我们的日常生活中需要经常性的切换网络那每一次的切换网络都将导致我们的IP地址发生变化，如果客户端接收到了一个未知的服务器发来的数据包那么客户端必须丢弃这些数据包。

图14- 连接迁移流程图    2.3 解决TCP队头阻塞问题   在HTTP/2中引入了流的概念，所以既然干不掉TCP那我不用它了我再自创一个传输层协议放到用户态然后再结合TLS这样不就可以把两个建连过程合二为一了吗是的这就是QUIC，显然HTTP/3属于应用层协议而它使用的QUIC协议属于传输层协议。

    图6-Client Hello报文