👉騰小云導讀
也許你有這樣的體驗：當你加入騰訊會議開會，老闆正在發佈重要任務時，你恰好要進電梯時 wifi 切換成了 cellular，畫面開始「轉菊花」，網絡斷開重連卻需要好久，最終老闆的指示你一個字都沒聽清楚!。這個問題，要從會議的傳輸協議開始說起。會議團隊遇到了網絡切換的難題，是怎麼解決的呢？歡迎繼續往下閱讀，看看騰訊會議團隊的思路。
👉看目錄，點收藏
1 傳統 TCP+TLS 套裝有哪些弊端
2 QUIC 帶着一大堆 buff 來了：條件分析
3 嘗試喫掉 QUIC 這隻大螃蟹：解決方案
4 蟹鉗厲害，務必小心：難點挑戰
5 螃蟹果然美味：未來展望
6 路漫漫其修遠兮：優化成果
01、傳統 TCP+TLS 套裝有哪些弊端
騰訊會議的業務特性決定了客戶端和服務器需要建立長連接，而且要保證安全可靠，因此我們在選擇傳輸層協議時採用了傳統 TCP+TLS 套裝。TCP 協議提供了可靠傳輸通道，TLS 加密協議爲通道提供了安全保障。TCP 連接建立需要經過三次握手，在此基礎上TLS 握手協議又需要四次握手。
因此，在正式開始數據通信之前，建立 TCP 連接需要 1.5 個 rtt，完成通道的 TLS 加密需要 1 個 rtt (TLS1.3)，會議業務整個握手總體流程如圖 1 所示：
圖 1 基於 TCP+TLS 技術的長鏈接建立流程
從圖 1 可以看到：統計數據表明，所有登錄失敗的用戶中，有 41.53% 的用戶是因爲連接建立超時導致登錄失敗。因爲弱網情況下rtt 較大，如果連接建立的流程複雜的話必然導致完成握手的耗時較多，超時的可能性更大。也就是文中開頭提到的：重新連接耗時比較久。因此，簡化握手環節，減少登錄耗時，提高登錄成功率和弱網抗性是需要解決的問題。
那爲什麼目前的機制下，wifi 和 cellular 之間互相切換需要斷開重連呢？因爲 TCP 協議使用一個四元組來標識一個長鏈接、源 IP 地址、目的 IP 地址、源端口、目的端口。當用戶設備網絡在 wifi 和 cellular 之間切換時，源 IP 會發生變化。因此 TCP 天然無法支持在 wifi 和 cellular 之間無縫切換，也就導致一旦用戶切換網絡，整個長鏈接必須斷開重連，否則數據無法繼續傳輸。表現在會議產品上就是會出現「轉菊花」場景，等待重連成功，見圖 2：
圖 2 TCP連接情況下 cellular/wifi 切換表現
在斷開重連期間，所有指令數據都無法發送接收。日常會議過程中，當用戶進出電梯或者偶現 wifi 信號不好，導致 wifi 和 cellular 互相頻繁切換的場景是非常常見的。也就是文中開頭說到的場景了。這樣的體驗其實非常影響用戶會議有效性。因此讓數據通道能夠實現在 wifi 和 cellular 之間無縫切換，更是亟待解決的問題。
02、QUIC 帶着一大堆 buff 來了！
QUIC 協議與 TCP 相比，本身就具有快速建立連接的優勢（0/1-rtt），而且同樣是可靠傳輸通道，自帶加密通信 buff，省略了 TLS 的握手步驟。QUIC 協議的握手流程見圖 3：
圖 3 QUIC 握手流程
如圖 3 所示，QUIC 在初次建立連接時， 只需要 1 個 rtt。客戶端收到服務端發送的 Rejection 之後，會在下次發送數據時帶上客戶端的加密信息，跟應用數據一起發送到服務端，從而在一個 rtt 裏完成握手和數據加密動作。相較於 TCP+TLS，它減省了 1.5 個 rtt。結合會議業務長連接握手流程，又能省掉 TLS 握手之前的協商過程。應用 QUIC 協議的長鏈接建立流程如圖 4 所示：
圖 4 基於 QUIC 技術的長鏈接建立流程
結合會議長連接建立的整體過程，理論上連接建立耗時能夠減少 40%~50%。這其中還沒有包括 QUIC 協議本身比 TCP 在某些場景下傳輸效率更高帶來的收益。
同時，QUIC 協議的設計是可以支持連接遷移（Connection Migration），因爲 QUIC 是使用 connectionID 來唯一標識一個鏈接。當客戶端網絡在wifi 和 cellular 之間切換時，即使源 IP 發生改變，這個長鏈接的 connectionID 不變，數據通道就不會斷。連接遷移流程如圖 5 所示：
圖 5 連接遷移UML序列圖
概括如下：
-
連接遷移之前，客戶端的 IP1，使用非探測包（non-probing packet）和服務端進行通信。
-
客戶端的 IP 變成 2，它可以發送包含非探測幀（non-probing frames）的包，將連接遷移到新的地址。
-
客戶端在新路徑啓動路經驗證，驗證新路徑的可達性。
-
客戶端發送包含 path_challenge 幀的探測包（probing packet），path_challenge 幀裏面包含一個不可預測的隨機值。
服務端在 path_response 幀裏面包含前一步 path_challenge 接收到的隨機值，響應探測包（probing packet）。
客戶端接收到服務端的 path_response，驗證 payload 裏面的值是否正確。
同樣的，服務端也需要使用路經驗證，驗證客戶端對其新IP地址的所有權。
因此，引入 QUIC 協議之後的長鏈接能夠做到在 wifi 和 cellular 之間的無縫切換，而不必重新建立連接。用戶在會議中發生網絡切換場景時，音視頻數據和開關麥克風/攝像頭等等網絡操作都可以直接續傳，用戶是完全無感知的。
03、嘗試喫掉 QUIC 這隻大螃蟹：解決方案
QUIC 目前只有 http 協議的應用，那麼它對於長鏈接的適用性怎麼樣呢？ 理論上完全可行，實際上我們一無所知，業界之前也沒有做過這方面的嘗試。但既然它如此滿足需求，爲什麼不試一試呢？我們考察了業內比較完善的 quic 組件方案，詳見圖 6：
圖 6 QUIC 方案選型
*注：cronet 僅暴露應用層 http 接口，無法滿足傳輸層接口封裝需求。QuicTransport 僅支持 TLS1.3 加密實現，無法與 stgw 互通，後者還停留在 quic 私有加密算法版本。
綜合接入成本、使用廣泛性和其他各方面考慮， TQUIC 是較優的選擇。TQUIC 是由騰訊公司 stgw(secure tencent gateway) 團隊提供的與其後臺架構相輔相成的 sdk。它只封裝了原始的 quic 功能接口，輕便易用。如果使用 stgw 的 quic 接入層服務，TQUIC 應該是首選。我們將 TQUIC sdk 集成到客戶端，打造了新的客戶端服務器交互架構。如圖 7 所示：
圖 7 QUIC 協議傳輸網絡
接入之後，業務數據包傳輸沒有任何問題。但是 tquic 基於 goolge 的 cronet 庫實現，google 只實現了 android 端的連接遷移， 而騰訊會議的網絡層是跨平臺的設計。因此我們面臨的一個重要問題是需要將連接遷移的特性擴展到全平臺，通過分析 google 的 android 平臺實現。該技術方案如圖 8 所示：
圖 8 cronet裏實現的連接遷移
其中實現了對 android 平臺的物理網絡監聽。 在網絡切換時，會收到系統通知，由於 ip 已經切換了， 原始 ip 綁定的 socket 已經無法繼續通信。因此需要新建一個 socket 跟新的 ip 綁定，繼續進行網絡收發包，並且對原始socket 緩存中發送失敗的包進行重發，從而完成網絡通道的遷移。
通過對連接遷移的原理和 google 的代碼分析，結合系統 socket 編程技術，引入跨平臺通用的連接遷移技術方案，真正實現了移動端 wifi 和 cellular 的無縫切換！
04、蟹鉗厲害，務必小心：難點挑戰
2020 年開始投入 QUIC 預研時， QUIC 還沒有在業界成爲主流，主要的原因有以下幾點：
- 中間件爲了保證 TCP 網絡鏈路通暢，強制丟棄 UDP 包；
- 機構和企業設置攔截防火牆，關閉了 QUIC 的通用端口。
而切換到新的建連方式，又面臨瞭如下挑戰：
-
提供 QUIC 服務的服務器集羣發生故障，導致 QUIC 大規模連接失敗；
-
引入 TQUIC 的 sdk，做的改造還沒有經過外網的大量驗證，可能帶來crash，在長連接建立路徑上發生 crash 將直接導致登錄失敗，會議所有功能都無法使用，這是致命的。
爲了避免這些問題導致的 QUIC 不通，或者會議服務不可用的情況，在正式上線前，我們從四個方面進行了預防，規避和補救。
- 從 TCP 切換到 QUIC 前，先進行嗅探，確認此路可通，才具備切換條件，而且連通性在使用過程中也會進行刷新；
- 通過雲端配置 QUIC 開關，可以進行地區，版本，網段，具體用戶等粒度的控制，進行 QUIC 功能的灰度和日常容災；
- 使用 QUIC 過程中，一旦產生協議層面的錯誤，就降級成 TCP；
- 在 QUIC 長連接建立過程中設置 crash 保護，一旦發生 QUIC 引入的crash，降級成 TCP，避免連續 crash；
總結如下圖：
圖 9 QUIC 開啓和在線降級策略
在正式灰度 QUIC 之前，我們統計了嗅探數據：外網的 QUIC 連通性達到98% 以上，所以理論上是可以全面鋪開的。完成這一系列的防護措施之後，纔開始灰度，2021 年已經完成全量。
關於 QUIC 的知識科普，官方的學習資料和一些科技大佬的解析都非常通俗易懂、值得學習。如果各位感興趣的話，可以在公衆號後臺回覆 QUIC 領取。
05、螃蟹果然美味：優化成果
通過將 QUIC 協議引入到建立客戶端和服務器之間的長鏈接過程，並結合騰訊會議產品的登錄握手協議，利用 QUIC 的快速握手同時通道加密的特性和連接遷移特性，取得了較大的優化效果。
根據線上數據統計，登錄平均耗時優化效果達 48.6%。因爲登錄耗時高產生的超時問題也得到改善，進而提高了登錄成功率，優化效果達 0.09%。
在實際會議場景中，大家用得最多的應該是開關麥和開關攝像頭功能。有過會議體驗的人應該有所感觸，網絡不是很好的時候，點擊開麥按鈕，半天都沒有反應，令人捉急。或者要關麥的時候怎麼都關不了......這些尷尬情況在使用QUIC 之後也得到了有效改善。
QUIC 協議的擁塞控制算法比 TCP 更加靈活。 因爲加大了 sack，所以其丟包重傳策略也比 TCP 更高效，可以有效增加弱網抗性。根據數據統計，會議中開關麥成功率，開關攝像頭等等關鍵信令成功率都得到不同程度的提升。
在添加網絡損傷場景下，QUIC 連接也表現出比 TCP 更好的網絡抗性.通過專業網絡損傷儀模擬不同的弱網場景，在加大丟包率和抖動的情況下，TCP 長鏈接的在線心跳在丟包率 70% 場景下會斷開。而 QUIC 長鏈接，同樣的心跳策略能扛住 80% 丟包率，如圖 10 所示。
圖 10 抗丟包率優化效果
從用戶角度來說，最直觀的感受是，網絡切換再也不「轉菊花」啦！
圖 11 QUIC 連接情況下 cellular/wifi 切換表現
06、路漫漫其修遠兮：未來展望
目前，QUIC 在會議業務長連接上的應用已經穩定運行 2 年多了。HTTP 切換QUIC 通道也基本部署完成、進入測試環節。QUIC 本來就是 google 爲 HTTP 請求量身打造的。0-rtt、避免隊頭阻塞、多路複用等等黑魔法的加持，使 QUIC 在 HTTP 業務上更「得心應手」。升級版的騰訊會議將給用戶帶來網頁秒開，資源秒加載的更棒的使用體驗。
因爲篇幅原因，這裏對 QUIC 的知識科普有限。個人強烈推薦各位去看看 QUIC 官方的學習資料和一些科技大佬的解析，非常通俗易懂、值得學習。各位，可以在公衆號後臺回覆 QUIC 領取（碼住，別喫灰!）。
更多騰訊會議的優化 case，可直接點擊騰訊會議10秒編譯百萬代碼｜鵝廠編譯加速標杆案例公開、企業微信零耦合集成騰訊會議和騰訊文檔插件化架構實踐。以上是本次分享全部內容，歡迎大家在評論區分享交流。
-End-
原創作者｜餘一
技術責編｜餘一
一直以來，性能優化是程序員面對的重要課題。頁面功能、代碼細節、數據庫調優......你見過哪些令你「瞠目結舌」的優化？在工作中經歷過哪些性能優化的項目？有什麼經驗分享？有哪些工具推薦？歡迎公衆號評論區留言。
我們將選取1則最有創意的分享，送出騰訊雲開發者-限定馬克杯1個（見下圖）。4月26日中午12點開獎。
關注騰訊雲開發者並點亮星標
公衆號回覆「QUIC」領作者推薦的連接遷移學習材料