五千年(敝帚自珍)

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

共:💬73 🌺79
全看分页树展 · 主题 跟帖
家园 HTTP,HTML,TCP/IP,UDP拨乱反正

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

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

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河