简单的文本协议、二进制协议
-
写网络程序躲不过协议,协议其实就是定义了消息的格式,以及消息是如何交换的。协议可简单可复杂,复杂精密如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。
From:www.2cto.com/net/201306/217729.html