在某些情況下，丟包可能并不是造成延時的原因。你可能會發現盡管兩臺主機之間通訊速度很慢，但這種慢速并沒有伴隨著TCP重傳或是重復ACK的征兆。在這種情況下，需要使用另一種方式來定位高延時點。 查找高延時點最有效的方法之一是檢查最初的握手信號以及跟隨其后的幾個報文。例如，一個簡單的客戶端與網絡服務器的連接，客戶端嘗試通過瀏覽器訪問網絡服務器的站點。我們只關心這一通信序列的前六個報文，包括TCP握手過程，首次HTTP GET請求，對此GET請求的確認，以及從服務器發至客戶端的第一個數據報文。 # 更多信息 **正常通訊****:** 在討論高延時狀況之前，找一個正常的通訊作為參照。在第二節已經介紹過TCP握手過程以及HTTP通訊，這里不再贅述。在下面這張圖里，我們關心的部分只有Time列：  這一通訊序列是非常快速的，整個過程耗時不到0.1秒。 接下來幾個抓包文件包含同樣的traffic模式，但是在報文時序上有所不同。 **慢速通訊——線路延時：** 讓我們看看下面這個報文。注意到所有報文都是相同的，除了報文2和5的時間延時較長：  逐一分析這六個報文，立刻就會看到第一次延時。客戶端（172.16.16.128）發送首次SYN報文以開始TCP握手，在服務器（74.125.95.104）返回SYN/ACK之前，有0.87秒的延時。這是線路延時的第一個信號，這是由客戶端和服務器之間的設備引起的。 我們判斷這是線路延時的依據是所傳送的報文類型特征。當服務器接收到一個SYN報文，只需花費很少的處理過程就可發送回復，因為這一工作負載并不包含任何傳輸層之上的處理。即使服務器工作負載非常繁重，它通常也會快速地以SYN/ACK來回復SYN報文。這就排除了服務器是高延時的潛在原因。 客戶端也被排除的原因在于，它除了接收SYN/ACK報文之外，沒有進行任何處理。 這一抓包的前兩個報文幫我們排除了客戶端和服務器，并指出了潛在原因。 繼續分析，我們發現結束三步握手信號的ACK報文快速出現，客戶端發送的HTTP GET請求也是如此。產生這兩個報文的所有處理在本地客戶端接收到SYN/ACK之后進行，因此在客戶端沒有繁重的負載需要處理的情況下，這兩個報文預計會很快傳送。 到了報文5，我們看到另一個延時高得離譜的報文。出現在最初的HTTP GET請求發送過后，從服務器返回的ACK報文花費了1.15秒才收到。接收到HTTP GET請求之后，服務器在開始發送數據之前首先發送了一個TCP ACK，同樣只需占用服務器很少的處理。這是另一個線路延時的信號。 不管何時你經歷著線路延時，你幾乎總是會看到：在最初的握手信號期間的SYN/ACK報文，以及整個通訊過程的ACK報文中，存在著高延時。即使這一信息并沒有告訴你網絡上延時的確切原因，至少讓你明白客戶端和服務器都不是延時點所在，因此延時發生在兩者之間的設備。這時，你應當開始檢查受影響主機之間的各種防火墻，路由器，以及代理，以定位罪魁禍首。 **慢速通訊——客戶端延時：** 下一個延時場景的抓包如下圖所示：  這一抓包開始時很正常，TCP握手非常迅速，沒有任何延時的跡象。正常狀態持續至第四個報文：握手信號結束之后接收到一個HTTP GET請求。這個報文距離前一個接收到的報文有1.34秒的延時。 要確認網絡的延時點，需要檢查第3和第4個報文之間發生了什么。報文3是客戶端發送到服務器的TCP握手信號中的最后一個ACK，報文4是從客戶端發送至服務器的GET請求。這兩個報文的共同之處在于都是由客戶端發送，并且獨立于服務器。由于所有這些操作都集中在客戶端上，GET請求應當在發送了ACK之后快速傳送。 不幸的是對于終端用戶，從ACK到GET的傳送并沒有快速發生。GET報文的創建與傳輸取決于應用層的處理，這一過程中的延時意味著客戶端無法及時的執行這一功能。這表示客戶端最終為通訊中的高延時負責。 **慢速通訊——服務器延時：** 最后一個延時場景的抓包如下圖所示：  在這一抓包中，兩個主機之間的TCP握手過程完成得干脆利落，因此開始時并無問題。接下來幾個報文也很順利，首個GET請求及回復ACK報文也在快速交付。直到最后一個報文，我們看到了高延時的信號。 第六個報文是服務器響應客戶端GET請求的第一個HTTP數據報文，但是在服務器發送GET請求的TCP ACK 0.98秒之后才到達。報文5和6的傳送過程與我們在前一個場景所見ACK和GTE請求的傳送類似。但是，在這一情況下，服務器是我們關注的焦點。 報文5是服務器對從客戶端接收GET請求的回應。只要該報文被發送，服務器就應當立即發送數據。這一讀取，封裝，傳送的過程是由HTTP協議完成的，由于這是應用層協議，需要服務器參與處理過程。這一報文的延遲接收表明服務器無法在合理的時間內處理數據，最終指向服務器是延時點。 **延時定位思路：** 通過六個報文，我們能夠定位服務器與客戶端之間的網絡高延時點。這些場景可能看起來有點復雜，但是下圖能使你的定位延時過程變得簡單快捷。這一原則幾乎能應用于任何基于TCP的通訊。