網(wǎng)絡(luò)處理的性能與延遲時(shí)間的增加是不成比例的。這是由于大多數(shù)網(wǎng)絡(luò)協(xié)議的內(nèi)在操作是雙向信息交換。本章的其余部分則側(cè)重于理解為什么會(huì)產(chǎn)生這些信息交換以及如何減少甚至消除它們交換的頻率。

圖3：網(wǎng)絡(luò)協(xié)議

傳輸控制協(xié)議

傳輸控制協(xié)議(TCP)是一種面向連接、基于ip的傳輸協(xié)議。TCP影響下的無(wú)差錯(cuò)雙工通信信道對(duì)其他協(xié)議如HTTP或TLS來(lái)說(shuō)都必不可少。

TCP展示了許多我們需要盡量避免的雙向通訊。這其中一些可以通過采用擴(kuò)展協(xié)議如TCP Fast Open協(xié)議來(lái)替代;另一些則可以通過調(diào)整系統(tǒng)參數(shù)來(lái)達(dá)到最小化，比如初始化擁塞窗口。在本節(jié)中,我們將探討這兩種方法同時(shí)也提供一些TCP內(nèi)部組件的背景。

TCP Fast Open

初始化一個(gè)TCP連接約定需要3次信息交換，也就是我們所說(shuō)的3次握手。TCP Fast Open(TFO)是TCP的一個(gè)擴(kuò)展，它消除了通常握手過程中的往返延遲。

TCP在客戶端和服務(wù)端的三次握手協(xié)商操作參數(shù)使得雙方做健壯的雙向通信稱為可能。最開始的SYN信息(同步信息)代表客戶端的連接請(qǐng)求;如果服務(wù)端接受這個(gè)請(qǐng)求，那么它將返回一個(gè)SYN-ACK消息(同步和接受消息);最后，客戶端發(fā)送一個(gè)ACK消息來(lái)應(yīng)答服務(wù)器。這時(shí)，一個(gè)邏輯連接就已經(jīng)建立完成，客戶端就可以發(fā)送數(shù)據(jù)了。這其中你如果注意到，3次握手過程中至少引入了一個(gè)RTT的延遲那就很好了。

圖4：TCP3次握手

從傳統(tǒng)角度來(lái)看，除了對(duì)連接進(jìn)行回收利用外沒有其他方法來(lái)避免TCP3次握手造成的延遲。然而，這種想法發(fā)生隨著Tcp Fast Open IETF規(guī)范的引入發(fā)生了變化。

TFO允許客戶端在邏輯連接建立之前就開始發(fā)送數(shù)據(jù)。這實(shí)際上否定了3次握手中的往返延遲。這種優(yōu)化的累積效應(yīng)是讓人印象深刻。根據(jù)谷歌的調(diào)查，TFO可以減少頁(yè)面40%的加載時(shí)間。雖然這個(gè)規(guī)范只是草案，但是TFO已經(jīng)被主流瀏覽器(Chrome22以上)和平臺(tái)(Linux3.6以上)所支持，并且其他供應(yīng)商也保證將在不久以后會(huì)完全支持它。

TCP Fast Open是對(duì)3次握手協(xié)議的一個(gè)修正，它允許在同步消息(SYN Message)內(nèi)有少量的數(shù)據(jù)負(fù)載(如HTTP請(qǐng)求)。這個(gè)有效負(fù)責(zé)會(huì)傳遞給應(yīng)用服務(wù)器,否則連接握手完成。

早些時(shí)候擴(kuò)展方案像TFO最終因安全問題而失敗。而TFO通過使用安全令牌或者cookie來(lái)解決這個(gè)問題，也就是說(shuō)在傳統(tǒng)的TCP連接握手過程中給客戶端分安全令牌(tooken),并且期望將安全令牌包含在TFO優(yōu)化請(qǐng)求的SYN消息中。

對(duì)于TFO的使用，這里有一些小的警告。其中最值得注意的是，在初始化的SYN消息中請(qǐng)求的數(shù)據(jù)缺乏冪等性保證。雖然TCP保證重復(fù)數(shù)據(jù)包(重復(fù)經(jīng)常發(fā)生)會(huì)被接受者忽略，但是這個(gè)保證并不適用于連接的握手過程。目前在規(guī)范草案中正在標(biāo)準(zhǔn)化這個(gè)解決方案，但是于此同時(shí)TFO仍然可以被安全的應(yīng)用于冪等性處理。

