【重复造轮子系列】手撸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数据。

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

相关推荐
盟接之桥1 小时前
盟接之桥EDI软件:API数据采集模块深度解析,打造企业数据协同新引擎
java·运维·服务器·网络·数据库·人工智能·制造
2501_907136821 小时前
离线工具箱 内含53个小工具
linux·服务器·网络
时空潮汐1 小时前
神卓N600 NAS身份核验功能深度解析
linux·运维·网络·神卓nas·神卓n600 pro·家庭轻nas
一路往蓝-Anbo2 小时前
第 7 章:内存地图 (Memory Map) 深度设计——DDR 与 SRAM
linux·stm32·单片机·嵌入式硬件·网络协议
一路往蓝-Anbo2 小时前
第 8 章:M33 领航——引导 A35 加载 U-Boot 与 Linux 内核
linux·运维·服务器·stm32·单片机·嵌入式硬件·网络协议
liron713 小时前
自定义MCP协议的一点想法
网络
The_Uniform_C@t24 小时前
论文浅读(第三期)|摘自《UAV Resilience Against Stealthy Attacks》(第一节)
网络·物联网·学习·网络安全
闲人编程4 小时前
任务监控与错误重试
linux·服务器·网络·celery·任务队列·任务监控·错误重试
tianyagukechat5 小时前
rockylinux9.5 配置IP
java·网络·tcp/ip
一次旅行5 小时前
网络硬件通用基础知识
网络·测试总结