Rust中TCPStream读取多TCP包的调用方式及最佳实践咨询

读取方法的包边界相关行为 #

Rust 标准库的TcpStream实现了std::io::Read特征，所有读取接口的行为完全匹配TCP协议的字节流本质：

• 单次读取调用天然支持合并多个TCP包的内容：只要内核套接字缓冲区中已经收到了多个TCP包的数据，调用read()时会尽可能将缓冲区中已有的所有数据（不管来自多少个TCP包）填充到你传入的读缓冲区中，不会和单个TCP包绑定
• 你仍然需要多次调用读取方法才能拿到完整的目标业务数据：如果内核缓冲区中当前只有部分目标数据，read()只会返回已有的部分内容，尚未到达网卡、还未被内核确认的剩余数据，必须通过后续的读取调用才能获取

举个实际场景的例子：假设你需要读取1000字节的业务数据，当前内核缓冲区中已经累计了2个TCP包共600字节，第一次read()调用会直接返回这600字节，剩下的400字节可能分布在后续的3个TCP包中，需要再次调用读取方法才能拿到。

不确定数据长度场景的最佳实践 #

TCP本身没有业务包边界，所有「业务包」的拆分逻辑都需要在应用层实现，不要依赖TCP包的边界做业务判断，通用实践如下：

• 明确知道目标数据长度时，直接使用read_exact()方法：该方法会自动循环调用底层read()，直到将传入的缓冲区完全填满或者出现IO错误，不需要自己手写循环读取逻辑
• 按分隔符拆分业务包时，使用BufRead特征的封装方法：给TcpStream套上BufReader后，可以直接调用read_until()（自定义分隔符）或read_line()（换行符分隔）方法，接口会自动处理跨包读取的逻辑，同时BufReader的内部缓冲也能减少系统调用次数，提升读取性能
• 自定义私有协议时，优先用「长度头+业务体」的结构设计：
  1. 协议头设置固定长度，至少包含后续业务数据的长度字段
  2. 读取时先调用read_exact()读固定长度的协议头，解析出业务体的长度
  3. 再根据解析出的长度调用read_exact()读取对应长度的业务体
  4. 处理完完整业务包后，缓冲中剩余的未处理数据留给下一个包解析，不要直接丢弃
• 错误处理注意点：非阻塞模式下要对WouldBlock、Interrupted这类可重试错误做重试逻辑，只有碰到连接断开、数据校验失败等不可逆错误时再关闭连接释放资源

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