LWIP协议栈TCP服务器send接口阻塞问题排查咨询

看起来你碰到了LWIP TCP服务器在send(socket_num, (const void *) msg, len, 0)调用上阻塞的棘手问题，而且复杂内网环境下1小时内就能复现，直连PC却要很久才会出现，确实挺头疼的。我来帮你梳理下可能的原因和排查方向：

核心原理先明确 #

首先要知道，LWIP的send函数默认是阻塞模式（除非你给socket设置了O_NONBLOCK非阻塞标志）。当TCP发送缓冲区被占满，或者对方（PC客户端）的TCP接收窗口收缩到0/很小的时候，send就会阻塞等待，直到有缓冲区空间或者对方窗口打开。复杂内网更容易触发，大概率和网络环境的丢包、延迟抖动、窗口交互异常有关。

可能的具体原因分析 #

1. TCP接收窗口收缩/零窗口死锁 #

复杂内网里的交换机、路由可能存在丢包或者延迟波动大的情况，容易引发以下问题：

• PC客户端的应用如果处理数据不及时（比如内网环境下PC资源被其他进程占用），其TCP接收缓冲区会被填满，此时客户端会给服务器发送窗口大小为0的报文，告诉服务器“我暂时收不下数据了”。
• 如果这个零窗口报文丢了，或者服务器后续没收到客户端的窗口更新报文，服务器的TCP层就会一直等待，导致send调用阻塞。
  看你提供的抓包片段，最后一条是服务器的ACK报文，建议查看后续的完整抓包：有没有客户端发送的窗口更新？服务器有没有重复发送之前的报文（重传）？如果服务器后续没有新的发送动作，很大概率是在等客户端的窗口打开。

2. 网络丢包引发的拥塞窗口收缩/重传等待 #

内网环境的丢包会触发TCP的拥塞控制机制：

• 当服务器发送的报文丢包后，LWIP会启动重传，如果重传多次失败，TCP的拥塞窗口会被急剧缩小，导致后续能发送的数据量变得很小，发送缓冲区很快就被占满，send自然就阻塞了。
• 如果LWIP的重传配置（比如TCP_MAXRTX最大重传次数、TCP_TIMEOUT超时时间）设置得太保守，服务器会花很长时间等待重传结果，期间send就会一直阻塞。

3. LWIP发送缓冲区配置过小 #

如果你的LWIP配置里TCP_SND_BUF（TCP发送缓冲区大小）或者TCP_SND_QUEUELEN（发送队列长度）设置得太小，在网络状况不佳时，数据发送速度变慢，缓冲区很容易被填满，直接导致send阻塞。而直连PC时网络延迟低、丢包少，数据能快速被发送出去，缓冲区不容易满，所以很久才会复现问题。

4. 应用层的交互逻辑问题 #

比如服务器端有没有及时处理客户端的ACK？或者有没有出现“发送速率远大于客户端接收速率”的情况？在复杂内网下，客户端的接收速率可能因为网络问题下降，这种速率不匹配的情况会更快导致发送缓冲区溢出，触发send阻塞。

排查建议 #

• 确认socket的阻塞模式：调用fcntl(socket_num, F_GETFL)查看是否带有O_NONBLOCK标志，如果是阻塞模式，那缓冲区满或窗口不足时阻塞是正常行为，可以考虑改为非阻塞模式，配合select/poll来管理发送时机。
• 调大发送缓冲区配置：尝试增大TCP_SND_BUF（建议设置为TCP_MSS的整数倍，比如4*MSS），同时调整TCP_SND_QUEUELEN，看看是否能缓解阻塞问题。
• 抓完整的故障链路包：从正常发送到阻塞的整个过程都要抓到，重点关注客户端的Win（窗口大小）字段变化，以及服务器的重传行为，这是定位问题的关键。
• 检查LWIP的TCP参数：查看TCP_MAXRTX、TCP_TIMEOUT等重传相关配置，是否因为等待时间太长导致send长期阻塞。
• 排查PC端应用状态：在复杂内网环境下，观察PC端的CPU、内存占用情况，确认客户端应用是否及时调用recv接收数据，有没有卡顿、未及时处理的情况。

备注：内容来源于stack exchange，提问作者user100079