TCP 上定义一个应用层传输协议,如何确定通信协议最大数据长度?

[bushenx]

背景: 业务组件需要通信,通信采用 TLV 格式编码的协议.由于原有 TLV 中 L(Length)定义太短,现在需要扩增 Length.

问题
1. 扩增长度主要应该考虑哪些因素?
2. 应该从哪些角度确定 Length 的最大值?
3. 如果不设最大长度校验,会有何种极端情况下的影响.

请教各位 V 站大佬

[3dwelcome]

websocket 也是基于 TCP 的协议，一般发送个 10M 文件，会被切成 100k 左右长度分片。

然后再让 TCP/IP 底层切成 4k 大小的 IP 包去传输。

我也不确定 chrome 浏览器的 100k 切分是怎么来的，可能就是经验参数吧。

[sujin190]

@3dwelcome 公网环境来说，较长的帧需要更大的接收发送缓冲区不用说，每帧需要较多 ip 包才能完成传输，平稳性较差，受丢包影响更大，而且多路复用并发传输中肯定会有大小数据之分，大数据考虑稳定小数据一般对延时更敏感，过大的帧有更明显的头部阻塞，对小数据传输延时可能影响很大，另一面对大数据传输来说，大帧在遇到网络异常恢复成本也更高，小帧缺点自然不用说，传输效率低，重排及优先级排序复杂，总得来说还是要看网络延时和丢包情况综合考虑，延时高丢包率高比如梯子这种 2 到 4 个 ip 包看起来是比较理想的，国内环境估计来个几十 k 吧，内网自然无所谓了吧

[3dwelcome]

@sujin190 我怎么理解不了你的意思呢。

比如我发 10M 的文件数据，不管我用什么长度切，最后路由发出每个 IP 包大小都是确定的，丢包率也是确定的。

也就是说，无论用 10K 还是 100K 切分，丢包率就是个恒定的百分比，不会因为长度变化而改变。

[sujin190]

@3dwelcome #3 要抓住重点啊，上层仍然是流式接收的，丢包率虽然固定，但是帧越大需要的 ip 包越多上层收到自然也是一大段一大段的，平稳性较差就在这，而且更重要的 tcp 再分包多路复用，自然就有优先级的要求，比如视频的优先级就应该比脚本优先级低，包大优先级的响应自然也更差

[lysS]

TCP 上不需要考虑长度，会在网络层自动分包