wirelshark tcptrace 识别

参考:http://packetbomb.com/understanding-the-tcptrace-time-sequence-graph-in-wireshark/

 

cwnd 查看方式

Congestion control 是发送端通过算法得到的一个动态变量,会实时调整,并不会体现在协议的传输数据中。所以要看这个,必须在发送端的机器上看。

在 Linux 中可以使用 ss -i 选项将 TCP 连接的参数都打印出来。

这里展示的单位是 TCP MSS. 即实际大小是 1460bytes * 10.

Wireshark 分析

Wireshark 提供了非常实用的统计功能,可以让你一眼就能看出当前的瓶颈是发生在了哪里。

这里面有 3 条线,含义如下:

客户端接收窗口的那条线和TCP数据段那条线之间的距离就是滑动窗口的大小

除此之外,另外还有两种线:

需要始终记住的是 Y 轴是 Sequence Number,红色的线表示 SACK 的线表示这一段 Sequence Number 我已经收到了,然后配合黄色线表示 ACK 过的 Sequence Number,那么发送端就会知道,在中间这段空挡,包丢了,红色线和黄色线纵向的空白,是没有被 ACK 的包。所以,需要重新传输。而蓝色的线就是表示又重新传输了一遍。

学会了看这些图,我们可以认识几种常见的 pattern:

丢包

很多红色 SACK,说明接收端那边重复在说:中间有一个包我没有收到,中间有一个包我没有收到。

吞吐受到接收端 window size 限制

从这个图可以看出,黄色的线(接收端一 ACK)一上升,蓝色就跟着上升(发送端就开始发),直到填满绿色的线(window size)。说明网络并不是瓶颈,可以调大接收端的 buffer size.

吞吐受到发送端 Buffer 的限制

为什么发送端也会限制带宽呢?如果你要榨干线路上所有的性能,那么就要了解一个概念:BDP

BDP = bandwidth * RTT

为什么这个概念很重要呢?因为 TCP 是一个可靠的协议,这就意味着它要保证发送的每一个 byte 都被 ACK,并不是发送出去就可以了。所以 sender buffer 的作用,不光是程序将要发送的内容传送给 Kernel,Kernel 要在 buffer 中存储这些数据,直到被接收端 ACK。

Buffer 需要多大才会不成为瓶颈呢?就是足够大能存放住所有未被 ACK 的数据。那么没有被 ACK 的数据最大是多大呢?其实就是 BDP。比如带宽是 10Mib/s, RTT 是 1s,那么 BDP 就是 10Mib/s * 1s = 10Mib,这个连接上最多可能有 10Mib 的数据没有被 ACK,发送端的容量必须比这个大才行(如果你要完全利用网络资源的话)。

下面是一个 Buffer 不足够大的例子:

可以看到绿线(接收端的 window size)远没有达到瓶颈,但是发送端的模式不是一直发, 而是发一段停一段。就说明发送端的 buffer 已经满了,这时候 Kernel block 住了 App,必须等这些数据被 ACK 了,才能让 App 继续往 buffer 中塞入数据。

那么怎么和下面要介绍的被 cwnd 限制了区分开呢?两种模式比较相似。

可以看一开始蓝色线的垂直距离很短,后面逐渐变长,说明 cwnd 在变大,然后变大到一定的成都不变了。说明 cwnd 没成为瓶颈。

在 Wireshark 中可以切换到 Window scaling 图。

可以发现 cwnd 并没有收缩回去。

在 window scaling 图中,绿色的是 Rcv Win, 蓝色的是 Bytes out. 蓝色线每次发送数据 burst 到某一个最高点就不再上升了。但是上升的过程也没有下降过,“没有下降过”就可以说明,cwnd 没有下降过,即 cwnd 没有成为瓶颈。

吞吐受到网络质量限制

从这张图中可以看出,接收端的 window size 远远不是瓶颈,还有很多空闲。但是发送端不会一直发直到填满接收端的 buffer。

放大可以看出,中间有很多丢包和重传,这会让发送端认为网络质量不好,会谨慎发送数据,想避免造成网络拥塞。发送端每次只发送一点点数据,发送的模式是发一点,停一点,然后再发一点,而不是一直发。这也说明很有可能是 cwnd 太小了,受到了拥塞控制算法的限制。

下面这种模式是一种更加典型的因为丢包导致带宽很小的问题:

从这个图中我们可以发现以下信息:

  1. 在这个链接中,Flow Control(即 Linux 中的 tcp buffer 参数,绿色线)远远没有达到瓶颈;
  2. 图中有很多红色线,表示 SACK,说明图中有很多丢包;
  3. 蓝色线表示发送的数据,发送的模式是,每隔 0.23s 就发送一波,然后暂停,等 0.23s 然后再发送一波。蓝色线在 Y 轴上表示一次性发送的数据,可以看到,每一段的纵向长度在不断减少。从中,我们可以得到以下信息:
    1. 0.23s 是物理上的延迟;
    2. 蓝色线没有一直发送,而是发送,暂停,发送,暂停,是因为拥塞控制算法的窗口(cwnd)变小了,每次发送很快填满窗口,等接收端(0.23s之后)收到了,再继续发送;
    3. 并且蓝色线的纵向距离每一波都在减少,说明这个窗口在每次发生丢包之后都在变小(减为一半)。

完美的 TCP 连接

最后放一张完美的 TCP 连接(长肥管道),发送端一直稳定的发,没有填满 receiver window,cwnd 也没有限制发送速率。这个完美连接的带宽是 10Mib/s,RTT < 1ms, 可以看到2s发送的 Sequence nunber 是 2500000,计算可以得到 2500000 / 1024 / 1024 * 8 = 19.07 Mib/s,正好达到了带宽。

本文中用到的抓包文件可以从这里下载(credit: https://www.youtube.com/watch?v=yUmACeSmT7o):

  1. https://www.cloudshark.org/captures/f5eb7c033728
  2. https://www.cloudshark.org/captures/c967765aef38

其他的一些参考资料:

  1. https://www.stackpath.com/edge-academy/what-is-cwnd-and-rwnd/
  2. https://www.baeldung.com/cs/tcp-flow-control-vs-congestion-control
  3. https://www.cs.cornell.edu/courses/cs4450/2020sp/lecture21-congestion-control.pdf
  4. https://www.mi.fu-berlin.de/inf/groups/ag-tech/teaching/2011-12_WS/L_19531_Telematics/08_Transport_Layer.pdf
  5. https://wiki.aalto.fi/download/attachments/69901948/TCP-CongestionControlFinal.pdf
  6. https://paulgrevink.wordpress.com/2017/09/08/about-long-fat-networks-and-tcp-tuning/

 

posted @   codestacklinuxer  阅读(475)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
点击右上角即可分享
微信分享提示