QUIC 協議非常有趣，這就是我們喜歡撰寫有關它的原因。 但是，如果之前有關 QUIC 的出版物更多的是歷史（本地歷史，如果你願意的話）性質和硬件，那麼今天我們很高興發布不同類型的翻譯 - 我們將在 2019 年討論該協議的實際應用。 此外，我們談論的不是所謂車庫中的小型基礎設施，而是幾乎在世界各地運作的 Uber。 該公司的工程師如何決定在生產中使用 QUIC、他們如何進行測試以及他們在生產中推出 QUIC 後看到的結果 - 低於標準。
圖片是可以點擊的。 享受閱讀！
Uber 的業務遍及全球，即 600 個城市，其應用程式完全依賴 4500 多家行動電信商的無線網路。 用戶期望應用程式不僅要快，而且要即時——為了實現這一點，Uber 應用程式需要低延遲和非常可靠的連接。 唉，但是堆疊 在動態和容易遺失的無線網路中表現不佳。 我們意識到，在這種情況下，低效能與作業系統核心中的 TCP 實作直接相關。
為了解決這個問題，我們應用了 ，一種現代通道復用協議，使我們能夠更好地控制傳輸協議的性能。 目前工作小組 將 QUIC 標準化為 .
經過大量測試後，我們得出的結論是，與 TCP 相比，在我們的應用程式中實施 QUIC 會帶來更低的尾部延遲。 我們觀察到駕駛員和乘客應用程式中的 HTTPS 流量減少了 10-30%。 QUIC 也為我們提供了對使用者包的端對端控制。
在本文中，我們分享了使用支援 QUIC 的堆疊為 Uber 應用程式優化 TCP 的經驗。
最新技術：TCP
如今，TCP 是在 Internet 上傳輸 HTTPS 流量時最常用的傳輸協定。 TCP 提供可靠的位元組流，從而應對網路擁塞和鏈路層丟失。 TCP 在HTTPS 流量中的廣泛使用是由於前者的普遍存在（幾乎每個作業系統都包含TCP）、大多數基礎設施上的可用性（例如負載平衡器、HTTPS 代理和CDN）以及可用的開箱即用功能在幾乎大多數平台和網路上。
大多數用戶在旅途中使用我們的應用程序，TCP 尾部延遲遠遠不能滿足我們實時 HTTPS 流量的需求。 簡而言之，世界各地的使用者都經歷過這種情況 - 圖 1 顯示了主要城市的延誤情況：
圖 1：Uber 主要城市的尾部延遲各不相同。
儘管印度和巴西網路的延遲高於美國和英國，但尾部延遲明顯高於平均延遲。 即使對於美國和英國也是如此。
TCP 空中傳輸效能
TCP 的創建目的是 有線 網絡，即強調高度可預測的連結。 然而， 無線的 網路有其自身的特徵和困難。 首先，無線網路容易因幹擾和訊號衰減而遭受損失。 例如，Wi-Fi 網路對微波、藍牙和其他無線電波敏感。 蜂窩網路遭受訊號遺失（）由於物體和建築物以及來自的訊號的反射/吸收 來自鄰近的 。 這會導致更顯著（4-10 倍）和更多樣化 與有線連接相比，資料包遺失。
為了應對頻寬波動和損失，蜂窩網路通常使用大緩衝區來應對流量突發。 這可能會導致過度排隊，這意味著更長的延遲。 TCP 通常將這種排隊視為由於逾時延長而造成的浪費，因此 TCP 傾向於中繼並從而填充緩衝區。 這個問題被稱為 (），這非常 現代互聯網。
最後，蜂窩網路效能因營運商、地區和時間而異。 在圖 2 中，我們收集了 2 公里範圍內跨小區的 HTTPS 流量的中位數延遲。 為印度德里的兩家主要行動營運商收集的數據。 正如您所看到的，不同單元的性能有所不同。 此外，一名操作員的生產率與另一名操作員的生產率不同。 這受到考慮時間和位置的網路進入模式、用戶移動性以及考慮塔密度和網路類型（LTE、3G等）比例的網路基礎設施等因素的影響。
圖 2. 以 2 公里半徑為例的延遲。 印度德里。
此外，蜂窩網路的效能隨時間而變化。 圖 3 顯示了一週中各天的平均延遲時間。 我們也在一天和一小時內觀察到較小規模的差異。
圖 3. 對於同一操作員，不同天的尾端延遲可能會有很大差異。
上述所有因素都會導致無線網路中 TCP 效能低。 然而，在尋找 TCP 的替代方案之前，我們希望對以下幾點有一個準確的理解：
- TCP 是我們應用程式中尾部延遲的罪魁禍首嗎？
- 現代網路是否存在顯著且變化的往返延遲 (RTT)？
- RTT和丟包對TCP效能有什麼影響？
TCP效能分析
為了了解我們如何分析 TCP 效能，讓我們快速了解 TCP 如何將資料從發送方傳輸到接收方。 首先，發送方建立TCP連接，執行三向 ：發送方發送 SYN 封包，等待接收方發送 SYN-ACK 封包，然後發送 ACK 封包。 額外的第二遍和第三遍用於建立 TCP 連線。 接收方確認收到每個資料包 (ACK) 以確保可靠的傳送。
如果封包或 ACK 遺失，發送方會在逾時（RTO、 ）。 RTO 是根據各種因素動態計算的，例如發送方和接收方之間的預期 RTT 延遲。
圖 4. TCP/TLS 上的封包交換包含重傳機制。
為了確定 TCP 在我們的應用程式中的執行情況，我們使用以下命令監控 TCP 封包 來自印度邊緣伺服器的戰鬥流量一周。 然後我們使用以下方法分析 TCP 連接 。 此外，我們創建了一個 Android 應用程序，將模擬流量發送到測試伺服器，盡可能模仿真實流量。 裝有此應用程式的智慧型手機被分發給幾名員工，他們在幾天內收集了日誌。
兩個實驗的結果是一致的。 我們發現 RTT 延遲很高； 尾部值幾乎比中位數高6倍； 算術平均延遲超過1秒。 許多連線遺失，導致 TCP 重新傳輸了所有資料包的 3,5%。 在機場和火車站等擁擠區域，我們看到了 7% 的損失。 這些結果對蜂窩網路中使用的傳統觀點提出了質疑 顯著減少運輸層面的損失。 以下是「模擬器」應用程式的測試結果：
網路指標
意
RTT，毫秒 [50%,75%, 95%,99%]
[350，425，725，2300]
RTT 發散，秒
平均~1,2秒
連接不穩定時丟包
平均約 3.5%（超載地區為 7%）
幾乎一半的連線至少有一個封包遺失，其中大多數是 SYN 和 SYN-ACK 封包。 大多數 TCP 實現對 SYN 封包使用 1 秒的 RTO 值，該值對於後續遺失呈指數增長。 由於 TCP 需要更長的時間來建立連接，因此應用程式載入時間可能會增加。
就封包而言，在無線網路中存在瞬態遺失的情況下，高 RTO 值會大大降低網路的有用使用率。 我們發現平均重傳時間約為 1 秒，尾部延遲近 30 秒。 TCP 等級的高延遲導致 HTTPS 逾時和重新要求，進一步增加網路延遲和效率低下。
測量的 RTT 的第 75 個百分位數約為 425 毫秒，而 TCP 的第 75 個百分位數幾乎為 3 秒。 這暗示遺失導致 TCP 需要 7-10 遍才能成功傳輸資料。 這可能是RTO計算效率低、TCP無法快速回應遺失的結果 視窗中的問題以及擁塞控制演算法的低效率，該演算法沒有區分無線遺失和網路擁塞造成的遺失。 以下是 TCP 遺失測試的結果：
TCP丟包統計
值
至少有 1 個資料包遺失的連線百分比
企業排放佔全球 45%
連線建立期間遺失的連線百分比
企業排放佔全球 30%
資料交換期間遺失的連線百分比
企業排放佔全球 76%
重傳延遲分佈，秒數 [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
一個資料包或TCP段的重傳次數分佈
[1,3,6,7]
QUIC的應用
QUIC 最初由 Google 開發，是一種運行在 UDP 之上的多執行緒現代傳輸協定。 目前 QUIC 處於 （我們已經寫過，QUIC 有兩個版本，好奇 – 大約。 譯者）。 如圖5所示，QUIC置於HTTP/3之下（事實上，QUIC之上的HTTP/2是HTTP/3，目前正在大力標準化）。 它透過使用 UDP 形成封包來部分替代 HTTPS 和 TCP 層。 QUIC 僅支援安全資料傳輸，因為 TLS 完全內建在 QUIC 中。
圖 5：QUIC 在 HTTP/3 下運行，取代了先前在 HTTP/2 下運行的 TLS。
以下是說服我們使用 QUIC 進行 TCP 放大的原因：
- 0-RTT 連線建立。 QUIC 允許重複使用先前連線的授權，從而減少安全握手的次數。 在未來 將支援 0-RTT，但仍需要三向 TCP 握手。
- 克服HoL阻塞。 HTTP/2 對每個客戶端使用一個 TCP 連線來提高效能，但這可能會導致 HoL（隊頭）阻塞。 QUIC 簡化了重複使用並獨立地將請求傳遞給應用程式。
- 擁塞控制。 QUIC 駐留在應用層，可以更輕鬆地更新基於網路參數（丟失數或 RTT）控制發送的主要傳輸演算法。 大多數 TCP 實作都使用該演算法 ，這對於延遲敏感的流量來說並不是最佳選擇。 最近開發的演算法如 ，更準確地對網路進行建模並優化延遲。 QUIC 允許您使用 BBR 並在使用時更新該演算法。 .
- 彌補損失。 QUIC 呼叫兩個 TLP（）在 RTO 觸發之前 - 即使損失非常明顯。 這與 TCP 實作不同。 TLP主要重傳最後一個資料包（或新的資料包，如果有的話）來觸發快速補充。 處理尾部延遲對於 Uber 運作其網路的方式特別有用，即短時、零星和延遲敏感的資料傳輸。
- 優化的ACK。 由於每個資料包都有唯一的序號，所以沒有問題 重傳資料包時。 ACK 封包還包含處理封包並在客戶端產生 ACK 的時間。 這些功能確保 QUIC 更準確地計算 RTT。 QUIC 中的 ACK 支援多達 256 個頻段 ，幫助發送方對資料包改組更有彈性，並在此過程中使用更少的位元組。 選擇性確認（TCP 中的 ) 並不能在所有情況下解決這個問題。
- 連接遷移。 QUIC 連線由 64 位元 ID 標識，因此如果用戶端變更 IP 位址，舊的連線 ID 可以繼續在新 IP 位址上使用，而不會中斷。 對於用戶在 Wi-Fi 和蜂窩連接之間切換的行動應用程式來說，這是一種非常常見的做法。
QUIC 的替代方案
在選擇 QUIC 之前，我們考慮了解決問題的替代方法。
我們嘗試的第一件事是部署 TPC PoP（存在點）來終止更靠近使用者的 TCP 連線。 本質上，PoP 終止與更靠近蜂窩網路的行動裝置的 TCP 連接，並將流量代理回原始基礎設施。 透過更接近地終止 TCP，我們可以潛在地減少 RTT 並確保 TCP 對動態無線環境的回應更加靈敏。 然而，我們的實驗表明，大部分 RTT 和損耗來自蜂窩網絡，且 PoP 的使用並不能提供顯著的效能改進。
我們也研究了調整 TCP 參數。 在我們的異質邊緣伺服器上設定 TCP 堆疊很困難，因為 TCP 在不同的作業系統版本上有不同的實作。 要實現這一點並測試不同的網路配置很困難。 由於缺乏權限，無法直接在行動裝置上設定 TCP。 更重要的是，0-RTT 連線和改進的 RTT 預測等功能對於協定的架構至關重要，因此僅透過調整 TCP 不可能獲得顯著的效益。
最後，我們評估了幾種基於 UDP 的協定來解決視訊串流問題 - 我們想看看這些協定是否對我們的案例有幫助。 不幸的是，它們嚴重缺乏許多安全設置，並且還需要額外的 TCP 連接來儲存元資料和控制資訊。
我們的研究表明，QUIC 可能是唯一可以幫助解決網路流量問題，同時兼顧安全性和效能的協定。
將 QUIC 整合到平台中
為了在連接不良的環境中成功嵌入 QUIC 並提高應用程式效能，我們用 QUIC 協定取代了舊堆疊（基於 TLS/TCP 的 HTTP/2）。 我們使用了網路圖書館 的 ，其中包含原始的 Google 版本協議 - gQUIC。 該實作也在不斷改進，以遵循最新的 IETF 規範。
我們首先將 Cronet 整合到我們的 Android 應用程式中以新增對 QUIC 的支援。 整合的方式是盡可能降低遷移成本。 而不是完全替換使用該庫的舊網路堆疊 ，我們在 OkHttp API 框架下整合了 Cronet。 透過這種方式進行集成，我們避免了對網路呼叫的變更（這些呼叫由 ）在 API 層級。
與 Android 裝置的方法類似，我們在 iOS 上的 Uber 應用程式中實作了 Cronet，攔截來自網路的 HTTP 流量 使用 。 這種抽象由 iOS 基金會提供，可處理特定於協議的 URL 數據，並確保我們可以將 Cronet 整合到我們的 iOS 應用程式中，而無需大量遷移成本。
在 Google Cloud Balancer 上完成 QUIC
在後端，QUIC 補全由 Google Cloud 負載平衡基礎架構提供，此基礎架構使用 回應中的標頭以支援 QUIC。 一般來說，平衡器會為每個 HTTP 請求新增一個 alt-svc 標頭，這已經驗證了該網域的 QUIC 支援。 當 Cronet 用戶端收到帶有此標頭的 HTTP 回應時，它會使用 QUIC 來傳送對該網域的後續 HTTP 請求。 一旦平衡器完成 QUIC，我們的基礎架構就會透過 HTTP2/TCP 明確將此操作傳送到我們的資料中心。
表現：結果
輸出效能是我們尋找更好協定的主要原因。 首先，我們創建了一個展位 了解 QUIC 在不同網路設定檔下的表現。 為了測試 QUIC 在現實網路上的效能，我們在新德里開車時使用與乘客應用程式中的 HTTP 呼叫非常相似的模擬網路流量進行了實驗。
實驗一
實驗設備：
- 使用 OkHttp 和 Cronet 堆疊測試 Android 設備，以確保我們分別允許 TCP 和 QUIC 上的 HTTPS 流量；
- 基於 Java 的類比伺服器，在回應中發送相同類型的 HTTPS 標頭並載入客戶端設備以接收來自它們的請求；
- 實體位置靠近印度的雲端代理，用於終止 TCP 和 QUIC 連線。 對於 TCP 終止，我們使用了反向代理 ，很難找到 QUIC 的開源反向代理。 我們使用 Chromium 的基本 QUIC 堆疊自行建構了 QUIC 的反向代理， 它作為開源的鉻。
圖 6. TCP 與 QUIC 道路測試套件由具有 OkHttp 和 Cronet 的 Android 裝置、用於終止連線的雲端代理以及類比伺服器組成。
實驗一
當 Google 推出 QUIC 時 中，我們使用了相同的清單，但進行了一項修改：我們使用 Google 負載平衡器取代 NGINX 來終止來自裝置的 TCP 和 QUIC 連接，並將 HTTPS 流量路由到模擬伺服器。 平衡器分佈在世界各地，但使用距離設備最近的 PoP 伺服器（得益於地理位置）。
圖 7.在第二個實驗中，我們想要比較 TCP 和 QUIC 的完成延遲：使用 Google Cloud 和使用我們的雲端代理。
結果，有幾個啟示等著我們：
- 透過 PoP 終止提高了 TCP 效能。 由於平衡器終止靠近使用者的 TCP 連線並且經過高度最佳化，因此可以降低 RTT，從而提高 TCP 效能。 儘管 QUIC 受到的影響較小，但在減少尾部延遲方面，它仍然優於 TCP（減少 10-30%）。
- 尾巴受到影響 . 儘管我們的QUIC 代理程式比Google 的負載平衡器距離設備更遠（延遲大約高50 毫秒），但它提供了相似的性能- 延遲減少了15%，而TCP 的第20 個百分位數減少了99 %。 這表明最後一哩過渡是網路中的瓶頸。
圖 8：兩個實驗的結果顯示 QUIC 顯著優於 TCP。
打擊交通
受到實驗的啟發，我們在 Android 和 iOS 應用程式中實現了 QUIC 支援。 我們進行了 A/B 測試，以確定 QUIC 對 Uber 營運城市的影響。 整體而言，我們發現兩個地區、電信業者和網路類型的尾部延遲均顯著減少。
下圖顯示了按宏觀區域和不同網路類型（LTE、95G、99G）劃分的尾部（3 和 2 百分位數）的百分比改善。
圖 9. 在戰鬥測試中，QUIC 在延遲方面優於 TCP。
僅轉發
也許這只是一個開始 - QUIC 投入生產為提高穩定和不穩定網路中的應用程式效能提供了絕佳的機會，即：
增加覆蓋範圍
分析了協定在實際流量上的效能後，我們發現大約 80% 的會話成功使用 QUIC 所有 請求，而 15% 的會話使用 QUIC 和 TCP 的組合。 我們假設這種組合是由於 Cronet 庫逾時返回 TCP，因為它無法區分真正的 UDP 故障和較差的網路條件。 我們目前正在尋找解決這個問題的方法，並致力於 QUIC 的後續實作。
QUIC優化
來自行動應用程式的流量對延遲敏感，但對頻寬不敏感。 此外，我們的應用程式主要用於蜂窩網路。 根據實驗，即使使用代理終止靠近使用者的 TCP 和 QUIC，尾部延遲仍然很高。 我們正在積極尋找改善擁塞管理並提高 QUIC 遺失復原演算法效率的方法。
透過這些和其他幾項改進，我們計劃改善用戶體驗，無論網路和地區如何，使世界各地更方便、無縫的資料包傳輸。
來源： www.habr.com