一次彻底搞透协议设计(没做过通讯底层也没有关系)!

简介: 系统设计,协议先行。

系统设计,协议先行。

大部分人不了解协议的设计细节,更多使用已有协议进行应用层设计,例如:

(1)使用HTTP,设计get/post/cookie参数,以及json包格式;

(2)使用dubbo,而不用去深究内部的二进制包头包体细节;

无论如何,了解协议设计的原则,对深入理解系统通信非常有帮助。

一、协议的分层设计
所谓“协议”,是双方共同遵守的规则,例如:离婚协议,停战协议。协议有语法、语义、时序三要素:
(1)语法,即数据与控制信息的结构或格式;
(2)语义,即需要发出何种控制信息,完成何种动作以及做出何种响应;
(3)时序,即事件实现顺序的详细说明;

画外音:后文主要讲语法设计。

协议设计通常分为三层:应用层协议、安全层协议、传输层协议。
image.png

下面分别看下这三层的协议应该如何选型。

二、应用层协议设计

应用层协议选型,常见的有三种:文本协议、二进制协议、流式XML协议。

image.png

文本协议

文本协议是指“贴近人类书面语言表达”的通讯传输协议,典型的协议是HTTP协议,一个HTTP协议的请求报文样例如下:

GET / HTTP/1.1
User-Agent: curl
Host: musicml.net
Accept: */*

文本协议的特点是:
(1)可读性好,便于调试;
(2)扩展性较好,能通过key:value扩展;
(3)解析效率不高,一行一行读入,按照冒号分割,解析key和value;
(4)对二进制不友好 ,比如语音/视频等;

二进制协议
二进制协议即binary协议,典型是IP协议,以下是IP协议的一个图示:
image.png

二进制协议一般包含:

(1)定长包头;

(2)可扩展变长包体;

(3)一般每个字段有固定的含义,以IP协议为例,前4个bit表示协议版本号(Version);

二进制协议的特点是:

(1)可读性差,难于调试;

画外音:打日志一般需要一个toString()函数增强可读性。

(2)扩展性不好,如果要扩展字段,旧版协议就不兼容了,所以设计时一般会有一个Version字段;
(3)解析效率超高,几乎没有解析代价,二进制流的每个字段表示固定含义;
(4)天然支持二进制流 ,比如语音/视频;

这是一个典型的16字节二进制定长包头的例子:

//sizeof(cs_header)=16
struct cs_header {
  uint32_t version;
  uint32_t magic_num;
  uint32_t cmd;
  uint32_t len;
  uint8_t data[];
}__attribute__((packed));

其中:

(1)前4个字节表示版本号version;

(2)接下来4个字节表示魔法数字magic_num,用来解决数据错位或丢包问题;

画外音:例如,约定好魔法数字是0x01020304,收到的报文,魔法数字匹配,认为是正常报文,否则认为是报文异常,断开连接。

(3)接下来4个字节表示命令号command,不同的命令号对应不同的变长包体;
(4)最后4个字节表示包体长度length,以确定变长包体有多少字节;

这是一个实际的二进制变长包体:

message CUserLoginReq {
  optional string username = 1;
  optional string passwd = 2;
}



message CUserLoginResp {
  optional uint64 uid =1;
}

它使用的是Google的Protobuf协议,容易看到:

(1)请求报文传入的是用户名与密码;

(2)响应包返回的是用户的uid;

PB是很流行的二进制变长包体协议,其优点为:
(1)通用,可以生成C++、Java、PHP等多语言代码;

(2)自带压缩功能;

(3)对二进制友好;

(4)在工业界已广泛应用;
画外音:Google出品,必属精品。

流式XML协议
流式XML似乎是文本协议的一个特例,亦可以单独作为一类。例如:xmpp就是典型的流式XML协议,下面是xmpp协议的一个典型报文:

<message

to=’romeo@example.net’

from=’juliet@example.com’

type=’chat’

xml : lang=’en’>

<body>Wherefore art thou, Romeo?</body>

</message>

从xml标签中大致可以判断这是一个romeo发给juliet的聊天消息。

XML协议有几个特点:
(1)可读性好,扩展性好,这是XML的特性;
(2)解析代价超高,需要进行dom树分析;

(3)有效数据传输率超低,有大量的标签;

(4)对二进制不友好 ,比如语音/视频等;

三、安全层协议设计

安全层协议设计,除了使用SSL,自行实现的话,常见的又有以下三种方案。

画外音:SSL秘钥管理是个问题。

固定密钥
服务端和客户端约定好一个密钥,同时约定好一个加密算法(例如:AES),每次客户端发送报文前,就用约定好的算法,以及约定好的密钥加密再传输,服务端收到报文后,用约定好的算法,约定好的密钥再解密。

画外音:安全性低,安全性基于程序员的职业操守。

一人一密
简单来说,就是一个人的密钥是固定的,但是每个人之间又不同。常见的实现方式是:

(1)固定加密算法;

(2)加密秘钥使用“用户的某一特殊属性”,比如用户uid、手机号、qq号、用户密码等;

一次一密
即动态密钥,一Session一密钥的安全性更高,每次会话前协商密钥。密钥协商的过程要经过2次非对称密钥的随机生成,1次对称加密密钥的随机生成,具体详情这里不展开。

四、传输层协议设计
可选的协议有TCP和UDP,现在基本都是使用TCP,有了epoll等技术后,多连接就不是瓶颈了,单机几十万链接没什么问题。

image.png

架构师之路-分享可落地的技术文章

目录
相关文章
|
20天前
|
缓存 网络协议 数据库连接
【底层服务/编程功底系列】「网络通信体系」深入探索和分析TCP协议的运输连接管理的核心原理和技术要点
【底层服务/编程功底系列】「网络通信体系」深入探索和分析TCP协议的运输连接管理的核心原理和技术要点
20 0
|
7月前
|
网络协议
网络通信协议整体框架
网络通信协议整体框架
34 0
|
9月前
|
存储 开发框架 缓存
数据流动的精妙之道——UniApp中的数据通信与状态管理解析
数据流动的精妙之道——UniApp中的数据通信与状态管理解析
|
11月前
|
存储 缓存 负载均衡
计网 - 怎样实现 RPC 框架
计网 - 怎样实现 RPC 框架
75 0
|
12月前
|
消息中间件 存储 运维
难住了,微服务之间的几种调用方式哪种最佳?
难住了,微服务之间的几种调用方式哪种最佳?
|
芯片
一文搞懂I2C协议-硬件基础
I2C总线是由飞利浦在80年代初设计的,以允许位于同一电路板上的组件之间能够轻松通信。其大大简化了电路的设计,早期的电视机中很多地方用到了I2C这种通信方式。飞利浦半导体于2006年迁移到了NXP。I2C名称翻译为“ Inter IC”。有时,该总线称为IIC或I²C总线。I2C总结的基本的特征
810 0
|
JavaScript Dubbo 小程序
4年工作经验,多线程间的5种通信方式都说不出来,你敢信?
有两个线程,A 线程向一个集合里面依次添加元素“abc”字符串,一共添加十次,当添加到第五次的时候,希望 B 线程能够收到 A 线程的通知,然后 B 线程执行相关的业务操作。线程间通信的模型有两种:共享内存和消息传递,以下方式都是基本这两种模型来实现的。
|
设计模式 负载均衡 数据可视化
服务管理与通信,基础原理分析
阅读源码最重要的是耐着心情慢慢看,并随手画下核心流程,实际上如果有一定的编程经验,不管是阅读什么工程的源码,只要用心去分析单点的实现原理,都算不上过度复杂。
104 0
服务管理与通信,基础原理分析
|
监控 网络协议 NoSQL
不为人知的网络编程(十一):从底层入手,深度分析TCP连接耗时的秘密
TCP的开销到底有多大,能否进行量化。一条TCP连接的建立需要耗时延迟多少,是多少毫秒,还是多少微秒?能不能有一个哪怕是粗略的量化估计?
492 0
不为人知的网络编程(十一):从底层入手,深度分析TCP连接耗时的秘密