【重磅】移動網路效能揭秘（下）--網路通訊協定及效能提升實踐

標籤：架構   web   移動   網路   

網路通訊協定的效能

現在輪到我們實際上可以控制的東西了。

網路處理的效能與延遲時間的增加是不成比例的。這是由於大多數網路通訊協定的內在操作是雙向資訊交換。本章的其餘部分則側重於理解為什麼會產生這些資訊交換以及如何減少甚至消除它們交換的頻率。

 

圖3：網路通訊協定

 

傳輸控制通訊協定

傳輸控制通訊協定(TCP)是一種連線導向、基於ip的傳輸協議。TCP影響下的無差錯雙工通訊通道對其他協議如HTTP或TLS來說都必不可少。

TCP展示了許多我們需要盡量避免的雙向通訊。這其中一些可以通過採用擴充協議如TCP Fast Open協議來替代；另一些則可以通過調整系統參數來達到最小化，比如初始化擁塞視窗。在本節中,我們將探討這兩種方法同時也提供一些TCP內部組件的背景。

TCP Fast Open

初始化一個TCP串連約定需要3次資訊交換，也就是我們所說的3次握手。TCP Fast Open（TFO）是TCP的一個擴充，它消除了通常握手過程中的往返延遲。

TCP在用戶端和服務端的三向交握協商巨集指令引數使得雙方做健壯的雙向通訊稱為可能。最開始的SYN資訊（同步資訊）代表用戶端的串連請求；如果服務端接受這個請求，那麼它將返回一個SYN-ACK訊息(同步和接受訊息)；最後，用戶端發送一個ACK訊息來應答伺服器。這時，一個邏輯串連就已經建立完成，用戶端就可以發送資料了。這其中你如果注意到，3次握手過程中至少引入了一個RTT的延遲那就很好了。

圖4：TCP3次握手

從傳統角度來看，除了對串連進行回收利用外沒有其他方法來避免TCP3次握手造成的延遲。然而，這種想法發生隨著Tcp Fast Open IETF規範的引入發生了變化。

TFO允許用戶端在邏輯串連建立之前就開始發送資料。這實際上否定了3次握手中的往返延遲。這種最佳化的累積效應是讓人印象深刻。根據Google的調查，TFO可以減少頁面40%的載入時間。雖然這個規範只是草案，但是TFO已經被主流瀏覽器（Chrome22以上）和平台（Linux3.6以上）所支援，並且其他供應商也保證將在不久以後會完全支援它。

TCP Fast Open是對3次握手協議的一個修正，它允許在同步訊息(SYN Message)內有少量的資料負載(如HTTP請求)。這個有效負責會傳遞給應用伺服器,否則串連握手完成。

早些時候擴充方案像TFO最終因安全問題而失敗。而TFO通過使用安全性權杖或者cookie來解決這個問題，也就是說在傳統的TCP串連握手過程中給用戶端分安全性權杖(tooken),並且期望將安全性權杖包含在TFO最佳化請求的SYN訊息中。

對於TFO的使用，這裡有一些小的警告。其中最值得注意的是，在初始化的SYN訊息中請求的資料缺乏等冪性保證。雖然TCP保證重複資料包(重複經常發生)會被接受者忽略，但是這個保證並不適用於串連的握手過程。目前在規範草案中正在標準化這個解決方案，但是於此同時TFO仍然可以被安全的應用於等冪性處理。

 

初始擁塞視窗

初始擁塞視窗是TCP的一個可配置項並且有巨大的潛在能力來加速小的網路事務。

最近的IETF規範促進通常的初始擁塞視窗的設定增長到3個報文段(如資料包)到10個報文段。這個建議是基於Google進行的廣泛研究,這個研究證明了這個參數的設定對效能有平均10%的提升。但如果不介紹TCP的擁塞視窗（cwnd）的話，這種設定的目的和潛在影響就不會被真正領會。

當在一個不可靠的網路上進行操作時，TCP來保證用戶端和服務端的可靠性。這相當於一個承諾,所有發送出去的資料都會被接收到,或者至少看起來是這樣。其中，包丟失是滿足可靠性要求的最大障礙，這需要偵測、錯誤修正以及預防。