初始擁塞窗口

初始擁塞窗口是TCP的一個(gè)可配置項(xiàng)并且有巨大的潛在能力來(lái)加速小的網(wǎng)絡(luò)事務(wù)。

最近的IETF規(guī)范促進(jìn)通常的初始擁塞窗口的設(shè)置增長(zhǎng)到3個(gè)報(bào)文段(如數(shù)據(jù)包)到10個(gè)報(bào)文段。這個(gè)建議是基于谷歌進(jìn)行的廣泛研究,這個(gè)研究證明了這個(gè)參數(shù)的設(shè)置對(duì)性能有平均10%的提升。但如果不介紹TCP的擁塞窗口(cwnd)的話，這種設(shè)置的目的和潛在影響就不會(huì)被真正領(lǐng)會(huì)。

當(dāng)在一個(gè)不可靠的網(wǎng)絡(luò)上進(jìn)行操作時(shí)，TCP來(lái)保證客戶端和服務(wù)端的可靠性。這相當(dāng)于一個(gè)承諾,所有發(fā)送出去的數(shù)據(jù)都會(huì)被接收到,或者至少看起來(lái)是這樣。其中，包丟失是滿足可靠性要求的最大障礙，這需要偵測(cè)、糾錯(cuò)以及預(yù)防。

TCP采用一個(gè)肯定應(yīng)答機(jī)制來(lái)檢測(cè)丟包情況，即每個(gè)發(fā)送出去的包都應(yīng)該被它預(yù)定的接收方應(yīng)答，如果沒有應(yīng)答就意味著這個(gè)包在傳輸過程中丟失。在等待確認(rèn)的過程中,傳輸數(shù)據(jù)包保存在一個(gè)特殊的緩沖區(qū)中，也就是所說(shuō)的擁塞窗口。當(dāng)這個(gè)緩沖區(qū)被塞滿時(shí)，一個(gè)被稱作cwnd耗盡的事件發(fā)生，所有傳輸停止，直到接收方應(yīng)答后騰出有效空間來(lái)發(fā)送更多的數(shù)據(jù)包。這些事件在TCP性能中至關(guān)重要。

除了網(wǎng)絡(luò)帶寬的限制，TCP吞吐量根本上受cwnd耗盡事件發(fā)生頻率的限制，而這可能與擁塞窗口的大小有關(guān)。當(dāng)TCP性能達(dá)到峰值時(shí)需要一個(gè)擁塞沖口來(lái)調(diào)節(jié)當(dāng)前的網(wǎng)絡(luò)狀態(tài)：擁塞窗口過大將增加網(wǎng)絡(luò)堵塞的風(fēng)險(xiǎn)--過度擁堵的網(wǎng)絡(luò)狀況會(huì)增加大量包丟失;過小則珍貴的網(wǎng)絡(luò)帶寬將不能充分被利用。從邏輯上講，對(duì)網(wǎng)絡(luò)情況了解的越多，肯能越能選擇一個(gè)最佳的擁塞窗口大小。實(shí)際情況則是，關(guān)鍵網(wǎng)絡(luò)屬性比如容量和延遲,是很難衡量的并且不斷在變化。而且，如果一個(gè)基于互聯(lián)網(wǎng)的TCP連接需要穿過許多網(wǎng)絡(luò)的這又會(huì)是一件更加復(fù)雜的事情。

由于缺乏手段來(lái)準(zhǔn)確確定網(wǎng)絡(luò)容量大小，相反TCP通過網(wǎng)絡(luò)擁堵情況來(lái)推斷擁塞窗口大小。當(dāng)TCP發(fā)現(xiàn)有包丟失時(shí)它就會(huì)擴(kuò)大擁塞窗口的大小，提示下行某處有一個(gè)網(wǎng)絡(luò)無(wú)法處理當(dāng)前的傳輸速率。通過采用這種擁塞避免機(jī)制,TCP最終最小化cwnd耗盡事件在某種程度上它消耗完為所有連接所分配的容量。那么現(xiàn)在，最終，我們也達(dá)到了目的，解釋清楚了初始擁塞窗口參數(shù)的重要性。

