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

1。关于stateful，我觉得这是视角不同。您可能是从web programming的角度去看，比如jsp/asp.net的角度，也是多数TX都关心的是在线客户数，但我做web server的，根本不会管连接是哪个客户的。对我来说只要一次http request完成，连接就被放入池中了。这个是现代web server的基本实现，比如apache web server。所以对我来说，所谓的用户在线状态根本就没有意义。这也是为什么我强调stateless易于优化的原因。考虑stateful调用，如果一个组件是有状态的，则在两次调用间我要保存该组件的状态，这对于服务器是非常麻烦的。基本的实现只有两种，一种是该对象不释放，然后等第二次连接时继续使用。这种方案的缺点很明显，就是时间长了服务器要完蛋。第二种是更通常用的，EJB和COM+都是这种方案，就是对象释放回对象池，状态持久于其它地方（比如内存/数据库），也即surrogate，第二次调用时，再从内存/数据库恢复对象状态。这个不会让服务器时间长了就完蛋，但是效率也不会高，主要就是surrogate对象的reactivate是比较费劲的。如果是完全的无状态对象才是比较理想的。

2。关于HTTP RPC调试的问题。实际上您说的不确切，基本上调试HTTP RPC不会用到Sniffer这么复杂的东西。它的原理很简单，就是一个port forwarder。简单说就是一个本地80端口上的daemon，收到caller传入的参数后，forward到服务器，然后收到服务器response后显示出调试信息后再回传给client。这东西写个简单的，在unix下10分钟的事儿，还用不上Sniffer。各个平台上都有这样的东西。

3。HTTP RPC的回调是可以实现的，您GOOGLE web service callback即可。但是这个实现确实不能说是精彩。但话说回来了，RPC中callback没有一个做的很好的，毛病都很多，您可以列举您熟悉的RPC callback，我都可以以实践经验告诉您它的不足。说白了，callback是RPC方式本身的一个本质缺陷了，倒不是HTTP本身的问题。毕竟隔了个网络不可能象本地调用那样一个function pointer搞定一切。我觉得这个只有下一代远程调用模型出来后才能解决。

4。关于活的最好的网络协议。我本来讨论的基础是各种可以承载HTML内容的网络协议，当时主要列了SMTP/FPT/TELNET/HTTP四种，在这四种中我个人意见是HTTP生命力最强。至于扩展到所有网络协议，那DNS强于HTTP那我倒无意见。

最后发点牢骚。其实我本人是做高性能服务器软件工作的，需要啥就做啥，HTTP、FTP、TELNET/SSH、P2P都实现过。我们这个圈子比较封闭，跟外界交流也不多，很少有TX能够接触到这种工作。我在这个圈子里本来是属于对HTTP没什么好感的人，我的兴趣主要是在多机虚拟化上。偏偏在这里讨论就被挤兑成一个HTTP FANS了。我觉得技术问题向来是不能读书不求甚解的。最怕的是一知半解还不肯承认。碰上自己说不明白的，要么指责别人新兵蛋子让人自己翻书，要么就说这个问题太低级，自己翻书或者GOOGLE。我对我自己不懂的事我从来也不会瞎说，或者说错了承认就是了。比如我对于网络游戏这一块的serverside我就是不熟悉，任何东西，说错了我愿意承认。这很多时候是个态度问题。客观的说，西西河信息技术版宏观视角比较多，谈论IT业界天下大势的，有不少新奇见解。但论微观角度，实际技术水平比其它专业论坛差距较大，这与读书不求甚解的风气恐怕有关，宏观的东西不需要太多技术上的验证，所以容易过关。一旦到微观技术视角，很多东西非黑即白，并不容易混过去，这里开口与不开口差异就大了。当然我想也许这是CCHERE的特色吧，其实这也没有什么不好，比如邓侃先生、太守同学的系列，我也都耐心的看完了，不管同不同意，也很喜欢。我相信多样的才是美丽的，所以也希望西西河IT版越办越好。如果言辞有得罪各位老大的地方请谅。

来的人也都是冲着时政经济的话题。技术讨论在这本来就不是亮点，要是真想讨论技术问题，CSDN都比这强。

看了大家的讨论，收获很大。讨论的时候大家热情洋溢了一把，也没吵架，看来大家还是就事论事的。

在我看来，http当今的状态，如大家所说，是很多因素造就的，yueyu说的杀手应用，moniker小哥从协议本身的角度进行探讨，还有无斋主人提到的企业行为，都有不可忽视的影响，老叫花受教了。

我其实很感兴趣的一个事情，是这里面的“经济因素”，比如，一个软件，或者协议标准，是设计的对机器友好重要呢，还是让人用起来更方便才好；换句话说，是让人更经济，还是让机器更经济。

