延遲與頻寬

網站越快，使用者黏性越高；
網站越快，使用者忠誠度越高；
網站越快，使用者轉化率越高。

決定網路通訊的兩個方面：延遲與頻寬。

• 延遲： 分組從資訊源傳送到目的地所需的時間。
• 頻寬：邏輯或物理通訊路徑最大的吞吐量。

目標： 低延遲，高頻寬

延遲

延遲是訊息或分組從起點到終點經歷的時間。

影響延遲的因素：

• 傳播延遲
  訊息從傳送端到接收端需要的時間，與訊號傳播距離和速度有關。
• 傳輸延遲
  把訊息中的所有位元轉移到鏈路中需要的時間，與訊息長度和鏈路速率有關。
• 處理延遲
  處理分組首部、檢查位錯誤及確定分組目標所需的時間。
• 排隊延遲
  到來的分組排隊等待處理的時間。

以上延遲的時間總和，就是客戶端到伺服器的總延遲時間。

CDN

CDN（Content Delivery Network，內容分發網路）主要就是把內容部署到全球各地，讓使用者從最近的伺服器載入內容，大幅降低傳播分組的時間。

使用traceroute測量延遲

traceroute是一個簡單的網路診斷工具，可以列出分組經過的路由節點，以及他在IP網路中的每一跳延遲。在windows系統中可以使用tracert來測試。

當ICMP協議被禁用的時候，可以採用 lft, paketto, hping, superping.d , NetPerf, IPerf

TCP

TCP協議

傳輸控制協議，即Transmission Control Protocol，縮寫為TCP，是一種面向連線的、可靠的、基於位元組流的傳輸層通訊協議，由IETF的RFC 793定義。TCP協議位於IP協議之上，應用層之下的傳輸層。

TCP連線包括了三種狀態： 連線建立、資料傳送和連線終止。作業系統將TCP連線抽象為套接字的程式設計介面給程式使用，並且要經歷一系列的狀態改變。

建立通路

所有的TCP連線要通過三次握手，客戶端與伺服器在交換應用資料之前，必須就起始分組序列號，以及其他的一些連線相關的細節達成一致。序列號由兩端隨機生成。

• SYN
  客戶端選擇一個隨機序列號X，併發送一個SYN分組，其中可能包括其他TCP標識和選項。
• SYN ACK
  伺服器給X加1，並選擇自己的一個隨機序列號Y，追加自己的標誌和選項，然後返回響應。
• ACK
  客戶端給X和Y加1併發送握手期間的最後一個ACK分組。

三次握手完成後，客戶端與伺服器就可以通訊了。客戶端在傳送ACK分組後就可以立即傳送資料，伺服器則必須等待接收到ACK分組後才能夠傳送資料。

三次握手帶來的延遲使得每次建立一個新TCP連線都要付出巨大代價，所以這裡是提升TCP應用效能的關鍵。

TCP Fast Open 是減少新建TCP連線帶來效能損失的一種機制。通過握手開始時的 SYN 包中的 TFO cookie（一個 TCP 選用項）來驗證一個之前連線過的客戶端。如果驗證成功，它可以在三次握手最終的 ACK 包收到之前就開始傳送資料，這樣便跳過了一個繞路的行為，更在傳輸開始時就降低了延遲。

擁塞預防及控制

1. 流量控制
   流量控制是一種預防傳送端過多向接收端傳送資料的機制。為了實現流量控制，TCP連線的每一方都要通告自己的接收視窗（rwnd），其中包含能夠儲存資料的緩衝區空間大小資訊。

   

   第一次建立連線時，傳送端和接收端都會使用視窗預設設定來發送rwnd。在瀏覽器網頁時，需要從伺服器向瀏覽器下載資料，所以此時客戶端的視窗成為瓶頸。而在上傳圖片等資料時，伺服器的接收視窗成為了瓶頸。

   在傳輸過程中，其中一端跟不上資料傳輸，此時它可以向傳送端通告一個較小的視窗。假設視窗為0，則意味著必須有應用層先清空緩衝區，才能夠接受剩餘資料。

   每個ACK分組都會攜帶相應的最新的rwnd值，以便於兩端動態調整資料流速，使之適應傳送端和接收端的容量和處理能力。

   在Linux作業系統中，可以通過以下命令檢查TCP視窗縮放機制。

   

2. 擁塞控制

   傳送端、接收端在連線建立之初，無法預測雙方的網路頻寬，因此需要一個估算機制，然後還需要根據網路中不斷變化的條件動態改變速度。

   1988年，Van Jacobson和Michael J. Karels撰文描述瞭解決這種問題的方法：慢啟動、擁塞預防、快速重發和快速恢復。

   • 擁塞預防
     TCP調節效能依賴於丟包反饋機制。擁塞預防演算法把丟包作為網路擁塞的標誌，即路徑中某個連線或者路由器已經擁堵，以至於必須採取刪包策略。因此，需要調整視窗大小，以避免更多的包丟失，保證網路暢通。重置擁塞視窗後，擁塞預防機制按照自己的演算法來增大視窗以及儘量避免丟包。
   • 慢啟動
     新的TCP連結最大資料量取決於RWND和CWND的最小值。慢啟動導致了客戶端與伺服器之間經過幾百毫秒才能夠達到接近最大速度的問題，對於大型流式下載服務影響不顯著，但對於大多數的HTTP連線，特別是一些短暫、突發的連線，常常會出現還沒達到最大視窗請求就被終止的情況，很多Web效能受到伺服器與客戶端之間往返時間的制約。慢啟動限制了可用的吞吐量，對於小檔案傳輸十分不利。

