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

随便您说的什么协议，凑合凑合传输HTML都没什么问题，可是就像您之前几篇帖子所言，http干这个活最合适不是？就好比秤砣，离了秤杆也没关系，它还能钉鞋、镇纸、杀人越货，秤杆子离了秤砣用处也不小，能敲锣、当教鞭，顺便还能挠痒痒，但是归根结底，还是称不离砣的状态广大人民群众比较喜闻乐见，所以秤砣火了，秤杆子也火了，但是您非得较汁，非得知道到底是秤杆子nb，还是秤砣nb，那就没办法了，还是我帖子里的一句话，这个叫做“轱辘话转圈儿说”，嘿嘿

NB，而您的回答是因为HTML NB，而HTTP适合HTML传输，所以HTTP NB。这个好象确实是您说的循环论证。我想说的是本质问题，您也看到了，在与TELNET、FTP、SMTP几个协议的比较中，只有HTTP是本质上stateless的，我觉得这才是HTTP NB的地方。就是因为它是stateless，所以它会流行起来，而不是说因为适合HTML传输才NB起来的。或者说，您是否有思考过，为什么HTTP适合HTML格式传输呢？我觉得这才是真正的答案。

如果当初选择在SMTP上传输HMTL，从表现层上来看没有任何问题。那为什么人们没有在浏览器上选择用SMTP协议传输HTML呢？我觉得您要是回答了这个问题，就应该真正回答了LZ原来的问题，为什么HTTP流行。SMTP去传输HTML，不仅理论可行，在实践中也是可行的，现有的MAIL网络流量中，HTML恐怕占了主导地位。那为什么HTML over SMTP没成为浏览器的主流呢？

是一个技术层面的答案。这个算是见仁见智吧。

HTML除了在HTTP上传输外，没有什么其它主流应用。HTTP用在RPC调用上，不管是web service/soap/rest，都已经是业界的一个标准，并且全面压倒了过去的RPC调用（如CORBA，COM+/DCOM、RMI）。而HTML混到现在还是网页应用，并且未来任何一种RIA应用，都在一定程度上废掉了HTML，理论上讲，没有一行HTML的FLASH或者SL都是可行的。

看您的意思，恐怕要从技术层面分析一下tcp/ip协议族了，这可是个大活儿，小羊可不敢凭印象就胡喷，还是且去读书吧

要不您老先开个题？小羊搬凳子等着听课

============================================================

咦？俺的tcp/ip详解和打印的RFC扔哪里去了~~~~

哦，角落里发霉呢。。。。。。。。

的层次。在七层模型中，前面举的HTTP、SMTP、TELNET、FTP最多只实现了上两层，跟TCP/IP还远着呢。HTTP协议本身与TCP/IP相关的只有一个吧，就是它选择了TCP而非UDP；另外还有一个端口一般为80的约定（TOMCAT就缺省是8080），其它的都是应用层与表示层的东西，与链路/传输层没有任何关系了。你要看RFC也就是那几个协议的RFC，HTTP算是一个定义简明又高效的典型例子。尤其是其无状态的本质，大大方便了服务器端的实现，兄弟不才还写过HTTP SERVER、TELNET SERVER和FTP SERVER部分实现工作，确实是HTTP SERVER的优化最好做，从做RPC来说，HTTP SERVER肯定是最好的选择。

HTTP：http://tools.ietf.org/html/rfc2616

TELNET：http://www.faqs.org/rfcs/rfc854.html。TELNET的协议有N个，尤其是IBM 3270/5250有自己的独立的协议，与普通的VT100/VT220有很大的差别。但从TELNET基本思想来说，RFC854已经足够说明。

SMTP：http://www.faqs.org/rfcs/rfc821.html

这个是不带增强版本信令的，就是那个HELO开始协商的

FTP：http://www.faqs.org/rfcs/rfc959.html

标准的FTP SERVER。

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

一不留神，自己北当作了不明真相的围观群众了，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的！

webservice都半死不活了，不带这么鞭尸地~~~，人家现在改头换面玩saas了

DEL

个层面的东西。我觉得您原意是SOA吧。。。。

DEL

DEL

DEL