从一个TCP抓包的例子看流量整形-概述

一个单向的TCP数据流从数据发送端到数据接收端之间，会经历什么？我的答案是，可能会有大不同！

通过抓包来看那是最真实的情况，首先通告一下，发送端的拥塞窗口的值为60个MSS，这个是在抓包中看不出来的。我们先看发送端的情况，且看下面的抓包分析：

发送端在既不超越拥塞窗口也不超越通告窗口的前提下持续发送数据段，直到达到二者之间的最小值，即接收端的通告窗口大小：

注意问题，接收端也会这样吗？？
        如果正常的话，比如两个端主机，即发送端和接收端由网线直连，那么可以预料，接收端将按照同样的特征接收数据包，然而，接收端真实的抓包如下：

这是为什么？
        非常简单且直接！数据在中间路径被整形了呗...如此简单的结论关键在于你是否注意细节。我们先来看数据发送端抓包的”Seq-time图“：

然后我们放大来看，只需注意最初的部分即可：

可是接收端是不是这样子呢？一看便知：

同样，我们放大来看，看出端倪：

明白了吗？
        发送端突发一大坨，接收端却匀速接收，数据包在网络介质上不会彼此掉队而在时间上拉开距离，因为它们在介质中速率一致，除非遇到整形设备！这就是我所谓的”非时间延展设备“，它们对数据包具有整形的作用，在当初的文章中，我没有给出任何细节，如今我也不会给出更多的细节，但是比前述要详细一些，如下图所示：

关于流量整形，还可以看我另外的一篇文章《 流量整形，延迟以及ACK丢失对TCP发送时序的影响》。
        理解上了上述整形设备的运作原理，我们就会知道，事实上对比《 流量整形，延迟以及ACK丢失对TCP发送时序的影响》，如果我们把这个整形设备看作是数据发送端的一部分，即它的发送缓存，那么就会将发送端的抓包和接收端的抓包对应起来了，此时，我所谓的发送端就是上图整形设备中的接口A。只要整形设备队列不溢出，那么发送端将在不丢包的情况下持续保持inflight报文数量为通告窗口的大小，超出整形设备出包能力的部分将被cache到队列里。
        值得注意的是，由于TCP的ACK时钟自调节功能，这个队列不会无限增长，在TCP发送端自己认为已经发送了通告窗口大小的数据之后，其是否可以继续发送数据取决于有没有数据从接收端被清空，即有没有收到接收端的ACK，因此后续的情况将会是一个数据段守恒的循环过程，即ACK可一段N大小的数据，发送端方可再发一段N大小的数据，这就是为什发送端和接收端在稳定之后都是两个两个MSS大小发送接收的原因：

之所以是两个两个发送和被ACK，那是因为接收端启用了Delay ACK！
        还记得TC的位置吗？还记得TC的位置和TCP位置以及网卡位置之间的关系吗？还记得我曾经用tcpprobe来挖掘TCP层的inflight和网卡inflight之间的关系吗？