探寻影响业务性能的隐形杀手——TCP Nagle算法、延迟确认及窗口大小故障分析案例(2)

haiwanxue

五、案例分析一

下面通过笔者在实际工作中遇到的案例来具体说明，分析过程中使用到科来网络分析系统，为了更好的显示分析效果或具有说服力，可能会采用其他工具辅助说明。

5.1案例背景

某信息研究院关键业务系统，供内部人员日常业务使用，其中上传文件是基本常见操作之一。之前发现过部分人员上传速度较慢，IT管理部门判断可能是由于网络带宽问题。

经过网络扩容，可用带宽比原来大大提升后，问题依旧存在。采用网络分析工具长期监测和分析，发现除了出口带宽占用率相对高一点外，内部网络使用率很低。

运维人员查找问题原因时还发现，有些反应上传速度慢的用户，在对相同机房的同网段的某些业务系统也通过B/S方式上传数据，但速度明显比前者快，而两者的网络结构完全相同。一时找不出问题的根本原因。

笔者在此时进行了该问题的分析。

5.2网络及应用结构

简单描述一下该研究院网络和应用结构。

客户端和服务器均在研究院内，可视为内部局域网间业务访问，内网为100Mbps带宽。业务访问为B/S方式。单台服务器兼做Web+App Server，IP地址为后面连接数据库。具体的软件为常见的传统产品，无明显特别之处。

下面为简单的用户网络环境示意图。



5.3分析方法与思路

分析方法较为简单，站在数据包看故障，因为数据包不会撒谎（Packets Never Lie）。

由于该问题为定操作发生，或者至少发现某些操作出现性能问题，即部分用户在上传文件操作时速度极慢，应该是30-40KB/s的样子。

所以，分别捕获相同用户上传“快”和慢的用户数据，对比分析，即可找到问题原因。

列举一下客户端与服务端地址信息。

客户端IP	服务器端IP	上传快慢情况
10.2.10.136	10.1.1.49	较快
10.2.10.136	10.1.1.43	慢

haiwanxue

5.1分析过程

整个分析过程是基于两个Trace file，一个为上传文件速度较快的，另一个则是上传相对较慢的。

5.4.1整体流量对比

先来一个整体效果对比，看看两者的平均上传速度。

下图为上传速度较快的流量信息统计，从流量峰值可以看到，其速度为19.30Mbps，19秒时间传输流量为12.35MB。



下图为上传速度慢的统计信息，从流量峰值可以看到，其速度为365.39Kbps，22秒时间传输流量为497.18KB。



从上述宏观比较不难发现，快与慢之间的确存在较大差异。按照如此传输速度，客户端上传一个5MB大小的文件，所需时间约为4小时，确实无法接收。

另外，从所谓快的上传操作也可以看到，上传操作速度最快时也只有19.30Mbps，这与实际网络可提供的吞吐能力也有较大出入。

5.4.2对比分析连接建立信息

了解清楚客户网络状况及应用系统架构后，在分析人员决定通过捕获流量信息分析时，尤其对这种类似定操作性能问题的对比分析，第一时间可能要对比分析两者对应连接建立信息（即TCP三步握手），试图从中找到一些问题的端倪，尤其会着重检查一下IP层和TCP层Option信息。所以，这里先对比分析一下两者对应的连接建立信息。

1)上传操作慢的三步握手分析

Frame 1，SYN



Frame 2，SYN ACK



Frame 3，ACK



以上三步握手报文关键信息：

内容	Client	Server
Window Size	65535	16384
MSS	1460	1380
SACK	True	True

根据统计信息，在该连接的数据传输过程中，MSS为1380（取最小的），启用SACK（选择性确认，RFC 2018）。

2)上传操作较快的三步握手分析

Frame 1，SYN



Frame 2，SYN ACK



Frame 3，ACK



以上三步握手报文关键信息：

内容	Client	Server
Window Size	65535	5840
MSS	1460	1380
SACK	True	True

