HTTP长连接服务器端推技术.doc

上传人:11****ws 文档编号:3179638 上传时间:2019-05-24 格式:DOC 页数:7 大小:93KB
下载 相关 举报
HTTP长连接服务器端推技术.doc_第1页
第1页 / 共7页
HTTP长连接服务器端推技术.doc_第2页
第2页 / 共7页
HTTP长连接服务器端推技术.doc_第3页
第3页 / 共7页
HTTP长连接服务器端推技术.doc_第4页
第4页 / 共7页
HTTP长连接服务器端推技术.doc_第5页
第5页 / 共7页
点击查看更多>>
资源描述

1、HTTP 长连接服务器端推技术服务器推送(Server Push) 推送技术的基础思想是将浏览器主动查询信息改为服务器主动发送信息。服务器发送一批数据,浏览器显示这些数据,同时保证与服务器的连接。当服务器需要再次发送一批数据时,浏览器显示数据并保持连接。以后,服务器仍然可以发送批量数据,浏览器继续显示数据,依次类推。客户端拉曳(Client Pull) 在客户端拖曳技术中,服务器发送一批数据,在 HTTP 响应或文档头标记中插入指令,让浏览器“在 5 秒内再次装入这些数据”或“10 秒内前往某 URL 装入数据” 。当指定的时间达到时,客户端就按照服务器的指示去做,或者刷新当前数据,或者调入新

2、的数据。 其实 push 和 pull 这两种技术手段非常不同,但目的几乎一致,都是为了给最终用户方便的提供最新信息。 在服务器推送技术中,HTTP 连接一直保持着,直到服务器知道自己已结束发送数据并发送一个结束信号,或者客户端中断连接。而在客户端拖曳技术中,并不保持 HTTP 连接,相反,客户端被告知合时建立新连接,以及建立连接是获取什么数据。 在服务器推送中,奇妙之处在于“multipart/mixed”格式的 MIME,它能够使一个报文(或 HTTP响应)包含许多数据项、在客户端拖曳中,奇妙之处在于 HTTP 响应头标(或等效的 HTML 元素) ,它能告知客户端在指定的延时时间后执行何

3、种动作。 服务器推送通常效率要比客户端拖曳效率高,因为它不必为后续数据建立新的连接。由于始终保持连接,即使没有数据传输时也是这样,因此服务器必须愿意分配这些 TCP/IP 端口,对于TCP/IP 端口数有限的服务器这将是一个严重的问题。 客户端拖曳效率低,因为这必须每次为传送数据建立新的连接。但是它不必始终保持连接。 在实际情况中,建立 HTTP 连接通常需要花费相当多的时间,多达一秒甚至更多。因此从性能上考虑,服务器推送对于最终用户更有吸引力,特别是对于需要经常更新信息的情况下。 服 务器推送相对客户端拖曳的另一点优势是,服务器推送相对比较容易控制。例如,服务器每一次推送时都保持一个连接,但

4、它又随时可以关闭其中的任何连接,而不 需要在服务器上设置特殊的算法。而客户端拖曳在同样的情况下要麻烦许多,它每次要与服务器建立连接,服务器为了处理将客户端拖曳请求与特定的最终用户匹配 等情况,需要使用相当麻烦的算法。 如果实现服务器推送的 CGI 程序是使用 Shell 脚本语言编写的,有时会存在一些问题。例如,客户 端最终用户中断连接,Shell 程序通常不能注意到,这将使资源毫无用处的浪费掉,解决这一问题的办法是用 Perl 或者 C 来编写这类 CGI 程序,以使用户 中断连接时能够结束运行。 如上所述,在服务器推送中,多个响应中连接始终保持,使服务器可在任何时间发送更多的数据。一个明显

5、的好处是服务器完全能够控制更新数据的时间和频率。另外,这种方法效率高,因为始终保持连接。缺点是保持连接状态会浪费服务器端的资源。服务器推送还比较容易中断。接下来就大概说说服务器推送技术 服 务器在响应请求时,HTTP 使用 MIME 报文格式来封装数据。通常一个 HTTP 响应只能包含一个数据块。但 MIME 有一种机制可用一个报文(或 HTTP 响 应)表示将多个数据块,这种机制就是成为“multipart/mixed”的标准 MIME 类型。multipart/mixed 报文大体格式如下: Content-type:multipart/mixed;boundary=ThisRandomS

6、tring -ThisRandomString Content-type:text/plain 第一个对象的数据。 -ThisRandomString Content-type:text/plain 第二个对象的数据。 -ThisRandomString- 上述报文包括两上数据块,二者的类型都是“text/plain”。最后一个“ThisRandomString”后的两条短线(-)表示报文结束,后面没有数据。 对 于服务器推送,使用一个“multipart/mixed” 类型的变种-multipart/x-mixed-replace 。这里, “x-”表示属于 实验类型。 “replace”表

