TCP协议-报文段数据中的自定义包头
-
问题背景
- TCP协议的包头中有源端口号和目标端口号,本质是为了标识某机器上的一个进程。
- 问题
- 一个进程可能需要有多条协议的数据通信,需要有别的标识字段来分辨不同协议的数据
- 服务器可能需要对不同类型的客户端的请求,响应不同的数据
- TCP协议包中的二进制数据的长度未知
- 目前了解到的主要有两种方法
- 结束符
- 定长数据
- 自定义包头中含有一个字段,在发送该包前记录报文段的长度
- 目前了解到的主要有两种方法
-
解决方案
- 较常用:TCP报文段预留一片区域,作为自定义的数据头,即方案3
- 这是工业界较为常用的一种手段
- 自定义数据头中填充协议号、版本号、用户ID等信息(开发人员自行选择)
- 通常有一个字段用以标识传输的协议数据的字节数(即长度)
- 实际传输的协议的二进制数据是TCP报文段减去自定义数据头的剩余数据
- 使用
Base64
编码再进行传输, \0作为结束符- 缺点:消耗带宽,因为base64编码之后占用的大小平均多了30%左右
- 较常用:TCP报文段预留一片区域,作为自定义的数据头,即方案3
-
延申
- UDP协议也可以使用该方案,可以在自定义的包头中加入字段作为检验和
-
参考资料
【推荐】还在用 ECharts 开发大屏?试试这款永久免费的开源 BI 工具!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET制作智能桌面机器人:结合BotSharp智能体框架开发语音交互
· 软件产品开发中常见的10个问题及处理方法
· .NET 原生驾驭 AI 新基建实战系列:向量数据库的应用与畅想
· 从问题排查到源码分析:ActiveMQ消费端频繁日志刷屏的秘密
· 一次Java后端服务间歇性响应慢的问题排查记录
· 互联网不景气了那就玩玩嵌入式吧,用纯.NET开发并制作一个智能桌面机器人(四):结合BotSharp
· 一个基于 .NET 开源免费的异地组网和内网穿透工具
· 《HelloGitHub》第 108 期
· Windows桌面应用自动更新解决方案SharpUpdater5发布
· 我的家庭实验室服务器集群硬件清单