通过与前面的三步握手数据信息对比，对于同一个客户端，数据没有什么变化。两者之中仅有一处不同，即Server window size。对于上传操作，在利用率较低的局域网访问，文件传输快慢与Server window size有关，但不一定是全部决定因素。

有趣的是，上传慢的接收方Window size比较快的要大。如果分析得到的这两个服务器端window size数据颠倒一下的话，很多人可能会猜想，传输速度可能跟这个数值有关。实际情况，试图通过对比分析两个连接的连接建立信息找出问题的可能原因的想法，有点小破灭了。

使用科来网络分析系统顺便查看一下两个连接建立花费的时间情况。

传输慢的连接建立完成时间情况。



传输较快连接建立完成时间情况。



两者连接建立完成时间可大致评估网络延时情况，从上图看到，两者是在0.5-1ms左右时间内完成三步握手操作，无明显异常。

haiwanxue

5.4.3传输行为和特征分析

上面的分析只是习惯性的尝试查找，结果不但没有定位到问题原因，反而发现了和常理相反的现象。

不过上面的分析只是上传操作的“开头”，从整体流量对比部分已经看到，差不多相同的时间段内，传输的文件大小及流量峰值都远远不同。

通过分析数据传输行为和特征，可以清晰的了解TCP在发送和接收报文时的详细轨迹。通过轨迹分析，能够准确定位故障现象，精确分析导致问题的根本原因。

1)上传操作慢数据传输行为和特征分析

首先来分析一下上传速度慢的连接TCP传输行为。

分析发现，发送方每发送几个报文后，总会出现一段等待时间，大约200ms多一点。直到再次收到接收端的确认报文后，才继续发送新的数据。如下图所示：



再来一张图，加以说明这种现象的存在。



如果将数据传输特征的部分位置放大，准确查看数据传输是怎么样随着时间的推移而变化的，则能更清晰的了解其传输行为。

下面两图分别展现了上传慢操作数据的传输特征，供参考。

一张黑白色。


一张彩色。



2)上传操作较快数据传输行为和特征分析

接下来分析上传操作较快的数据传输过程，查看其具有什么样的特征和行为，是否也会像上传慢的操作现象一样呢？

通过分析发现，对于相同的客户端，在向不同服务器上传数据时，其表现特征不尽相同。如下图，在多处地方发现大于350ms，或接近400ms的延时等待现象。

另外，分析发现每当出现这种较大延时现象，都会伴随着数据报文重传的事件发生。



同样，为了更好说明传输特征，同样来多几张图形。



另外一张图。



从上面对上传操作速度较快的数据传输特征分析来看，发现也存在不小的问题，因为这些问题的存在，才导致其不是真正的上传速度“快”。文中一直称其上传速度快，是相对于上传更慢的操作来说。

以上分析只是从表面或者说不够深入的分析到了两者的数据传输特征，稍后笔者将细致分析问题根本原因。

笔者认为，所有通过网络方式传输数据的相关网络故障、应用性能问题等，都可以使用分析数据包的方式查找到问题原因，至少能分析出深层的问题现象，或者查找到响应时间最长或Top N的应用层语句。这就是网络分析技术的魅力所在，站在数据包看故障，站在网络看应用。

haiwanxue

5.1根本原因分析

通过前面的分析，虽然貌似找到了上传操作慢的可能原因，尚未具体分析，但同时也发现，即使是上传操作较快的数据传输过程，也存在较为严重的问题。简单的说，100Mbps的内网数据传输，速率峰值却不超过20Mbps，跟这里的发现是密切联系的。

下面分别分析两者性能问题的根本原因。

5.5.1上传操作速度慢的问题根本原因分析

从最前面的Nagle算法和延迟确认部分，笔者已经写出这两者的设计意义和运行机制，各自的特点及可能会带来的问题。

有了前面的基础理论部分，可以明显的看到，上传操作速度慢的问题根本原因是Nagle算法遇到了延迟确认。

以下图为例，详细分析说明。



