五千年(敝帚自珍)

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

共:💬73 🌺79
分页树展主题 · 全看首页 上页
/ 5
下页 末页
    • 家园 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的!

      • 家园 接上一篇,继续讨论,纠正一些看法

        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搞不定。

      • 家园 MM下线鸟,多个短回复合成一个长回复[其它几个可以无视]

        俺有个坏毛病,就是一边开着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的成败很大程度上受其对象缓存技术高低的影响。

        • 家园 哎,你因果关系没理解

          你强调的http多好是因为:stateless。但是stateless的代价是scalability的下降。我说time_wait设为零是反讽啊。。。

          修正一下,看来你并没考虑到多级路由背后端口快速被用尽的场景。以为都是局域网一两个路由呢

          至于http其实不适合传binary其实我们没有分歧。boundary都必须用特殊文本的,传binary太别扭。

          至于rpc,真正应用起来大小endian自己写很简单,说没法解决真是滑稽了。文本传数组之类的浪费太惊人

          ibm想不想卖机器和don box是不是ibm员工有逻辑关系么?

          我的观点很简单,http流行不过因为其简单而已,简单是针对他应用而不是标准本身,因为httpserver太多鸟,程序员不用自己干很多事情了,养懒也养傻了。但他低效的特性使你在有能力的情况下将无情地抛弃他。简而言之,http不是一个放诸四海而皆试用的大一统标准

          还有,新兵蛋子不可怕,多读多看多写多思考,不要对某种技术产生感情而不够理性了

          • 家园 您显然还没明白Scalability的意思是什么。

            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失效。

                • 家园 我觉得你太在意技术的细节了

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

                  • 家园 还有一点,您的一个没弄清楚的地方。HTTP协议

                    本身与传输内容没有太大关系,您文内老在强调多字节环境下HTTP如何如何之类的。实际上HTTP标准中对多字节单字节有什么约定呢?他只管理服务器与浏览器之间的调用约定,至于多字节单字节会不会出错,跟HTTP没有什么关系(跟浏览器和ISAPI(对IIS来说)或apache mod有关系。您还是把表示层的概念给混进来了。或者更具体的说,您跟前面几个TX犯的错误一样,把HTML跟HTTP给混在一起了。

                  • 家园 还有一点最汗的是。

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

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

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

                    • 家园 stateles也不是http独有的特性

                      所以拿来解释http在技术上的成功,说服力还不太大。

                      按照我的说法,http的成功在于沾了html的光。按照羽羊兄的说法,就是http在成名之初,找到了一个killer app--当然,他站的高度比我更高,更有概括性。而你举的所有失败的例子,基本上都不具备这点。

                      而即使是你举的例子中的SMTP,因为找到了一个依附于其上的killer app,所以即使它是stateful的,至少到目前,活得还是好好的。这其实也是一个很好的反面例子:stateful和stateless并不是其成败的根本因素,killer app才是。

                      • 家园 如果是HTTP沾了HTML的光的话,我举了三个例子

                        TELNET、FTP、SMTP。这三个协议成名都在HTTP之前,也都有各自的kiler application。按您的说法,还有按一般逻辑,都不需要重新再发明轮子了,对吧?为什么人们没选择HTML over smtp?没有选择html over telnet?没有选择html over ftp?这几个选择都是可以实现的,尤其是html over smtp,还在大量应用。

                        今天在物联网那个贴子里发太多了,现在已经超过发贴限制了。把另一个回复贴过来吧。

                        我觉得您对于协议分析那段写的

                        过于学院化了。您要是真实的做一回服务器,别的不说,就一个最简单的telnet服务器,您就会痛恨binary不已了。最简单的,也是我前面已经说过的,调试时咋办呢?尤其是RPC调用返回中文的时候。您要能看HEX如看中文般流畅那我非常佩服您。

                        今天发不了贴了,您有意见只管回,明天下午才能回复。谢谢讨论,尽管在这个贴子里吵成这样非常不开心。

                        • 家园 花一个,别生气别生气

                          你们的讨论我学到很多东西,可别生气,你们生气了我怎么学学习呢。

                        • 家园 别的不说,这活我还真的干过

                          在51单片机上驱动ISA口的8029网卡,在裸机上用汇编实现一个完整的telnet服务器和客户端。另外,为了实现用单片机上bbs(当然是基于telnet协议的那种,不知道还有多少人记得那种古老的bbs?)灌水的目的,还特意为4x4小键盘做了一个中文输入法。这就是无聊的我的学生年代干的很疯狂的活之一。

                          所以在开发效率这点上我没有什么异议。其实,用二进制协议之所以高效,是因为从协议制定到协议实现,都做了很多的优化工作。而在基于文本的协议中,这些工作,都交给了程序来执行。所以在运行效率和开发效率上,两者刚好反过来,至于权衡取舍,那就看具体的情况吧。

分页树展主题 · 全看首页 上页
/ 5
下页 末页


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

Copyright © cchere 西西河