系统设计，协议先行。
大部分人不了解协议的设计细节，更多使用已有协议进行应用层设计，例如：
（1）使用 HTTP，设计 get/post/cookie 参数，以及 json 包格式；
（2）使用 dubbo，而不用去深究内部的二进制包头包体细节；
无论如何，了解协议设计的原则，对深入理解系统通信非常有帮助。
一、协议的分层设计
所谓 “协议”，是双方共同遵守的规则，例如：离婚协议，停战协议。协议有语法、语义、时序三要素：
（1）语法，即数据与控制信息的结构或格式；
（2）语义，即需要发出何种控制信息，完成何种动作以及做出何种响应；
（3）时序，即事件实现顺序的详细说明；
画外音：后文主要讲语法设计。
协议设计通常分为三层：应用层协议、安全层协议、传输层协议。
下面分别看下这三层的协议应该如何选型。
二、应用层协议设计
应用层协议选型，常见的有三种：文本协议、二进制协议、流式 XML 协议。
文本协议
文本协议是指 “贴近人类书面语言表达” 的通讯传输协议，典型的协议是 HTTP 协议，一个 HTTP 协议的请求报文样例如下：
GET / HTTP/1.1
User-Agent: curl
Host: musicml.net
Accept: /
文本协议的特点是：
（1）可读性好，便于调试；
（2）扩展性较好，能通过 key:value 扩展；
（3）解析效率不高，一行一行读入，按照冒号分割，解析 key 和 value；
（4）对二进制不友好 ，比如语音 / 视频等；
二进制协议
二进制协议即 binary 协议，典型是 IP 协议，以下是 IP 协议的一个图示：
二进制协议一般包含：
（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’>
Wherefore art thou, Romeo?
从 xml 标签中大致可以判断这是一个 romeo 发给 juliet 的聊天消息。
XML 协议有几个特点：
（1）可读性好，扩展性好，这是 XML 的特性；
（2）解析代价超高，需要进行 dom 树分析；
（3）有效数据传输率超低，有大量的标签；
（4）对二进制不友好 ，比如语音 / 视频等；
三、安全层协议设计
安全层协议设计，除了使用 SSL，自行实现的话，常见的又有以下三种方案。
画外音：SSL 秘钥管理是个问题。
固定密钥
服务端和客户端约定好一个密钥，同时约定好一个加密算法（例如：AES），每次客户端发送报文前，就用约定好的算法，以及约定好的密钥加密再传输，服务端收到报文后，用约定好的算法，约定好的密钥再解密。
画外音：安全性低，安全性基于程序员的职业操守。
一人一密
简单来说，就是一个人的密钥是固定的，但是每个人之间又不同。常见的实现方式是：
（1）固定加密算法；
（2）加密秘钥使用 “用户的某一特殊属性”，比如用户 uid、手机号、qq 号、用户密码等；
一次一密
即动态密钥，一 Session 一密钥的安全性更高，每次会话前协商密钥。密钥协商的过程要经过 2 次非对称密钥的随机生成，1 次对称加密密钥的随机生成，具体详情这里不展开。
四、传输层协议设计
可选的协议有 TCP 和 UDP，现在基本都是使用 TCP，有了 epoll 等技术后，多连接就不是瓶颈了，单机几十万链接没什么问题。
架构师之路 - 分享可落地的技术文章
相关推荐：
调研：
贵司的加密，是在代码中写死秘钥么？