发送方在发送完Frame 99后，由于发送的报文大小为1292，小于MSS（这里的MSS大小为1380），Nagle算法机制阻止其在接收到Frame 99的ACK之前，不再发送其他数据包。

接收方在收到Frame 99前后都ACK之前的报文，当接收到Frame 99时，由于该报文大小小于MSS，由于Delayed ACK机制，不对Frame 99进行ACK，直到默认时间200ms达到，才进行ACK报文发送。

上图中Frame 103是对Frame 99的ACK。

其实，这里还有一个现象，对于发送方来说，Frame 99和104之间是两个连续发出的报文，但这两者之间存在应用层数据向系统处理核心复制数据的过程，即写操作或读操作的过程。

截止当前，已基本清楚为什么上传操作速度慢了。

haiwanxue

5.5.2上传操作速度较快的问题可能原因分析

接着来分析上传操作速度较快的数据传输过程中的问题。

通过上面的分析得知，所谓上传较快只是相对刚刚分析过的那个“倒霉鬼”而已。就其本身传输速度来说，如果真正能够发挥网络真实传输能力的话，则上传速度肯定不会小于20Mbps。

下面进行两点问题分析：①为什么在传输过程中，总有350-400ms的延时现象出现；②为什么上传速度流量峰值小于20Mbps。

先分析第一个问题。

以下图为例，发送方完成Frame 5724后，不再继续发送报文，由于Frame 5724小于MSS（大小为1292），可以暂时理解为Nagle算法机制作用。
实际现象与Nagle算法或者Delayed ACK等机制作用并不相同，有两点可以说明①延时明显较大；②当延时出现时有重传报文出现。如下图：



在不明确具体问题原因前，先不做判断。先详细分析一下相关数据，看看能否找到原因或可能的原因。

上图分析可得，Frame 5726是对Frame 5721的ACK（680008119 =680006739+1380），Frame 5727是5726的重传（Duplicate ACK）。从Frame 5727到Frame 5728历经382.77ms时间后，发送方重传了Frame 5722，之后立刻接收到Frame 5724的ACK（680012171=680010879+1292），即Frame 5729。

以上分析得到的结论是在数据传输过程中，Frame 5722丢失或接收方未处理或处理出错。

另外，从上面的分析中看到，Frame 5726是SACK报文。在未看详细解码内容前，这点也是可以判断的，发送端在重传了Frame 5722后，并没有重传接下来的Frame 5723和5724，接收端快速确认了Frame 5724，即5729。

关于SACK的具体解码内容见下图。



以上分析，只是看到了一个现象，数据传输过程存在较大延时，并有重传现象发生；得到了一个可能的结论，数据包丢失或程序处理出现问题。具体是什么原因，可能需要继续分析。

经过对该数据传输中的重传数据行为统计分析发现，每当发送端在发送应用信息块的最后几个报文时，如果出现Duplicate ACK时，就会有300-400ms的延时产生，而这里的Duplicate ACK多数是SACK。

同时发现，不少这类现象都存在共性，或者说有规律性。即应用数据块的最后几个报文总是无法得到ACK，然后出现SACK，然后时延等待，继而发送端重传。如下面的几个图，分别显示了每个应用块的倒数第三个报文未“接收”到，再次被重传的行为。

第二个例子：



第三个例子：



第四个例子：



从以上的几个例子中看到，产生延时和重传的现象有着明显的规律性。应用数据块结尾——报文未“收到”——发生延时——产生重传。

统计分析所有网络数据重传状况，可以排除网络拥塞等因素造成的报文丢失。下图内容辅助说明该问题现象。



上图中，横轴为时间，竖直的蓝红色条状为一簇数据报文的集合，竖条与竖条之间的空隙是延时间隔，即这段时间内无数据传输。黄色R及数字代表数字对应的Frame被重传，几乎所有间隙后的第一个报文为上个竖条内的报文重传。

另外接收方Window size没有减小或更新等明显的现象或规律。

通过上述的分析结果，回答笔者的问题①，为什么在传输过程中，总有350-400ms的延时现象发生？

