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

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

更多信息

正常通訊**:**

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

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

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

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

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

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

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

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

慢速通訊——客戶端延時：

下一個延時場景的抓包如下圖所示：