精华内容
参与话题
问答
  • 作者:卢满宇, 腾讯后台开发 工程师 商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处。 原文链接:http://wetest.qq.com/lab/view/355.htmlWeTest 导读HTTP/1.X出色地满足互联网的普遍访问需求,但随着...

    作者:卢满宇, 腾讯后台开发 工程师
    商业转载请联系腾讯WeTest获得授权,非商业转载请注明出处。
    原文链接:http://wetest.qq.com/lab/view/355.html

    WeTest 导读

    HTTP/1.X出色地满足互联网的普遍访问需求,但随着互联网的不断发展,其性能越来越成为瓶颈。IETF在2015年发布了HTTP/2标准, 着重于提高HTTP的访问体验, HTTP2优势主要包括: 二进制传输、头部压缩、多路复用和服务器推送(Server Push)。 截止目前, 大部分CDN厂商已经宣布支持HTTP/2,然而”支持”大多省略了服务器推送(ServerPush)特性。估计这和nginx开源版本没有支持Server Push相关。为提供完备的HTTP2能力,腾讯CDN现已完成HTTP/2的Server Push支持,并完成了详细的性能测试。


    序言

    在介绍Server Push功能之前,先来分析网站的加载过程。图1是腾讯课堂(https://ke.qq.com/index.html)的时间瀑布图。

    a) 首先浏览器请求主页面index.html,服务端响应内容;

    b) 获取到主页应答,浏览器开始解析主页的html标签,发现构建DOM树还需要CSS, GIF, JS等资源;

    c) 发起针对CSS,GIF,JS的内容请求;

    d) 获取并解析JS和CSS等内容, 然后继续请求依赖资源。

    图1 腾讯课堂域名的时间瀑布图

    图2是简化的浏览器和服务器的交互过程,横轴代表时间轴,每个虚线区间是1个RTT。红色竖线表示DOM 加载完成的时间。从图中可知,虽然存在并发传输, 但主页index.html和依赖的资源common.css、0684a8bf.css、comb.nowrap.0b772fee.js等总体上是顺序的,等待资源响应的时间减慢了主页面加载速度。并发传输并不能提高串行解析的资源访问体验。

    如果服务端接收到客户端主请求,能够“预测”主请求的依赖资源,在响应主请求的同时,主动并发推送依赖资源至客户端。客户端解析主请求响应后,可以”无延时”从本地缓存获取依赖资源, 减少访问延时, 提高访问体验,也加大了链路的并发能力。Server Push正是基于此原理来提高网络体验。

    图3说明了若采用服务端推送的功能,则JS/CSS资源基本可以和HTML资源同步到达,浏览器可以“无延时”获取JS/CSS资源,客户端的延时最多可以减少一个RTT。

    构建一个简单的例子来验证我们的说法。图4所示为simple_push.html代码,页面依赖资源simple_push.js和simple_nopush.js, 页面大小均不超过1KB,主要时间消耗在传输延时。如图5所示为推送simple_push.js和不推送simple_nopush.js的效果对比。

    图4 推送测试HTML代码

    图5 不推送&推送的效果对比

    我们上线了一个测试demo网站(https://http1.gtimg.cn/push/mypush.html)。网页上展示一张世界地图,由400个小图片组成。对比三种访问方式:HTTP/1.1、HTTP/2(无Server Push)和 HTTP/2(Server Push)。Server Push选择推送第150~179个共30个小图。访问性能数据对比如图6所示:可以发现预推送比无推送有一定的性能提升(受网络延时和客户端行为影响,结果存在波动,后文有相应分析)。

    图6 demo网站测试

    简要介绍了Server Push的优化原理之后,伴随而来的疑问,推送什么资源,怎么去推送,以及比其他优化技术有什么优势?读完本章,这些问题将一一得到解答,文章最后用实例展示Server Push的应用场景和性能优化效果。

    一、推送实现

    1、标识依赖资源

    W3C候选推荐标准(https://www.w3.org/TR/preload/)建议了依赖资源的两种做法:文件内标签和HTTP头部携带, 表示该资源后续会被使用, 可以预请求, 关键字preload修饰这个资源, 写法如下:

    a) 静态Link标签法:

    b) HTTP头表示法:

    Link: <push.css>; rel=preload; as=style

    其中rel表明了资源</push.css>是预加载的,as表明了资源的文件类型。另外,link还可以用nopush修饰,表示浏览器可能已经有该资源缓存,指示有推送能力的服务端不主动推送资源,只有当浏览器先检查到没有缓存,才去指示服务端推送资源,nopush格式写成:

    Link: </app>; rel=preload; as=script;nopush。

    2、推送资源

    用户访问CDN,主要包括直接访问的边缘节点, 若干中间节点和客户源站,路径中的每层都可以对请求做分析,预测可能的依赖资源,通过插入静态标签或者增加响应头部返回给浏览器。 CDN的推送主要采用头部携带推送信息。

    a) 客户端指定推送资源

    客户端通过url或者请求头说明需要的资源url,写法如下:

    Url:http://http2push.gtimg.com/simple_push.html?req-push=simple_push.js

    或者:

    GET /simple_push.html HTTP/1.1

    Host: http2push.gtimg.com

    User-Agent: curl/7.49.1

    Accept: /

    X-Push-Url: simple_push.js

    b) CDN节点指定推送资源

    CDN节点针对请求资源配置推送资源, 基础配置如下:

    location ~ “/simple_push.html$” {

    http2_server_push_url /simple_push.js

    c) 源站指定推送资源

    通过增加响应头link通知客户端或者CDN节点,后续希望推送的依赖资源,中间具有 推送功能的节点(如CDN节点)可以基于此信息进行资源请求与推送.

    3、功能实现

    图7所示为CDN的Server Push架构, 基本流程如下:

    a) 用户请求到达服务器之后,依赖资源预测模块根据请求头或者配置预测浏览器需要的资源,该推送资源url必须是和主请求是同一host。如果不属于同一host,服务器拒绝推送资源。

    b) 服务器通过PUSH_PROMISE桢告诉浏览器准备推送的资源路径,该信息在原主请求流上发送,必须优先主请求响应发送,否则浏览器可能在推送资源到达前已经发起了依赖资源请求,造成重复和浪费.

    c) 依赖资源请求模块构造和主请求一样的请求信息,在本地或后端服务器请求推送资源,并主动创建新的HTTP/2请求流,后续服务器就可以发送资源响应,推送资源响应在服务端创建的流上传输,主页面响应在原始流传输。

    图7 CDN的Server Push模块改造示意图

    CDN节点的推送资源发送顺序在主请求响应之前,如图8所示,主要基于以下因素考量:

    d) 推送资源一般是静态的缓存命中率高的资源,如JS、CSS、字体和图片等。这些资源可以从源站预先推送并缓存到CDN节点。相比之下, 主页面变更较多,需要等待网络IO去源站取数据。同时,CDN边缘节点到浏览器的RTT一般是比CDN节点到源站的RTT更短。所以在取到主页面最新响应之前,有充足的时间去推送资源。

    e) 资源推送可以探测提高TCP拥塞窗口,窗口逐渐增大,后续可以一次性发送完主页面响应。TCP拥塞窗口对推送影响将在下文第三部分讨论。

    f) 在等待主请求响应的网络IO时间期间,推送资源可以是无优先级关系,资源推送优先级对推送影响也将在下文第三部分讨论。

    图8 推送时间点位于主页面响应之前

    二、Server Push技术对比

    1、纵向对比

    Server Push相对应没有Server Push的具体提升如下:

    a) Nopush加载耗时:Tnopush = RTT+ max(RTT, size(HTML)/BandWidth)+size(JS)/BandWidth

    b) push耗时:Tpush = RTT + size(HTML)/BandWidth + size(JS)/BW

    c) 改善效率:diff =1 - Tpush/TnoPush

    所以决定推送是否有改善性能的衡量因素是size(HTML/BandWidth)和RTT谁大。这里引入BDP(BandWidth-Delay product, 带宽时延乘积)概念。BDP描述了单位时间内该带宽能传输的数据大小。如果size(HTML)<BDP,推荐使用push;反之不推荐使用push。

    2、横向对比

    HTTP/1.1中有个资源内联(Resource Inlining)技术,把资源内容拷贝到HTML标签中。比如说可以装载js的内容,

    3、内核缓冲区

    HTTP/2的请求优先级并不能影响已经在内核发送缓冲区的数据。假设内核发送缓冲区大小比TCP拥塞串口大,导致服务端发送低优先级的数据,存在内核缓冲区。这时,后续有高优先级的响应必须等内核缓冲区空出才能被完成。假设我们访问一个HTML页面,这个HTML页面需要回源站取数据,而HTML需要的静态JS资源缓存在CDN边缘节点上。在回源站的等待时间内,把静态JS资源发送给浏览器。如果这时候静态JS资源很大,塞满了内核发送缓冲区,此时HTML响应已经到达CDN边缘节点,却不得不等内核缓冲区有空间才能继续发送。等待浏览器解析HTML内容后续的link请求也会被推迟。

    4、浏览器缓存

    推送浏览器已缓存的资源有可能使的加载时间更长,并且浪费带宽资源。重复推送已缓存的资源,如果没有额外的空闲带宽传输,网络会阻塞它之后正常的请求,导致拖累了整个网站的加载时间。

    四、网站测试

    我们对现网一些网页进行Server Push性能测试,因为推送要求同一个域名下的HTTP/2请求,为了规避非HTTP/2和跨余名带来的干扰,我们设置了代理节点,代理节点完成HTTP/2支持和域名收归,同时配置Server Push功能,观察网页的加载收益。为了准确测试Push带来网络时延变化,需要稳定的网络环境,在chrome设置网络环境mytest(RTT: 200ms, Download: 29Mb/s, Upload: 14Mb/s),以下的例子都在该网络环境进行测试。

    1、腾讯新闻

    按照前面描述的推送适用场景,用这个腾讯新闻页面(https://news.qq.com/a/20171031/032143.htm)做测试。主请求页面大小为11.6K。可以看出,预先推送js、css、图片等资源给客户端带来的网站性能变快。

    图11 腾讯新闻页面

    图12 腾讯新闻页面的无推送&推送对比图

    2、腾讯客服

    腾讯客服页面不支持HTTPS协议。之所以用这个页面是因为该网页页面主请求比较小,并且有JS、CSS触发的次优先级资源请求。我们把这个网页下载下来,并做了一些推送资源域名收归等必要的处理,放在CDN边缘节点做测试。这并没有改变网站的资源和请求顺序,不影响测试效果。

    图13是腾讯客服的页面。图14列出腾讯客服页面的所有请求。我们关注下具体几种情况的时间轴:无推送、推送小文件、推送大文件。小文件推送预先在第一个RTT把3个第3层请求才能触发的资源(tcss.ping.js、cdn_djl.js、layer.css)预先推送给浏览器。大文件推送是预先推送了indexBanner.png。

    从图14中的无推送和推送3个小文件的子图中,红色虚竖线是指不包括indexBanner.png的加载完成时间,由于3个小文件(尤其是次优先级请求tcss.ping.js)的提取推送,比无推送的时间延迟要短。但是又从无推送和推送大文件的子图中看到,如果无优先级顺序地推送大文件indexBanner.png(782KB)对缩短网站时延无帮助。

    图13 腾讯客服页面

    图14 无推送&推送小文件&推送大文件的对比图

    五、总结

    虽然本章的测试用例只是庞大互联网网页的冰山一角,文章不能覆盖各种网页场景。但是以下的一些总结建议是有实践意义的。

    1、在合适的时机,推送合适的资源,Push比No Push带来的网站时延提升是明显的。在网络带宽足够承载推送资源的前提下,我们预先推送浏览器后续请求需要的资源,网站的整体加载时间得到缩短。但是现实网络环境有不一样的延时和带宽。慢速网络环境影响TCP拥塞窗口增长的速度,除非主页面请求足够小,Push才能看到效果。

    2、即使是错误地实施某些推送策略(比如说推送过大文件),带来的最严重后果,也就是改善不明显。所以建议是多做一些推送策略的尝试,直到把合适的资源在合适的时机把资源推送给浏览器。

    3、网站往HTTP/2的环境迁移是个趋势。迁往HTTP/2需要将页面的所有请求尽量收归到同一域名,并且剥离出主页面的资源文件成多个独立的请求。假如你的网站已迁移到HTTP/2,而且网站的主请求不大,但是可能会触发很多资源请求。建议push这些资源。另外不要推送存放在浏览器cookie的资源,这只会浪费带宽。

    4、目前的Server Push推送机制没有解决浏览器已经具有资源缓存,而服务器已经推送到网络中,虽然浏览器可以发送RST桢拒绝推送流,但是服务器推送的资源已经在网络中等待浏览器接收。现在已经有一些规范草案(https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-01)尝试用协商缓存摘要来解决问题。

    5、CDN中的负载均衡机制可能会将低优先级的推送资源送入到系统缓存区,这会影响高优先级资源的推送效率问题。引入QUIC替代TCP,可以对缓存中推送资源进行分级,高优先级资源先发。

    6、未来或将引入AI分析取代固定推送实现智能化推送。


    WeTest压测大师——为了帮助开发者发现服务器端的性能瓶颈,腾讯WeTest开放了压力测试功能,通过基于真实业务场景和用户行为进行压力测试,实现针对性的性能调优,降低服务器采购和维护成本。

    压测大师还服务了包括王者荣耀、龙之谷手游、轩辕传奇手游、火影忍者等多款高星级手游,也包括QQ、NOW直播等明星产品

    目前压测大师正式对外开放,点击链接:http://wetest.qq.com/gaps/ 即可使用。

    如果对使用当中有任何疑问,欢迎联系腾讯WeTest企业QQ:800024531

    展开全文
  • 服务器推送技术

    千次阅读 2018-11-04 10:07:37
    什么是服务器推送技术 推送技术是指通过客户端与服务器端建立长链接,客户端可以接收由服务器端不定时发送的消息。 解决方案 1.Ajax短轮询 2.Ajax长轮询 3.WebSocket 短轮询 Ajax短轮询:http 短轮询是 server 收到...

    什么是服务器推送技术

    推送技术是指通过客户端与服务器端建立长链接,客户端可以接收由服务器端不定时发送的消息。

    解决方案

    1.Ajax短轮询

    2.Ajax长轮询

    3.WebSocket

    短轮询

    Ajax短轮询:http 短轮询是 server 收到请求不管是否有数据到达都直接响应http请求;如果浏览器收到的数据为空,则隔一段时间,浏览器又会发送相同的http请求到server 以获取数据响应,就是用一个定时器不停的去网站上请求数据。

    		缺点:消息交互的实时性较低(server端到浏览器端的数据反馈效率低)。
    

    长轮询

    http 长轮询是server 收到请求后如果有数据,立刻响应请求;如果没有数据 就会 停留 一段时间,这段时间内,如果 server 请求的数据到达(如查询数据库或数据的逻辑处理完成),就会立刻响应;如果这段时间过后,还没有数据到达,则以空数据的形式响应http请求;若浏览器收到的数据为空,会再次发送同样的http请求到server。

    AJAX的长轮询

    1,DeferredResult:Springmvc的控制层接收用户的请求之后,采用异步处理,立即返回DeferedResult泛型对象,此时驱动控制层的容器主线程,可以处理更多的请求。
    2,Servlet3:也是异步处理。

    				缺点:server 没有数据到达时,http连接会停留一段时间,这会造成服务器资源浪费;
    

    SSE

    严格地说,HTTP 协议无法做到服务器主动推送信息。但是,有一种变通方法,就是服务器向客户端声明,接下来要发送的是流信息(streaming)。
    也就是说,发送的不是一次性的数据包,而是一个数据流,会连续不断地发送过来。这时,客户端不会关闭连接,会一直等着服务器发过来的新的数据流,视频播放就是这样的例子。本质上,这种通信就是以流信息的方式,完成一次用时很长的下载。
    SSE 就是利用这种机制,使用流信息向浏览器推送信息。它基于 HTTP 协议,目前除了 IE/Edge,其他浏览器都支持。
    SSE 与 WebSocket 作用相似,都是建立浏览器与服务器之间的通信渠道,然后服务器向浏览器推送信息。

    总体来说,WebSocket 更强大和灵活。因为它是全双工通道,可以双向通信;SSE是单向通道,只能服务器向浏览器发送,因为流信息本质上就是下载。如果浏览器向服务器发送信息,就变成了另一次 HTTP 请求。

    				SSE 也有自己的优点:
    					SSE 使用 HTTP 协议,现有的服务器软件都支持。WebSocket 是一个独立协议。
    					SSE 属于轻量级,使用简单;WebSocket 协议相对复杂。
    					SSE 默认支持断线重连,WebSocket 需要自己实现。
    					SSE 一般只用来传送文本,二进制数据需要编码后传送,WebSocket 默认支持传送二进制数据。
    					SSE 支持自定义发送的消息类型。
    					SSE 也是长连接	
    

    http长轮询和短轮询的异同

    1)相同点:当server 的数据不可达时,基于http长轮询和短轮询 的http请求,都会 停留一段时间;
    2)不同点:http长轮询是在服务器端的停留,而http 短轮询是在 浏览器端的停留;
    3)性能总结:从这里可以看出,不管是长轮询还是短轮询,都不太适用于客户端数量太多的情况,因为每个服务器所能承载的TCP连接数是有上限的,这种轮询很容易把连接数顶满;

    WebSocket通信

    什么是WebSocket

    WebSocket 是 html5 规范发布的新协议,和 http协议完全是两个不同的概念,或者说基本没关系;WebSocket协议和http协议的唯一联系点在于,WebSocket协议为了兼容现有浏览器的握手规范而采用了http协议中的握手规范以建立WebSocket连接,其客户端与服务器建立的是 持久连接。

    		WebSocket 解决了 HTTP 的几个难题:
    			1(http协议的被动性):采用 WebSocket 协议后,服务器可以主动推送消息给客户端;而不需要客户端以(长/短)轮询的方式发起http请求到server以获取数据更新反馈;这样一来,客户端只需要经过一次HTTP请求,就可以做到源源不断的信息传送了(在程序设计中,这种设计叫做回调,即:server端有信息了再来通知client端,而不是client端每次都傻乎乎地跑去轮询server端 是否有消息更新);
    			2(http协议的无状态性/健忘性):短轮询是每次http请求前都要建立连接,而长轮询是相邻几次请求前都要建立连接;http请求响应完成后,服务器就会断开连接,且把连接的信息全都忘记了;所以每次建立连接都要重新传输连接上下文(下面有补充),将 client 端的连接上下文来告诉server端;而WebSockct只需要一次HTTP握手,整个通讯过程是建立在一次连接(状态)中的,server端会一直推送消息更新反馈到客户端,直到客户端关闭请求,这样就无需客户端为发送消息而建立不必要的 tcp 连接 和 为了建立tcp连接而发送不必要的冗余的连接上下文消息;
    
    		特点:
    			1,HTML5中的协议,实现与客户端与服务器双向,基于消息的文本或二进制数据通信
    			2,适合于对数据的实时性要求比较强的场景,如通信、直播、共享桌面,特别适合于客户与服务频繁交互的情况下,如实			时共享、多人协作等平台。
    			3,采用新的协议,后端需要单独实现
    			4,客户端并不是所有浏览器都支持
    

    实现

    1,HTML5规范中的WebSocket API

    2,WebSocket的子协议STOMP。

    				STOMP(Simple Text Oriented Messaging Protocol):
    					1,简单(流)文本定向消息协议
    					2,STOMP协议的前身是TTMP协议(一个简单的基于文本的协议),专为消息中间件设计。是属于消息队列的一种协议, 和AMQP,JMS平级.它的简单性恰巧可以用于定义websocket的消息体格式.STOMP协议很多MQ都已支持,比如RabbitMq, ActiveMq。
    					3,生产者(发送消息)、消息代理、消费者(订阅然后收到消息)
    					4,STOMP是基于帧的协议
    

    SSE和WebSocket相比的优势

    1,最大的优势就是便利:不需要添加任何新组件,用任何你习惯的后端语言和框架就能继续使用。你不用为新建虚拟机、弄一个新的IP或新的端口号而劳神,就像在现有网站中新增一个页面那样简单。可以称为既存基础设施优势。

    2,SSE的第二个优势是服务端的简洁。相对而言,WebSocket则很复杂,不借助辅助类库基本搞不定。WebSocket能做的,SSE也能做,反之亦然,但在完成某些任务方面,它们各有千秋。WebSocket是一种更为复杂的服务端实现技术,但它是真正的双向传输技术,既能从服务端向客户端推送数据,也能从客户端向服务端推送数据。

    总结

    技术没有优劣之分,只有场景是否合适,在京东的支付完成之后的跳转的推送技术中,也是用的ajax段轮训的方式,原因是要用有限的资源来为千万级甚至上亿的用户提供服务,如果是用长连接,对于接入的服务器,比如说Nginx,是很大的压力,光是为用户维持这个长连接都需要成百上千的Nginx的服务器,这是很划不来的。因为对于京东这类购物网站来说,用户的浏览查询量是远远大于用户下单量的,京东需要注重的是服务更多的用户,而且相对于用户浏览页面的图片等等的流量而言,这点带宽浪费占比是很小的。所以我们看京东的付款后的实现,是用的短轮询机制,而且时长放大到了5秒。

    展开全文
  • HTTP/2 服务器推送(Server Push)教程 ...

    HTTP/2 服务器推送(Server Push)教程

    2018-03-16 Java知音

    点击上方“Java知音”,选择“置顶公众号”

    技术文章第一时间送达!


    本文作者:阮一峰; 原文:

    http://www.ruanyifeng.com/blog/2018/03/http2_server_push.html

    知音专栏

     

    Javaweb练手项目源码下载

    常用设计模式完整系列篇

    100套IT类简历模板下载

    Java常见面试题汇总篇


    HTTP/2 协议的主要目的是提高网页性能。


    头信息(header)原来是直接传输文本,现在是压缩后传输。原来是同一个 TCP 连接里面,上一个回应(response)发送完了,服务器才能发送下一个,现在可以多个回应一起发送。


    服务器推送(server push)是 HTTP/2 协议里面,唯一一个需要开发者自己配置的功能。其他功能都是服务器和浏览器自动实现,不需要开发者关心。


    本文详细介绍服务器推送的原理和配置方法。




    一、传统的网页请求方式


    下面是一个非常简单的 HTML 网页文件index.html。


    <!DOCTYPE html>
    <html>
    <head>
      <link rel="stylesheet" href="style.css">
    </head>
    <body>
      <h1>hello world</h1>
      <img src="example.png">
    </body>
    </html>


    这个网页包含一张样式表style.css和一个图片文件example.png。为了渲染这个网页,浏览器会发出三个请求。第一个请求是index.html。


    GET /index.html HTTP/1.1


    服务器收到这个请求,就把index.html发送给浏览器。浏览器发现里面包含了样式表和图片,于是再发出两个请求。


    GET /style.css HTTP/1.1
    GET /example.png HTTP/1.1


    这就是传统的网页请求方式。它有两个问题,一是至少需要两轮 HTTP 通信,二是收到样式文件之前,网页都会显示一片空白,这个阶段一旦超过2秒,用户体验就会非常不好。


    二、传统方式的改进


    一种解决办法就是把外部资源合并在网页文件里面,减少 HTTP 请求。比如,把样式表的内容写在<style>标签之中,把图片改成 Base64 编码的 Data URL。


    另一种方法就是资源的预加载(preload)。网页预先告诉浏览器,立即下载某些资源。比如,上例可以写成下面这样。


    <link rel="preload" href="/styles.css" as="style">
    <link rel="preload" href="/example.png" as="image">


    对于上例来说,preload命令并没有什么帮助。但是,如果前一个网页就使用这个命令,预加载后一个网页需要的资源,那么用户打开后一个网页时,就会感觉速度飞快。


    这两种方法都有缺点。第一种方法虽然减少了 HTTP 请求,但是把不同类型的代码合并在一个文件里,违反了分工原则。第二种方法只是提前了下载时间,并没有减少 HTTP 请求。


    三、服务器推送的概念


    服务器推送(server push)指的是,还没有收到浏览器的请求,服务器就把各种资源推送给浏览器。


    比如,浏览器只请求了index.html,但是服务器把index.html、style.css、example.png全部发送给浏览器。这样的话,只需要一轮 HTTP 通信,浏览器就得到了全部资源,提高了性能。


    四、Nginx 实现


    Nginx 从 1.13.9 版开始,支持服务器推送。首先,进入工作目录,把原来的首页删除。


    $ cd nginx-docker-demo
    $ rm html/index.html


    然后,新建html/index.html文件,写入本文第一节的网页源码。


    另外,html子目录下面,还要新建两个文件example.png和style.css。前者可以随便找一张 PNG 图片,后者要在里面写一些样式。


    h1 {
      color: red;
    }


    最后,打开配置文件conf/conf.d/default.conf,将 443 端口的部分改成下面的样子。


    server {
        listen 443 ssl http2;
        server_name  localhost;
    
        ssl                      on;
        ssl_certificate          /etc/nginx/certs/example.crt;
        ssl_certificate_key      /etc/nginx/certs/example.key;
    
        ssl_session_timeout  5m;
    
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers   on;
    
        location / {
          root   /usr/share/nginx/html;
          index  index.html index.htm;
          http2_push /style.css;
          http2_push /example.png;
        }
    }


    其实就是最后多了两行http2_push命令。它的意思是,如果用户请求根路径/,就推送style.css和example.png。


    现在可以启动容器了。


    $ docker container run \
      --rm \
      --name mynginx \
      --volume "$PWD/html":/usr/share/nginx/html \
      --volume "$PWD/conf":/etc/nginx \
      -p 127.0.0.2:8080:80 \
      -p 127.0.0.2:8081:443 \
      -d \
      nginx


    打开浏览器,访问 https://127.0.0.2:8081 。浏览器会提示证书不安全,不去管它,继续访问,就能看到网页了。


    网页上看不出来服务器推送,必须打开"开发者工具",切换到 Network 面板,就可以看到其实只发出了一次请求,style.css和example.png都是推送过来的。



    查看完毕,关闭容器。


    $ docker container stop mynginx


    五、Apache 实现实现


    Apache 也类似,可以在配置文件httpd.conf或者.htaccess里面打开服务器推送。


    <FilesMatch "\index.html$">
        Header add Link "</styles.css>; rel=preload; as=style"
        Header add Link "</example.png>; rel=preload; as=image"
    </FilesMatch>


    六、后端实现


    上面的服务器推送,需要写在服务器的配置文件里面。这显然很不方便,每次修改都要重启服务,而且应用与服务器的配置不应该混在一起

    服务器推送还有另一个实现方法,就是后端应用产生 HTTP 回应的头信息Link命令。服务器发现有这个头信息,就会进行服务器推送。


    Link: </styles.css>; rel=preload; as=style


    如果要推送多个资源,就写成下面这样。


    Link: </styles.css>; rel=preload; as=style, </example.png>; 
    rel=preload; as=image


    可以参考 Go、Node、PHP 的实现范例。


    这时,Nginx 的配置改成下面这样。


    server {
        listen 443 ssl http2;
    
        # ...
    
        root /var/www/html;
    
        location = / {
            proxy_pass http://upstream;
            http2_push_preload on;
        }
    }


    如果服务器或者浏览器不支持 HTTP/2,那么浏览器就会按照 preload 来处理这个头信息,预加载指定的资源文件。


    事实上,这个头信息就是 preload 标准提出的,它的语法和as属性的值都写在了标准里面。


    七、缓存问题


    服务器推送有一个很麻烦的问题。所要推送的资源文件,如果浏览器已经有缓存,推送就是浪费带宽。即使推送的文件版本更新,浏览器也会优先使用本地缓存。


    一种解决办法是,只对第一次访问的用户开启服务器推送。下面是 Nginx 官方给出的示例,根据 Cookie 判断是否为第一次访问。


    server {
        listen 443 ssl http2 default_server;
    
        ssl_certificate ssl/certificate.pem;
        ssl_certificate_key ssl/key.pem;
    
        root /var/www/html;
        http2_push_preload on;
    
        location = /demo.html {
            add_header Set-Cookie "session=1";
            add_header Link $resources;
        }
    }
    
    
    map $http_cookie $resources {
        "~*session=1" "";
        default "</style.css>; as=style; rel=preload";
    }


    八、性能提升


    服务器推送可以提高性能。网上测评的结果是,打开这项功能,比不打开时的 HTTP/2 快了8%,比将资源都嵌入网页的 HTTP/1 快了5%。


    可以看到,提升程度也不是特别多,大概是几百毫秒。而且,也不建议一次推送太多资源,这样反而会拖累性能,因为浏览器不得不处理所有推送过来的资源。只推送 CSS 样式表可能是一个比较好的选择。


    九、参考链接

    • https://www.smashingmagazine.com/2017/04/guide-http2-server-push

    • https://www.nginx.com/blog/nginx-1-13-9-http2-server-push


    (完)

    微信扫一扫
    关注该公众号

    展开全文
  • COMET 和 WebSocket 技术来说,服务器推送事件的使用更简单,对服务器端的改动也比较小。对于某些类型的应用来说,服务器推送事件是最佳的选择。本文对服务器推送技术进行了详细的介绍,包含浏览器端和服务器端的...

              阿里云低价服务器1折特惠,优惠爽翻天,点我立即低价购买

    简介

    服务器推送事件(Server-sent Events)是 HTML 5 规范中的一个组成部分,可以用来从服务端实时推送数据到浏览器端。相对于与之类似的 COMET 和 WebSocket 技术来说,服务器推送事件的使用更简单,对服务器端的改动也比较小。对于某些类型的应用来说,服务器推送事件是最佳的选择。本文对服务器推送技术进行了详细的介绍,包含浏览器端和服务器端的相应实现细节,为在实践中使用该技术提供了指南。

     

    对于一般的 Web 应用开发,大多数开发人员并不陌生。在 Web 应用中,浏览器和服务器之间使用的是请求 / 响应的交互模式。浏览器发出请求,服务器根据收到的请求来生成相应的响应。浏览器再对收到的响应进行处理,展现给用户。响应的格式可能是 HTML、XML 或 JSON 等。随着 REST 架构风格和 AJAX 的流行,服务器更多地使用 JSON 作为响应的数据格式。Web 应用使用 XMLHttpRequest 对象来发送请求,并根据服务器端返回的数据,对页面的内容进行动态更新。通常来说,用户在页面上的操作,比如点击或移动鼠标,会触发相应的事件。由 XMLHttpRequest 对象来发出请求,得到服务器响应之后进行页面的局部更新。这种方式的不足之处在于:服务器端产生的数据变化不能及时地通知浏览器,而是需要等到下次请求发出时才能被浏览器获取。对于某些对数据实时性要求很高的应用来说,这种延迟是不能接受的。

    为了满足这类应用的需求,就需要有某种方式能够从服务器端推送数据给浏览器,以保证服务器端的数据变化可以在第一时间通知给用户。目前常见的解决办法有不少,主要可以分成两类。这两类方法的区别在于是否基于 HTTP 协议来实现。不使用 HTTP 协议的做法是使用 HTML 5 新增的 WebSocket 规范,而使用 HTTP 协议的做法则包括简易轮询、COMET 技术和本文中要介绍的 HTML 5 服务器推送事件。下面会对这几种技术进行介绍。

    在介绍 HTML 5 服务器推送事件之前,首先介绍一些上面提到的几种服务器端数据推送技术。第一种是 WebSocket。WebSocket 规范是 HTML 5 中的一个重要组成部分,已经被很多主流浏览器所支持,也有不少基于 WebSocket 开发的应用。正如名称所表示的一样,WebSocket 使用的是套接字连接,基于 TCP 协议。使用 WebSocket 之后,实际上在服务器端和浏览器之间建立一个套接字连接,可以进行双向的数据传输。WebSocket 的功能是很强大的,使用起来也灵活,可以适用于不同的场景。不过 WebSocket 技术也比较复杂,包括服务器端和浏览器端的实现都不同于一般的 Web 应用。

    除了 WebSocket 之外,其他的实现方式是基于 HTTP 协议来达到实时推送的效果。第一种做法是简易轮询,即浏览器端定时向服务器端发出请求,来查询是否有数据更新。这种做法比较简单,可以在一定程度上解决问题。不过对于轮询的时间间隔需要进行仔细考虑。轮询的间隔过长,会导致用户不能及时接收到更新的数据;轮询的间隔过短,会导致查询请求过多,增加服务器端的负担。

    COMET 技术改进了简易轮询的缺点,使用的是长轮询。长轮询的方式在每次请求时,服务器端会保持该连接在一段时间内处于打开状态,而不是在响应完成之后就立即关闭。这样做的好处是在连接处于打开状态的时间段内,服务器端产生的数据更新可以被及时地返回给浏览器。当上一个长连接关闭之后,浏览器会立即打开一个新的长连接来继续请求。不过 COMET 技术的实现在服务器端和浏览器端都需要第三方库的支持。

    综合比较上面提到的 4 种不同的技术,简易轮询由于其本身的缺陷,并不推荐使用。COMET 技术并不是 HTML 5 标准的一部分,从兼容标准的角度出发,也不推荐使用。WebSocket 规范和服务器推送技术都是 HTML 5 标准的组成部分,在主流浏览器上都提供了原生的支持,是推荐使用的。不过 WebSocket 规范更加复杂一些,适用于需要进行复杂双向数据通讯的场景。对于简单的服务器数据推送的场景,使用服务器推送事件就足够了。

    在浏览器支持方面,服务器推送事件已经在除 IE 外的大部分桌面和移动浏览器上得到了支持。支持服务器推送事件的浏览器及其版本包括:Firefox 6.0+、Chrome 6.0+、Safari 5.0+、Opera 11.0+、iOS Safari 4.0+、Opera Mobile 11.1+、Chrome for Android 25.0+、Firefox for Android 19.0+ 以及 Blackberry Browser 7.0+ 等。关于 IE 的支持,在下面的章节中有详细的介绍。

    下面对服务器推送事件的规范进行具体的说明。

     

    回页首

    规范

    Server-sent Events 规范是 HTML 5 规范的一个组成部分,具体的规范文档见参考资源。该规范比较简单,主要由两个部分组成:第一个部分是服务器端与浏览器端之间的通讯协议,第二部分则是在浏览器端可供 JavaScript 使用的 EventSource 对象。通讯协议是基于纯文本的简单协议。服务器端的响应的内容类型是“text/event-stream”。响应文本的内容可以看成是一个事件流,由不同的事件所组成。每个事件由类型和数据两部分组成,同时每个事件可以有一个可选的标识符。不同事件的内容之间通过仅包含回车符和换行符的空行(“\r\n”)来分隔。每个事件的数据可能由多行组成。代码示例 1 给出了服务器端响应的示例。

    示例1. 服务器端响应的示例

    data: first event
    
    data: second event
    id: 100
    
    event: myevent
    data: third event
    id: 101
    
    : this is a comment
    data: fourth event
    data: fourth event continue

    如代码示例 1 所示,每个事件之间通过空行来分隔。对于每一行来说,冒号(“:”)前面表示的是该行的类型,冒号后面则是对应的值。可能的类型包括:

    • 类型为空白,表示该行是注释,会在处理时被忽略。
    • 类型为 data,表示该行包含的是数据。以 data 开头的行可以出现多次。所有这些行都是该事件的数据。
    • 类型为 event,表示该行用来声明事件的类型。浏览器在收到数据时,会产生对应类型的事件。
    • 类型为 id,表示该行用来声明事件的标识符。
    • 类型为 retry,表示该行用来声明浏览器在连接断开之后进行再次连接之前的等待时间。

    在代码示例 1 中,第一个事件只包含数据“first event”,会产生默认的事件;第二个事件的标识符是 100,数据为“second event”;第三个事件会产生类型为“myevent”的事件;最后一个事件的数据为“fourth event\nfourth event continue”。当有多行数据时,实际的数据由每行数据以换行符连接而成。

    如果服务器端返回的数据中包含了事件的标识符,浏览器会记录最近一次接收到的事件的标识符。如果与服务器端的连接中断,当浏览器端再次进行连接时,会通过 HTTP 头“Last-Event-ID”来声明最后一次接收到的事件的标识符。服务器端可以通过浏览器端发送的事件标识符来确定从哪个事件开始来继续连接。

    对于服务器端返回的响应,浏览器端需要在 JavaScript 中使用 EventSource 对象来进行处理。EventSource 使用的是标准的事件监听器方式,只需要在对象上添加相应的事件处理方法即可。EventSource 提供了三个标准事件,如表 1 所示。

    表 1. EventSource 对象提供的标准事件

    名称 说明 事件处理方法
    open 当成功与服务器建立连接时产生 onopen
    message 当收到服务器发送的事件时产生 onmessage
    error 当出现错误时产生 onerror

    如之前所述,服务器端可以返回自定义类型的事件。对于这些事件,可以使用 addEventListener 方法来添加相应的事件处理方法。代码示例 2 给出了 EventSource 对象的使用示例。

    示例 2. EventSource 对象的使用示例

    var es = new EventSource('events');
    es.onmessage = function(e) {
        console.log(e.data);
    };
    
    es.addEventListener('myevent', function(e) {
        console.log(e.data);
    });

    如代码示例 2 所示,在指定 URL 创建出 EventSource 对象之后,可以通过 onmessage 和 addEventListener 方法来添加事件处理方法。当服务器端有新的事件产生,相应的事件处理方法会被调用。EventSource 对象的 onmessage 属性的作用类似于 addEventListener( ‘ message ’ ),不过 onmessage 属性只支持一个事件处理方法。

     

    服务器端和浏览器端实现

    1.服务端用的是java其他编程语言也可以,只要返回数据格式正确即可)

     

    这是一个消息推送接口,记得将

     

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    @RequestMapping("pushMessage.json")  
        public void pushMessage(HttpServletResponse response,HttpServletRequest request){
             
                OutputStream bos = null;
                try {
                    String data1 =" www.imiansha.com爱面纱网站上线了\n\n";
                    String data2 = " www.imiansha.com爱面纱网站正在招兵买马\n\n";
                    //声明浏览器在连接断开之后进行再次连接之前的等待时间 10秒
                    String retry = "retry:"+10000+"\n\n";
                    //事件的标识符
                    String id="id:100\n\n";
                    //最后一次接收到的事件的标识符
                    String last = request.getHeader("Last-Event-ID");
                    logger.info(last);
                    bos = new BufferedOutputStream(response.getOutputStream());
                    response.setContentType("text/event-stream");//记得要设置哦
                    bos.write(data1.getBytes());
                    bos.write(data2.getBytes());
                    bos.write(retry.getBytes());
                    bos.write(id.getBytes());
                    bos.flush();
                } catch (IOException e) {
                    e.printStackTrace();
                }finally{
                    try {
                        bos.close();
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                }
     
             
        }

    2.客户端实现

     

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    <!DOCTYPE html>
    <html>
        <head>
            <meta charset="UTF-8">
            <title>HTML 5 服务器推送消息事件</title>
     
        </head>
     
        <body>
                    <h1>获得服务器更新的消息</h1>
                    <div id="result"></div>
                     
                    <script>
                    if(typeof(EventSource)!=="undefined")
                      {
                              var eventSource=new EventSource("/test/pushMessage.json");
                              eventSource.onopen = function(){
                                   console.log("连接打开。。。。。。");
                              }
    eventSource.onerror = function(e) {
    console.log('error');
    };
                              eventSource.onmessage=function(event) {
                                 
                                   document.getElementById("result").innerHTML+=event.data + "<br />";
                               };
                      }else{
                             document.getElementById("result").innerHTML="Sorry, your browser does not support server-sent events...";
                      }
                    </script>
        </body>
    </html>

     

    对IE 支持

     

    使用浏览器原生的 EventSource 对象的一个比较大的问题是 IE 并不提供支持。为了在 IE 上提供同样的支持,一般有两种办法。第一种办法是在其他浏览器上使用原生 EventSource 对象,而在 IE 上则使用简易轮询或 COMET 技术来实现;另外一种做法是使用 polyfill 技术,即使用第三方提供的 JavaScript 库来屏蔽浏览器的不同。本文使用的是 polyfill 技术,只需要在页面中加载第三方 JavaScript 库即可。应用本身的浏览器端代码并不需要进行改动。一般推荐使用第二种做法,因为这样的话,在服务器端只需要使用一种实现技术即可。

    在 IE 上提供类似原生 EventSource 对象的实现并不简单。理论上来说,只需要通过 XMLHttpRequest 对象来获取服务器端的响应内容,并通过文本解析,就可以提取出相应的事件,并触发对应的事件处理方法。不过问题在于 IE 上的 XMLHttpRequest 对象并不支持获取部分的响应内容。只有在响应完成之后,才能获取其内容。由于服务器端推送事件使用的是一个长连接。当连接一直处于打开状态时,通过 XMLHttpRequest 对象并不能获取响应的内容,也就无法触发对应的事件。更具体的来说,当 XMLHttpRequest 对象的 readyState 为 3(READYSTATE_INTERACTIVE)时,其 responseText 属性是无法获取的。

    为了解决 IE 上 XMLHttpRequest 对象的问题,就需要使用 IE 8 中引入的 XDomainRequest 对象。XDomainRequest 对象的作用是发出跨域的 AJAX 请求。XDomainRequest 对象提供了 onprogress 事件。当 onprogress 事件发生时,可以通过 responseText 属性来获取到响应的部分内容。这是 XDomainRequest 对象和 XMLHttpRequest 对象的最大不同,也是使用 XDomainRequest 对象来实现类似原生 EventSource 对象的基础。在使用 XDomainRequest 对象打开与服务器端的连接之后,当服务器端有新的数据产生时,可以通过 XDomainRequest 对象的 onprogress 事件的处理方法来进行处理,对接收到的数据进行解析,根据数据的内容触发相应的事件。

    不过由于 XDomainRequest 对象本来的目的是发出跨域 AJAX 请求,考虑到跨域访问的安全性问题,XDomainRequest 对象在使用时的限制也比较严格。这些限制会影响到其作为 EventSource 对象的实现方式。具体的限制和解决办法如下所示:

    • 服务器端的响应需要包含 Access-Control-Allow-Origin 头,用来声明允许从哪些域访问该 URL。“*”表示允许来自任何域的访问,不推荐使用该值。一般使用与当前应用相同的域,限制只允许来自当前域的访问。
    • XDomainRequest 对象发出的请求不能包含自定义的 HTTP 头,这就限制了不能使用 Last-Event-ID 头来声明浏览器端最近一次接收到的事件的标识符。只能通过 HTTP 请求的其他方式来传递该标识符,如 GET 请求的参数或 POST 请求的内容体。
    • XDomainRequest 对象的请求的内容类型(Content-Type)只能是“text/plain”。这就意味着,当使用 POST 请求时,服务器端使用的框架,如 servlet,不会对 POST 请求的内容进行自动解析,无法使用 HttpServletRequest 类的 getParameter 方法来获取 POST 请求的内容。只能在服务器端对原始的请求内容进行解析,获取到其中的参数的值。
    • XDomainRequest 对象发出的请求中不包含任何与用户认证相关的信息,包括 cookie 等。这就意味着,如果服务器端需要认证,则需要通过 HTTP 请求的其他方式来传递用户的认证信息,比如 session 的 ID 等。

    由于 XDomainRequest 对象的这些限制,服务器端的实现也需要作出相应的改动。这些改动包括返回 Access-Control-Allow-Origin 头;对于浏览器端发送的“text/plain”类型的参数进行解析;处理请求中包含的用户认证相关的信息。

    本文的示例使用的 polyfill 库是 GitHub 上的 Yaffle 开发的 EventSource 项目,具体的地址见参考资源。在使用该 polyfill 库,并对服务器端的实现进行修改之后,就可以在 IE 8 及以上的浏览器中使用服务器推送事件。如果需要支持 IE 7,则只能使用简易轮询或 COMET 技术。本文的示例代码见参考资源。

     

    小结

     

    如果需要从服务器端推送数据给浏览器,可以使用的基于 HTML 5 规范标准的技术包括 WebSocket 和服务器推送事件。开发人员可以根据应用的具体需求来选择合适的技术。如果只是需要从服务器端推送数据,服务器推送事件的规范更加简单,实现起来更容易。本文对服务器推送事件的规范内容、服务器端和浏览器端的实现都进行了详细的介绍,对如何支持 IE 浏览器也进行了具体的分析。

    参考资料

    W3C HTML 5 服务器发送事件

     

    W3C HTML 5 教程

     

              阿里云低价服务器1折特惠,优惠爽翻天,点我立即低价购买

    ---------------------------------------------------------------------------------------------------------------------------------------- 

    如果您认为本教程质量不错,读后觉得收获很大,预期工资能蹭蹭蹭的往上涨,那么不妨小额赞助我一下,让我有动力继续写出高质量的教程。 
       ----------------------------------------------------------------------------------------------------------------------------------------                                                           

     

     

     

    展开全文
  • 通常情况下,无论是web浏览器还是移动app,我们与服务器之间的交互都是主动的,客户端向服务器端发出请求,然后服务器端返回数据给客户端,客户端浏览器再将信息呈现,客户端与服务端对应的模式是: 客户端请求--...
  • 服务器主动推送技术

    千次阅读 2018-05-17 22:01:28
    传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作,服务端不能主动发送请求(消息)给客户端。 这种方式并不能满足很多现实应用的需求,譬如:  监控系统:后台硬件热插拔、LED、温度、电压发生变化;...
  • 服务器主动推送消息数据给客户端

    千次阅读 2019-02-11 15:17:14
    这个问题第一次是我在实现一个导师的方案的时候所发现的,一开始我需要实现服务器与客户端的密钥协商和数据传递,服务器需要主动分发(推送)密钥给客户端,因为以前没有做过相关编码,后来只能想到用反向连接,也...
  • 服务器推送技术的研究与应用

    千次阅读 2011-04-22 14:08:00
    3.1服务器推送技术(Server Push) 3.1.1服务器推送技术概述 服 务器推送技术是最近Web技术中最热门的一个流行术语,它是继AJAX之后又一个倍受追捧的Web技术。我们可以认为AJAX解决了单用户响应的...
  • Web服务器推送技术

    万次阅读 2009-05-12 11:47:00
    服务器推送(Server Push) 推送技术的基础思想是将浏览器主动查询信息改为服务器主动发送信息。服务器发送一批数据,浏览器显示这些数据,同时保证与服务器的连接。当服务器需要再次发送一批数据时,浏览器显示数据并...
  • 服务器推送技术之——SSE

    千次阅读 2018-08-18 14:58:02
    服务器推送技术在日常开发中较为常用。 SSE:Server send Event:服务端发送事件。 本项目推送技术是基于:当客户端向服务端发送请求,服务端会抓住这个请求不放,等有数据更新的时候才返回给客户端,当客户端...
  • 最近研究服务器推送技术
  • java web 服务器推送技术--comet4j

    万次阅读 2015-07-17 15:45:11
    首先实现服务器推送技术一直一来是B/S应用开发的一块难题,因为是基于HTTP协议的,HTTP协议为无状态,单向性的协议,即,必须由客户端发起一个请求建立连接,服务器接收请求,把数据返回给客户端,然后释放连接。...
  • 服务器推送技术

    2007-03-13 14:52:00
    Server push——崭新的“技术,它是一种先进的服务器和客户机之间的通信连接方式,利用在服务器端的CGI脚本程序把数据源源不断地推向客户机,从而使客户机和服务器之间的交互性能大大提高。在中国计算机报电脑...
  • 服务器推送技术常用的三个解决方案,im消息服务架构
  • 深入了解 cometd的服务器推送技术

    千次阅读 2013-09-14 19:17:20
    简介: 服务器推送技术已经出来一段时间了,业界上也有不少基于这种技术(应该说是设计模式)的开源实现,但是要移植或者说应用到自己的项目上都比较麻烦。Dojo 这样一个大型的 Web2.0 开发框架提供了一套封装好的...
  • dwr 后台服务器推送技术

    千次阅读 2013-09-28 20:52:10
    刚才写了一篇《dwr传对象到前台》,现在继续下一个总结点,dwr又一个令人兴奋的技术后台服务器推送技术,需要的包我就不写了 web.xml配置  DWR Servlet  dwr-invoker  org.directwebremoting.servlet.DwrServlet...
  • Comet服务器推送技术

    2015-04-01 13:21:46
    其思想很简单:将数据直接从服务器推到浏览器,而不必等到浏览器请求数据。 主要思想:服务器端将数据推送到客户端(浏览器) 本人做了简单的web实时聊天系统:  系统简单说明如下: { 系统所用数据库...
  • 主要思想:服务器端将数据推送到客户端(浏览器) 简单的web实时聊天系统:服务器推送(聊天).zip 系统简单说明如下: { 系统所用数据库:sqlite数据库  UserInfo:用户信息表  UserRelation:用户关系表  ...
  • Web应用服务器推送技术Comet

    千次阅读 2009-08-28 15:40:00
    由于只能由浏览器建立 Web 浏览器和服务器之间的 HTTP 连接,服务器无法在改动发生时将变化 “推送” 给浏览器。Ajax 应用程序可以使用两种基本的方法解决这一问题:一种方法是浏览器每隔若干秒时间向服务器
  • 服务器推送技术”(ServerPushing)是最近Web技术中最热门的一个流行术语。它是继“Ajax”之后又一个倍受追捧的Web技术。“服务器推送技术”最近的流行跟“Ajax ”有着密切的关系。 随着 Ajax技术的兴起,让...
  • 服务器推送消息方法总结及实现(java)

    万次阅读 多人点赞 2018-10-24 11:00:26
    服务器推送消息方法总结及实现(java) 最近在进行web开发时,有用到服务端推送消息这个功能,相信大家在平常开发时,也经常会有这种需求。本文对常用的几种服务器推送消息方法进行整理和总结,并实现使用流的方式推送...
  • HTML服务器推送技术简介

    千次阅读 2012-07-31 12:25:37
    1. 为什么需要服务器推送?   最大的优点:实时   适用场景:实时股票价格、商品价格、实时新闻、Twitter/weibo timeline、基于浏览器的聊天系统   2. Web交互的发展历程?   F5手动刷新 --> AJAX轮询...
  • 网络编程五-服务器推送技术

    万次阅读 2020-01-19 16:56:44
    一、服务器推送技术 1、服务器推送技术的兴起 2、应用场景 二、Ajax短轮询 1、定义 2、特点 三、Comet 3.1 AJAX 的长轮询 1、定义 2、特点 3.2 SSE 1、定义 2、特点 四、WebSocket通信 1、什么是...
  • 接收服务器推送普通消息 接收普通消息 当普通微信用户向公众账号发消息时,微信服务器将POST消息的XML数据包到开发者填写的URL上。 服务器介入获取微信推送消息代码: /** * 此方法用于微信回复消息 * @param ...
  • 推送技术的基础思想是将浏览器主动查询信息改为服务器主动发送信息。服务器发送一批数据,浏览器显示这些数据,同时保证与服务器的连接。当服务器需要再次发送一批数据时,浏览器显示数据并保持连接。以后,...
  • 服务器推送技术Server Push详解

    千次阅读 2012-07-31 12:13:58
    服务器推送技术(Server Push)是最近Web技术中最热门的一个流行术语,它的别名叫Comet(彗星)。它是继AJAX之后又一个倍受追捧的Web技术。服务器推送技术最近的流行与AJAX有着密切的关系。本文详细介绍了服务器推送技术...

空空如也

1 2 3 4 5 ... 20
收藏数 189,067
精华内容 75,626
关键字:

服务器推送