【重复造轮子系列】手撸RPC(四):通信协议

一、前文回顾

在上一篇文章中我们简单完成了服务的注册,成功的将服务端暴露的接口添加到注册中心上了,而且也客户端和服务端已经可以进行最基本的通信,接下来要做的就是要定义好通信协议。

二、通信协议

通信协议是指双方实体完成通信或服务所必须遵循的规则和约定。通过通信信道和设备互连起来的多个不同地理位置的数据通信系统,要使其能协同工作实现信息交换和资源共享,它们之间必须具有共同的语言。交流什么、怎样交流及何时交流,都必须遵循某种互相都能接受的规则。这个规则就是通信协议。

简单的来说通信协议就是通信双方约定的一种形式,例如我发送0001表示Hello,则对方收到0001的时候就知道我发送的Hello。我们的RPC当然也需要通信协议(当然直接使用Http也是可以的)

在网络通信中,服务端和客户端之间是通过发送数据包来进行通信,所以协议就是规定要发送的数据包是什么样子的。参考Http请求,Http请求就大体分为请求头和请求体两部分,那我们自定义的协议也可以这么做。那么接下来要讨论的就是如何设计这个数据包了。

1、请求头

通常我们会把一些描述信息放在请求头里(例如Http请求头中会记录application-content),所以我们也这么做,同时也参考一下Dubbo的实现。

1、魔术值:前4个字节我们放魔术值,。

2、版本号:我们再拿1个字节来标记协议的版本。

3、头部长度:2个字节来表示头部长度

4、总长度:4个字节来表示总长度(头部长度+请求体长度)

5、请求类型、序列化方式、压缩方式:各1个字节

6、请求ID:8个字节

说明:所谓魔术值就是一段自定义的数据用于标记当前协议。客户端和服务端之间通过对比魔术值来判断是否为相同的协议;版本号就是用来标记版本的(协议版本);请求类型:用于区分是否为心跳请求(这里先按下不表,之后的文章再细讲);这里比较重要的是头部长度总长度 ,为什么需要这几个字段呢?这就涉及到TCP的粘包/拆包问题了,具体可以参考这里https://zhuanlan.zhihu.com/p/609934467,所以我们需要把包的长度提前定义好,这样就可以避免上述问题。

2、请求体

请求体就比较简单了,就是一大段byte数据。

综上我们自定义的协议如上图所示,下一篇文章我们会整理一下代码,然后开始实际的开发,希望对你有所帮助。

相关推荐
源远流长jerry2 分钟前
dpdk之kni处理dns案例
linux·网络·网络协议·ubuntu·ip
玉梅小洋4 分钟前
iperf 网络性能测试完整指南(含多服务端测试)
网络·测试工具·性能测试·iperf
Danileaf_Guo8 分钟前
我们的WireGuard管理系统支持手机电脑了!全平台终端配置,支持扫码连接,一键搞定
网络
犀思云43 分钟前
构建全球化多云网格:FusionWAN NaaS 在高可用基础设施中的工程实践
运维·网络·人工智能·系统架构·机器人
Black蜡笔小新1 小时前
国密GB35114平台EasyGBS筑牢安防安全防线,GB28181/GB35114无缝接入
网络·安全·音视频·gb35114
多多*2 小时前
2月3日面试题整理 字节跳动后端开发相关
android·java·开发语言·网络·jvm·adb·c#
vortex52 小时前
Alpine Linux syslinux 启动加固(密码保护)
linux·服务器·网络
犀思云3 小时前
网络运维减负:解构FusionWAN NaaS 面向企业广域网的技术逻辑演进
网络·智能仓储·fusionwan·专线·naas
倔强的石头1063 小时前
边缘侧时序数据的选型指南:网络不稳定、数据不丢、回传可控——用 Apache IoTDB 设计可靠链路
网络·apache·iotdb
南墙上的石头3 小时前
docker日常使用命令汇总
docker·容器·rpc