【记录】从0设计一款分布式通用网络通讯协议

每天记录一点点, 直到开源, 欢迎指正和交流

前言

        当下已有非常多也可靠的通讯协议, 我们熟知的包括: 飞秋基于UDP, 微信/QQ基于TCP, 还有HTTP、WS、FTP(文件传输)、IMAP/SMTP(邮件访问)、SSH(安全壳, 常见Linux客户端)、HLS(IOS的流媒体传输)、RTMP(Adobe的流媒体传输), MQTT(IBM的物联网消息协议)等等..

        综上协议进行异同分析, 我们可能会思考几个问题:

• 它们都是某一个领域的专用协议, 是否存在一个通用的通讯协议呢?

        比如飞秋/微信都是即时通讯的协议, HTTP是文本传输, FTP文件传输, SSH加密传输, RTMP流媒体传输, MQTT消息队列遥测传输, 而这些场景在物联网的大趋势下真的不能共用一套协议吗? 

• 它们都是点对点进行通讯的, 那集群/分布式场景下多节点的协议如何治理?

        点对点就是TCP/IP的实质行为, 连接必须基于IP, 所以协议的通讯方必须是点对点, 而上诉协议也都是如此, 在集群/分布式盛行的年代, 多节点间如何进行协作呢, 协议如何治理呢?

        题外话: "协议治理" 这应该在行业内是一个新概念。

• 它们有的对传输数据时加密的, 有的则不然, 这不该是用户决定的吗?

        邮件访问, 安全壳等协议的确数据传输是有加密的, 但HTTP则不然。加密自然会对性能有影响, 但是否需要加密这个事情用户才会最清楚也最有决定权, 是否应该让用户自己选择?

• 它们哪怕在相同领域也有很大的性能差异, 我们还能通过哪些手段提升?

        HLS和RTMP都是流媒体传输协议, 但是RTMP的性能却远胜于它, 这其中有什么隐情, 通过观察并精准优化我们是否可以做到比RTMP还优秀?

定位

        做一款全场景通用具有分布式治理能力的网络通讯协议。

---

        取名: CC, 称作CC协议, 其框架称作CcFreamwork, 为解决通讯烦恼而生。

        在当下进行抄送、通知、@艾特等操作经常会简写成: CC

        通讯中心的英文我们也会简写成: CC

        客户端到客户端我们也会简写成: C2C

        你们还知道哪些呢?

        ....

   

设计思路

1. 先学习常见的网络协议是如何定义的
2. 然后取其精华去其糟粕用于定义cc
3. 最后对其进行校准优化使其符合定位

学习HTTP可见: 用换行符分割不同语义的数据、要有请求地址、协议版本、数据长度/格式

学习WS可见: 用固定的位置表达不同的语义、要有标志位、操作码、安全码、拆包传输

学习RTMP可见: 要有流、块编号、时间戳、消息类型(省略消息编号、长度等头数据)

​

学习MQTT可见: 要有可变位(扩展)、控制位(重发)、负载位

概念设计

明文

协议位

• 占用1字节

7	6	5	4	3	2	1	0
版本号		操作码

• 版本号: 00第1个版本、01第2个版本、10第3个版本、11第4个版本
• 操作码: 共支持64个操作码, 包括: 握手、挥手、传输、心跳、治理..
• 解决问题: 协议治理

控制位

• 占用1字节

7	6	5	4	3	2	1	0
-	-	-	重发	-	确认	拆包	加密

• 加密: 后面的数据是否是加密数据, 如果是则需要解密后才是协议明文数据
• 拆包: 当前消息是否拆包传输, 如果是拆包则意味着这是1个消息片段
• 确认: 消息的质量要求, 如果需要确认, 则在单位时间内没有收到ACK将重发
• 重发: 表示这个消息发过了, 只是因为没有收到ACK才重发的
• 解决问题: 通讯质量和通讯安全治理

消息头

如果是流媒体, 长度 表示当前包的有效数据长度; 否则表示消息的总大小

如果是流媒体, 消息头 必须存在; 否则只有在第一个包是必须的, 其他包则无

• 占用1字节

7	6	5	4	3	2	1	0
-	first	last	小道消息	消息类型

• 消息类型: 0000流媒体、0001文本、0010代码、0011文件...
• 小道消息: 消息长度只占1个字节, 适用弱网环境...
• last: 拆包独有, 表示是否为尾包
• first: 拆包独有, 表示是否为头包

3	2	1	0
消息长度

• 消息长度: 数据有效载体(消息)的实际长度
  • 小道消息: 占1字节
  • 常规消息: 占4字节
• 解决问题: 全场景通用, 弱网传输

消息体

• 占用len字节

len	...	0
消息内容

• 消息内容: 真实数据
• 解决问题: 使协议在弱网环境传输能力更强

标识位

• 占用length+1字节

0	length	...	0
length	包序列

• length: 序列长度, 表示包编号占用的字节数
• 包序列: 会话内唯一且有序的包编号, 使其拆包&并发传输可靠。

密文

ACK

握手

挥手

CC: 常规字节数为4, 可在较恶劣的网络环境传输。

协议开发

名词解释

会话

• 连接隔离
• 通讯安全

管道

• 协议治理
• 带宽限制

包

• 编解码
• 拆并包

通讯模块

        负责TCP/IP的基础通讯能力的封装, 计划基于Java - AIO实现。

协议模块

        负责CC协议的实现与封装

框架模块

        负责长链接常见场景的封装

• P2P
• 广播
• 协议治理
  • 网络管理
  • 故障转移
  • 监控
• 协议转换

示例模块

        负责将CC框架应用在具体的场景(仅作简单的演示)

测试模块

        负责各阶段的测试编码

应用实战

待续..