网络排查案例课
杨胜辉
eBay 资深运维专家,流量系统负责人
22781 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
实战三:不用抓包就能做的网络排查篇 (2讲)
网络排查案例课
15
15
1.0x
00:00/00:00
登录|注册

10 | 窗口:TCP Window Full会影响传输效率吗?

可能是接收端处理能力不足或网络延迟等
接收端只确认部分数据,导致数据在发送端积压
方便数据比对
展示TCP Window Full历史曲线图
展示传输速度图
有数据滞留时需使用改进公式
适用于无数据滞留现象的传输
速度 = 确认数据 / 往返时间
公式:Bytes_in_flight = latest_nextSeq - latest_ack_from_receiver
在途数据等于接收窗口时提示
会影响传输速度
接收端的接收窗口小于发送端的发送能力
抓包示例文件
数据滞留现象背后的可能原因
TCP序列号和确认号的最大值
原因
定义
自定义列
TCP Stream Graphs
I/O Graph
应用场景
改进公式
速度 = 窗口 / 往返时间
计算在途数据
Wireshark提示
影响
定义
附录
思考题
数据滞留现象
Wireshark工具使用技巧
TCP传输核心公式
TCP Window Full
TCP Window Full 和传输效率

该思维导图由 AI 生成,仅供参考

你好,我是胜辉。
有时候,不少知识点在过段时间重新回看的时候,又会有新的体会和发现。比如在第 8 讲里,我们回顾了一个 MTU 造成传输失败的案例,虽然整个排查过程的步骤不算很多,但也算是 TCP 传输问题的一个缩影了。尤其是其中那个失败的 TCP 流中的一些现象,比如客户端发出的重复确认(DupAck),还有服务端启动的超时重传,都值得我们继续深挖,所以我会在后续的课程里继续这个话题。
然后在上节课里,我们还探讨了传输速度的相关知识,也初步学习了窗口的概念。最后,我们终于推导出了 TCP 传输的核心公式:速度 = 窗口 / 往返时间。这个公式,对于我们理解传输本质和排查传输问题,都有很强的指导意义。
然而,如果你足够细心的话,其实可能会对上节课里的细节有一些疑问,比如:既然接收窗口满了,那为什么当时没有看到 TCP Window Full 这种提示呢?
其实,我这边也有不少内容按住没有展开,包括核心公式的理解,我们在这节课里将有一个新的认识。另外,我也将带你继续挖掘窗口这个细分领域,这样你以后遇到跟窗口相关的问题,就知道如何破解了。

案例:TCP Window Full 是导致异地拷贝速度低的原因吗?

