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

其实说真的，很多时候，这些历史遗留问题，未必和技术本身密切相关的。类似的话题包括但不局限于：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协议为什么能盛行了。