带你读《2022技术人的百宝黑皮书》——HTTP3 RFC标准正式发布， QUIC会成为传输技术的新一代颠覆者吗？（1）https://developer.aliyun.com/article/1340580?groupCode=taobaotech
如何应用QUIC/HTTP3来提升传输性能表现
这次IETF发布的RFC9114和9204分别描述的是HTTP/3.0和配套的Header压缩算法QPACK的协议机制。HTTP/3.0相对于HTTP/2到底有什么本质提升？这需要从HTTP/3底层的QUIC传输机制讲起。
我们都知道，QUIC基于UDP之上的多流（Stream）传输，实现解决原来TCP大管道下的Head-of-Line问题[3]，同时0-RTT等握手机制可以保证连接会话的快速建立和首包的加速。QUIC提供了两种传输模式，基于Steam的可靠传输，和基于Datagram的非可靠传输。基于Stream的模式下，发送方和接收方基于Steam的Offset进行流 数据的重排和有序还原，并确保投递给应用层的是有序可靠数据。基于Datagram的模式则适用于实时流媒体类型的场景，针对延迟有强诉求的同时不要求数据完全可靠有序的这类场景，Datagram提供了一种数据封装和ACK通 知的方式，帮助半可靠诉求的场景实现数据的快速投递，并向应用层反馈送达情况。
[3] TCP Head-of-line头部阻塞问题：原因是TCP是一条大的传输管道，基于TCP传输的数据，由于TCP的传输机制，需要等待前面的数据包完成送达，后续的数据包才能被完成送达和向应用层投递。这在多路复用的场景下， 会导致不同的流数据之间互相block，这在HTTP/2是一个没有被完全解决的问题。
QUIC在丢包检测和重传机制方面也有较大革新。在丢包检测方面，QUIC提供了两大类丢包检测方式，基于packet number的阈值检测，和基于定时器的超时丢包检测。这两类机制相对于传统的TCP检测方式可以带来更快的丢包感知和恢复。在重传恢复方面，QUIC针对每一个packet分配独立的packet number，避免了过去TCP因重传包和原始包复用相同的sequence，导致的RTT测量不准确的问题。准确测量的RTT，作为拥塞控制算法的一维 重要输入，能够使得算法对瓶颈段拥塞状况的检测更加准确。
这次发布的HTTP3 RFC，则是在QUIC基础之上，描述了HTTP请求如何通过跟QUIC steam的映射，实现完整的HTTP语义，以及针对基于UDP的多流机制设计的专用头部压缩。因此所有QUIC在UDP之上实现的传输机制革新，HTTP3都可以享受到红利。
那么如何把这项革新的技术用起来呢？XQUIC针对QUIC和HTTP/3协议栈提供了完整的能力实现，并且完全符合IETF标准，并通过了IETF工作组的互通性验证[4]。在手机淘宝我们提供了整套的网络解决方案，包含客户端的SDK和服务端网关的能力支持，各类业务场景核心关注开关和放量情况即可。对于外部开发者，可以移步到XQUIC在github的开源仓库[5]，开源仓库有相对完整的文档说明和RFC译文，同时后续开源版本我们也将逐步更
新IETF工作组版本的Multipath[8]多路传输能力，以及Tengine相关的适配版本和模块，方便外部开发者能够更方便地使用。
带你读《2022技术人的百宝黑皮书》——HTTP3 RFC标准正式发布， QUIC会成为传输技术的新一代颠覆者吗？（3）https://developer.aliyun.com/article/1340578?groupCode=taobaotech
