2022年6月6日，IETF QUIC和HTTP工作组成员Robin Mark在推特上宣布，历时5年，HTTP/3终于被标准化为 RFC，这也标志值QUIC作为http/3的底层传输协议的地位正式宣布转正。
之前我也简单的尝试了一下.net中基于MS-QUIC的Quic协议，当时用的版本是.net中的未正式版本，.net中对ms-quic的封装是计划在11月份的.net 7中发布，由于.net 7马上要进入rc阶段了，预览版的api接口已经完善，周末的时候简单的测试了一下目前对.net中使用msquic的情况。
- 预览版的.net 7已经开放了System.Net.Quic名字空间了
- Visual Studio 2022已经支持对.net 7预览版sdk开发
有了上面两个预研后，便简单的摸索了一下当前预览版的Quic协议的使用，基本接口没啥大变化，主要还是初始化参数上有些许差异。由于还不是正式版，代码这里就不附录了。
Demo程序测试成功后，顺便测试了一下它的性能，quic虽然基于udp协议，但它能提供类似tcp的可靠连接，并且能解决传统tcp的如下问题：
- 建连耗时问题。对于长连接来讲，连接包括 TCP 握手和信令握手，需要 2RTT。而通过 QUIC 协议可以做到协议层 0RTT 握手，总共能节省一个 RTT。
- 连接保活。TCP 使用 WIFI 切换 4G，或者是 4G 切换 WIFI 会导致连接中断，影响连接保活率。而 QUIC 协议支持连接迁移，网络切换无需重连，所以当 IP 发生变化，仍然可以保持长连接，不需要中断。
- 头部阻塞。单个 TCP 连接，队头报文丢失，会影响队列中所有信令时延。在 QUIC 协议中基于 UDP 传输，创建多 Stream，所以队头报文丢失，不会影响其他信令，传输耗时也会有所改善。
- 弱网优化。经过数据统计分析，在丢包率比较高的链路上，由于端上的拥塞控制算法依赖丢包检测，导致耗时较高。基于 QUIC 协议，可以在应用层面定制优化一些算法，例如使用像 BBR 等拥塞控制算法，弱网条件下抗丢包能力比较强。
我日常的典型弱网环境就是国外网站的访问了，便将quic作为底层的传输协议写了一个代理服务器， 试了下效果非常明显，在晚高峰期的时候访问，除了第一次连接代理服务器慢点外，后面通过代理服务器访问github或msdn等国外的网站基本上都能在几百毫秒内打开,感觉就是丝般顺滑。用它来做个网络加速器应该是个不错的选择。
相关文章：