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

恩恩，这个题目口气太大了，我掌自己先，标题党而已了，大家别介意。

一不留神，自己北当作了不明真相的围观群众了，sigh。。。

好吧

HTTP不过是基于TCP／IP上的协议层的一种协议而已。当然他也可以基于其他传输层协议，不过目前browser基本上只用tcp而已了。

说到http，那么他的用途其实可以从他的名字看出来，hyper text transfer protocol，要问我为啥这名字背的这么熟，还不是一天到晚和人争论蒸熟的阿。。。

这协议名字已经清清楚楚地告诉了我们，他是用来传输文本的。那么自然，传输文本么，他可以用文本的tag来做起始标记。这对协议解析者来说，是好是坏，我不好说。我只能说，事实是，大量tag parser，大量容错能力超强的tag parser如雨后春笋般地冒了出来。浏览器们就是这个tag parser上面进行了重重复杂的封装和表现的产物。不得不说，对于文本的表现，这个协议是合格的。当然，他也可以用来传输binary数据。不过早期他是不能的，所以他借用了另外一个标准，MIME，这是Multipurpose Internet Mail Extensions用来传输非文本内容。比如图片等。所以http真的很牛么？不见得吧，果真如此，何必借用他人标准来补充了，这也叫不用打什么补丁？Http 1。1相当的复杂，基本上颠覆了Http 1。0的很多概念，有空细说。

Http基本上初衷就是为了在互联网上展现文字信息而已。当然，本质就是stateless和textbased了。然后浏览器就流行开了。浏览器流行开了，意味着大部分电脑上都装有了这么一个能解析同一个标准的客户端，人们才开始在这个协议上面下功夫，让他干更多事儿。好，然后他可以浏览图片了，可以执行一些简单的脚本了（jaascript）。好，基本上传统的http协议就到此为止了。下面有朋友说，http天然适合rpc，我真是有些无语了。

rpc在http的世界里面对应的，基本上就是webservice了，不要和我争论这个基本上了，我知道他还可以被其他的用法使用，我也用过。我是说主流。

webservice这么完全一个基于文本的rpc协议，最大的特点，就是人容易读。但是很讽刺的是，rpc是人来执行么？不是。电脑容易不容易读，可不是设计webservice的人想的事情了。事实上，如果基于二进制方式来作rpc，或许更天然适合计算机来执行。

不过讽刺的事情是，当年那帮新兵蛋子成长过程中就是学http合html，他们自然更会用这套东西。而且这东西的确省心，不用考虑性能的前提下，的确是不错的选择。

好，终于拐弯抹角地说到性能了。

如果我们用stateless的方式来调用rpc，那么，意味着每次网络连接都要关闭（请暂时不要和我说http 1。1的long socket）。那么请问，在一台没有经过特别配置的linux server他所能接受的并发连接是多少？答案是不超过60个每秒。我不卖关子，原因就是基于tcp的socket关闭，默认有4分钟的TIME_WAIT，而为什么是四分钟，因为网络的复杂性，各级路由为了保证tcp这个协议的可靠性，可能会重发某些packet，而为了不污染新的socket，这四分钟算是静默期。当然，你可以把这个时间调整为0，在局域网环境下应该问题不大。但是更好的解决办方式，client用long socket，尽量复用连接。至于您如果还要问，为什么会这样，那我实在不想解释了，您得补补课。

当然，http 1。1加入的long socket，可以很大程度解决这个问题。但是我们要问，经过这样修补过的http还是那个简单的http么？如果您有能力，自己设计一套最适合自己应用的协议，您为什么要用http。比如streaming conference。的确可以用http来分段发，但是确实有更好的办法来做，如果您有能力做，为什么不呢？能用10台server干的事情，为什么非要用200台来做呢？当然，如果没有那么多人能干这个活，用http顶着先也可以，毕竟能招来不少便宜的人手。不过，我实在是怀疑，大力推广webservice的ibm其实就是想托慢应用程序的效率来卖更多机器，毕竟人家是卖machine的！