0%

[转]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 字节。如果要归纳出一条公式,可以表示成:

1
在途字节数 = Seq + Len − Ack

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

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

图5

欢迎关注我的其它发布渠道