QUIC
大纲
-
为什么使用QUIC？
- 对比TCP
- QUIC/TCP与TLS的关系
-
QUIC会带来哪些问题？
为什么使用QUIC
HTTP3使用QUIC最核心的原因就是 速度。
对比TCP
由于QUIC构建与UDP之上，所以在传输前对比TCP来说少了三次握手的两次往返过程（0往返）。 而如果加上TLS协议的话，还需要再增加几次握手。
TCP包由于需要保存链接信息、握手信息、标志位等，会比UDP包大。在HTTP2中，虽然使用了链接的多路复用以及引入了Stream的概念，使其减少了建立连接的次数以及连接的数量，但这个方案也有缺点。
TCP/UDP对比：
-
QUIC 协议可以在 1 到 2 个数据包（取决于连接的服务器是新的还是已知的）内，完成连接的创建（包括 TLS）
- 在高网速环境下（5G），一个数据包的延时为10ms~50ms，而对于响应的感知只要不超过50ms就不会有太大感觉。但在4G的环境下C/S之间的延时通常在100ms以上。传统TCP+TLS的传输方式在创建连接时需要4个数据包，对于QUIC的一/二个数据包而言就意味着延时至少为200ms
-
HTTP2中，多路复用链接时只要其中一个
Frame丢失那么流上的所有包都需要等待服务器重传，在此期间其中所有包的传输都将阻塞。 -
多路复用意味着连接数量减少，在减少连接次数的同时由于每个连接的吞吐量有限，那就意味着TCP的窗口大小也将缩小，达到一定传输量后所有流都会被限流。
-
由于UDP建立连接的低成本，所以会建立多个流，数据将平摊在每个流中。这样意味着如果出现丢包也只会影响该流中的数据传输，其他流中的数据只要等待该流重传即可，而TCP重传该报文段时后面的所有报文段都将阻塞
-
UDP在网络抖动的情况下正常来说是比TCP表现的更为优秀的。因为在应用层能比TCP更快的探测和重传（也是因为没有握手过程），而超时后服务端使用UDP时也可以直接断开socket，而不需要挥手
-
QUIC为了减少丢包导致的影响（确认丢包、请求重传、等待数据包），有
向前纠错的特性。其每份数据包中都有10%的数据区存放了其他数据包的数据，因此少量丢包可以通过其他包的冗余数据直接组装无需重传。【RAID 5】 -
UDP在建立连接时无需依赖来源IP而是会生成一个标记（连接UUID），而TCP标识一个连接需要四个参数：来源IP、来源端口、目的IP和目的端口，只要其中任一参数改变 TCP都需要重建连接。
- 移动设备由于网络环境的不确定性，经常会出现网络切换（WIFI->5G, 5G->4G），从而导致TCP重新建立连接.
- 利用连接UUID的特性，使用UDP协议可以让设备的网络接口共享UUID从而达到并行下载的目的。（因为UDP只会识别UUID，而不会识别是哪个IP；参考手机中WIFI+5G的解决方案）
（WiKiPedia）
（HTTP2缺陷）
hkt999.medium.com/tls-1-3-qui…
（TLS 1.3 / QUIC 與 HTTP/3 對效能的改善）
（什么是QUIC）
(Google QUIC 协议：从 TCP 到 UDP 的 Web 平台)
docs.google.com/presentatio… （QUIC在google developer meeting中的slides）
