2014年9月1日EMCCommunityNetwork-ECN:如果看了这个你还是不会用Wireshark，那就来找我吧（8月6日完结）
https://community.emc.com/thread/194901?start=0&tstart=01/7
一站式学习Wireshark（四）：网络性能排查之TCP重传与重复ACK
转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese
介绍
作为网络管理员，很多时间必然会耗费在修复慢速服务器和其他终端。但用户感到网络运行缓慢并不意味着就是网
络问题。
解决网络性能问题，首先从TCP错误恢复功能（TCP重传与重复ACK）和流控功能说起。之后阐述如何发现网络慢
速之源。最后，对网络各组成部分上的数据流进行概况分析。这几张内容将会帮助读者识别，诊断，以及排查慢速
网络。
更多信息
接下来的内容，较多是黑白图片了。虽然看起来有点不爽，但还是很值得一看。
TCP错误恢复功能：
TCP的错误恢复功能是定位，诊断及修复网络延时的最佳工具。
延时可以在单程也可以往返方向测量。高延时是网络管理员的头号大敌。本节我们讨论TCP高延时是如何导致序列
号和确认号乱序的。
TCP重传：
主机报文重传是TCP最基本的错误恢复功能，它的目的是防止报文丢失。
报文丢失的可能因素有很多种，包括应用故障，路由设备过载，或暂时的服务宕机。报文级别速度是很高的，而通
常报文丢失是暂时的，因此TCP能够发现和恢复报文丢失显得尤为重要。
决定报文是否有必要重传的主要机制是重传计时器（retransmissiontimer），它的主要功能是维护重传超时
（RTO）值。当报文使用TCP传输时，重传计时器启动，收到ACK时计时器停止。报文发送至接收到ACK的时间称
为往返时间（RTT）。对若干次时间取平均值，该值用于确定最终RTO值。在最终RTO值确定之前，确定每一次报
文传输是否有丢包发生使用重传计时器，下图说明了TCP重传过程。
当报文发送之后，但接收方尚未发送TCPACK报文，发送方假设源报文丢失并将其重传。重传之后，RTO值加倍；
如果在2倍RTO值到达之前还是没有收到ACK报文，就再次重传。如果仍然没有收到ACK，那么RTO值再次加倍。
如此持续下去，每次重传RTO都翻倍，直到收到ACK报文或发送方达到配置的最大重传次数。
2014年9月1日EMCCommunityNetwork-ECN:如果看了这个你还是不会用Wireshark，那就来找我吧（8月6日完结）
https://community.emc.com/thread/194901?start=0&tstart=02/7
最大重传次数取决于发送操作系统的配置值。默认情况下，Windows主机默认重传5次。大多数Linux系统默认最
大15次。两种操作系统都可配置。
示例如下图：
TCP重传过程发送的第一个报文如下图所示（图片不很清楚，已经尽力了）：
2014年9月1日EMCCommunityNetwork-ECN:如果看了这个你还是不会用Wireshark，那就来找我吧（8月6日完结）
https://community.emc.com/thread/194901?start=0&tstart=03/7
这是一个TCPPSH/ACK报文①，包含648字节数据②，从10.3.30.1发送至10.3.71.7。这是一个典型的数据报文。
在通常情况下，第一个报文发送之后很快会收到TCPACK报文。然而，在这个case里，第二个是重传报文。可以
在Packetlist面板里看到。Info栏清楚的标明“TCPRetransmission”，报文以黑色背景红色字体标出。下图
是PacketList面板中的重传示例（仍然不清楚，但可参见上图）：
也可以在PacketDetails和PacketBytes面板中查看来确定是否是重传报文，如下图所示：
注意此报文与源报文相同（除了IP标识和checksum字段）。要验证这一点，比较两个报文的PacketBytes①。
在PacketDetails面板，注意到重传报文在SEQ/ACKAnalysis下面有些额外的信息②。这些信息是由Wireshark提
供的而并非报文本身。SEQ/ACKAnalysis告诉我们这确实是一个重传报文，RTO值是0.206秒，此时的RTO是基于
报文1的时间增量。
检查剩下的报文会得到类似的结果，不同之处只有IP标识和checksum，以及RTO值。要使报文之间的时间间隔形
象化，在PacketList面板中查看Time栏，如下图所示。这里可以看到RTO值的翻倍增长关系。
2014年9月1日EMCCommunityNetwork-ECN:如果看了这个你还是不会用Wireshark，那就来找我吧（8月6日完结）
https://community.emc.com/thread/194901?start=0&tstart=04/7
TCP重复ACK以及快速重传：
重复ACK是指在接收方收到乱序报文时，所发出的一类TCP报文。TCP使用报文头的序列号和确认号以有效保证数
据按照发送的顺序接收和重组。
当TCP连接建立以后，握手过程中交换的一个最重要的信息是初始序列号（ISN）。一旦连接双方设定了ISN之后，
接下来发送的报文所包含的序列号增加一个数据载荷值。
假设有个主机ISN是5000，发送500字节报文至接收方。一旦报文接收之后，接收端回复一个ACK号为5500的TCP
ACK报文，基于以下公式：
SequenceNumberIn+BytesofDataReceived=AcknowledgmentNumberOut
按照上述计算结果，返回发送端的确认编号实际上是接收端希望收到的序列号。示例如下图：
数据接收方通过序列号来检查报文丢失。接收方通过追踪接收到的序列号，能够确认序列号是否乱序。当接收方收
到一个不正常的序列号，它会假设传输过程中有报文丢失。为了正确重传数据，接收方必须拥有丢失报文，所以它
发送包含有丢失报文正确序列号的ACK报文，以便发送方重传此报文。
当重传主机从发送端接收到3个重复ACK时，它会假设此报文确实在传送中丢失，并且立即发送一个快速重传。一
旦触发了快速重传，所有正在传输的其他报文都被放入队列中，直到快速重传报文发送为止。过程如下图所示：
2014年9月1日EMCCommunityNetwork-ECN:如果看了这个你还是不会用Wireshark，那就来找我吧（8月6日完结）
https://community.emc.com/thread/194901?start=0&tstart=05/7
承接上文的彩图：
本例中第一个报文如下图：
2014年9月1日EMCCommunityNetwork-ECN:如果看了这个你还是不会用Wireshark，那就来找我吧（8月6日完结）
https://community.emc.com/thread/194901?start=0&tstart=06/7
这是一个TCPACK报文，从数据接收端（172.31.136.85）发给发送端（195.81.202.68）①，确认前一个报文所
发送的数据。
此报文中的确认编号是1310973186②，应当是下一个接收报文的序列号，如下图所示：
不幸的是接收端的序列号是1310984130①，并不是所期望的值。这意味着报文在传送中丢失。接收端注意到报文
乱序，并且在第三个报文中发送重复ACK，如下图所示：
可以通过以下两种方式之一来确认这是一个重复ACK：
在PacketDetaisl面板中的Info栏。报文呈现黑色背景红色字体。
SEQ/ACKAnalysis下的PacketDeatails面板。扩展这一栏会发现报文显示为duplicateACK。接下来几个报文重复
此过程。如下图所示：
2014年9月1日EMCCommunityNetwork-ECN:如果看了这个你还是不会用Wireshark，那就来找我吧（8月6日完结）
https://community.emc.com/thread/194901?start=0&tstart=07/7
此文件中的第四个报文是发送端所发出具有错误序列号①的另一个数据块。因此，接收端发送第二个重复ACK②。
接收端又收到一个乱序报文③。从而触发了第三以及最后一个重复ACK④.
一旦发送方接收到接收方所发来的第三个重复ACK，它就会暂停所有传输报文并且重传丢失报文，下图显示了快速
重传过程：
重传报文同样可以通过PacketList面板的Info栏观察到。报文呈现黑色背景红色字体。这个报文的SEQ/ACK
Analysis截面告诉我们这可能是一个快速重传帧。（标识报文为快速重传的信息不是报文本身所包含的内容，而
是Wireshark的功能）。最后一个报文是接收到快速重传的ACK。
|
|
