1. LWIP TCP数据发送机制的核心原理
在嵌入式网络开发中，LWIP作为轻量级TCP/IP协议栈被广泛应用。很多开发者在使用LWIP的raw API时会遇到一个典型问题：明明发送数据流程看起来没问题，但通信一段时间后却无法继续接收数据。这往往与TCP滑动窗口机制和tcp_recved函数的调用时机密切相关。
TCP协议通过滑动窗口实现流量控制，这个窗口就像快递柜的格子间。当接收方收到数据包时，窗口会相应缩小（相当于格子被占用）；只有当应用层处理完数据后，才需要通过tcp_recved通知协议栈释放窗口空间（相当于腾出空格子）。LWIP的特别之处在于，使用raw API时需要开发者手动管理这个过程，而socket/netconn等高级API会自动处理。
我曾在一个智能家居项目中踩过坑：设备作为TCP服务器接收控制指令时，最初把tcp_recved放在发送回调函数中调用。测试时发现，如果客户端连续发送10条指令后停止发送，服务器就无法接收第11条指令。这就是典型的接收窗口耗尽现象——相当于快递柜所有格子都被占满，新的包裹无法投递。
2. tcp_recved函数的正确调用时机
2.1 常见错误实践分析
网上很多示例代码（包括某些开发板提供的tcp_echoserver）存在一个典型误区：在tcp_sent发送回调中调用tcp_recved。这种做法在echo服务（收到数据立即原样返回）场景下看似可行，但在实际业务中会引发严重问题。
这种错误用法的本质是混淆了发送窗口和接收窗口的管理。当我们在发送回调中调用tcp_recved时，只有在发送数据时才会释放接收窗口。如果应用长时间只收不发（比如监控设备持续接收控制指令），接收窗口就会逐渐收缩直至归零。这就像只在你寄出包裹时才清理快递柜，显然不符合实际需求。
2.2 正确调用模式详解
正确的做法应该遵循"谁消费，谁释放"原则。具体操作要点包括：
- 在tcp_recv回调中，当应用层完成数据处理后立即调用tcp_recved
- 调用时要传入实际处理的数据长度（pbuf->tot_len）
- 对于分片数据包，需要等所有分片处理完毕后再统一通知
这里有个实际项目中的优化技巧：如果处理数据需要较长时间（比如要写入Flash），可以先立即调用tcp_recved再处理数