原文转自：http://blog.sina.com.cn/s/blog_987e00020102wq6b.html
查找高延时点最有效的方法之一是检查最初的握手信号以及跟随其后的几个报文。例如，一个简单的客户端与网络服务器的连接，客户端尝试通过浏览器访问网络服务器的站点。我们只关心这一通信序列的前六个报文，包括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的通讯。
