这是一个创建于 1019 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景: 业务组件需要通信,通信采用 TLV 格式编码的协议.由于原有 TLV 中 L(Length)定义太短,现在需要扩增 Length.
问题
1. 扩增长度主要应该考虑哪些因素?
2. 应该从哪些角度确定 Length 的最大值?
3. 如果不设最大长度校验,会有何种极端情况下的影响.
请教各位 V 站大佬
问题
1. 扩增长度主要应该考虑哪些因素?
2. 应该从哪些角度确定 Length 的最大值?
3. 如果不设最大长度校验,会有何种极端情况下的影响.
请教各位 V 站大佬
 |
1
3dwelcome 2022-03-09 17:10:38 +08:00
websocket 也是基于 TCP 的协议，一般发送个 10M 文件，会被切成 100k 左右长度分片。
然后再让 TCP/IP 底层切成 4k 大小的 IP 包去传输。 我也不确定 chrome 浏览器的 100k 切分是怎么来的，可能就是经验参数吧。 |
 |
2
sujin190 2022-03-10 00:09:31 +08:00 via Android  1
@3dwelcome 公网环境来说，较长的帧需要更大的接收发送缓冲区不用说，每帧需要较多 ip 包才能完成传输，平稳性较差，受丢包影响更大，而且多路复用并发传输中肯定会有大小数据之分，大数据考虑稳定小数据一般对延时更敏感，过大的帧有更明显的头部阻塞，对小数据传输延时可能影响很大，另一面对大数据传输来说，大帧在遇到网络异常恢复成本也更高，小帧缺点自然不用说，传输效率低，重排及优先级排序复杂，总得来说还是要看网络延时和丢包情况综合考虑，延时高丢包率高比如梯子这种 2 到 4 个 ip 包看起来是比较理想的，国内环境估计来个几十 k 吧，内网自然无所谓了吧
|
|
3
3dwelcome 2022-03-10 02:27:05 +08:00 1
@sujin190 我怎么理解不了你的意思呢。
比如我发 10M 的文件数据，不管我用什么长度切，最后路由发出每个 IP 包大小都是确定的，丢包率也是确定的。 也就是说，无论用 10K 还是 100K 切分，丢包率就是个恒定的百分比，不会因为长度变化而改变。 |
|
4
sujin190 2022-03-10 09:32:12 +08:00
@3dwelcome #3 要抓住重点啊，上层仍然是流式接收的，丢包率虽然固定，但是帧越大需要的 ip 包越多上层收到自然也是一大段一大段的，平稳性较差就在这，而且更重要的 tcp 再分包多路复用，自然就有优先级的要求，比如视频的优先级就应该比脚本优先级低，包大优先级的响应自然也更差
|
 |
5
lysS 2022-03-10 10:09:39 +08:00
TCP 上不需要考虑长度，会在网络层自动分包
|
Select Language