作为网络管理员,很多时间必然会耗费在修复慢速服务器和其他终端。但用户感到网络运行缓慢并不意味着就是网络问题。
解决网络性能问题,首先从TCP错误恢复功能(TCP重传与重复ACK)和流控功能说起。之后阐述如何发现网络慢速之源。最后,对网络各组成部分上的数据流进行概况分析。这几张内容将会帮助读者识别,诊断,以及排查慢速网络。
接下来的内容,较多是黑白图片了。虽然看起来有点不爽,但还是很值得一看。
TCP的错误恢复功能是定位,诊断及修复网络延时的最佳工具。
延时可以在单程也可以往返方向测量。高延时是网络管理员的头号大敌。本节我们讨论TCP高延时是如何导致序列号和确认号乱序的。
主机报文重传是TCP最基本的错误恢复功能,它的目的是防止报文丢失。
报文丢失的可能因素有很多种,包括应用故障,路由设备过载,或暂时的服务宕机。报文级别速度是很高的,而通常报文丢失是暂时的,因此TCP能够发现和恢复报文丢失显得尤为重要。
决定报文是否有必要重传的主要机制是重传计时器(retransmission timer),它的主要功能是维护重传超时(RTO)值。当报文使用TCP传输时,重传计时器启动,收到ACK时计时器停止。报文发送至接收到ACK的时间称为往返时间(RTT)。对若干次时间取平均值,该值用于确定最终RTO值。在最终RTO值确定之前,确定每一次报文传输是否有丢包发生使用重传计时器,下图说明了TCP重传过程。
最大重传次数取决于发送操作系统的配置值。默认情况下,Windows主机默认重传5次。大多数Linux系统默认最大15次。两种操作系统都可配置。
示例如下图:
在通常情况下,第一个报文发送之后很快会收到TCP ACK报文。然而,在这个case里,第二个是重传报文。可以在Packet list面板里看到。Info栏清楚的标明“TCP Retransmission”,报文以黑色背景红色字体标出。下图是Packet List面板中的重传示例(仍然不清楚,但可参见上图):
在Packet Details面板,注意到重传报文在SEQ/ACK Analysis下面有些额外的信息②。这些信息是由Wireshark提供的而并非报文本身。SEQ/ACK Analysis告诉我们这确实是一个重传报文,RTO值是0.206秒,此时的RTO是基于报文1的时间增量。
检查剩下的报文会得到类似的结果,不同之处只有IP标识和checksum,以及RTO值。要使报文之间的时间间隔形象化,在Packet List面板中查看Time栏,如下图所示。这里可以看到RTO值的翻倍增长关系。
重复ACK是指在接收方收到乱序报文时,所发出的一类TCP报文。TCP使用报文头的序列号和确认号以有效保证数据按照发送的顺序接收和重组。
当TCP连接建立以后,握手过程中交换的一个最重要的信息是初始序列号(ISN)。一旦连接双方设定了ISN之后,接下来发送的报文所包含的序列号增加一个数据载荷值。
假设有个主机ISN是5000,发送500字节报文至接收方。一旦报文接收之后,接收端回复一个ACK号为5500的TCP ACK报文,基于以下公式:
Sequence Number In + Bytes of Data Received = Acknowledgment Number Out
按照上述计算结果,返回发送端的确认编号实际上是接收端希望收到的序列号。示例如下图:
当重传主机从发送端接收到3个重复ACK时,它会假设此报文确实在传送中丢失,并且立即发送一个快速重传。一旦触发了快速重传,所有正在传输的其他报文都被放入队列中,直到快速重传报文发送为止。过程如下图所示:
此报文中的确认编号是1310973186②,应当是下一个接收报文的序列号,如下图所示:
SEQ/ACK Analysis下的Packet Deatails面板。扩展这一栏会发现报文显示为duplicate ACK。接下来几个报文重复此过程。如下图所示:
一旦发送方接收到接收方所发来的第三个重复ACK,它就会暂停所有传输报文并且重传丢失报文,下图显示了快速重传过程:
本文转自微信公众号:EMC易安信中国技术社区
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞1
添加新评论0 条评论