欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  网络运营

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

程序员文章站 2024-01-01 15:44:34
简单的文本协议、二进制协议   写网络程序躲不过协议,协议其实就是定义了消息的格式,以及消息是如何交换的。协议可简单可复杂,复杂精密如TCP协议,简单奔放如HTTP的协议。这里将...

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

 

写网络程序躲不过协议,协议其实就是定义了消息的格式,以及消息是如何交换的。协议可简单可复杂,复杂精密如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。

上一篇:

下一篇: