五千年(敝帚自珍)

主题:【原创】我有一个问题 -- 美人他爹

共:💬73 🌺79
全看分页树展 · 主题 跟帖
家园 我觉得你太在意技术的细节了

其实说真的,很多时候,这些历史遗留问题,未必和技术本身密切相关的。类似的话题包括但不局限于:Windows vs *nix、IE vs Netscape/Firefox、c/s vs b/s、CISC vs RISC等等等等。

但既然提到了技术,那也不妨就你所提到的一些点,展开讨论一下。

其实你多次提到的be/le的问题,业界早就有共识了:就是网络字节序(be)。如果现在有谁要设计一个二进制网络协议而不不使用网络字节序,那么出问题是他活该。

其实这个问题就相当于总有些新人在问:一个byte一定是8个bit吗?答案当然不是。谁都可以设计一个系统,从cpu到应用软件,全部采用9bit一个byte的。但是,除非你提供一个8bit的转换方案,否则,你的机器别想上网--因为整个IP协议层,都是规定8bit一个byte的。

说完了能力问题,那就再说说性能问题。

其实be/le的转换,对于这类转换,也是你所非常推崇的stateless的操作。在cpu/硬件一层都可以用非常简单高效的实现。用纯组合电路实现一个这样的转换方案,应该是任何一个学过大学数字电路的学生都能完成的。

相反,对于文本协议的匹配判定和识别,就麻烦多了。二进制不同的协议命令,基本上都用一个整数来识别。这样,协议指令的匹配和跳转,在c语言来说,一个switch搞定。在编译器底层,基本上是用一个跳转表或者一个hashtable实现,优化得好的话,基本上都是O(1)的复杂度。而文本串的识别,即使再简单,也不可能提供一个O(1)的解决方案出来。更别提如果有N多命令,那么这个效率差距就更大。

然后再说说,即使不考虑性能上的差距,文本协议自己还是有很多的问题问题。

如果你不能认同二进制协议的be/le的问题可以通过协议约定来解决,那么文本协议的大小写你觉得要怎么解决?如果每个命令接收和处理,都要先经过大小写的适配预处理,那么它的性能损耗,绝对远远高于字节序的转换--至于能不能接受,那是另一回事。

如果说大小写还很好约定的话,那么字符编码就显然是一个更棘手的问题,直到现在,都还没有一个成熟的解决方案,各个网站,都还经常为乱码而头痛。不过幸好大家都在http中基本使用英文,所以用起来也没有太大的问题--不过话说回来,这也不是一个约定吗?既然http能有这么多的约定,那么一个二进制协议有个什么be/le的约定,就那么的不可忍受?

说起来,http更大幸运在于:在http开始初期,中国等地方的互联网影响力还很小,所以对多字节字符的编码问题可以忽略不计,不支持就不支持,大家都没话说。等到中国开始nb了,大家也就有时间给各个基于文本的协议开始打补丁了。不然,这个协议再好,也注定成不了气候。

所以,http协议之所以能有这么强的生命力,其实在我看来还真的是沾了html的光。因为现在网络上绝大部分的网络服务,都要基于html协议。而html协议的首选应用层协议(为什么会成为首选,这个另外再讨论),自然能够在网络设备中得到优先的支持。我就曾经做过一个项目,原本走二进制的协议,需要外包一个http的壳,走80端口,伪装为http协议。无他,因为某个网络环境中,只有80端口是通的,而且还要经过防火墙的过滤和检查,过滤掉所有非http协议的包。这http伪装的东西,估计你不会很陌生吧?这种在功能上没有任何增强,反倒损耗性能的工作本身的必要性,就很能说明了http协议为什么能盛行了。

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河