通信协议可以理解两个节点之间为了协同工作实现信息交换，协商一定的规则和约定，例如规定字节序，各个字段类型，使用什么压缩算法或加密算法等。常见的有tcp，udp，http，sip等常见协议。协议有流程规范和编码规范。流程如呼叫流程等信令流程，编码规范规定所有信令和数据如何打包/解包。
编码规范就是我们通常所说的编解码，序列化。不光是用在通信工作上，在存储工作上我们也经常用到。如我们经常想把内存中对象存放到磁盘上，就需要对对象进行数据序列化工作。
本文采用先循序渐进，先举一个例子，然后不断提出问题-解决完善，这样一个迭代进化的方式，介绍一个协议逐步进化和完善，最后总结。看完之后，大家以后在工作就很容易制定和选择自己的编码协议。
紧凑模式
本文例子是A和B通信，获取或设置基本资料，一般开发人员第一步就是定义一个协议结构:
struct userbase
{
//1-get, 2-set, 定义一个short，为了扩展更多命令
unsigned short cmd;
//1 – man , 2-woman
unsigned char gender;
//当然这里可以定义为 string name；或len + value 组合，
为了叙述方便，就使用简单定长数据char name[8];
}
在这种方式下，A基本不用编码，直接从内存copy出来，再把cmd做一下网络字节序变换，发送给B。B也能解析，一切都很和谐愉快。
这时候编码结果可以用图表示为(1格一个字节)
这种编码方式，我称之为紧凑模式，意思是除了数据本身外，没有一点额外冗余信息，可以看成是Raw Data。在dos年代，这种使用方式非常普遍，那时候可是内存和网络都是按K计算，cpu还没有到1G。如果添加额外信息，不光耗费捉襟见肘的cpu，连内存和带宽都伤不起。
可扩展性
有一天，A在基本资料里面加一个生日字段，然后告诉B
struct userbase
{
unsigned short cmd;
unsigned char gender;
unsigned int birthday;
char name[8];}
这是B就犯愁了，收到A的数据包，不知道第3个字段到底是旧协议中的name字段，还是新协议中birthday。这是后A，和B终于从教训中认识到一个协议重要特性——兼容性和可扩展性。
于是乎，A和B决定废掉旧的协议，从新开始，制定一个以后每个版本兼容的协议。方法很简单，就是加一个version字段。
struct userbase
