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等國外的網站基本上都能在幾百毫秒內打開,感覺就是絲般順滑。用它來做個網絡加速器應該是個不錯的選擇。
相關文章：