TCP採用一個肯定應答機制來檢測丟包情況，即每個發送出去的包都應該被它預定的接收方應答，如果沒有應答就意味著這個包在傳輸過程中丟失。在等待確認的過程中,傳輸資料包儲存在一個特殊的緩衝區中，也就是所說的擁塞視窗。當這個緩衝區被塞滿時，一個被稱作cwnd耗盡的事件發生，所有傳輸停止，直到接收方應答後騰出有效空間來發送更多的資料包。這些事件在TCP效能中至關重要。

除了網路頻寬的限制，TCP輸送量根本上受cwnd耗盡事件發生頻率的限制，而這可能與擁塞視窗的大小有關。當TCP效能達到峰值時需要一個擁塞衝口來調節當前的網路狀態：擁塞視窗過大將增加網路堵塞的風險--過度擁堵的網路狀況會增加大量包丟失；過小則珍貴的網路頻寬將不能充分被利用。從邏輯上講，對網路情況瞭解的越多，肯能越能選擇一個最佳的擁塞視窗大小。實際情況則是，關鍵網路屬性比如容量和延遲,是很難衡量的並且不斷在變化。而且，如果一個基於互連網的TCP串連需要穿過許多網路的這又會是一件更加複雜的事情。

由於缺乏手段來準確確定網路容量大小，相反TCP通過網路擁堵情況來推斷擁塞視窗大小。當TCP發現有包丟失時它就會擴大擁塞視窗的大小，提示下行某處有一個網路無法處理當前的傳輸速率。通過採用這種擁塞避免機制,TCP最終最小化cwnd耗盡事件在某種程度上它消耗完為所有串連所分配的容量。那麼現在，最終，我們也達到了目的，解釋清楚了初始擁塞視窗參數的重要性。

網路擁堵情況只能通過丟包測試來檢測。一個新的或者閒置串連由於沒有足夠丟包資料來證明建立擁塞視窗的最佳大小；TCP採用了一個比較明智的做法就是以一個可能最小情況導致網路擁堵的大小一開始作為擁塞視窗大小；這最初意味著需要設定1個分區(大約1480位元組)，而且有些時候這種做法是推薦的。而稍後的實驗會示範一個高達4的設定也是有效。在實踐中你也通常發現初始擁塞視窗設定為3報文段(大約4kb)。

初始擁塞視窗不利於小的網路交易處理。這種效果很容易說明。在表中的3個報文段設定下，在發送3個資料包或者4k的資料後cwnd耗盡時間就會發生。假設資料包是連續發送的，響應的響應不會在任何所允許的往返時間(RTT)之前到達；假如RTT是100ms的話，那麼有效傳輸速率只有可憐的400位元組/秒。儘管TCP會調節自身的擁塞視窗來充分利用有效容量，但是它在一開始將會很慢。事實上，這種方式被稱為慢啟動。

為了減少慢啟動對較小的下載的效能影響，它需要重新評估初始擁塞視窗的風險回報。Google正是這樣做的，而且發現將初始擁塞視窗設定在10個報文段（約14kb）會在最小網路擁堵情況下達到最大輸送量。現實世界中也證明了這樣設定總共可以減少頁面10%的載入時間；串連的往返延遲將得到更大的改善。

修改初始擁塞視窗的預設值也並不是那麼簡單的。在大多數伺服器作業系統下，一個系統級的配置只有有特權的使用者才可設定；這個參數也很少甚至不能被沒有許可權的應用在用戶端配置。需要注意的是一個更大的初始擁塞視窗在伺服器端可以加速下載,而在用戶端則可以加速上傳。如果無法在用戶端改變這個設定就意味著應該特別努力去減少請求負載的大小。

 

超文字傳輸通訊協定 (HTTP)

本節將討論在超文字傳輸通訊協定 (HTTP)（HTTP）效能方面來減少高的往返延遲的技術。

KeepAlive

