網絡協議的性能瀏覽器
現在輪到咱們實際上可以控制的東西了。緩存
網絡處理的性能與延遲時間的添加是不成比例的。這是由於大多數網絡協議的內在操做是雙向信息交換。安全
本章的其他部分則側重於理解爲何會產生這些信息交換以及怎樣下降甚至消除它們交換的頻率。微信
圖3：網絡協議cookie
傳輸控制協議網絡
傳輸控制協議(TCP)是一種面向鏈接、基於ip的傳輸協議。TCP影響下的無差錯雙工通訊信道對其它協議如HTTP或TLS來講都不可缺乏。架構
TCP展現了不少咱們需要儘可能避免的雙向通信。這當中一些可以經過採用擴展協議如TCP Fast Open協議來替代；還有一些則可以經過調整系統參數來達到最小化，比方初始化擁塞窗體。在本節中,咱們將探討這兩種方法同一時候也提供一些TCP內部組件的背景。異步
TCP Fast Open分佈式
初始化一個TCP鏈接約定需要3次信息交換，也就是咱們所說的3次握手。性能
TCP Fast Open（TFO）是TCP的一個擴展，它消除了一般握手過程當中的往返延遲。
TCP在client和服務端的三次握手協商操做參數使得兩方作健壯的雙向通訊稱爲可能。最開始的SYN信息（同步信息）表明client的鏈接請求；假設服務端接受這個請求，那麼它將返回一個SYN-ACK消息(同步和接受消息)；最後。client發送一個ACK消息來應答server。這時，一個邏輯鏈接就已經創建完畢，client就可以發送數據了。這當中你假設注意到，3次握手過程當中至少引入了一個RTT的延遲那就很是好了。
圖4：TCP3次握手
從傳統角度來看。除了對鏈接進行回收利用外沒有其它方法來避免TCP3次握手形成的延遲。然而，這樣的想法發生隨着Tcp Fast Open IETF規範的引入發生了變化。
TFO贊成client在邏輯鏈接創建以前就開始發送數據。這實際上否認了3次握手中的往返延遲。這樣的優化的累積效應是讓人印象深入。依據谷歌的調查，TFO可以下降頁面40%的載入時間。儘管這個規範僅僅是草案，但是TFO已經被主流瀏覽器（Chrome22以上）和平臺（Linux3.6以上）所支持，並且其它供應商也保證將在不久之後會全然支持它。
TCP Fast Open是對3次握手協議的一個修正，它贊成在同步消息(SYN Message)內有少許的數據負載(如HTTP請求)。
這個有效負責會傳遞給應用server,不然鏈接握手完畢。
早些時候擴展方案像TFO終於因安全問題而失敗。而TFO經過使用安全令牌或者cookie來解決問題。也就是說在傳統的TCP鏈接握手過程當中給client分安全令牌(tooken),並且指望將安全令牌包括在TFO優化請求的SYN消息中。
對於TFO的使用，這裏有一些小的警告。
當中最值得注意的是，在初始化的SYN消息中請求的數據缺少冪等性保證。儘管TCP保證反覆數據包(反覆經常發生)會被接受者忽略。但是這個保證並不適用於鏈接的握手過程。
眼下在規範草案中正在標準化這個解決方式，但是於此同一時候TFO仍然可以被安全的應用於冪等性處理。
初始擁塞窗體
初始擁塞窗體是TCP的一個可配置項並且有巨大的潛在能力來加速小的網絡事務。
近期的IETF規範促進一般的初始擁塞窗體的設置增加到3個報文段(如數據包)到10個報文段。這個建議是基於谷歌進行的普遍研究,這個研究證實了這個參數的設置對性能有平均10%的提高。
但假設不介紹TCP的擁塞窗體（cwnd）的話。這樣的設置的目的和潛在影響就不會被真正領會。
當在一個不可靠的網絡上進行操做時，TCP來保證client和服務端的可靠性。這至關於一個承諾,所有發送出去的數據都會被接收到,或者至少看起來是這樣。當中，包丟失是知足可靠性要求的最大障礙。這需要偵測、糾錯以及預防。
TCP採用一個確定應答機制來檢測丟包狀況。即每個發送出去的包都應該被它預約的接收方應答，假設沒有應答就意味着這個包在傳輸過程當中丟失。
在等待確認的過程當中,數據傳輸包保存在一個特殊的緩衝區中，也就是所說的擁塞窗體。當這個緩衝區被塞滿時，一個被稱做cwnd耗盡的事件發生，所有傳輸中止，直到接收方應答後騰出有效空間來發送不少其它的數據包。
這些事件在TCP性能中相當重要。
除了網絡帶寬的限制，TCP吞吐量根本上受cwnd耗盡事件發生頻率的限制。而這可能與擁塞窗體的大小有關。
當TCP性能達到峯值時需要一個擁塞衝口來調節當前的網絡狀態：擁塞窗體過大將添加網絡阻塞的風險--過分擁堵的網絡情況會添加大量包丟失；太小則珍貴的網絡帶寬將不能充分被利用。
從邏輯上講，對網絡狀況瞭解的越多，肯能越能選擇一個最佳的擁塞窗體大小。
實際狀況則是，關鍵網絡屬性比方容量和延遲,是很是難衡量的而且不斷在變化。
而且，假設一個基於互聯網的TCP鏈接需要穿過不少網絡的這又會是一件更加複雜的事情。
由於缺少手段來準確肯定網絡容量大小，相反TCP經過網絡擁堵狀況來判斷擁塞窗體大小。
當TCP發現有包丟失時它就會擴大擁塞窗體的大小，提示下行某處有一個網絡沒法處理當前的傳輸速率。
經過採用這樣的擁塞避免機制,TCP終於最小化cwnd耗盡事件在某種程度上它消耗完爲所有鏈接所分配的容量。那麼現在，終於，咱們也達到了目的。解釋清楚了初始擁塞窗體參數的重要性。
網絡擁堵狀況僅僅能經過丟包測試來檢測。
一個新的或者空暇的鏈接由於沒有足夠丟包數據來證實建立擁塞窗體的最佳大小。TCP採用了一個比較明智的作法就是以一個可能最小狀況致使網絡擁堵的大小一開始做爲擁塞窗體大小。這最初意味着需要設置1個分片(大約1480字節)，而且有些時候這樣的作法是推薦的。而稍後的實驗會演示一個高達4的設置也是有效的。在實踐中你也一般發現初始擁塞窗體設置爲3報文段(大約4kb)。
初始擁塞窗體不利於小的網絡事務處理。這樣的效果很是easy說明。在表中的3個報文段設置下。在發送3個數據包或者4k的數據後cwnd耗盡時間就會發生。若是數據包是連續發送的，響應的響應不會在不論什麼所贊成的往返時間(RTT)以前到達；假如RTT是100ms的話，那麼有效傳輸速率僅僅有可憐的400字節/秒。雖然TCP會調節自身的擁塞窗體來充分利用有效容量，但是它在一開始將會很是慢。其實，這樣的方式被稱爲慢啓動。
爲了下降慢啓動對較小的下載的性能影響，它需要又一次評估初始擁塞窗體的風險回報。谷歌正是這樣作的，而且發現將初始擁塞窗體設置在10個報文段（約14kb）會在最小網絡擁堵狀況下達到最大吞吐量。現實世界中也證實了這樣設置總共可以下降頁面10%的載入時間；鏈接的往返延遲將獲得更大的改善。
改動初始擁塞窗體的默認值也並不是那麼簡單的。在大多數server操做系統下，一個系統級的配置僅僅有有特權的用戶纔可設置；這個參數也很是少甚至不能被沒有權限的應用在client配置。需要注意的是一個更大的初始擁塞窗體在server端可以加速下載,而在client則可以加速上傳。假設沒法在client改變這個設置就意味着應該特別努力去下降請求負載的大小。
超文本傳輸協議
本節將討論在超文本傳輸協議（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採用一個複雜的握手協議包含兩次交換client-服務端信息。一個TLS安全的HTTP傳輸明顯比較慢也正是這個緣由。一般。發現一個TLS慢其實是在抱怨它的握手協議中多重往返所產生的延遲。
圖6：DNS查詢
一般，主平臺提供了緩存實現來避免頻繁的DNS查詢。DNS緩存的語義很easy：每個DNS響應包括一個存活時間（time-to-live，TTL）屬性來聲明結果會被緩存多長時間。TTL的範圍一般在幾秒鐘到幾天之間，但一般爲幾分鐘。
很低的TTL值。一般在一分鐘下面，被用在影響負載分配或者下降server替換或ISP故障轉移的時間。
刷新失敗
高可用系統一般依賴於他們IP機房的冗餘基礎設施主機。
TTL值較小的DNS條目可以下降客戶指向失敗主機的時間，但是同一時候會致使大量額外的DNS查詢。因此說，TTL的值應該是下降停機時間和client性能最大化的一個折中。
一般減小client性能是沒有意義的。但當server故障時是個例外。有一個簡單的方法來解決問題，也就是說不是嚴格的遵照TTL，而是隻當更高層協議如TCP或HTTP檢測到不可恢復錯誤時才刷新DNS緩存。
這樣的技術在大多數場景下模擬TTL保持DNS緩存一致的行爲。然而這差點兒消除了不論什麼基於DNS高可用性解決方式中的性能損失。
但是需要注意的是這個技術方案和其它基於DNS的分佈式負載方案不兼容。
異步刷新
異步刷新是一個DNS緩存方法，它遵照已經設置TTL規則但是在很是大程度上消除了頻繁查詢DNS的延遲。在這項技術中，需要一個異步DNSclient庫如c-ares來實現。
這種方法很是easy。一個過時的請求仍然返回的是老的結果，但是後臺有一個非堵塞的DNS查詢來定時刷新DNS緩存。這樣的方案假設採用堵塞式(如同步)回調來查詢每條老的DNS數據，那麼這個方法差點兒不受DNS查詢延遲的影響，但是仍然和很是多基於DNS的故障轉移方案以及分佈式負載方案兼容。
總結
要下降移動網絡高延遲的影響就需要經過下降使移動網絡延遲急劇添加的網絡往返次數來實現。而採用軟件優化專一於最大限度地下降或消除往返協議的消息是克服這項艱鉅的性能問題的關鍵。
（移動網路性能篇，全文完。）
1. 本文由程序猿學架構翻譯
2. 本文譯自The Performance of Open Source Software | Secrets of Mobile Network Performance
3. 轉載請務必註明本文出自：程序猿學架構(微信號：archleaner )
4. 不少其它文章請掃碼：