主题：【原创】我有一个问题 -- 美人他爹
DEL
DEL
DEL
DEL
DEL
俺有个坏毛病，就是一边开着QQ跟MM聊天一边回复，所以就一堆短回复，这也是为什么俺很少发主贴的原因。。。。现在MM下线鸟，把几个短回复整合成一个吧，也方便大家看。结果发现俺等级2个小时只能发10贴，晕。MM误事啊。[又花5分钟时间把短回复的贴子标题全改掉了，K，以后再不干这样的事儿了。]
1。yueyu同学认为，HTTP适合传文本，而RPC不适合用文本，言下之意应该用二进制方式比HTTP更合适。
反驳：
显然yueyu同学对于RPC的情况不了解。在之前，比如CORBA，使用的就是二进制协议，结果被淘汰了。RPC不适合用二进制一个主要原因就在于RPC很多是在异构平台，什么是异构平台呢，就是UNIX/LINX/WINDOWS之类OS的大杂烩。。异构平台的一个大问题就在于二进制数据解释上有分歧，这个类似于中文乱码问题，比如MOTOROLA CPU和INTEL CPU架构下有big indian和little india的问题，又比如早期的机器对于字节长度的定义还不一样。这样构造一个各平台都能用的RPC协议几乎成了不可完成的任务。CORBA的失败，有很多原因，这个就是其一。而文本用于RPC有很大的优势就是定义明确，不管是ANSI还是UNICODE，各平台都是一样的。而且，RPC调用，如果您真的做过一遍，就会明白，实际上文本已经能够满足绝大多数要求了。
2。yueyu同学认为，HTTP协议解决不了TIME_WAIT问题。这个是在有意无意的混淆概念。TIME_WAIT是传输层的问题，HTTP协议是应用层和表示层的协议，两者根本就不发生关系。任何一个协议，包括yueyu认为的，一种“理想”的binary的RPC协议，都不可能解决TIME_WAIT问题。这个问题是TCP/IP协议栈上multiplex的问题，跟HTTP没有任何关系。
3。yueyu同学认为，HTTP1.1的修正太大了，以致于没有实用价值。这个一方面yueyu同学的概念没搞清，HTTP1.1协议有一个KeepAlive标头会影响到连接情况，但这个实现跟原文所说的修改socket完全没有关系。这个的实现只需要做一个socket连接池即可解决问题。HTTP1.1不是什么先进的玩艺儿，主流的web server没有一个不支持它的。HTTP1.1也不需要修正socket，那是TCP/IP栈的事。如果实现HTTP1.1要修改tcp/ip栈的话，那Robert McCool就要疯掉了，Linus也要疯掉了。（记住，当初BORLAND kylix需要修正linux内的一个BUG，结果被LINUX社区狂骂，要Robert McCool也这么干的话，apache就不可能有linux版本了）
4。关于长连接和短连接，这个是个大题目。很多对server side不理解的TX都有一种错觉，就是网络连接/数据库连接应该越早打开，越迟关闭越好。这是不对的，因为现代的数据库都有连接缓充概念，并且在服务器端和客户端都有连接池。打开连接的代价比想像中要小得多。并且多数应用服务器都是鼓励要用连接时再打开的，这样能够提高服务器的可伸缩性。比如EJB吧（如果需要COM+的例子，也一样的），stateless bean的效率最高这大家都公认，一个原因就是不需要维护两次调用间的状态，如果把数据库连接暂存下来，会导致surrogate的代价，反而效率大降。
5。我想我和Yueyu同学的看法分歧主要原因就是我是做application server的，而Yueyu同学可能主要是网络游戏编程，这是完全不同的两种情况。网络游戏那样的连接，只能是长连接，没有什么办法。但application server强调的是快速短连接调用，一个application server的成败很大程度上受其对象缓存技术高低的影响。
1.Yueyu同学认为HTTP还需要MIME才能传输二进制内容,所以HTTP不牛B.这显然对于Martin Fowler同学提出的Layer概念的直接违背（参考 PEAA）啊.HTTP只管传输,不管表示的,谁规定一定要MIME才能在HTTP上进行二进制的传输呢.这是误会之一.
2.HTTP1.1颠覆了HTTP1.0。这个我可以肯定的告诉Yueyu同学，你自己写一个web server就会明白。HTTP1.1跟HTTP1.0从实现上差别并不大。要不就不叫HTTP1.1而叫HTTP2.0了。
3.TIME_WAIT时间，您说设成0，在局域网环境问题不大。这说真的比较汗，这跟局域网环境没有什么关系，而是在于TCP/IP协议栈的重用方式有关。我见过的协议栈的算法大多数是前一端口加一后作为下一端口的，这意味着多数情况下，TIME_WAIT为0也不会太倒霉（除非点儿背到在4分钟之内65536个端口都用了一遍）。而这个跟局域网不局域网，影响很小，主要还是由于这个重用方式有关。看起来您对LINUX应该比较熟悉，看看tcp_ipv4.c文件中的tcp_v4_get_port就明白了。
4.您举streaming conference为例子，显然是不对的吧。我说的RPC跟streaming conference能一样吗？标准的RPC都是指远程过程调用，返回个object array已经是顶天的难度了，总不成让function call返回一video stream吧。就object array的问题，一般SOAP调用中返回xml，有很多人认为效率不高，就有用json的，但从来没有人把object array弄成binary传回来的，无它，没有什么特别的必要而已。两者间差10%的效率而牺牲可移植性，多数架构师都不会这么选。。
至于您说的streaming conference，我理解是video audio stream，那需要专门设计协议这应该是的。
5.您的意思是IBM卖机器，所以IBM狂推Web service。估计您没想到Web Service是MS提出来的吧。。。原作者叫Don Box，是MS的员工。IBM力推WS的主要原因是。。。。IBM自己的异构平台太多(AIX.400.OS/390。OS/2。LINUX），binary的RPC搞不定。
你强调的http多好是因为：stateless。但是stateless的代价是scalability的下降。我说time_wait设为零是反讽啊。。。
修正一下，看来你并没考虑到多级路由背后端口快速被用尽的场景。以为都是局域网一两个路由呢
至于http其实不适合传binary其实我们没有分歧。boundary都必须用特殊文本的，传binary太别扭。
至于rpc，真正应用起来大小endian自己写很简单，说没法解决真是滑稽了。文本传数组之类的浪费太惊人
ibm想不想卖机器和don box是不是ibm员工有逻辑关系么？
我的观点很简单，http流行不过因为其简单而已，简单是针对他应用而不是标准本身，因为httpserver太多鸟，程序员不用自己干很多事情了，养懒也养傻了。但他低效的特性使你在有能力的情况下将无情地抛弃他。简而言之，http不是一个放诸四海而皆试用的大一统标准
还有，新兵蛋子不可怕，多读多看多写多思考，不要对某种技术产生感情而不够理性了
http://www.ccthere.com/article/2424203
楼主问的是协议层
传输层更复杂，协议层花头更多
因为所有公司都会开放ＨＴＴＰ ｐｏｒｔ，所以只有ＨＴＴＰ能穿过Ｆｉｒｅｗａｌｌ。
这个是最最关键的原因，其他任何基于ＴＣＰ／ＩＰ的，一碰上Ｆｉｒｅｗａｌｌ就死才，必须在Ｆｉｒｅｗａｌｌ上开个口子，而通常ｄｅｆａｕｌｔ是封上的。
1。要Scalability恰恰必须避免长连接，您要都长连接了，除了增加服务器性能，你还有什么可能性服务新连接呢。所以恰恰您的方案不能增加Scalability。而且恰恰是您的方案才适合让IBM卖服务器，所以我不知道您的逻辑在哪里。
2。关于TIME_WAIT为0的问题。我前面很含蓄的说过了，您没真正理解这个TIME_WAIT的问题，TIME_WAIT实际上最小值是1，估计您还没弄清楚为什么这样吧。
3。即然您硬要不了解的东西扯到底，那我就问你，多级路由对TIME_WAIT的值有什么直接影响，多级路由何以会快速耗尽端口？这两者逻辑在哪里？
4。关于RPC与big/little Endian的关系问题，我可没说过不能解决（废话，软件上除了N/P完全问题，有理论上不能解决的么）。但如果选择一种，比如选big Endian，那另一种在传输时是否需要大量的转换工作，这样合算吗？或者说，设计时是不是双方还要协商下使用big Endian/little Endian？这样不是大大增加了协商的复杂程度了（这个在TELNET协议中倒有类似的方式，但是那是长连接的啊）。
5。我觉得您的跳跃性够强，我本身也不是HTTP的FANS，做高性能的其它服务端我当然也做过，包括P2P。我前面讨论时一直都在说RPC，倒是您一会儿streaming conference，一会儿又BLOB的跳来跳去。我前已经强调过，video/audio stream一定得自己重写协议的。对于RPC本身而言，几乎不可能有大量传输binary的情况，所以用文本足以。您要真做过RPC，应该知道，这类应用99%的情况下，传输内容量在10k字节以内，10K字节的内容用binary和text间有多大的差异呢。又举个例子吧。MS在WS/REmoting里，都提供了binary的serializer，也就是说你把传输内容改为binary是非常方便的，可惜就这样的情况下，程序员也很少会用binary，无它，binary在调试时怎么看啊？哪有text方便。
6。我说点无关的，就是关于文风的问题。我最反感的，就是一会儿说人新兵蛋子，一会儿又说某个问题你去翻书去，没功夫给讲之类的。
您既然要比这个，我可以跟您比，而且我有十足的信心。我1992年开始做C程序员，1995时就是国家认证的系统分析员。。估计这个证书的价值您还不知道，1995年时这个人数还没超过200人。。可不是你们现在那个充水的系统分析员可比。往少里说，做SA的时间已经是14年了，不知您有这个资本么。。。
这是气话，我只希望能听到您客观的答复，也希望您以后别老是把技术问题政治化，一会一个新兵蛋子挂在嘴边。这不是做技术的认真态度。
删了算了，不做口舌之争。我有点personal了
本来都是技术性的问题嘛，何必扯上无关的东西呢。其实我本来也不是一定要支持HTTP吧。您算一算也应该知道我做纯SOCKET比HTTP时间要更长，我开始做socket是在unix平台，那时移植到win平台时MS自己的tcp/ip协议栈都还不完善，用的是novell提供的。那时候我想做HTTP FANS都还没机会。我也不认为HTTP是万能药，只是说HTTP在RPC上有特殊的优势而已。
binary的RPC，我觉得一个典型的例子就是CORBA，结果就是失败；MS提出的DCOM，也是binary的，一样也不够成功；至于SUN的RMI，是还有人在用，但远称不上主流了。倒不是说binary的RPC失败的本质原因在于二进制，但binary在异构平台上不方便，这是一个非常大的问题。就前面说的big/little endian，你说选择哪一个，业界能够大家都接受？毕竟谁选择妥协，谁就要付出性能上的代价，这个远比二进制和文本间的差异大（废话，每一个DWORD数据都要倒一遍，这效率降低的不是一点半点）。当然内部binary转为ANSI/UNICODE文本，一样也有效率降低的问题，但是设计时平台一般都考虑到这一点了，效率怎么也比b/l endian转换好点。另一个对于程序员来讲，二进制形式对于调试来说不够友好，要VS那样的IDE界面有自已的查看器的还好，GDB这样命令行调试的，binary data struct怎么方便的看啊？当然不如文本的方便，这一点从程序员的角度出发也是愿意用text的。
就LZ原来说的，新协议，我确实更看好P2P方式。如果能够有一个吸收HTTP优点，但又支持P2P方式的网络协议，那是更好的。至于RPC能不能用P2P，这个存疑，毕竟我觉得现在对于P2P的理论研究还没跟上。
对于中国来说，P2P方式的类HTTP协议有特殊的意义，就是一劳永逸的（当然这个我也怀疑）使GFW失效。
1.stateless/stateful就是个相对概念。某种程度上,HTTP的stateless对提高server段的“并发连接数目”有很大的好处。比如，某WEB server的并发连接是60/每秒,但通过时分复用，“并发客户数目”可以做到1800/每30秒。这里的关键是stateful是一个CASE BY case的定义。对西西河而言，用户在线的状态是多少时间更新一次？这个只有铁手自己知道。
2.TEXT BASED指的是HTTP协议本身，HTTP的“body”采用什么格式（文本，二进制）完全由客户端和服务器协商决定。就是文本格式，HTTP也可以指定压缩格式来提高应用数据的传输效率（速度）。TEXT BASED的最大好处就是方便调试和监控，非常简单的sniffer程序就可以搞定。调试完成后直接将“body”格式转为压缩即可提高效率。
3.MIME的最重要的目的不是传输非文本内容，而是用于防止宝贵的带宽不用于传输网络“废话”。比如客户端的请求说可接受的内容格式仅限于html/txt，服务器给的应答是SGML/TXT,这服务器不是找抽吗？！
4.主从概念的HTTP没有一种“回调机制”。从这个角度上看，HTTP不适合RPC是肯定的。
5.关于“新兵蛋子/SA证书”的事情还是少讲为好。大家还是对事情不要对人。拜托。
6.最多网络协议中活的最好的是DNS而不是HTTP。FIREWALL首先要让DNS通过，然后HTTP才能有意义地工作。