KeepAlive是一個HTTP約定來允許同步連續的HTTP請求來使用同一個TCP串連。至少一個單組往返請求所需要的TCP的3次握手可以避免，每次請求可以節省幾十或者幾百毫秒。更深層次的，keepalive還有一個額外的但是未被提及的好處就是它在各個請求之間保留了當前TCP的擁塞視窗大小，這將導致更少的cwnd耗盡事件發生。

圖5：HTTP pipelining

實際上，管道使網路延遲分佈於網路往返的各個HTTP事務中。例如，5個管線式的HTTP請求通過一個100毫秒的RTT串連時將產生一個平均20毫秒的往返延遲；在同樣條件下，10個管線式請求時這個平均延遲將減少到10毫秒。

但是，HTTP pipeling有明顯的缺點阻止了它被廣泛使用，即曆史上參差不齊的HTTP代理支援和拒絕服務的攻擊的影響。

安全傳輸層協議

傳輸層安全性(Transport Layer Security,TLS)是一個面向會話的網路通訊協定允許在公用網路安全地交換敏感資訊。雖然TLS在安全通訊方面卓有成效，但是在高延遲網路下它的效能會下降。

TLS採用一個複雜的握手協議包括兩次交換用戶端-服務端資訊。一個TLS安全的HTTP傳輸明顯比較慢也正是這個原因。通常，發現一個TLS慢實際上是在抱怨它的握手協議中多重往返所產生的延遲。

圖6：DNS查詢

通常，主平台提供了緩衝實現來避免頻繁的DNS查詢。DNS緩衝的語義非常簡單：每個DNS響應包含一個存活時間（time-to-live，TTL）屬性來聲明結果會被緩衝多長時間。TTL的範圍通常在幾秒鐘到幾天之間，但通常為幾分鐘。非常低的TTL值，通常在一分鐘以下，被用在影響負載分配或者減少伺服器替換或ISP容錯移轉的時間。

重新整理失敗

高可用系統通常依賴於他們IP機房的冗餘基礎設施主機。TTL值較小的DNS條目可以減少客戶指向失敗主機的時間，但是同時會導致大量額外的DNS查詢。所以說，TTL的值應該是減少停機時間和用戶端效能最大化的一個折中。

通常降低用戶端效能是沒有意義的，但當伺服器故障時是個例外。有一個簡單的方法來解決這個問題，也就是說不是嚴格的遵守TTL，而是僅僅當更高層協議如TCP或HTTP檢測到不可恢複錯誤時才重新整理DNS緩衝。這種技術在大多數情境下類比TTL保持DNS緩衝一致的行為，然而這幾乎消除了任何基於DNS高可用性解決方案中的效能損失。

但是需要注意的是這個技術方案和其他基於DNS的分布式負載方案不相容。

非同步重新整理

非同步重新整理是一個DNS緩衝方法，它遵守已經設定TTL規則但是在很大程度上消除了頻繁查詢DNS的延遲。在這項技術中，需要一個非同步DNS用戶端庫如c-ares來實現。

這個方法很簡單，一個到期的請求仍然返回的是老的結果，但是後台有一個非阻塞的DNS查詢來定時重新整理DNS緩衝。這種方案如果採用阻塞式(如同步)回調來查詢每條老的DNS資料，那麼這個方案幾乎不受DNS查詢延遲的影響，但是仍然和很多基於DNS的容錯移轉方案以及分布式負載方案相容。

 

總結

要減少移動網路高延遲的影響就需要通過減少使移動網路延遲急劇增加的網路往返次數來實現。而採用軟體最佳化專註於最大限度地減少或消除往返協議的訊息是克服這項艱巨的效能問題的關鍵。

 

（移動網路效能篇，全文完。）

 

1. 本文由程式員學架構翻譯

2. 本文譯自The Performance of Open Source Software | Secrets of Mobile Network Performance

3. 轉載請務必註明本文出自：程式員學架構(號：archleaner )

4. 更多文章請掃碼：

【重磅】移動網路效能揭秘（下）--網路通訊協定及效能提升實踐