ESP8266 lwIP v2模式下TCP_write分片异常原因及配置咨询

你碰到的现象不属于TCP分片异常，是ESP8266平台lwIP协议栈TCP发送流控的正常表现：

• TCP.write()的逻辑不是直接把数据推到网络链路，而是先将数据拷贝到lwIP内核为每个TCP连接分配的发送缓冲区中，函数返回值代表成功写入内核缓冲的字节数。当内核发送缓冲被已发送但未收到对端ACK的数据占满、或对端通告的接收窗口收缩时，剩余可写入空间不足，就会出现返回值小于传入packetSize的情况；如果可用空间为0，返回值就是0。等待数次重试后，对端ACK返回、内核释放已确认数据的缓冲空间，发送功能就会自动恢复。
• 你观测到的首次返回650的数值没有特殊指向性，只是触发异常时内核发送缓冲刚好剩余的可用空间大小，和你本地应用层缓冲区的配置没有直接关联。

1. 应用层缓冲区是否必须设置为小于TCP_MSS的值 #

完全不需要。
TCP_MSS=1460是TCP层单个报文段的最大有效载荷长度，是内核协议栈内部处理报文拆分的参数，对应用层传入TCP.write()的数据长度没有强制约束。哪怕单次传入数KB的数据，lwIP也会自动按照MSS拆分报文排队发送，不需要应用层手动适配MSS长度。
你当前定义的1810字节应用层缓冲区不存在合规性问题，不需要调整到小于MSS的数值。

注：你问题描述中笔误提到当前缓冲区为1860，实际代码定义为1810，该数值本身不会触发发送异常。

2. 是否需要将缓冲区改为长度等于packetSize的动态数组 #

完全不需要，且强烈不推荐这种做法。

• ESP8266的堆内存空间极小且碎片化严重，使用动态分配（malloc/new）生成可变长度数组，很容易出现内存分配失败、堆崩溃的问题，远不如全局静态数组稳定。
• 你当前定义的MAX_BUFFER_SIZE是支持的最大单包长度，只要自定义的packetSize不超过该上限，固定长度的全局缓冲区可以兼容所有更小的包长场景，不会产生额外的性能损耗或内存安全问题。
• 发送返回值偏小的问题根因在内核流控，和应用层缓冲区的分配方式、长度没有关系，换成动态数组完全无法解决该问题。

• 不要默认TCP.write()会一次性写入所有传入数据，必须根据返回值处理剩余未发送内容：当返回值sent < packetSize时，记录剩余待发送数据的偏移量，注册TCP.onSendAvailable()回调，等内核发送缓冲有可用空间时再继续发送剩余数据，不要在主循环里无间隔重试——无间隔重试只会持续返回0，还会阻塞主循环、拉长ACK等待时间，加剧缓冲占满的问题。
• lwIP v2高带宽模式下的默认发送缓冲参数已经是适配ESP8266内存上限的最优值，不要随意调大TCP_SND_BUF等参数，否则容易触发内存不足导致的设备重启。

内容的提问来源于stack exchange，提问作者Vassilis Papanikolaou