|
|
楼主 |
发表于 2012-6-7 16:06:55
|
显示全部楼层
本帖最后由 haiwanxue 于 2012-6-7 16:56 编辑
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的延时现象发生？
答案很简单，接收方没有接收到部分客户端的报文。但是，为什么没有接收到，网络问题？系统问题还是应用问题？
有了上面的分析过程，恐怕没有人会肯定的判定问题出现在哪，因为缺少了数据支持一切都显得很苍白无力。
笔者分析，问题①的根本原因可能与网络没有关系，注意只是可能。在没有监测和获取接收方系统和应用相关信息，仅从网络捕获数据分析，无法精确定位问题根本原因。
| 笔者认为，如果仅从分析中得到诸如客户端问题或服务器问题或网络问题或应用问题等结论，准确的说，这类分析结论都是模糊的，缺乏说服力的。只有详细的阐述问题原理，给出精确的量化数据依据，才算是真正的分析结论。 |
|
|
发表于 2012-6-7 16:02:07