答案很简单，接收方没有接收到部分客户端的报文。但是，为什么没有接收到，网络问题？系统问题还是应用问题？

有了上面的分析过程，恐怕没有人会肯定的判定问题出现在哪，因为缺少了数据支持一切都显得很苍白无力。

笔者分析，问题①的根本原因可能与网络没有关系，注意只是可能。在没有监测和获取接收方系统和应用相关信息，仅从网络捕获数据分析，无法精确定位问题根本原因。

笔者认为，如果仅从分析中得到诸如客户端问题或服务器问题或网络问题或应用问题等结论，准确的说，这类分析结论都是模糊的，缺乏说服力的。只有详细的阐述问题原理，给出精确的量化数据依据，才算是真正的分析结论。

haiwanxue

接下来再继续分析笔者的问题②：为什么上传速度流量峰值小于20Mbps？

问题①中的现象可能是该问题的答案，但不是全部。就是说，有了问题①的存在，可能会影响真实的数据上传速度，但还不至于影响到流量的峰值，或者说可能有影响，但影响不至于这么严重，但其对平均速率影响倒是较为严重。

影响网络传输的主要因素基本有如下几个：

• BDP（Bandwidth-Delay Product），与带宽和网络延时有关；

• 拥塞窗口大小；

• 接收方窗口大小；

• 发送方窗口大小。

其中BDP一般不会成为影响数据传输的主要因素，尤其在带宽较大的局域网环境下。

拥塞窗口是个动态值，会在TCP连接中的不同过程动态变化，主要用来防止网络拥塞。

接收方窗口大小是TCB（TCP Control Block）中的一个组成部分，一般为接收方宣告的window size。其中TCP Option中的一个选项window scale，可影响其大小，代表连续接收数据的能力。

影响网络传输能力的各个因素分析是一个较为复杂的话题，如果以后有机会，笔者再与大家分享其中的乐趣。这里大家只需知道，最大传输能力取决于上述因素中的最小值即可。

这里直接讨论问题。

由于是上传文件操作，而且在低延时的高带宽网络环境中，关注接受者的窗口大小相对较为关键，当然，发送者的快慢除了发送者发送窗口大小外，还与应用处理有关。

通过分析，接收者在进行接收数据时，只进行了一次窗口更新，下面用几个与接收者窗口大小相关的信息来辅助说明。

下图是在整个连接中，服务器向客户端宣告的窗口大小变化情况。从中可以清晰的看到一次窗口更新现象，时长不足1秒。其中横轴为时间，纵轴为服务器端宣告的窗口大小。



这里补充一下，从连接建立到12s之前，客户端通过get等方式访问服务器端页面，从12s靠后一点，开始上传文件操作。

为了更为清晰，通过几张图来显示服务器端接收窗口变化情况。

下面是连接建立后，客户端在进行HTTP GET访问时，服务器端窗口大小变化情况，从中可以清晰的看到慢启动的过程，直到大小为16350bytes（16KB）才稳定。



客户端开始上传文件操作时，出现第二次慢启动过程，直到接收端窗口大小增大到32767bytes（32KB）。如下图所示。



在接收端接收上传数据过程中，出现了一次窗口更新过程，在历经不到2秒的“消化”后，再次出现慢启动，直到窗口大小再次达到32KB。之后持续以此大小窗口接收数据。



之所以要分析和列举接收端窗口大小变化情况，是因为要在这里分析，在什么位置文件上传速度达到了峰值，以及该峰值是如何计算得来。这样才有助于优化上传速度，提供上传效率，没有人不期望业务操作效率过高吧。

对了，顺便查看一下，在上传过程中，或连接建立后的GET访问时，客户端的窗口大小情况，如下图。

蓝色线条代表客户端Window size在整个过程中的大小，从中看到，基本处于65535bytes（64KB）。因为其并未接收大量的数据，所以Receive Buffer大小基本处于未变化状态。



继续分析上传操作速度峰值时段的量值由来。

还记得整体流量对比分析时，上传操作速度较快的流量峰值大小为多少吗。是的，是19Mbps左右，该数量是如何得来，这里简单描述一下。

