简单的文本协议、二进制协议

写网络程序躲不过协议，协议其实就是定义了消息的格式，以及消息是如何交换的。协议可简单可复杂，复杂精密如TCP协议，简单奔放如HTTP的协议。这里将我所接触到的协议稍微总结一下，最后抛出一个个人设计的简单通用的文本协议。

设计一个协议不是一件很容易的事情，尤其是当对设计的要求包含很好的描述性和可扩展性的时候。如果再将效率考虑在内，则更是件耗脑力的活。在继续讨论下去之前，先看看现有的一些协议吧。这里主要讨论的是应用层的协议，应用层的协议大多是请求响应模式（除了zeromq这个变态的家伙，后面再说），所以这里侧重讨论消息格式。

HTTP协议

这可能是大家接触得最多的协议了，HTTP协议是一个比较简单的基于文本的协议。消息格式基于文本，换行分隔键值串，键和值用冒号分隔，同时定义了一些标准的键和值。这个协议描述性教强——人类可读。扩展性强——加自定义的头很容易，也几乎不会有副作用（除了消息体积增加一点点）。但是，缺点就是标准定义的东西太多了，细节太多。解析较复杂。

memcached协议

memcached有两种协议，文本协议和二进制协议，文本协议以换行表示一个请求结束。请求内部参数以空格分隔。为了二进制安全，在二进制数据前要加上长度这个参数，如set x 3 abc\r\n。

文本协议固然简单，可是当请求很小的时候，过多的协议本身的数据则显得浪费（比如每个HTTP请求只发送一个字母，可HTTP头可能有上百的字符，太浪费了），而且，server在接收到请求之后还要做文本解析，也耗cpu，于是memcached又推出了二进制协议，为了锦上添花，是的memcached更加高效。二进制协议的优点就是高效，因为所有信息都以最少的数据量来表达，且server解析请求时做的是数学比较而不是字符串比较，效率高很多。

memcached的协议比起HTTP来就轻得多了（当然，两者所面向的场景不一样，故这个比较没太大意义）。但是，也有缺点，就是扩展性较差，协议定得比较死，哪个位置上有哪些东西，是什么意义是定死的。所以，直接哪来用在不同的场景下不大现实。

redis协议

redis的协议也是文本协议，但是设计得比较小心和通用（我后面自己定义的协议深受其影响），在保证描述性的同时尽量减少协议本身的数据量，比如，在memcached的文本协议中，错误用“ERROR\r\n”来表示，而redis使用“-”来表示，用“:”开头的行表示整数等等。这样的设计结合了文本协议的简单和一部分二进制协议的高效。用在redis这个场合，很是适合。交换方式同样是请求响应。redis协议有一个缺点，就是，一个消息有多少参数是需要在开头指定的。不像HTTP协议用空行来表示结束。这就带来一个缺点，不好流水操作，也就是说消息必须在发送第一个字节之前被完全确定，因为第一个东西就是参数个数:-(。

上面讨论的基本都是文本协议，当然还有很多采用二进制协议的服务，如gearman、mysql等，二进制协议就相当于压缩版的文本协议，提高了传输效率，但是降低了描述性和灵活性（万一那个位置预留的位数不够就囧了）。

总的来说，这就是一个平衡的过程。如果消息体不是很小（比如每次只传一个字节的消息就很小了），那么采用文本协议还是值得的。毕竟文本协议简单，好扩展，利于调试（telnet就可以当客户端用），虽说消息是让计算机读的，但有时候也要人去看。所以，能用文本还是用文本吧。

简单文本协议

最后我定义了一个简单的基于文本的协议，叫做simpletp（Simple Text based Protocol），详细定义在这里http://simpletp.org，这个协议是为了简单的RPC而设计，结合了HTTP协议的灵活（以空行结束），redis协议的轻量（size+data）。但为了简单通用，没有采用redis的单字符表示类型的设计，因为这样就会引入额外的复杂性，如表示整数用“:”，那么浮点数、复数等等怎么办，干脆什么类型都没有，就简单的传输size+data串（有点类似zeromq，但是比zeromq做的事情少），而具体的类型则交由其他机制去处理，如protocol buffer。