谁家的加密密钥，写死在代码里？

2024-10-31

系统设计，协议先行。

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

使用HTTP，设计 get/post/cookie 参数，以及json包格式；
使用dubbo，而不用去深究内部的二进制包头包体细节；

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

一、协议的分层设计

所谓“协议”，是双方共同遵守的规则，例如：离婚协议，停战协议。协议有语法、语义、时序三要素：

语法，即数据与控制信息的结构或格式；
语义，即需要发出何种控制信息，完成何种动作以及做出何种响应；
时序，即事件实现顺序的详细说明；

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

协议设计通常分为三层：应用层协议、安全层协议、传输层协议。

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

二、应用层协议设计

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

(1) 文本协议

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

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

文本协议的特点是：

可读性好，便于调试；
扩展性较好，能通过key:value扩展；
解析效率不高，一行一行读入，按照冒号分割，解析key和value；
对二进制不友好，比如语音/视频等；

(2) 二进制协议

二进制协议即binary协议，典型是IP协议，以下是IP协议的一个图示：

二进制协议一般包含：一般包含：

定长包头；
可扩展变长包体；
一般每个字段有固定的含义，以IP协议为例，前4个bit表示协议版本号（Version）；

二进制协议的特点是：

可读性差，难于调试；画外音：打日志一般需要一个toString()函数增强可读性。
扩展性不好，如果要扩展字段，旧版协议就不兼容了，所以设计时一般会有一个Version字段；
解析效率超高，几乎没有解析代价，二进制流的每个字段表示固定含义；
天然支持二进制流，比如语音/视频；

这是一个典型的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协议，容易看到：