首先，流量峰值一定会发生在流量拥塞控制过程中接收方窗口最大时段，即上面提到过的32KB时，如下图，笔者截取某时段发送和接收流量大小示意图，分流量显示了速率大小，由18814.096+277.92=19092.016Kbps可得流量峰值。当然，这里只是以概览的方式显示一下。我们需要精确分析为什么上传速率为18814.096Kbps， ACK速率是277.92Kbps。



关于速率的计算方式，比较简单，传输的流量大小除以所用时间，但这里需要注意的是，网络流量大小计量方式bps为bit每秒，而我们看到的数据传输报文大小一般都是以byte为单位，所以不要忘记乘以8，得出速率。

haiwanxue

来看一下上传操作时的极限速度，方法就是把时间不用秒为单位，如果改为毫秒、微妙甚至纳秒，则能更为精确的分析出真实的上传速率，但现实中都是以秒为单位计算，即bps。但如果要得到精确得出实际网络速率，或更准确的说，想了解网络速率的实现原理和实际现象，缩小时间粒度来分析，基本算得上是种方法。

通过分析上传速度峰值时段的数据报文传输行为可以看到，发送方每发送6个数据包，便得到两个ACK，然后再发送6个，再接受两个ACK。如果把6+2看做一个单元，则单元与单元之间的时间间隔基本相同。如下图。

从Frame 9805到Frame 9813为一个单元，用时0.002774s。数据传输情况，发送方发送了8540bytes（1380*5+1292+58*6）网络数据，接收了128bytes（64*2）数据。



同理，下面图形基本与上面的表达内容一致，时间为0.002727，传输数据个数和大小均与上相同。



在用一个增强说明，下图用时为0.002724。



使用以上内容能够精确计算出，不同流向的速率大小，只是时间单位精确到了微妙。计算方法为，每单元不同流向数据和除以时间，即得到该单元实际网络速率大小。

以第一张图为例计算

发送到接收方向：8540bytes/0.002774s=3078586.878byte/s，换算为常见格式，3078586.878byte/s*8= 24628695.025 bps=24.629Mbps。

接收到发送方向：128bytes/0.002774s=46142.754byte/s，换算后为46142.754byte/s*8=369.142Kbps。

为什么计算结果与之前的统计数据不一致？这是因为峰值统计是以秒为单位计算出的，而以上数据是以微妙为单位计算得出，而且选择的是相对速率最快的内容。实际中，由于网络、系统或应用的因素，所有上传数据并非按照上述速度严格传输，因此总体时间肯定大于按照上述方法统计的时间，所有平均速度相对会小。

上述分析有什么意义？

通过上述分析，笔者的目的是想讨论，如何才能提高文件上传速度，即如何提高数据传输速率。因为实际网络理论速率完全远大于真实上传速率。

从上面的计算方法可以看到，要提供速率有两个办法：

一是提高单元时间内的传输流量大小；

另一个则是减少单元之间的时间间隔。

先简单说一下，上文提及的单元，在实际应用设计和操作系统协议栈工作过程是可以控制的。先假设应用在设计时，放宽了所有在Socket及Socket Option里面的限制。则该单元的大小可由TCP Buffer来控制，其中涉及到window size的相关内容，要实现快速传输需要TCP option中的scale window支持。

在下一个案例中，笔者将详细介绍如何通过控制影响TCP传输行为的部分参数，而使数据传输速度更快，业务完成效率更高。

王希尔

支持，辛苦

gogogo6626

够辛苦的，没全看明白

aaa96588

辛苦辛苦了

czq227

有点看不明白啊

icexplorer

看得眼花缭乱，但是我知道是精华贴啊，建议超版加精

redhat9i

学习一下！！！

baidu2345

katrinacamille

这是经典分析，谢谢lz提供！

yuanye002

精品帖子。。
支持

iejtqy

怎么没有做成文档。。。

zzzhangmt

真的大拿啊，期待继续！

lmc791204

顶，学习。