- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】我有一个问题 -- 美人他爹
家园 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小键盘做了一个中文输入法。这就是无聊的我的学生年代干的很疯狂的活之一。
所以在开发效率这点上我没有什么异议。其实，用二进制协议之所以高效，是因为从协议制定到协议实现，都做了很多的优化工作。而在基于文本的协议中，这些工作，都交给了程序来执行。所以在运行效率和开发效率上，两者刚好反过来，至于权衡取舍，那就看具体的情况吧。