網(wǎng)絡(luò)擁堵情況只能通過丟包測(cè)試來(lái)檢測(cè)。一個(gè)新的或者空閑的連接由于沒有足夠丟包數(shù)據(jù)來(lái)證明創(chuàng)建擁塞窗口的最佳大小;TCP采用了一個(gè)比較明智的做法就是以一個(gè)可能最小情況導(dǎo)致網(wǎng)絡(luò)擁堵的大小一開始作為擁塞窗口大小;這最初意味著需要設(shè)置1個(gè)分片(大約1480字節(jié))，而且有些時(shí)候這種做法是推薦的。而稍后的實(shí)驗(yàn)會(huì)演示一個(gè)高達(dá)4的設(shè)置也是有效的。在實(shí)踐中你也通常發(fā)現(xiàn)初始擁塞窗口設(shè)置為3報(bào)文段(大約4kb)。

初始擁塞窗口不利于小的網(wǎng)絡(luò)事務(wù)處理。這種效果很容易說(shuō)明。在表中的3個(gè)報(bào)文段設(shè)置下，在發(fā)送3個(gè)數(shù)據(jù)包或者4k的數(shù)據(jù)后cwnd耗盡時(shí)間就會(huì)發(fā)生。假設(shè)數(shù)據(jù)包是連續(xù)發(fā)送的，響應(yīng)的響應(yīng)不會(huì)在任何所允許的往返時(shí)間(RTT)之前到達(dá);假如RTT是100ms的話，那么有效傳輸速率只有可憐的400字節(jié)/秒。盡管TCP會(huì)調(diào)節(jié)自身的擁塞窗口來(lái)充分利用有效容量，但是它在一開始將會(huì)很慢。事實(shí)上，這種方式被稱為慢啟動(dòng)。

為了減少慢啟動(dòng)對(duì)較小的下載的性能影響，它需要重新評(píng)估初始擁塞窗口的風(fēng)險(xiǎn)回報(bào)。谷歌正是這樣做的，而且發(fā)現(xiàn)將初始擁塞窗口設(shè)置在10個(gè)報(bào)文段(約14kb)會(huì)在最小網(wǎng)絡(luò)擁堵情況下達(dá)到最大吞吐量。現(xiàn)實(shí)世界中也證明了這樣設(shè)置總共可以減少頁(yè)面10%的加載時(shí)間;連接的往返延遲將得到更大的改善。

修改初始擁塞窗口的默認(rèn)值也并不是那么簡(jiǎn)單的。在大多數(shù)服務(wù)器操作系統(tǒng)下，一個(gè)系統(tǒng)級(jí)的配置只有有特權(quán)的用戶才可設(shè)置;這個(gè)參數(shù)也很少甚至不能被沒有權(quán)限的應(yīng)用在客戶端配置。需要注意的是一個(gè)更大的初始擁塞窗口在服務(wù)器端可以加速下載,而在客戶端則可以加速上傳。如果無(wú)法在客戶端改變這個(gè)設(shè)置就意味著應(yīng)該特別努力去減少請(qǐng)求負(fù)載的大小。

超文本傳輸協(xié)議

本節(jié)將討論在超文本傳輸協(xié)議(HTTP)性能方面來(lái)減少高的往返延遲的技術(shù)。

KeepAlive

KeepAlive是一個(gè)HTTP約定來(lái)允許同步連續(xù)的HTTP請(qǐng)求來(lái)使用同一個(gè)TCP連接。至少一個(gè)單組往返請(qǐng)求所需要的TCP的3次握手可以避免，每次請(qǐng)求可以節(jié)省幾十或者幾百毫秒。更深層次的，keepalive還有一個(gè)額外的但是未被提及的好處就是它在各個(gè)請(qǐng)求之間保留了當(dāng)前TCP的擁塞窗口大小，這將導(dǎo)致更少的cwnd耗盡事件發(fā)生。

圖5：HTTP pipelining

實(shí)際上，管道使網(wǎng)絡(luò)延遲分布于網(wǎng)絡(luò)往返的各個(gè)HTTP事務(wù)中。例如，5個(gè)管線式的HTTP請(qǐng)求通過一個(gè)100毫秒的RTT連接時(shí)將產(chǎn)生一個(gè)平均20毫秒的往返延遲;在同樣條件下，10個(gè)管線式請(qǐng)求時(shí)這個(gè)平均延遲將減少到10毫秒。

