江山如画2022-02-11问题1: 序列号和确认号都占用 32bit，空间范围从 [0, 2**32-1], 最大是 2**32-1 问题2: 感觉接收端确认的这部分数据，就是用户进程从内核接收缓冲区中读取的数据。出现数据滞留，说明写接收缓冲区的速度大于读接收缓冲区的速度，基于此，可以从接收缓冲区的大小(接收窗口的大小)，写接收缓冲区的速度，读接收缓冲区的速度三方面考虑。 从接收缓冲区的自身的大小考虑，出现数据滞留，可能是接收窗口太小了，比如 /proc/sys/net/ipv4/tcp_window_scaling 设置为了0，导致窗口上限就是 65535。 从读接收缓冲区的角度考虑，出现数据滞留，可能是用户进程读取速度太慢了，用户进程读取的时候也可能一次也读区不完，需要读取多次，这里取决于用户进程的代码逻辑，极端情况下，比如每调用一次 recv，就 sleep 一段时间。 写接收缓冲区的速度由tcp协议栈维护，取决于接收窗口大小和读接收缓冲区的速度。作者回复: 正确。而且你的答案非常细致了，说明你经过了深入的思考，很棒：）带着问题去学习，一直是非常高效的学习方法，比如这个问题里面，涉及缓冲区的概念、TCP窗口的概念等等。每次这样的思考，就让我们的理解，更加深入了一点~
14
静静同学2022-03-26老师，我们工作中有同事遇到了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的接收缓冲区~
10
好吃不贵2022-02-19老师好，请教下，如果是长连接，没法抓到TCP之前的SYN报文了，在抓到的报文里，window size scaling factor字段显示为-1(unknown)，有什么办法解决吗？多谢。作者回复: 这个没有办法，ws系数只在握手包里。不过，你可以对比实际的bytes in flight，间接的推测这个系数，这就不是很准了，但是如果还有tcp window full信息出现，那就可以确定了。你试试看
共 4 条评论2
那时刻
2022-02-11第一题：tcp头的序列号是32位，所以最大值是2^32。 如果短时间内发送大量数据，会有序列号回绕的问题。 第二题，接收端只确认了部分数据，可能接收程序处理慢，没有及时响应网卡缓冲区的irq，接收了部分数据。抑或网卡多队列导致接收不及时。作者回复: 恩差不多。第一题确切说是2^32-1 ：）
1
JianXu2022-10-15 来自上海如果把老师这个课程里的案例都实际操作一遍，相信一定对于网络抓包分析问题达到实操水平的。对于我们部门的分布式防火墙和分布式负载均衡系统的问题排查我也相信用同样的方法可以批量的培训人。 更难或者更重要的是：怎么才能让更多的人有像老师这样的心和动力去 准备这样的培训呢？人性的善需要被激发，而激发的方法是多样的。作者回复: 确实是可以实操的，我也推荐大家去gitee上下载这些课件，对照我的分析过程做一遍，会比单纯看文字的收获要大得多。毕竟，抓包分析是实践性很强的技术，不动手是很难学到真本事的。 另外关于分享，我觉得每个人都有自己的独特优势，如果一个人本身乐于分享，那么做培训的过程也是令他享受的。此时我似乎明白了“享”字的双关之义，哈哈
AlohaJack2022-08-18 来自上海"不知道你有没有考虑到这个问题：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字节~
共 4 条评论
orange2022-03-12我们公司之前遇到一个问题，访问特别慢，排查到最后，ss命令发现是 被攻击了，8081端口的 接收队列满了，默认是128作者回复: 嗯新的连接进不来了：）可以调大tcp_max_syn_backlog值看看~
许凯2022-02-24如果高速公路的路更宽、车速更快，那么就相当于接收窗口变得更大，车辆就能进更多，也就相当于 Bytes in flight 更大了。 老师这句话是否不妥哈？作者回复: 谢谢：）你是不是觉得“车速更快”的表述有点多余？
宝仔2022-02-15老师我想问下，你这个案例里用scp从北京机房拷贝到上海机房，为什么服务端数据确认这么慢，这个你们后来查到是为啥吗作者回复: 您好，当时我们作为云服务商，帮助排查了云平台网络，确认没有这方面问题，后来客户自己去检查操作系统方面的原因了，更近一步的信息后来就没有沟通了。我这里介绍这个案例主要想让大家学会如何做网络分析，特别是传输速度和窗口、确认等这些关键环节的关系。 就那个主机的原因来说，可能有一定的特殊性，而网络排查过程相对来说比较普适，希望对大家平时的工作有帮助：）
- Geek__e15575f5b6ec2022-02-13(2) 有时候发送的时候拆包了 接收端接收的时候 需要完整数据 所以只能等到后续的数据
作者回复: 嗯如果有做IP分片，确实要在接收端组装的~