7、示每一个新数据块都会代替前一个数据块。也就是说,新数据不是附加到旧数据之后,而是替代它。 下面是实际使用的“multipart/x-mixed-replace” 类型: Content-type:multipart/x-mixed-replace;boundary=ThisRandomString -ThisRandomString Content-type:text/plain 第一个对象的数据 -ThisRandomString Content-type:text/plain 第二个(最后一个)对象的数据。 -ThisRandomString- 使用这一技术的关键是,服务器并不是推送整个“

8、multipart/x-mixed-replace”报文,而是每次发送后数据块。 HTTP 连接始终保持,因而服务器可以按自己需要的速度和频率推送新数据,两个数据块之间浏览器仅需在当前窗口等候,用户甚至可以到其他窗口做别的事情,当服务器 需要发送新数据时,它只是源(ABC 输入法没那个字*boundary=-ThisRandomString-“ echo “ echo “-ThisRandomString-“ while true do echo “Content-type: text/html“ echo “ echo “h2Processes on this machine updated

9、 every 5 seconds/h2“ echo “time:“ date echo “p“ echo “plaintext“ ps -el echo “-ThisRandomString-“ sleep 5 done 注意到,边界设置在 sleep 语句之前发送,这能够确保浏览器清除其缓冲区,并显示所接收到的最新数据。 NCSA HTTPD 用户在内容类型中不能使用空格,包括边界参数。NCSA HTTPD 只能将不带空格字符的字符串作为内容类型。如果在内容类型行中存在空格(冒号后面的空格除外) ,空格后的任何文本都会被删除。 下面的示例是正确的: Content-type: multipa

10、rt/x-mixed-replace;boundary=ThisRandomString 而下例则不能正常工作,因为它在中间有空格: Content-type: multipart/x-mixed-replace; boundary=ThisRandomString 服务器推送的另一个优点是它可以针对单个内联图象进行。包括图象的文档可以由服务器定时或定周期进行更新。而实现这一点非常简单:只需使 IMG 元素的 SRC 属性指向推送一系列图象的 URL 即可。 如果服务器推送用于单个内联图象,文档中的图象就会一次次被新推送来的图象所代替,而文档本身不需变化(假设文档没有进行服务器推送) 。这样,

11、WEB 页面中有限的动画就可以为静态画面所代替。 客户端拖曳 客户端拖曳的一个简单用法是使文档按固定周期自动重载。例如,考虑下面的 HTML 文档: Document ONE This is Document ONE! Heres some text. 如果将它载入支持动态文档的浏览器(Netscape 1.1 以上,Internet Explorer 和 Mosaic 也支持客户端拖曳) ,它将每隔一秒将自己重载一次。 由于 META 元素实际是在 HTML 文档中模拟 HTTP 响应头标,所以它能够告知浏览器将自身信息当作 HTTP 响应使用。上例中的 META 标记相当于: Refres

12、h:1 这样,实际上就是 HTTP 头标告知浏览器每一秒更新一次文档。如果需要延时是 12 秒,那么就是这样的指令: 那么它等效于: Refresh:12 关于客户端的拖曳我也懒的继续写下去,关于怎么使客户端自动申请其他 URL 的数据话,请使用如下: 注意的是,此处的 URL 不能使用相对路径,必须全部指定。 其中时间间隔可以设置为 0,这样浏览器在当前文档显示完毕后,以最快的速度载入新的数据!Moon1 发表于 2008 年 11 月 21 日 10:54:46 所 有的客户端都是连接到服务器的 webserver 端口,比如 80, 这个根本和服务器的端口数无关. 是个错误的提法. 文章

13、链接:http:/ 发表时间:2008 年 11 月 21 日 10:54:46“举报multipart/mixed 头一次看到这个,研究下。不过文中 : “因此服务器必须愿意分配这些 TCP/IP 端口,对于 TCP/IP 端口数有限的服务器这将是一个严重的问题。“所有的客户端都是连接到服务器的 webserver 端口,比如 80, 这个根本和服务器的端口数无关. 是个错误的提法. wzd24 发表于 2008 年 11 月 21 日 15:01:47 举报美丽的馅饼。IE 同时只会打开两个连接来请求数据。如果你使用服务端推送技术的话,连接将被占用而导致其他资源无法被请求。singyea

14、发表于 2008 年 11 月 21 日 21:02:17 举报推?简直疯了,让一个一个保持连接不断开,不知道要耗多少资源撒?kingwei1977 发表于 2008 年 11 月 22 日 1:48:57 举报楼主方法太好了。to:Moon1每次客户端都是连接到服务器,服务器会分配个 socket 出来处理本次请求,它是要占断口的。to:wzd24E 同时只会打开两个连接来请求数据?不知道从哪儿来的说法?to:singyea让一个一个保持连接不断开,应该不是问题,至于耗多少资源,那是你代码的问题你们都不太懂啊,还是楼主强,用 multipart.,我怎么没想到呢。saighost 发表于 2

15、008 年 11 月 22 日 22:04:12 举报GlassFish 已经支持 Comet 了,比这种做法会更好!krisky 发表于 2008 年 11 月 23 日 11:25:33 举报楼 主,我不知道你思考这个“推“的问题时, 所看问题的角度是什么,但我认为你对通信技术本身的设计原则不太了解 如果服务器去推送 哪服务器如何知道用户的下一个动作是什么 如果用户的下一个请求要跳转到其它服务器上你如何实现,在这种情况下, 是不是通过客 户端主动去访问其它服务器这样比较容易, 如果这样的话 我为什么不使用客户端主动 服务器被动响应的方式, 而要用你的什么“推“的方式了.有时在 思考问题的时

16、候。 要全面一点.xxfun 发表于 2008 年 11 月 24 日 1:16:32 举报楼主的文章太好了。非常谢谢!同时也支持 kingwei1977。to krisky,推的本意是自动更新状态,而不是用在用户主动请求的情况,要好好理解楼主的意思。比如在线页面聊天,你怎么知道对方什么时候发来信息呢。服务器“推”就可以解决这个问题了。wzd24 发表于 2008 年 11 月 24 日 9:01:04 举报TO:kingwei1977 这是 HTTP 规范决定的,详细的你可以去 BAIDU 和 Google 搜索。这个服务器“推”技术很早以前就有人研究了,我在 2000 年的时候就有人发表这

17、样的文章了,但结论是:不实用。呵呵wzd24 发表于 2008 年 11 月 24 日 9:03:06 举报2000 年的时候看到关于“推”技术的文章。不是我写的。呵呵我那时还没这样的能耐。richer_dong 发表于 2008 年 11 月 24 日 14:53:49 举报微软的 MVP 真的越来越烂了,如果这片文章不是 LZ 写的,希望能加以下评论。如果是 LZ 写的,那么希望 LZ 研究下通讯技术后,再来涂鸦。服务器推技术的根本问题是,当客户端建立 Socket 套接字后,服务器需要对该套接字进行输出。如果客户端 Shutdown,服务端也需要至少发送一次请求,每次请求至少 1 个调度

18、周期。换句话说,如果该技术放在 90 年,因为网络客户端有局限性该技术还能被用。但现今社会是机器都能上网,哪个服务不被全球 M 多台机器访问,如果用推技术,估计(不计 TCP 资源)服务器的周期需要 10 分钟以上。另外如果计 TCP 资源,需要直接面临服务器的端口数限制。又一个快餐式程序员. .ghostbear 发表于 2008 年 11 月 24 日 20:04:07 举报#richer_dong:你有病么,这么这么评论 LZ 的文章.你厉害你写篇啊.yangfan_25845220 发表于 2009 年 2 月 7 日 16:02:20 举报公司正要用这个呢,来学习一下,文章写的真好,

19、评论也不错,再好的东西也有弊端,我支持你啊!liuzuofei 发表于 2009 年 4 月 29 日 15:58:03 举报个人认为,LZ 的文章写的没有问题,就是不实用,WEB 方式的根本点在于客户端的主动请求,因此服务器端的“推”不是很好,只有在特殊应用,例如:聊天室.如果真要在大型系统中用推技术,不如直接用 C/S 模式!iflyer_1019 发表于 2009 年 5 月 5 日 15:51:30 举报偶 然搜到楼主的文章,源于中午看 NBA 文字直播的疑问:我在腾讯看的NBA 文字直播,同事用的新浪的文字直播。两个网站的直播都是无刷新的,所以开始我们都 认为是 AJAX 的定时异步请求结果。另外说下我们公司在工作时间(中午 1 点之后)是禁止上外网的,在网关封掉了所有的网站。所以一到一点,我的文字直播页 面数据便不再刷新了,奇怪的是同事的新浪直播页面仍可以继续刷新数据,而他确认没有安装任何的插件。我想除了推送技术,应该没有什么东西来解释这个原因了 吧?iflyer_1019 发表于 2009 年 5 月 5 日 15:54:04 举报如果说这种技术非常占资源的话,那 NBA 文字直播势必会占用相当大的网络资源。为什么新浪就可以呢?

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 教育教学资料库 > 精品笔记

Copyright © 2018-2021 Wenke99.com All rights reserved

工信部备案号浙ICP备20026746号-2  

公安局备案号:浙公网安备33038302330469号

本站为C2C交文档易平台,即用户上传的文档直接卖给下载用户,本站只是网络服务中间平台,所有原创文档下载所得归上传人所有,若您发现上传作品侵犯了您的权利,请立刻联系网站客服并提供证据,平台将在3个工作日内予以改正。