3. 頻寬延遲積

   頻寬延遲積（Bandwidth-delay product），資料鏈路的容量與其端到端延遲的乘積。這個結果就是任意時刻處於在途未確認狀態的最大資料量。

   

   傳送端和接收端指甲的在途未確認的最大資料量，取決於擁塞視窗和接收視窗的最小值。接收視窗會隨著每次的ACK一起傳送，擁塞視窗則由傳送端根據擁塞控制和預防演算法動態調整。當接收或傳送的資料超過了未確認的最大資料量，都必須停下來等待另一方的ACK來確認某些分組才能夠繼續。等待的時間取決於往返時間。

   為了獲得最大的吞吐量，應該讓視窗足夠大，以保證任何一段能在ACK返回前持續傳送資料。只有傳輸不間斷，才能夠保證最大的吞吐量。

   • 流量控制視窗和擁塞控制視窗多大才合適呢？假設cwnd和rwnd的最小值為16KB，往返時間為100ms：

     

     不論接受或傳送的實際頻寬，TCP連線的資料傳輸率都不會超過1.31Mbit/s。

   • 如果往返時間不變，傳送端的頻寬為10Mbit/s，接收端為100Mbit/s+，且兩端之間沒有網路擁塞。那麼視窗應該是多大呢？

     

     視窗至少要122.1KB才能夠充分利用10Mbit/s頻寬。但在RFC 1323中，TCP接受視窗最大隻有64KB。所以，儘管視窗大小會自動調節，但也仍舊是TCP效能限制因素。

   BDP是往返時間和目標傳輸速度的函式，因此往返時間不僅是高傳輸延遲中的瓶頸，也是LAN中的瓶頸。

4. 隊首阻塞

   每個TCP分組都會帶著唯一的序列號被髮出，而所有分組必須按照傳輸順序傳送到接收端。如果中途有一個分組沒能到到接收端，而後續分組必須儲存在接收端的TCP緩衝區裡，等待丟失的分組重發併到達接收端。這些情況都發生在TCP層，應用程式對TCP重發和緩衝區排隊的分組一無所知，必須等待分組全部到達才能夠訪問。在此之前，應用程式只能通過套接字讀資料時感覺延遲交付。這種效應成為TCP的隊首阻塞。

   隊首阻塞造成的延遲可以讓程式不必關心分組重排和重組的事情，從而使得我們的程式碼更加簡潔。但是，分組到達時間存在無法預知的延遲變化。這個時間變化通常被稱為抖動。對延遲或者抖動要求高或者無需按序交付資料、能夠自行處理分組丟失的應用程式可以選用UDP。

   丟包是TCP達到最佳效能的關鍵，被刪除的包是一種反饋機制，能夠讓接收端和傳送端各自調整速度，以免網路擁堵，同時保持延遲最短（緩衝區爆滿問題）。

針對TCP優化意見

優化目標： 最大吞吐量 最小延遲

TCP是一個自適應、對所有網路節點一視同仁的、最大限制利用底層的網路協議。

優化TCP的最佳路徑就是調整它感知當前網路狀況的方式，根據它之上或之下的抽象層型別和需求來改變他的行為。

TCP的核心原理和影響是不變的：

• TCP三次握手增加了整整一次的往返時間；
• TCP慢啟動被應用到每一次的新連線；
• TCP流量及擁塞控制會影響所有連線的吞吐量。
• TCP的吞吐量由當前擁塞視窗大小確定。

現代高速網路中的TCP連線的資料傳輸速度受到接收端和傳送端的往返時間的限制。此外，延遲依舊受限於光速，而且已經限定在其最大值的一個很小的常數因子之內。所以，大多數情況下，TCP的瓶頸都是延遲，而非頻寬。

伺服器配置調優

• 增大TCP的初始擁塞視窗
  加大擁塞視窗能夠讓TCP在第一次往返中就可以傳輸較多的資料，而隨後的速度提升明顯。對於突發性的短暫連線，這是一個很重要的優化的點。
• 慢啟動重啟
  在連線空閒時禁用慢啟動可以改善瞬時傳送資料的長TCP連線的效能。
• 視窗縮放（RFC 1323）
  啟用視窗縮放可以增大最大接收視窗的大小，可以讓高延遲的連線達到更好的吞吐量。
• TCP快速開啟
  在某些條件下，允許在第一個SYN分組中傳送應用程式資料。不過需要傳送端和客戶端同時支援TFO（TCP快速開啟）

在Linux系統中，可以使用ss檢視當前開啟的套接字的各種統計資訊。

ss --options --extended --memory --processes --info

可以檢視到當前的通訊節點以及他們相應的連線設定。

應用程式行為調優

• 消除不必要的資料傳輸，如不必要的資源下載後者通過壓縮演算法將傳送的資料量降到最低；
• 實現資料的短距離傳輸，如採用CDN技術來減少網路往返的延遲，從而顯著提升TCP的效能；
• 儘可能重用TCP連線，把慢啟動和其他擁塞控制機制的影響降低到最小。

效能檢查清單

• 把伺服器核心升級到最新版（Linux 3.2+）
• 確保cwnd大小為10
• 禁用空閒後的慢啟動
• 確保啟動視窗的縮放
• 減少傳輸的冗餘資料
• 壓縮要傳輸的資料
• 把伺服器放到離使用者最近的地方減少往返時間
• 盡最大可能重用已經建立的TCP連線

來源

1. 《Web效能權威指南》
2. 《圖解TCP/IP》