在某些情况下，丢包可能并不是造成延时的原因。你可能会发现尽管两台主机之间通讯速度很慢，但这种慢速并没有伴随着TCP重传或是重复ACK的征兆。在这种情况下，需要使用另一种方式来定位高延时点。

查找高延时点最有效的方法之一是检查最初的握手信号以及跟随其后的几个报文。例如，一个简单的客户端与网络服务器的连接，客户端尝试通过浏览器访问网络服务器的站点。我们只关心这一通信序列的前六个报文，包括TCP握手过程，首次HTTP GET请求，对此GET请求的确认，以及从服务器发至客户端的第一个数据报文。

更多信息

正常通讯**:**

在讨论高延时状况之前，找一个正常的通讯作为参照。在第二节已经介绍过TCP握手过程以及HTTP通讯，这里不再赘述。在下面这张图里，我们关心的部分只有Time列：

逐一分析这六个报文，立刻就会看到第一次延时。客户端（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报文中，存在着高延时。即使这一信息并没有告诉你网络上延时的确切原因，至少让你明白客户端和服务器都不是延时点所在，因此延时发生在两者之间的设备。这时，你应当开始检查受影响主机之间的各种防火墙，路由器，以及代理，以定位罪魁祸首。

慢速通讯——客户端延时：

下一个延时场景的抓包如下图所示：