比如，一个现存的软件或者协议标准，是不是扩展它比建立新的软件/协议更经济？

比如，企业/政府对软件或者协议的限制和开放，是怎么影响用户和开发人员行为的？

这些都是有意思的问题。

在此对太守帮助维护讨论秩序表示感谢。

为避免误解，特此说明。

1. Yueyu和羽羊是对的，HTTP支持Web这个killer app。一人得道，鸡犬升天。细说起来，与Web相关的几个技术，HTML，HTTP，Browser等等，起初缺陷都很多，但是架不住市场饥渴，于是不成熟的技术也大红大紫。

2. 无斋是对的。Firewall vendor看到HTTP大行其道，就预留了方便之门。岂不料，方便门又反过来促进了HTTP更加大行其道。

3. 太守是对的。HTTP一些看起来瑕疵的地方，也有有用的一面。真正的瑕疵，经不住大浪淘沙，会被逐渐淘汰的。

4. 老叫化是对的。进化的过程，是性能和代价角力的过程。当缝缝补补性能能够苟延残喘的时候，更新的代价有更大的话语权。反过来，如果性能的缺陷无法令人容忍，那么大家就能忍受高昂的代价去更新进化。所谓相对平静的进化缓慢的时期，是对立面势均力敌的均衡状态。

5. 我也是对的。唯恐天下不乱的看客们，盼望着人们对于互联网的期望和要求越来越高，最终打破沉闷的均衡状态。所以，坚持不懈地放大互联网种种缺陷。

1. 西河的气氛好，理性，礼貌。其它网站的确也有不少好帖子，但是读读那些回帖，缺了西河的心平气和，多了谩骂的野蛮暴力。

2. 我的不少好友在西河，如果我把这些帖子发到其它地方。是不是还得挨家挨户地去拉人？

3. 气候的养成非一日之功。今日西河的确政经讨论很热闹，但是回想当年，经济在西河也是冷门。

我也可以学习学习，长长见识。

参与讨论人员的技术背景不同，这对于常常受制于本行业限制的人来说，是个认识外部世界的好机会。如果要讨论细节问题，IRC或者Maillist自然是最好的选择了，但是这种讨论脱离不了本行业技术的局限性。

恭喜：你意外获得【通宝】一枚 关闭

【回复讨论】 2470360 号帖 [赞同理性讨论，我同意您基本的意思，但有些补充] 原创 请使用【分类词】来注明

鲜花已经成功送出，可通过工具取消

提示：此次送花为此次送花为【有效送花赞扬，涨乐善、声望】。

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

我承认您说的都有道理，而且这种讨论确实会陷入这样的矛盾境地，就是谁都无法实证哪种转换的效率低（比如说主机顺序到ANSI的转换效率高低与be/le转换效率的高低），这样谁都只能选择对自己有利的去讲，比如您就选择说如果大小写相关，可HTTP本身跟大小写没有任何关系嘛，为什么非要挑大小写转换这样的例子来说明呢。您说be/le在电路级转换效率很高，这有点抬杠了，问题就在于这虽然很简单，任何一个学数电的学生都会做，但哪个CPU，哪个主板上专门做了le/be转换的电路啊。

我只是陈述一种客观事实，所有基于BINARY的RPC都完蛋了，从CORBA开始，到RMI结束，我试图说明为什么这么多binaryRPC都不行，所以才列举了这些因素。我觉得讨论一下为什么binary RPC会失败，意义可能更大一些。

其实我开始强调的是HTTP的stateless，我刚开始并没有说http文本化是优点。是YueYu说HTTP只能传输文本，并且说这是它的问题，我才开始说文本也有优点（注意我是在强调说也有优点，并不是说文本化就完美的不行）。其实我本身支持的是HTTP的stateless，我一开始并不是说文本化是优点，是后来YueYu讨论时一个劲儿的说文本化不好，我给挤兑到那个份儿上了。事实上HTTP只能传输文本么？显然不是。HTTP没有表示层协议，跟文本不文本没有关系。。这里有好几个同学讨论时都没搞清楚这一点。

如果您还不满意的话，我可以再强调一遍，我支持的是HTTP的stateless，不是文本化。。这样可以了吧。

其实我前面已经诉过苦了。我本身又不是一个HTTP的FANS，我看好的未来技术是多机虚拟化，支持的现有技术是P2P。做web server时吃够HTTP标准的苦了，我为啥要说它的好话呢。。开始我只是随便说点关于HTTP RPC的分析而已，没想到吵起架来给挤兑成一个HTTP控，还是个支持文本化的变态。。好象我跟二进制有仇似的。晕。