当接收方rwnd缩为0时，tcpdump可见连续ACK报文：源/目的端口相同、序列号不变、仅ACK标志置位、Window Size恒为0，且ack number不变、时间间隔固定。
滑动窗口为0时tcpdump能看到什么现象
当接收方通告窗口（rwnd）缩到0，发送方会停止发新数据，只发keepalive探测包。此时用tcpdump抓包，最典型的信号是：连续出现源端口相同、目的端口相同、序列号不变、只有ACK标志位且window size value字段恒为0的报文。
注意不是所有ACK都代表卡住——必须同时满足：ack number不变（说明对方没消费数据）、window size持续为0、时间间隔固定（默认2小时，但Linux可通过/proc/sys/net/ipv4/tcp_keepalive_time调整）。
常见误判点：
- 把重传超时（RTO）后的
retransmission当成窗口为0——重传包的seq会变，且window通常非0 - 忽略Nagle算法影响——小包合并可能掩盖窗口更新延迟，建议测试时关掉
TCP_NODELAY - 服务端收包后未调用
recv()或read()，缓冲区满却不通知应用层，导致内核无法更新窗口
如何确认是应用层未读取而非内核缓冲区耗尽
关键看/proc/net/snmp和/proc/net/netstat中的TCP指标。执行grep -i "RT" /proc/net/snmp，重点查TCPRcvQDrop（因接收队列满被丢弃的包数）；再查netstat -s | grep -A 5 "Tcp:"里的prune和drop计数。
立即学习“C++免费学习笔记（深入）”；
如果TCPRcvQDrop == 0，但连接僵死，基本可排除内核接收队列溢出，问题在应用层没调用recv()；如果该值持续增长，说明应用读得太慢或阻塞，内核已开始丢包。
实操建议：
- 用
ss -i查看单个连接的rwnd、rcv_ssthresh、rcv_space，对比rcv_wnd是否真为0 - 检查应用是否在
recv()前做了长耗时操作（如锁竞争、磁盘IO），导致接收线程卡住 - 对多线程服务，确认
socket是否被错误地跨线程共享——一个线程recv()阻塞，其他线程无法读取同一fd
setsockopt(TCP_QUICKACK)能否缓解窗口为0僵死
不能。TCP_QUICKACK只影响ACK的延迟发送策略（禁用Delayed ACK），它让ACK更快发出，但不改变窗口通告逻辑。窗口大小由接收缓冲区剩余空间决定，而recv()调用才真正释放缓冲区空间。
真正有效的是控制接收行为本身：
- 确保
recv()调用频率足够高，比如用epoll_wait()监听EPOLLIN后立刻读完所有可用数据，而不是只读一次就返回 - 避免在
recv()后做耗时处理——应把数据拷贝到业务队列，让IO线程尽快回到循环 - 设置合理的
SOMAXCONN和SO_RCVBUF，但注意SO_RCVBUF设太大反而延长窗口更新周期（内核按比例缩放通告窗口）
如何用gdb实时观察socket接收缓冲区状态
Linux内核不直接暴露socket缓冲区水位给用户态，但可以通过gdb附加到进程，读取struct sock内部字段。前提是程序未strip符号，且内核开启CONFIG_INET_DIAG（通常默认开启）。
步骤如下：
- 用
lsof -i :PORT找到进程PID，gdb -p PID - 执行
call (int)tcp_ioctl($rdi, SIOCINQ, (void*)&$rax)（x86_64下$rdi常存sock指针），$rax将返回当前可读字节数 - 更可靠方式是用
cat /proc/PID/fdinfo/FD_NUM，其中st_size字段即为接收队列字节数（仅Linux 4.10+）
注意：gdb注入可能暂停线程，观察到的只是瞬时快照；若看到st_size长期接近SO_RCVBUF上限，说明应用消费严重滞后。
真正难排查的点往往不在协议栈，而在应用层对socket fd的生命周期管理——比如worker线程崩溃后未关闭fd，残留连接持续占用缓冲区却无人读取。这种场景下，ss -tni看到的rwnd=0只是表象，根因是资源泄漏。
