如今，作為國內短視頻賽道上的領跑者之一，快手 2020 上半年，快手直播日活達 1.7 億，電商日活超過 1 億，在保持內容多元化方向的同時每日還需處理萬億規模的用戶行為數據，這對單位時間內所處理流量的峰值 QPS 提出了更高要求。2020 年 7 月底，快手結合自身業務特點，針對短視頻場景下的痛點做了系列優化，推出了自研打造的支持 QUIC/HTTP/HTTPS 多協議同層接入的高性能伺服器 kQUIC。目前已全面上線，其集群峰值 QPS 已突破千萬量級。
針對 QUIC 協議存在的不足，快手是如何進行適配改造的？QUIC 協議在不同企業、不同場景下該如何應用？kQUIC 在滿足業務訴求和用戶體驗方面又發揮著怎樣的特殊優勢？等等
8 月 15 日，在快手舉辦的網絡傳輸技術沙龍上，kQUIC 研發團隊核心成員與來自阿里、騰訊的技術大咖，為現場的工程師們分享了 QUIC 在各自企業應用實踐的思考、分析了新一代網絡傳輸技術的標準化方向，以及在探索前沿技術時的實戰經驗。
本文整理自「快手網絡傳輸技術沙龍」中 7 位大咖的演講。
1kQUIC 千萬量級架構設計與部署實踐
快手系統運營部 SRE 李隆，詳細介紹了 kQUIC 的架構設計和部署。
QUIC 協議經過多年的探索和實踐，可大幅降低直播的卡頓問題，增強在各種複雜網絡環境下的直播體驗。快手之所以會選擇 QUIC，主要是基於以下三點特性來考量：
1）更快速
首先體現在低延遲連接上，相比 HTTPS，QUIC 建立連接的過程中至少少一個 RTT；與 TCP 不同，UDP 不是面向連接的，因此 QUIC 連接只需首次建立一次 QUIC 握手，後續便可在 0RTT 完成。其次是優化了多路復用，解決了 TCP 連接下請求丟包導致的隊頭阻塞的問題。
2）更靈活
主要體現兩個方面：一是擁塞控制，QUIC 將擁塞控制放在應用層，更新擁塞控制算法不需要停機升級，使得在某些場景下可更有效地改變擁塞策略，達到更優的效果；二是連接遷移，TCP 使用四元組 (源 IP，源埠，目的 IP，目的埠) 標識連接，網絡切換時會導致重連，而 QUIC 使用自定義的 Connection ID 作為連結標識，只要客戶端使用的 Connection ID 不變，即使網絡切換也能保證連結不中斷。
3）更安全
TCP 協議頭部未經過加密和認證，但 QUIC 所有的頭部信息均經過認證，並且對所有信息進行加密，可有效避免數據傳輸過程中被中間設備截取並篡改。
那麼，如何在具體實踐中引入 QUIC 協議？kQUIC 是怎麼來的？這要從快手的架構層說起。
在接入層架構設計層面，快手的 QUIC 架構經歷了眾多版本，早期快手採用兩層設備三層網關的架構，一層四層接入的公網 LB，獨立部署；兩層七層接入，一層 QUIC 服務負責處理 QUIC 請求，一層 NGINX 服務負責處理 HTTPS 請求，同機部署；但在該架構場景下，QUIC 進程與 NGINX 進程必然會產生競爭。
因此，快手對架構進行拆分，進行了多層設備多層網關架構的改動，即 QUIC 服務和 NGINX 服務拆分，通過內網 LB 進行交互；QUIC 請求通過公網 LB 轉到 QUIC 服務處理後，再由內網 LB 轉到 NGINX 服務進行處理。該架構雖然減少了整個資源間的競爭，但卻增加了鏈路的長度，又導致排查問題難度增高。
經過幾個月的努力，快手將 QUIC 服務 與 NGINX 服務進行了融合，由一層七層服務處理 QUIC 與 NGINX 請求，實現了最傳統的兩層網關架構的邏輯：一層四層 LB，一層七層負載均衡。這個過程裡面無論是 QUIC 請求還是 HTTPS 請求，都可以由 kQUIC 服務來處理，並且轉發給後端，減少了層級之間的複雜性。
最後在接入層部署中，快手主要進行了四方面的實踐：
第一是連接遷移。QUIC 客戶端使用 Connection ID 來支持連接遷移，但在服務端集群架構下，四層和七層服務同樣需要做支持。快手在四層做了轉發策略改造，支持根據 Connection ID 進行請求轉發，確保同一個 Connection ID 的請求被轉發到同一個七層接入上；在七層做了內核和進程的改造，實現了多進程代理情況下同一個 Connection ID 請求由同一個代理的同一個進程處理，真正實現了連接遷移。
第二是性能優化。基於 CPU TLS 加解密的會消耗大量 CPU 資源，導致性能瓶頸出現。因此快手採用遠端硬體加速卡異步 SSL 卸載集群的方式對加解密進行了優化。但由於其帶來的少量延遲，快手進一步優化，最終運用動態卸載的方式。當 CPU 在使用一定範圍之內使用本地卸載，高於這個範圍由遠端卸載，進而達到充分利用資源的同時儘量減少延遲帶來的影響。
第三是災備處理。由於 QUIC 協議的應用時間較短，所以在整個上線過程中快手充分考慮了降級和多集群災備預案。當發生 QUIC 請求失敗時，客戶端觸發 Broken 邏輯，降級為 HTTPS 繼續請求。另外，快手部署在多個 IDC 搭建了多套服務來進行容災，靈活支持 QUIC 和 HTTPS 的請求。通過客戶端 fallback 和服務端切流的邏輯，保證出現問題時能夠快速止損。
第四是安全保障。安全主要包含兩部分：數據安全和攻擊防護。QUIC 支持頭部認證和端到端加密，確保數據在網絡傳輸過程中的安全性。在防攻擊方面，針對 QUIC 一種十分有效的手段是 DDoS 反射攻擊。對此，快手採取的策略也簡單有效——「數據填充」。即通過填充數據包應對攻擊，客戶端第一個建聯數據包必須大於 1024 位元組，服務包至多三倍大小，盡最大可能降低被攻擊的可能性。
快手系統運營部 CDN 架構師沈坤針對 QUIC 場景落地實踐及結合快手場景優化做了介紹。
雖然 QUIC 的很多特性依靠協議本身就可實現，例如基於 UDP 消除了隊首阻塞問題、提供了更安全的報文加密機制等等。但是 QUIC 協議的兩個重要特性連接遷移和 0RTT，在協議層面只是為特性的實現奠定了基礎，單靠協議本身並不能保證獲得良好的實現效果，還需要在落地上做更多的優化。
通常而言，接入層的架構會分為兩層，一個四層的 LB 與七層的負載均衡，後面再是實際的業務邏輯層。當 quic 發生連接遷移時，訪問極可能失敗。
產生這個問題的原因，就是發生連接遷移時用戶的網絡發生了變化，四層 LB 如果還是按四元組哈希來派發請求，那就極可能把請求派發到其他伺服器上去，丟失連接的上下文導致訪問中斷。快手根據 QUIC 協議的設計，將四層 LB 上基於四元組的哈希修改成按照連接 ID 哈希，從而解決了連接遷移時請求被派發到不同伺服器的問題。
在七層的單個伺服器上，由於 NGINX 多進程之間數據沒有共享，導致了這隻實現了伺服器之間連接遷移的一半功能。當發生連接遷移的時候，因為請求的源 ip 和埠發生了變化，很可能被不同的 NGINX 進程處理，這樣也會丟失上下文，導致請求失敗。內核在派發報文時提供了 reuseport 的功能，和四層 LB 一樣是基於四元組做哈希。所以，我們可以使用和四層一樣的辦法，也採取按連接 ID 哈希的方式，保證同樣連接 ID 的請求落到同樣的進程上，進一步落地連接遷移的特性。
在 0RTT 方面，客戶端將服務端應答的 server config 和對應的 server config id 記錄下來，當重新建連時，直接使用 server config 計算密鑰並發送加密的數據，從而實現 0RTT。但在大規模的四至七層集群中，不同的七層伺服器、不同的伺服器進程生成的 server config 和 ID 均不相同。重新建連後連接 ID 發生了變化，經過按照連接 ID 哈希的方式處理後，很可能匹配到沒有對應的 server config 的伺服器上，導致 0RTT 握手的失敗。
沈坤認為，要實現穩定的 0RTT，核心在於伺服器要能夠根據客戶端請求里的 server config id 找到對應的 server config，基於這個思路，快手總結了兩個解決方案，具體如下：
方案一：
理念相對簡單，讓每個伺服器、每個進程生成相同的 server config 和 server config id，直接解決了兩台伺服器之間的不被採納的問題，實現跨機房、跨地域的 0RTT。理想情況下，這個方案的 0RTT 成功率可以達到 100%。但是這種方案的缺點也顯而易見，因全局使用單一的 server config，一旦出現信息泄漏，所有 0RTT 的請求都破解掉。不過因為 QUIC 的前向安全機制，影響範圍還是可控的。但如果業務有非常高的安全性要求，並不推薦這個方案。
方案二：
2數據驅動的統一客戶端網絡接入方案
快手音視頻體驗優化中心負責人郭君健，針對 kQUIC 的客戶端網絡接入方案做了詳細介紹。
kQUIC 項目的推出，需要快手的客戶端、音視頻、平台研發、系統運營等多個部門合作。那麼，快手是如何用不到一年的時間實現 kQUIC 快速穩定上線，並達到千萬 QPS 的？除了保證架構的創新以及穩定運維外，客戶端上的音視頻和網絡體驗優化也同樣重要。
首先，快手實現了客戶端統一接入方案。
客戶端優化目標，是建設完善的用戶體驗指標體系，以數據驅動為核心，驅動音視頻品質感達到業界領先，為用戶提供極致的網絡體驗。
快手設計了統一的客戶端網絡接入方案，從統一這個點來看可以分為三層：Android 接口適配層、iOS 接口適配層和網絡優化核心模塊，其中網絡優化核心模塊是網絡庫的關鍵，採用 C++ 開發，適用於 Android 和 iOS 雙端。如此便能實現統一數據上報、配置下發管理。通過更完善的協議支持，以及更高效的集成接入方案，同時配合統一指標體系建設，可以實現更加極致的性能優化。
客戶端網絡庫代替原 okhttp/AFNetworking 和 curl 進行 API 請求和短視頻下載，提供了 QUIC/HTTP/HTTPS 多協議支持。通過完善的信息上報和分析，針對 QUIC 場景進行了多項協議相關的優化，這裡有兩個例子：
預建連優化：網絡庫針對不同業務域名，協同 IDC 測速模塊，在啟動、網絡切換等時機進行連接的預先建立。不同於一般的預建連實現，針對使用 QUIC 的場景，在預建連 QUIC Session 的基礎上，網絡庫還會同時建立一個 TCP 連接或者 SSL Session 用於 HTTP(s) fallback，保證在 QUIC 失敗的情況下快速的回落到普通 HTTP(S) 連接。
SSL Session 復用優化：在服務端的支持下，網絡庫對 SSL Session Ticket 進行持久化並在後續連接中復用，在保證安全性的前提下大幅降低了 HTTPS 服務端的負載，同時降低了連接耗時，解決了 APP 啟動時首個 SSL Session 建立需要 2 個 RTT 的問題。
其次，快手構建了專業的實驗室測試方案。
基於現有的網絡庫，快手在實驗室對線上的場景進行細緻的拆分，通過配合服務端和客戶端模擬環境，進行細粒度的測試，由此來驗證算法的優劣，指導算法分析和優化。架構上包括客戶端、QUIC Server 和網損儀幾個部分，需要實現客戶端接口模塊、損傷配置模塊和數據處理模塊。
通過實驗室測試，可以發現一些線上環境比較難注意的問題。比如在項目初期，發現 kQUIC 在 20KB 文件大小 + 低丟包率場景下性能相比 HTTPS 低了近 30%。分析原因是，CC 算法在起步階段以特定速率發包，會額外多發一些包，導致帶寬利用率低、速度下降，20KB 文件 +20ms 延遲 + 低丟包率的網絡場景剛好能讓 CC 算法進入起步階段但無法進入穩定階段，剛好能觸發這個問題。這表明測試條件選取不能完全依賴應用場景，也要根據算法在不同階段特徵、差異增加 case 進行覆蓋，才能得到極致的優化體驗。
最後，快手進一步實施了網絡優化指標體系建設。
快手經常被大家戲稱為 AB 手，雖然是玩笑，但也說明快手非常注重數據，在實驗系統設計和數據驅動理念方面做的還是比較專業的。A/B 分析需要將研究對象隨機分組（保證同質性），對不同組實施不同干預，在這種嚴格條件下對照效果的不同。在研究對象數量足夠的情況下，這種方法可以抵消已知未知的混雜因素對各組的影響。
因為網絡優化會同時設計到客戶端和服務端，所以我們需要設計不同的實驗，來適配不同的場景，比如上線網絡庫，是一個客戶端實驗，只需要在客戶端層對用戶分組即可，服務端不需要特別配置。服務端實驗，比如 API QUIC 優化 CC 算法，第一輪實驗沒有考慮到機房的差異性，會對實驗帶來新的變量，在性能差異不大的極致優化場景，很難得出顯著性結論，所以在後續實驗里，做了一個調整，讓對照組和實驗組用戶都同時訪問同一個機房，來保證變量的唯一性。最後是更為複雜的 CDN QUIC 實驗，由於短視頻下載會涉及到 CDN、ISP、網絡類型、地域多個變量，所以在實驗期間需要在更多細分場景下做分析，逐步上線 QUIC 有收益的地區，其對服務側配置管理和客戶端適配能力要求較高。
從業務角度簡化來說，實驗上線的基本過程，需要拆解業務場景，進行灰度版本驗證，灰度版本 A/B 實驗，然後開啟全量版本 A/B 實驗。目前完成和正在進行的實驗包括 7 個大組：API 請求上線網絡庫、API 請求上線 QUIC、播放器上線網絡庫、短視頻下載逐步上線 QUIC、圖片顯示上線網絡庫、圖片顯示上線 QUIC、直播拉流上線 QUIC。
同時，在數據驅動的疊代優化的前提下，快手構建了一套網絡優化指標體系。該體系根據業務場景分為四部分：
- 內容 API 請求：其中 QoE 包含活躍用戶量和 APP 使用時長兩項指標，QoS 包括 API 連接成功率，連接復用率以及總耗時；
- 短視頻：短視頻下載的指標有播放和下載、播放時長、連接成功率、復用率以及總耗時等；
- 圖片：圖片顯示場景有單獨的指標，QoE 包括圖片展示的個數等，QoS 包括渲染成功率及下載成功率；
- 直播拉流：該部分為總時長、拉流人均時長、各種卡頓等多項指標。
總的來看，QoS 是一個很敏感的性能指標，能夠比較客觀地表現一些算法策略。無論量級如何，在大部分的實驗中都可以通過 QoS 得到比較可靠顯著的結論。QoE 衡量的則是項目對於公司業務指標的影響。
據了解，目前快手在客戶端方面正在推進的事情包括：MP-TCP、MP-UDP 等。未來也會在客戶端上進行完善的測速模型建設，協助客戶端和服務端進行策略和算法上的優化。
3長連接 QUIC 實踐及 HTTP3
快手基礎架構中心孫煒，詳細介紹了長連接 QUIC 的具體實踐。
所謂長連接，是指在一個連接上可以連續發送多個數據包，在連接保持期間，如果沒有數據包發送，需要雙方發鏈路檢測包。
今年上半年，快手在長連接的一個集群裡面，峰值達到了每秒 40 萬的新建連接，每秒 300 萬信令傳輸，9000 多萬同時在線連接，已經支持內部 20 多個核心在線業務。
快手的長連接系統支持 QUIC 協議後解決了如下協議層問題。
- 第一、建連耗時問題。對於長連接來講，連接包括 TCP 握手和信令握手，需要 2RTT。而通過 QUIC 協議可以做到協議層 0RTT 握手，總共能節省一個 RTT。
- 第二、連接保活。TCP 使用 WIFI 切換 4G，或者是 4G 切換 WIFI 會導致連接中斷，影響連接保活率。而 QUIC 協議支持連接遷移，網絡切換無需重連，所以當 IP 發生變化，仍然可以保持長連接，不需要中斷。
- 第三、頭部阻塞。單個 TCP 連接，隊頭報文丟失，會影響隊列中所有信令時延。在 QUIC 協議中基於 UDP 傳輸，創建多 Stream，所以隊頭報文丟失，不會影響其他信令，傳輸耗時也會有所改善。
- 第四、弱網優化。經過數據統計分析，在丟包率比較高的鏈路上，由於端上的擁塞控制算法依賴丟包檢測，導致耗時較高。基於 QUIC 協議，可以在應用層面定製優化一些算法，例如使用像 BBR 等擁塞控制算法，弱網條件下抗丟包能力比較強。
孫煒表示，快手的長連接 QUIC 實踐工作主要包含兩個方面。
首先是客戶端，QUIC 協議層依賴了 Chromium，而 Chromium 默認只提供面向七層的 QUIC 集成，團隊基於 Chromium 封裝實現了通用面向四層的 QUIC SDK，提供了類 POSIX socket APIs，使得 TCP 場景可以快捷的遷移到 QUIC 上。目前這套 QUIC SDK 已經應用長連接接入，RTMP 推流等。
其次在服務端，基於 Nginx stream 模塊搭建了 QUIC 代理層來 offload 協議，把用戶的 UDP 報文轉換成 TCP 報文，轉發給連接接入 server。另外，實踐中發現部分安卓設備上強制關閉 APP 以後，QUIC 實驗組無法上行清理服務端連接狀態，會導致 QUIC 實驗組假在線連接偏高。為了解決這個問題，在協議層面主動下行 QUIC PING，減少了假在線的比例，進一步對於下行的 PUSH 成功率有一些改善。
根據快手的實驗數據表明，建連耗時指標由於 QUIC 長連接減少一個 RTT 開銷，因此從 P10 到 P90 耗時收益比較高。在重連的次數上，QUIC 長連接下降了 5.8%，比例下降 0.38PP 左右，在信令長尾耗時方面 QUIC 長連接有 3% 到 8% 的正向收益。正因 QUIC 的種種優勢，所以身兼 IETF 旗下 HTTP 工作組組長和 QUIC 工作組組長的 Mark Nottingham 提議，將 HTTP-over-QUIC 改名為 HTTP/3，HTTP/3 協議標準便由此而來。
回顧 HTTP 的演進過程，HTTP 大致經歷了 HTTP1.1、HTTP2、HTTP3 這幾個階段。2012 年穀歌提出 QUIC 協議，QUIC 在傳輸層面由 UDP 換成了 TCP，並在傳輸加密層使用了谷歌自研 QUIC Crypto。谷歌在 QUIC 協議的提出到大規模落地過程中也經歷了比較長的時間，直到 2016 年，IETF 的標準化組織開始對 QUIC 進行標準化工作，也經歷了三年半左右的時間，直到今年 7 月份最後一版草案落地。
快手的 QUIC 實踐也是基於谷歌的 QUIC （GQUIC）協議，處於第三個階段 (GQUIC w/ H2)。那麼，第三個階段到第四個階段演變在協議層帶來什麼變化呢？為此，快手也對於 Google QUIC w/ H2 到 IETF QUIC w/ H3 之間發生的幾個變化進行了總結，大致可分為以下四點：
第一是握手。谷歌的 QUIC 協議使用的是 QUIC Crypto，IETF QUIC （IQUIC）使用的是 TLS1.3，整個握手的過程相對來講更安全。計算代價方面，對 QUIC 完全握手，RSA 證書的簽名比較耗時。而谷歌 QUIC 實現中存在一個問題，對於體積較小的證書也做了兩次 RSA 簽名，並且第二次簽名不會發送客戶端。快手內部的版本實現做了優化，即把簽名降到一次，因此全握手過程只需要簽一次名，0RTT 無需計算簽名。
第二是連接遷移。GQUIC 協議裡面連接遷移是依賴於 CID，是由客戶端產生，這樣 LB 可以根據 UDP 報文固定的部分做哈希路由。而 IQUIC 採用 DCID 路由，該欄位由 server 產生，因此會導致客戶端首報文和後續的報文 DCID 存在差異，無法簡單按照 DCID 哈希路由。為了解決這個問題，一個通用的做法是在服務端產生的 DCID 內編碼 HOST、進程 ID 等語義信息，LB 端解碼 DCID，再轉發至對應的主機。
第三是擁塞控制。GQUIC 實現支持 Cubic、BBR、etc。而 IQUIC 默認採用 NewReno，可替換，也支持 ECN 探測。ECN 主要功能為顯式擁塞通知，支持 ECN 的路由器通過對產生擁塞的報文修改其 IP 首部，告知接收端中間發生擁塞，接收端以響應的方式通知發送端，從而降低發送端速率，實現較快的擁塞反饋。
第四是頭部壓縮。GQUIC 採用 HPACK，但是其對於時序有要求，而在 QUIC 協議中多個 Stream 間沒有順序保證。為了解決這個問題，谷歌的實現通過用一個專門的 Header Stream 傳輸所有 Header，當接收端收到一個 Stream 之後，需要等待 Header Stream 上對應 Stream 頭部的編碼字典和引用到達後可解碼，存在隊頭阻塞問題。IQUIC 中採用 QPACK，不再依賴一個 Header Stream 傳輸編碼引用，極大的減少了這個問題。
第五是 HTTP2 Frames。在 HTTP2 中關於流控相關幀轉移到了 QUIC 協議層實現，同時還為 Server PUSH 增加了兩個控制幀。孫煒也透露，目前從標準化進程來看，HTTP3 從 draft 1 到草案 draft 29，經過 29 個版本疊代。今年 7 月已完成最後一個草案的反饋徵集，預計正式版本將很快會發布。
4MPQUIC 的技術探索
阿里雲智能技術專家洪小遲，分享了阿里基於 MPQUIC 的探索，即 MULTIPATH QUIC（簡稱 MPQUIC）
從 QUIC 出現之後，人們對其寄予了很大的厚望。除快手以外，關於 QUIC 協議國內各大廠商也都推出了相關服務。阿里雲作為國內較早開始擁抱 QUIC 協議的雲服務商，實踐經驗豐富。
阿里雲自研的 MPQUIC 類似於 TCP 提出的 NTCP 方案，可支持同時在多個鏈路通道上傳輸一條 QUIC 連接的數據，是 QUIC 協議多路徑方案的擴展。
具體來看，MPQUIC 提供兩種能力：一是進行無縫網絡切換，在智慧型手機使用場景裡面 MPQUIC 提供了協議棧多通道的能力，讓網絡訪問突破了單條鏈路的物理帶寬上限，從而提高了整體的訪問速度。二是同時使用兩個鏈路進行上網，單條鏈路的網絡中斷可及時切換到另外一條網絡鏈路上，實現網絡的無縫切換。
MPQUIC 使用多路徑進行傳輸，相當於使用了更多成本來提高整體的傳輸效率，所以在 MPQUIC 應用中一個比較大的困擾是如何做交互效率和成本的取捨。為此洪小遲分享了 MPQUIC 多路徑方案需要結合不同的業務場景關注的指標，做好傳輸策略，從而達到整體的優化目標。具體如下：
在圖片下載上，MPQUIC 拓寬了整個帶寬，通過設計支持底層傳輸協議的按優分配，提高了下載速度。在短視頻上，通過雙通道傳送同樣一份數據做冗餘傳輸，規避丟包帶來的秒開的影響，對短視頻秒開與卡斷做到了優化。
動態加速場景下，上行加速的能力尤為重要。MPQUIC 屬於用戶態協議棧，所以可以進行相應疊代。同時 MPQUIC 還增加多通道支持，為動態加速場景下的協議棧優化提供了多種選擇。
在直播場景中，與短視頻場景類似，卡頓秒開和延遲同樣關鍵。不同的是直播時間較長，需要面對網絡場景變化帶來的影響。可通過推流鏈路到達 CDN，經過播放鏈路到達播放器， 以 CDN 充當緩衝 Buffer 來減少卡頓產生的影響。
5QUIC 在騰訊海量業務的實踐和優化
提供線索的編輯騰訊 TEG 雲架構平台部專家工程師羅成、騰訊雲 CDN 傳輸協議研發負責人陳立，分享了 QUIC 在騰訊的海量優化的實例，以及新一代的架構升級
QUIC 看似功能強大，但是靈活性欠佳。為此騰訊設計升級了全新一代 LEGO 的 TQUIC 架構。第一點與 QUIC 的不同是 TQUIC 全部為多線程；第二點其基於 EPO 進行，由全異步事件驅動，從而提高開發者的效率；第三點多線程的配置共享和加載和通訊成本非常低，效率較高，並且配置靈活。
作為提升終端用戶訪問速率的 CDN 服務，其節點之間存在大量數據，而網絡連接、傳輸架構等因素又會對 CDN 服務質量產生影響。對此，陳立透露，針對商用 CDN 的場景，TQUIC 在傳輸性能方面做了很多優化工作。
目前原生 QUIC 在 CDN 應用中存在一些問題，眾所周知 CDN 承載的業務類型眾多，各業務對性能指標的定義不盡相同，另外全球加速服務也決定 CDN 面對網絡環境更加複雜，所以很多時候需要對性能做更深入的優化。但是 QUIC 傳輸層對網絡進行抽象封裝從而大幅提高易用性的同時也降低了開發者對網絡的感知能力，在此基礎上想對複雜場景下的傳輸性能做更深入的優化，是非常困難的，為此騰訊也提出了自己的優化解決方案。
第一，建立傳輸層實時評價體系。對網絡的傳輸行為做細化統計。在此基礎上，騰訊還在傳輸層完整記錄整個協議交互的過程並有選擇的存儲。這樣可以保證任何異常在事後是可回溯分析。
第二，複雜場景的預測分類。複雜場景下想通過一套傳輸策略來解決所有問題是不太現實的，細分並針對性解決是更為合適的方案，但在傳輸開始階段信息較為有限，想要準確的預測分類相當困難。騰訊通過在服務側構建了眾多的細分指標統計並結合一些客戶端的標籤數據進行基礎訓練取得了一些不錯的進展，比如在用戶接入方式的預測上目前準確率和召回率都可以達到 95% 以上。
第三，針對場景參數自動調優。在有足夠的細分統計數據後基本可以實時的對傳輸質量進行準確的評判，同時通過場景進行細分，降低場景相互干擾帶來的複雜程度，那麼針對各個場景就是比較典型的黑盒優化過程。
6寫在最後
無論在何種場景下，想要為用戶提供上佳體驗，讓用戶保持新鮮感，就需要企業不斷實現技術創新。成立 9 年以來，快手一直以用戶的極致體驗為目標，積極耕耘技術，推陳出新。未來，相信快手會與大家分享更多的技術落地實踐經驗及解決方案，為通信傳輸技術和產業發展添磚加瓦。
點個在看少個 bug
文章來源: https://twgreatdaily.com/yPosL3QBd8y1i3sJo__U.html