也是在公有云服务的时候,有个客户有这么一个需求,就是要把文件从北京机房拷贝到上海机房。但是他们发现传输速度比较慢,就做了抓包。在查看抓包文件的时候,发现 Wireshark 有很多 TCP Window Full 这样的提示,不明白这些是否跟速度慢有关系,于是找我们来协助分析。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了TCP窗口满(TCP Window Full)对传输效率的影响,并通过具体案例和技术分析为读者提供了深入理解TCP传输原理和排查传输问题的实用方法。作者首先回顾了TCP传输问题的一个案例,强调了理解窗口概念对于排查传输问题的重要性。随后,文章详细解读了TCP Window Full的含义,并通过Wireshark抓包文件展示了其具体表现。重点讨论了TCP传输中的窗口相关知识,特别是围绕TCP Window Full展开了深入的讨论,包括Wireshark工具使用技巧和窗口相关的计算方法。此外,文章还探讨了接收窗口、拥塞窗口和发送窗口之间的协调关系,以及如何利用Wireshark的Window Scaling工具来分析TCP Window Full事件。总之,本文通过具体案例和技术分析,深入探讨了TCP窗口满对传输效率的影响,为读者提供了深入理解TCP传输原理和排查传输问题的实用方法。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《网络排查案例课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(16)

  • 最新
  • 精选
  • 江山如画
    问题1: 序列号和确认号都占用 32bit,空间范围从 [0, 2**32-1], 最大是 2**32-1 问题2: 感觉接收端确认的这部分数据,就是用户进程从内核接收缓冲区中读取的数据。出现数据滞留,说明写接收缓冲区的速度大于读接收缓冲区的速度,基于此,可以从接收缓冲区的大小(接收窗口的大小),写接收缓冲区的速度,读接收缓冲区的速度三方面考虑。 从接收缓冲区的自身的大小考虑,出现数据滞留,可能是接收窗口太小了,比如 /proc/sys/net/ipv4/tcp_window_scaling 设置为了0,导致窗口上限就是 65535。 从读接收缓冲区的角度考虑,出现数据滞留,可能是用户进程读取速度太慢了,用户进程读取的时候也可能一次也读区不完,需要读取多次,这里取决于用户进程的代码逻辑,极端情况下,比如每调用一次 recv,就 sleep 一段时间。 写接收缓冲区的速度由tcp协议栈维护,取决于接收窗口大小和读接收缓冲区的速度。

    作者回复: 正确。而且你的答案非常细致了,说明你经过了深入的思考,很棒:)带着问题去学习,一直是非常高效的学习方法,比如这个问题里面,涉及缓冲区的概念、TCP窗口的概念等等。每次这样的思考,就让我们的理解,更加深入了一点~

    2022-02-11
    15
  • 静静同学
    老师,我们工作中有同事遇到了tcp window zero,我当时没参与这个任务,没去看具体的抓包数据,但好像也是接收端窗口满了的原因。请问window zero 和window full的区别是什么呢?是视角不同吗?zero是接收端视角,full是发送端视角?

    作者回复: 你好,这两个信息都是关于window的,确实很容易搞混,我这里解释一下。其实跟视角没关系。 tcp window zero是指,这个tcp报文的window字段明确就是0,也就意味着这个报文的发送方的接收缓冲区已经变成0了,另一方就会停止发送数据。当然,为了避免无限等待,另一方会有探测机制,定制发送一个零载荷的报文,让window zero这一端回复报文,从这个回复报文里读取到最新的window值。 tcp window full是指,这个报文发送后,另一端的接收窗口就满了。我举个例子,现在A和B在通信,A的一个报文被wireshark标记为tcp window full,指的是A的未被确认的数据量(也就是在途字节数)跟B的接收窗口相等。这意味着A不会发送更多报文(即使B没有发送window zero的报文),因为A知道发送出去的数据量已经“填满”了B的接收缓冲区~

    2022-03-26
    10
  • 好吃不贵
    老师好,请教下,如果是长连接,没法抓到TCP之前的SYN报文了,在抓到的报文里,window size scaling factor字段显示为-1(unknown),有什么办法解决吗?多谢。

    作者回复: 这个没有办法,ws系数只在握手包里。不过,你可以对比实际的bytes in flight,间接的推测这个系数,这就不是很准了,但是如果还有tcp window full信息出现,那就可以确定了。你试试看

    2022-02-19
    4
    2
  • Geek_4661de
    这里理解起来还是有点复杂的, 1. 首先v = 窗口 / rtt,这里的窗口是指发送窗口,又知道发送窗口 = Math.min(对端接收窗口,自身拥塞窗口),在自身拥塞窗口不是瓶颈的情况下,窗口就是指接收窗口; 2. 发送的data其实等于发送窗口值(也就是接收窗口),如果这些数据全部被ack了,那么套上正确公式```v = acked_data / rtt```也就等价于```v = 窗口 / rtt ```

    作者回复: 嗯理解起来略有点复杂,不过核心思想能理解就可以了。比如实际中遇到类似问题,想到有这么一个简单公式,可能会有一定的帮助~

    2023-09-25归属地:广东
    1
  • Henry
    文件从北京机房拷贝到上海机房。但是他们发现传输速度比较慢 接收端只确认部分数据,导致了“数据滞留”现象,这个现象背后的原因可能是什么呢? 1、确认接收端 TCP接收缓冲区大小 2、已到达tcp缓冲区的字节,为什么没有快速的被取走,属于知识盲区

    作者回复: 大的方向来说,就是接收端的性能不够用了。比如CPU过于繁忙,用在收包上的时间片就少,导致软中断(也就是负责收报文的内核线程)没有足够的CPU资源完成工作,自然导致接收不及时。 解决这类问题,一般升级下机器配置,加上接收队列优化(启用irqbalance服务,或者对网卡RSS的硬件中断号跟CPU核做硬绑定),应该可以改善很多~

    2023-06-10归属地:重庆
    1
  • 那时刻
    第一题:tcp头的序列号是32位,所以最大值是2^32。 如果短时间内发送大量数据,会有序列号回绕的问题。 第二题,接收端只确认了部分数据,可能接收程序处理慢,没有及时响应网卡缓冲区的irq,接收了部分数据。抑或网卡多队列导致接收不及时。

    作者回复: 恩差不多。第一题确切说是2^32-1 :)

    2022-02-11
    1
  • JianXu
    如果把老师这个课程里的案例都实际操作一遍,相信一定对于网络抓包分析问题达到实操水平的。对于我们部门的分布式防火墙和分布式负载均衡系统的问题排查我也相信用同样的方法可以批量的培训人。 更难或者更重要的是:怎么才能让更多的人有像老师这样的心和动力去 准备这样的培训呢?人性的善需要被激发,而激发的方法是多样的。

    作者回复: 确实是可以实操的,我也推荐大家去gitee上下载这些课件,对照我的分析过程做一遍,会比单纯看文字的收获要大得多。毕竟,抓包分析是实践性很强的技术,不动手是很难学到真本事的。 另外关于分享,我觉得每个人都有自己的独特优势,如果一个人本身乐于分享,那么做培训的过程也是令他享受的。此时我似乎明白了“享”字的双关之义,哈哈

    2022-10-15归属地:上海
  • AlohaJack
    "不知道你有没有考虑到这个问题:Bytes in flight 是指真的一直在网络上两头不着吗?一般来说,数据到了接收端,接收端就发送 ACK 确认这部分数据,然后 TCP Window 就往下降了。比如 ACK 300 字节,那么 TCP Window 就又空出来 300 字节,也就是发送端又可以新发送 300 字节了。" 老师,这里对应的图里面,t3时刻回的ack包里面,窗口应该是从0变成了300吧,图里面ack的window=1000,这里不是很直观。 t3时刻ack的包里window是300 t4时刻A收到了这个ack,才可以继续发送300B 图里面改成300可能要直观点,还是我理解有偏差

    作者回复: 如果你看一下本课的示例文件,会发现接收端在Window Full前后,receive window确实是保持不变的,对比到这个例子里就是保持在win=1000。不过这个其实并不重要。关键点在于理解bytes in flight的变化。 在t2时刻,发送端认为有1000字节的bytes in flight; 在t4时刻,由于300字节被确认了,所以发送端认为bytes in flight是1000-300=700字节。 也就是在t4-t2这一个RTT内,被确认的数据是300字节,而不是700字节或者1000字节~

    2022-08-18归属地:上海
    4
  • orange
    我们公司之前遇到一个问题,访问特别慢,排查到最后,ss命令发现是 被攻击了,8081端口的 接收队列满了,默认是128

    作者回复: 嗯新的连接进不来了:)可以调大tcp_max_syn_backlog值看看~

    2022-03-12
  • 许凯
    如果高速公路的路更宽、车速更快,那么就相当于接收窗口变得更大,车辆就能进更多,也就相当于 Bytes in flight 更大了。 老师这句话是否不妥哈?

    作者回复: 谢谢:)你是不是觉得“车速更快”的表述有点多余?

    2022-02-24
收起评论
显示
设置
留言
16
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部