Android TcpServer接收0xFF偶发丢失及NVT相关问题咨询

• 读取逻辑未处理TCP粘包/拆包场景
  TCP是无边界的流协议，若你的服务端读取代码未做跨缓冲区的状态持久化，当连续的0xFF被拆分到两次socket读取操作中时，隐含的转义处理逻辑无法识别跨包的连续0xFF序列，就会出现时好时坏的现象。你给出的示例中4个0xFF最终收到2个，完全符合每两个连续0xFF合并为1个的转义逻辑特征。
• TcpServer内置默认NVT转义逻辑
  若你使用的是第三方封装的TcpServer组件，即使未暴露NVT开关，内部也可能默认集成了Telnet协议兼容逻辑：按照NVT规范，0xFF是IAC命令前缀，连续两个0xFF会被转义为1个普通的0xFF字节。该现象偶发的原因是：当连续0xFF刚好被拆分为多个TCP分片到达时，转义逻辑无法匹配到连续的0xFF序列，就不会触发合并，此时所有字节正常接收。
• Docklight隐含的特殊字符处理逻辑
  即使Docklight没有显式的NVT开关，若你开启了发送配置中的「Telnet兼容」「特殊字符自动转义」类选项，发送端就会主动合并连续的0xFF字节。偶发原因是发送时数据分片的时机不固定，连续0xFF被拆到两个独立发送包时不会触发合并规则。
• Android系统定制化的TCP流处理逻辑
  部分深度定制的Android ROM内核中带有TCP报文清洗规则，会对疑似Telnet协议的报文做自动转义处理，仅当报文特征匹配（如连续出现多个0xFF）时触发转义，其余场景正常透传，也会导致偶发的丢失问题。

快速排查方案：分别在Docklight所在设备、Android设备上抓TCP报文，确认0xFF丢失发生在发送阶段、传输阶段还是服务端处理阶段，即可快速定位根因。

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