林沛满-TCP之在途字节数

本文整理自：《Wireshark网络分析的艺术 第1版》
作者：林沛满 著
出版时间：2016-02

我一直谨记斯蒂芬·霍金的金玉良言—每写一道数学公式就会失去一半读者。不过为了深度分析网络包，有时候是不得不计算的，好在小学一年级的加减法就够用了。

网络的承载量就是一个需要计算的值。怎样理解这个概念呢？如图 1 所示，一架波音 747 能够承载上万个小包裹，而一架无人机只能承载一个，这就反映了它们不同的承载量。换个角度，也可以说承载量就是处于运输工具中的货物量，即已经从源仓库发货，但还没有到达目的地的包裹数量。

图1

和运输机类似，网络承载量也可以用已经发送出去，但尚未被确认的字节数来表示。在英文技术文档中，形象地用“bytes in flight”来描述它，我觉得用“在途字节数”来翻译最好。

飞机如果超载了，是会发生严重事故的。而在途字节数如果超过网络的承载能力，也会丢包重传，这就是我们需要计算它的原因。怎么计算呢？假如网络上只有一个 TCP 连接在通信，那么还可以通过带宽和延迟来计算最多能承载多少在途字节数。而实际环境往往如图 2 所示，同一条网络路径是由多台主机之间共享的，根本不知道多少比例的带宽是分配给某个 TCP 连接。这时候就需要用到网络神器 Wireshark 来分析了。

图2

分析之前要先抓包。应该在哪一端抓呢？我们先两边都尝试一下。上文《书上错了吗？》已经交代过，网络延迟会导致同样的网络包在两端体现出不同的顺序，并用下面的图 3 演示

图3

我在图 3 的服务器上随机挑选一个时间点并标志为 T1。由于服务器在该点之前收到 8 号包并立即回复了“Ack 9”（表示 9 号之前的包都收到了），所以在途字节数为 0。也就是说，在数据接收方抓的包里是看不到在途字节数的，没有分析意义。

接着我在图 3 的客户端随机挑选一个时间点并标志为 T2，由于在该时间点之前 10 号包已经发出去，但收到的“Ack 7”只表示 7 号之前的包都收到了，也即意味着 7、8、9、10 号包都还没有确认，所以在途字节数就是这 4 个包所携带的数据量。这说明在数据发送方抓到的包才能用来分析在途字节数。

从模型图中理解了原理，接下来就可以用 Wireshark 来分析真实的包了。图 4
是在客户端（数据发送方）抓到的，如果我们想知道第 0.400000 秒时的在途字节数，应该如何计算呢？

图4

在该时间点之前客户端发送的是 10 号包，即“Seq=265248，Len=180”字节，表示序号在 265248+180=265428 之前的字节已经发送出去了。而第 0.400000 秒之前服务器的 Ack 为 3284，表示序号在 3284 之前的字节已经收到了。那么在途字节数就是 265428−3284=262144 字节。如果要归纳出一条公式，可以表示成：

在途字节数 = Seq + Len − Ack 

其中 Seq 和 Len 是来自上一个数据发送方的包，而 Ack 则来自上一个数据接收方的包。我们再拿第 0.500000 秒来练习一下，套用公式可以算出在途字节数应该是 266816+361−5033=262144，与第 0.400000 秒的一样多。

我们也可以使用Wireshark提供的功能来查看在途字节数,这样就不用我们手动来计算了。

图5