（六）：狙擊網(wǎng)絡(luò)高延時(shí)點(diǎn)

在某些情況下，丟包可能并不是造成延時(shí)的原因。你可能會(huì)發(fā)現(xiàn)盡管兩臺(tái)主機(jī)之間通訊速度很慢，但這種慢速并沒有伴隨著TCP重傳或是重復(fù)ACK的征兆。在這種情況下，需要使用另一種方式來定位高延時(shí)點(diǎn)。

查找高延時(shí)點(diǎn)最有效的方法之一是檢查最初的握手信號(hào)以及跟隨其后的幾個(gè)報(bào)文。例如，一個(gè)簡(jiǎn)單的客戶端與網(wǎng)絡(luò)服務(wù)器的連接，客戶端嘗試通過瀏覽器訪問網(wǎng)絡(luò)服務(wù)器的站點(diǎn)。我們只關(guān)心這一通信序列的前六個(gè)報(bào)文，包括TCP握手過程，首次HTTP GET請(qǐng)求，對(duì)此GET請(qǐng)求的確認(rèn)，以及從服務(wù)器發(fā)至客戶端的第一個(gè)數(shù)據(jù)報(bào)文。

更多信息

正常通訊**:**

在討論高延時(shí)狀況之前，找一個(gè)正常的通訊作為參照。在第二節(jié)已經(jīng)介紹過TCP握手過程以及HTTP通訊，這里不再贅述。在下面這張圖里，我們關(guān)心的部分只有Time列：

逐一分析這六個(gè)報(bào)文，立刻就會(huì)看到第一次延時(shí)?？蛻舳耍?72.16.16.128）發(fā)送首次SYN報(bào)文以開始TCP握手，在服務(wù)器（74.125.95.104）返回SYN/ACK之前，有0.87秒的延時(shí)。這是線路延時(shí)的第一個(gè)信號(hào)，這是由客戶端和服務(wù)器之間的設(shè)備引起的。

我們判斷這是線路延時(shí)的依據(jù)是所傳送的報(bào)文類型特征。當(dāng)服務(wù)器接收到一個(gè)SYN報(bào)文，只需花費(fèi)很少的處理過程就可發(fā)送回復(fù)，因?yàn)檫@一工作負(fù)載并不包含任何傳輸層之上的處理。即使服務(wù)器工作負(fù)載非常繁重，它通常也會(huì)快速地以SYN/ACK來回復(fù)SYN報(bào)文。這就排除了服務(wù)器是高延時(shí)的潛在原因。

客戶端也被排除的原因在于，它除了接收SYN/ACK報(bào)文之外，沒有進(jìn)行任何處理。

這一抓包的前兩個(gè)報(bào)文幫我們排除了客戶端和服務(wù)器，并指出了潛在原因。

繼續(xù)分析，我們發(fā)現(xiàn)結(jié)束三步握手信號(hào)的ACK報(bào)文快速出現(xiàn)，客戶端發(fā)送的HTTP GET請(qǐng)求也是如此。產(chǎn)生這兩個(gè)報(bào)文的所有處理在本地客戶端接收到SYN/ACK之后進(jìn)行，因此在客戶端沒有繁重的負(fù)載需要處理的情況下，這兩個(gè)報(bào)文預(yù)計(jì)會(huì)很快傳送。

到了報(bào)文5，我們看到另一個(gè)延時(shí)高得離譜的報(bào)文。出現(xiàn)在最初的HTTP GET請(qǐng)求發(fā)送過后，從服務(wù)器返回的ACK報(bào)文花費(fèi)了1.15秒才收到。接收到HTTP GET請(qǐng)求之后，服務(wù)器在開始發(fā)送數(shù)據(jù)之前首先發(fā)送了一個(gè)TCP ACK，同樣只需占用服務(wù)器很少的處理。這是另一個(gè)線路延時(shí)的信號(hào)。

不管何時(shí)你經(jīng)歷著線路延時(shí)，你幾乎總是會(huì)看到：在最初的握手信號(hào)期間的SYN/ACK報(bào)文，以及整個(gè)通訊過程的ACK報(bào)文中，存在著高延時(shí)。即使這一信息并沒有告訴你網(wǎng)絡(luò)上延時(shí)的確切原因，至少讓你明白客戶端和服務(wù)器都不是延時(shí)點(diǎn)所在，因此延時(shí)發(fā)生在兩者之間的設(shè)備。這時(shí)，你應(yīng)當(dāng)開始檢查受影響主機(jī)之間的各種防火墻，路由器，以及代理，以定位罪魁禍?zhǔn)住?/p>

慢速通訊——客戶端延時(shí)：

下一個(gè)延時(shí)場(chǎng)景的抓包如下圖所示：