Cloudflare 營運著全球最快的網路。今天，我們分享了一項更新，介紹我們如何透過改造軟體技術來加速所有伺服器，從而提升全球速度。
但我們並未就此止步。為了進一步提高速度，我們還必須確保我們的網路能夠迅速處理每天發生的網際網路規模的壅塞，並將流量路由到現在更快的伺服器。
多年來，我們不斷地投入資金來控制壅塞。今天，我們很高興地與大家分享，我們如何利用網路的超級群體——龐大的免費方案使用者群體——來實現效能最佳化，並為全球所有客戶找到在我們的網路中路由流量的最好方式。
早期結果顯示，與之前的基準相比，效能平均提高了 10%。我們基於每天觀察到的網際網路資料，套用不同的演算方法來提高效能，從而達成了這一目標。我們很高興開始向所有客戶推出這些改進措施。
網際網路是一個包含很多互連網路的龐大集合，其中每個網路都由許多機器（「節點」）組成。資料的傳輸方式如下：將資料分解為較小的封包，然後（透過「連結」）將它們從一台電腦傳遞到另一台電腦。這些機器中的每一台都與其他很多機器連結，且每個連結的容量都是有限的。
當我們透過網際網路傳送封包時，它將經過連結上的一系列「躍點」從 A 移動到 B。在任何指定時間，都會有一個連結（一個「躍點」）的可用容量是該路徑中最小的。這個躍點在連線中的哪個位置並不重要——它將成為瓶頸。
但存在一個很大的挑戰——當您透過網際網路傳送資料時，您不知道它會選擇哪條路線。事實上，每個節點都會自行決定透過哪條路線傳送流量，不同的封包從 A 到 B 可以採取完全不同的路線。儘管系統的變化性和分散性可以確保網際網路如此有效，但也導致很難確定可以傳送多少資料。那麼，傳送者如何才能知道瓶頸在哪裡，以及應該以多快的速度傳送資料呢？
在 Cloudflare 節點之間，我們的 Argo Smart Routing 產品利用我們對全球網路的可見度來加速通訊。同樣，當我們啟動與客戶來源伺服器的連線時，我們可以利用 Argo 和其他深入解析來實現連線最佳化。然而，從您的手機或筆記型電腦（下文稱「用戶端」）到最近的 Cloudflare 資料中心的連線速度，將取決於從您到 Cloudflare 的鏈路（在我們的網路外部）中瓶頸躍點的容量。
如果有太多的資料到達正在處理請求的路徑中的任何一個網路節點，請求者會因壅塞而遇到延遲。資料會排入佇列等待一段時間（導致 bufferbloat 風險），或者其中一些資料會直接捨棄。像 TCP 和 QUIC 這樣的通訊協定會透過重新傳輸資料來回應捨棄的封包，但這會引入延遲，甚至可能因進一步超過有限容量的負載而導致問題惡化。
如果像 Cloudflare 這樣的雲端基礎架構提供者在管理壅塞時不夠謹慎，則我們的系統就有可能過載，進而降低資料的傳輸速度。實際上，這種情況早在網際網路發展初期就發生過。為了避免這種情況，網際網路基礎架構社群開發了壅塞控制系統，讓每個人輪流傳送資料，這樣就不會導致網路過載。隨著網路變得越來越複雜，這一挑戰也在不斷發展，我們也在不斷尋求控制壅塞的最佳方法。目前已經開發出許多不同的演算法，這些演算法採用不同的資訊來源和訊號，以特定的方法實現最佳化，並採取不同的方式應對壅塞。
壅塞控制演算法使用多種訊號來估算正確的流量傳送速率，而無需瞭解網路的設定方式。一個非常重要的訊號就是遺失。收到封包後，接收者會傳送「ACK」，告知傳送者封包已成功送達。如果在途中某處捨棄封包，傳送者永遠不會收到回執，且逾時後會將該封包視為遺失。
最新的演算法使用了額外的資料。例如，我們的大部分流量都在使用一種稱為 BBR（瓶頸頻寬和往返傳播時間）的熱門演算法，該演算法嘗試在指定時段內可傳輸的最大資料量每次連線期間，使用往返時間估計值和遺失資訊建置一個模型。
最佳演算法的選擇通常取決於工作負載。例如，對於像視訊通話這樣的互動式流量，偏向傳送過多流量的演算法可能會導致佇列累積，進而導致延遲較高且視訊體驗不佳。如果僅針對該使用案例進行最佳化，並透過減少傳送的流量來避免這種情況，則網路將無法充分利用連線來為進行大量下載的用戶端提供服務。效能最佳化的結果各不相同，取決於諸多不同的因素。但是，我們可以看到很多因素！
在壅塞控制方法的發展過程中，BBR 是一個令人興奮的進步，它從基於被動遺失的方法轉變為基於主動模型的最佳化，顯著提高了現代網路的效能。我們的資料為我們提供了更進一步的機會，從而套用不同的演算方法來提高效能。
現有的所有演算法都僅限於使用在當前連線的生命週期內收集的資訊。值得慶幸的是，我們在任何指定時間對網際網路的瞭解都遠超於此！透過 Cloudflare 的流量視角，我們在任何指定時間看到的流量比任何單一客戶或網際網路服務提供者 (ISP) 都要多。
每天，我們都能看到來自全球各大網路的流量。當請求進入我們的系統時，我們知道正在與哪個用戶端裝置進行通訊，哪種類型的網路啟用了連線，以及我們是在與消費者 ISP 還是雲端基礎架構提供者進行通訊。
我們瞭解全球網際網路的負載模式，以及我們認為系統過載的位置，不論是在我們的網路內部還是外部。我們知道，有些網路的屬性非常穩定，但會因行動數據連線而導致高封包遺失，而有些網路則穿越低地球軌道衛星鏈路，每 15 秒就會徹底改變一次路線。
我們在不斷地遷移網路技術堆疊以使用由 Rust 提供支援的新平台，該平台具有更大的靈活性，讓我們可以嘗試改變用於處理壅塞控制的演算法中的參數。然後，我們還需要資料。
為這些實驗提供支援的資料需要反映我們嘗試最佳化的指標，即使用者體驗。我們不僅要向全球幾乎所有的網路傳送資料；我們還必須能夠看到客戶享有的體驗。那麼，我們如何在現有規模下做到這一點呢？
首先，我們會「被動地」詳細記錄我們的網路傳送資料能夠達到的速率，以及目的地確認接收所需的時間。這些記錄涵蓋了我們所有的流量，讓我們可以瞭解用戶端接收資料的速度，但不保證能告知我們使用者體驗如何。
其次，我們有一個系統專門用於收集真實使用者測量結果 (RUM) 資料，它會記錄支援的 Web 瀏覽器中有關頁面載入時間 (PLT) 等指標的資訊。任何 Cloudflare 客戶都可以啟用此功能，並會在儀表板中收到詳細的深入解析。此外，我們還會彙總所有客戶和網路的中繼資料，來瞭解客戶的真實體驗。
然而，RUM 資料僅存在於我們網路上的一小部分連線中。因此，我們一直在努力尋找一種方法，透過從僅在被動記錄中看到的資料進行推斷，來預測 RUM。例如，我們對兩種不同的演算法與立方基準進行了比較實驗，結果如下。
以下是我們透過基於被動記錄的預測觀察到的相同時幅。這些曲線非常相似——但更重要的是，曲線之間的比率非常相似。這是巨大的進步！我們可以使用相對較少的 RUM 資料來驗證我們的發現，但透過使用所有的被動記錄，能夠以更精細的方式實現網路最佳化。
推斷太遠會變得不可靠，因此我們也在與一些最大的客戶合作，以從他們客戶的角度來提高我們對網路行為的可見度，從而讓我們能夠進一步擴展此預測模型。而作為回報，我們將能夠以其他平台無法提供的方式，讓客戶深入瞭解其客戶的真實體驗。
我們目前正在對所有免費方案的 QUIC 流量進行實驗，並改進了壅塞控制演算法。隨著我們瞭解的深入，對更複雜的客戶進行驗證，以及擴展到 TCP 流量，我們會在 2026 年及以後逐步將此功能推廣至所有客戶，覆蓋所有流量。與基準相比，我們的實驗結果提高了多達 10%！
我們正在與一組精選企業合作，在提前存取計畫中對此進行測試。如果您希望瞭解更多資訊，請連絡我們！