一个单向的TCP数据流从数据发送端到数据接收端之间,会经历什么?我的答案是,可能会有大不同!
通过抓包来看那是最真实的情况,首先通告一下,发送端的拥塞窗口的值为60个MSS,这个是在抓包中看不出来的。我们先看发送端的情况,且看下面的抓包分析:
如果正常的话,比如两个端主机,即发送端和接收端由网线直连,那么可以预料,接收端将按照同样的特征接收数据包,然而,接收端真实的抓包如下:
非常简单且直接!数据在中间路径被整形了呗...如此简单的结论关键在于你是否注意细节。我们先来看数据发送端抓包的”Seq-time图“:
发送端突发一大坨,接收端却匀速接收,数据包在网络介质上不会彼此掉队而在时间上拉开距离,因为它们在介质中速率一致,除非遇到整形设备!这就是我所谓的”非时间延展设备“,它们对数据包具有整形的作用,在当初的文章中,我没有给出任何细节,如今我也不会给出更多的细节,但是比前述要详细一些,如下图所示:
理解上了上述整形设备的运作原理,我们就会知道,事实上对比《 流量整形,延迟以及ACK丢失对TCP发送时序的影响》,如果我们把这个整形设备看作是数据发送端的一部分,即它的发送缓存,那么就会将发送端的抓包和接收端的抓包对应起来了,此时,我所谓的发送端就是上图整形设备中的接口A。只要整形设备队列不溢出,那么发送端将在不丢包的情况下持续保持inflight报文数量为通告窗口的大小,超出整形设备出包能力的部分将被cache到队列里。
值得注意的是,由于TCP的ACK时钟自调节功能,这个队列不会无限增长,在TCP发送端自己认为已经发送了通告窗口大小的数据之后,其是否可以继续发送数据取决于有没有数据从接收端被清空,即有没有收到接收端的ACK,因此后续的情况将会是一个数据段守恒的循环过程,即ACK可一段N大小的数据,发送端方可再发一段N大小的数据,这就是为什发送端和接收端在稳定之后都是两个两个MSS大小发送接收的原因:
还记得TC的位置吗?还记得TC的位置和TCP位置以及网卡位置之间的关系吗?还记得我曾经用tcpprobe来挖掘TCP层的inflight和网卡inflight之间的关系吗?
通过抓包来看那是最真实的情况,首先通告一下,发送端的拥塞窗口的值为60个MSS,这个是在抓包中看不出来的。我们先看发送端的情况,且看下面的抓包分析:
如果正常的话,比如两个端主机,即发送端和接收端由网线直连,那么可以预料,接收端将按照同样的特征接收数据包,然而,接收端真实的抓包如下:
非常简单且直接!数据在中间路径被整形了呗...如此简单的结论关键在于你是否注意细节。我们先来看数据发送端抓包的”Seq-time图“:
发送端突发一大坨,接收端却匀速接收,数据包在网络介质上不会彼此掉队而在时间上拉开距离,因为它们在介质中速率一致,除非遇到整形设备!这就是我所谓的”非时间延展设备“,它们对数据包具有整形的作用,在当初的文章中,我没有给出任何细节,如今我也不会给出更多的细节,但是比前述要详细一些,如下图所示:
理解上了上述整形设备的运作原理,我们就会知道,事实上对比《 流量整形,延迟以及ACK丢失对TCP发送时序的影响》,如果我们把这个整形设备看作是数据发送端的一部分,即它的发送缓存,那么就会将发送端的抓包和接收端的抓包对应起来了,此时,我所谓的发送端就是上图整形设备中的接口A。只要整形设备队列不溢出,那么发送端将在不丢包的情况下持续保持inflight报文数量为通告窗口的大小,超出整形设备出包能力的部分将被cache到队列里。
值得注意的是,由于TCP的ACK时钟自调节功能,这个队列不会无限增长,在TCP发送端自己认为已经发送了通告窗口大小的数据之后,其是否可以继续发送数据取决于有没有数据从接收端被清空,即有没有收到接收端的ACK,因此后续的情况将会是一个数据段守恒的循环过程,即ACK可一段N大小的数据,发送端方可再发一段N大小的数据,这就是为什发送端和接收端在稳定之后都是两个两个MSS大小发送接收的原因:
还记得TC的位置吗?还记得TC的位置和TCP位置以及网卡位置之间的关系吗?还记得我曾经用tcpprobe来挖掘TCP层的inflight和网卡inflight之间的关系吗?