10 | 窗口：TCP Window Full会影响传输效率吗？
该思维导图由 AI 生成，仅供参考
案例：TCP Window Full 是导致异地拷贝速度低的原因吗？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了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-1115
静静同学老师，我们工作中有同事遇到了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-2610
好吃不贵老师好，请教下，如果是长连接，没法抓到TCP之前的SYN报文了，在抓到的报文里，window size scaling factor字段显示为-1(unknown)，有什么办法解决吗？多谢。作者回复: 这个没有办法，ws系数只在握手包里。不过，你可以对比实际的bytes in flight，间接的推测这个系数，这就不是很准了，但是如果还有tcp window full信息出现，那就可以确定了。你试试看
2022-02-1942- 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-111
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