但是，HTTP pipeling有明顯的缺點(diǎn)阻止了它被廣泛使用，即歷史上參差不齊的HTTP代理支持和拒絕服務(wù)攻擊的影響。

安全傳輸層協(xié)議

傳輸層安全性(Transport Layer Security,TLS)是一個(gè)面向會(huì)話的網(wǎng)絡(luò)協(xié)議允許在公共網(wǎng)絡(luò)安全地交換敏感信息。雖然TLS在安全通信方面卓有成效，但是在高延遲網(wǎng)絡(luò)下它的性能會(huì)下降。

TLS采用一個(gè)復(fù)雜的握手協(xié)議包括兩次交換客戶端-服務(wù)端信息。一個(gè)TLS安全的HTTP傳輸明顯比較慢也正是這個(gè)原因。通常，發(fā)現(xiàn)一個(gè)TLS慢實(shí)際上是在抱怨它的握手協(xié)議中多重往返所產(chǎn)生的延遲。

圖6：DNS查詢

通常，主平臺(tái)提供了緩存實(shí)現(xiàn)來(lái)避免頻繁的DNS查詢。DNS緩存的語(yǔ)義非常簡(jiǎn)單：每個(gè)DNS響應(yīng)包含一個(gè)存活時(shí)間(time-to-live，TTL)屬性來(lái)聲明結(jié)果會(huì)被緩存多長(zhǎng)時(shí)間。TTL的范圍通常在幾秒鐘到幾天之間，但通常為幾分鐘。非常低的TTL值，通常在一分鐘以下，被用在影響負(fù)載分配或者減少服務(wù)器替換或ISP故障轉(zhuǎn)移的時(shí)間。

刷新失敗

高可用系統(tǒng)通常依賴于他們IP機(jī)房的冗余基礎(chǔ)設(shè)施主機(jī)。TTL值較小的DNS條目可以減少客戶指向失敗主機(jī)的時(shí)間，但是同時(shí)會(huì)導(dǎo)致大量額外的DNS查詢。所以說(shuō)，TTL的值應(yīng)該是減少停機(jī)時(shí)間和客戶端性能最大化的一個(gè)折中。

通常降低客戶端性能是沒有意義的，但當(dāng)服務(wù)器故障時(shí)是個(gè)例外。有一個(gè)簡(jiǎn)單的方法來(lái)解決這個(gè)問題，也就是說(shuō)不是嚴(yán)格的遵守TTL，而是僅僅當(dāng)更高層協(xié)議如TCP或HTTP檢測(cè)到不可恢復(fù)錯(cuò)誤時(shí)才刷新DNS緩存。這種技術(shù)在大多數(shù)場(chǎng)景下模擬TTL保持DNS緩存一致的行為，然而這幾乎消除了任何基于DNS高可用性解決方案中的性能損失。

但是需要注意的是這個(gè)技術(shù)方案和其他基于DNS的分布式負(fù)載方案不兼容。

異步刷新

異步刷新是一個(gè)DNS緩存方法，它遵守已經(jīng)設(shè)置TTL規(guī)則但是在很大程度上消除了頻繁查詢DNS的延遲。在這項(xiàng)技術(shù)中，需要一個(gè)異步DNS客戶端庫(kù)如c-ares來(lái)實(shí)現(xiàn)。

這個(gè)方法很簡(jiǎn)單，一個(gè)過期的請(qǐng)求仍然返回的是老的結(jié)果，但是后臺(tái)有一個(gè)非阻塞的DNS查詢來(lái)定時(shí)刷新DNS緩存。這種方案如果采用阻塞式(如同步)回調(diào)來(lái)查詢每條老的DNS數(shù)據(jù)，那么這個(gè)方案幾乎不受DNS查詢延遲的影響，但是仍然和很多基于DNS的故障轉(zhuǎn)移方案以及分布式負(fù)載方案兼容。

總結(jié)

要減少移動(dòng)網(wǎng)絡(luò)高延遲的影響就需要通過減少使移動(dòng)網(wǎng)絡(luò)延遲急劇增加的網(wǎng)絡(luò)往返次數(shù)來(lái)實(shí)現(xiàn)。而采用軟件優(yōu)化專注于最大限度地減少或消除往返協(xié)議的消息是克服這項(xiàng)艱巨的性能問題的關(guān)鍵。