HTTP长连接的“服务器推”技术
浏览器与服务器长连接技术
浏览器与服务器长连接技术浏览器和服务器保持持久连接的⼿段。
定时器最简单，使⽤setTimeout、setInterval或其他计时⼿段定期向服务器发送请求，此⽅法优点就是简单，缺点就是不灵活，容易造成⼤量没有意义的请求。
长轮询浏览器向服务器发出⼀个请求，服务器收到请求并将这个请求挂起(pending)，当服务器需要向浏览器发送数据了，就响应挂起的这个请求，浏览器收到响应之后⽴刻再发送⼀个请求，服务器再把它挂起，如此反复，即实现了最简单的长轮询机制，它不需要任何新的协议。
适合B/S不频繁的通信，因为即便是很⼩的数据量，也要重新发送⼀个完整的http请求。
浏览器端代码：function validHttpStatus(){return arguments[0] > 199 && arguments[0] < 300;}async function longPolling(){let response = await fetch("http://localhost:3000/getdata");if (!validHttpStatus(response.status)) {// 发⽣了错误，打印⼀下错误console.error(`${response.url}: ${response.statusText}`);setTimeout(() => { // 过⼀会再试longPolling();}, 1e3);}else{// 打印出服务器返回的数据let data = await response.text();(data);// ⽴刻再次调⽤，保持连接⼀直处于打开状态longPolling();}}longPolling(); // 开始长轮询服务器端代码：// 使⽤了Koafunction delay(seconds){return new Promise(ok=>setTimeout(ok, 1e3*seconds));}router.get('/getdata', async(ctx, next)=>{ctx.set('Access-Control-Allow-Origin', '*');ctx.set('Content-Type', 'text/plain; charset=utf-8');ctx.set("Cache-Control", "no-store"); // 禁⽤缓存await delay(Math.floor(Math.random()*10) + 1); // 模拟服务器突然向浏览器响应数据ctx.body = 'hi ' + (new Date);await next();});Server Sent Event1. 只能由服务器向浏览器推送数据，浏览器不能主动向服务器发送数据2. 推送的数据只能是⽂本SSE使⽤的也是http协议，它可以⾃动重连，⽽websocket需要我们⼿动处理重连，对于单向的且数据量不多的情景可以使⽤SSE，没必要强⾏使⽤websocket。
sse原理
SSE原理介绍Server-Sent Events（SSE）是一种用于实现服务器向客户端推送数据的技术。
与传统的HTTP请求-响应模式不同，SSE允许服务器主动向客户端发送数据，实现实时性和即时通信。
SSE通常用于实时的Web应用程序、即时聊天、股票市场报价等场景。
SSE与传统长轮询的比较•长轮询：客户端发送一个请求给服务器，服务器不会立即响应，而是等待新的数据到达或者超时才会响应。
如果服务器没有新的数据，客户端必须重新发送请求。
这种方式需要频繁的客户端与服务器的交互，增加了网络负载和延迟。
•SSE：SSE使用了HTTP的长连接机制，通过一个持久的连接，服务器可以实时地向客户端发送数据，客户端只需要建立一次连接，接收完数据后，连接也不会断开。
这样可以减少了不必要的请求和响应，节省了网络资源并提高了实时性。
SSE协议SSE协议基于纯文本，使用HTTP协议的GET方法向服务器发送请求。
服务器使用Content-Type: text/event-stream作为响应头，告知客户端此次请求是SSE请求。
客户端通过EventSource对象监听服务器的响应。
SSE的消息格式服务器发送的每个消息都以data:开头，以两个换行符\n\n结束。
消息可以包含多行，每行以冒号开头，并使用换行符分隔。
示例：data: This is a messagedata: This is another messagedata: This is a multi-linedata: messageSSE的事件类型SSE允许服务器发送不同类型的事件给客户端，事件类型以event:开头，并使用换行符分隔。
客户端可以通过事件类型来过滤感兴趣的事件。
示例：event: logindata: UserA logged inevent: logoutdata: UserB logged out保持SSE连接的活跃为了保持SSE连接的活跃，服务器可以发送一个注释行（以冒号开头），客户端会忽略这一行并继续等待下一个消息。
DWR中的反向“全推”和“半推”AJAX技术（第1部分）
目录1.1DWR 中的反向“全推”和“半推”AJAX技术（第1部分） (2)1.1.1反向Ajax技术的实现原理 (2)1.1.2DWR 中的反向“全推”Ajax技术的实现实例 (5)1.1.3设计服务器端的Java程序类 (10)1.1DWR 中的反向“全推”和“半推”AJAX技术（第1部分）1.1.1反向Ajax技术的实现原理1、什么是反向Ajax技术（1）反向Ajax反向Ajax的基本概念是客户端不必从服务器获取信息，服务器会把相关信息直接推送到客户端。
（2）为什么要应用反向Ajax技术这样做的目的是解决Ajax传统Web模型下的实时信息获取的问题，常规的实现方式是客户端浏览器必须不断地请求服务器，并主动询问是否存在变更的信息，如果有变更的信息立即更新当前的页面（或者页面中的一部分）。
比如监控（后台硬件热插拔、LED、温度、电压发生变化）、即时通信（其它用户登录、发送信息）、即时报价系统（后台数据库内容发生变化）都需要将后台发生变化的数据实时地传送到客户端而无须客户端浏览器不停地刷新。
（3）反向Ajax技术能够更好地解决这个问题应用反向Ajax技术，能够实现由服务器主动地联系所有的浏览器，并通告这些浏览器服务器端的数据已经发生的变更。
2、常规的Web应用系统无法实现反向Ajax技术（1）常规的AJAX技术所存在的局限性AJAX技术提高了单用户操作的响应性，但Web 本质上是一个多用户的系统。
现有的AJAX 技术的发展并不能解决在一个多用户的Web 应用中，将更新的信息实时地传送给客户端，从而用户可能在“过时”的信息下进行操作。
（2）为什么常规的Web应用中无法实现反向Ajax技术因为HTTP的特点是需要客户端浏览器产生请求后，服务器端响应的程序才会产生响应输出。
如果客户端浏览器等程序不再对服务器端程序产生新的请求，服务器端响应的程序也就不响应客户端程序的请求。
因此，在正常的情况下，服务器端的程序是不可能操纵客户端浏览器。
轮询和长轮询
轮询和长轮询轮询：说⽩了就是客户端定时去请求服务端，是客户端主动请求来促使数据更新；长轮询：说⽩了也是客户端请求服务端，但是服务端并不是即时返回，⽽是当有内容更新的时候才返回内容给客户端，从流程上讲，可以理解为服务器向客户端推送内容；从中可以看出区别：轮询： 1：⼤量耗费服务器内存和宽带资源，因为不停的请求服务器，很多时候并没有新的数据更新，因此绝⼤部分请求都是⽆效请求 2：数据不⼀定是实时更新，要看设定的请求间隔，基本会有延迟。
长轮询： 1：解决了轮询的两个⼤问题，数据实时更新； 2：唯⼀的缺点是服务器在挂起的时候⽐较耗内存；web通信中的长连接长轮询基于HTTP的长连接，是⼀种通过长轮询⽅式实现“服务器推”的技术，它弥补了HTTP简单的请求应答模式的不⾜，极⼤地增强了程序的实时性和交互性。
什么是长连接、长轮询？ 简单点就是客户端不停的向服务器发送请求以后去最新的数据信息。
这⾥的 '不停' 其实是有停⽌的。
只是我们⼈眼⽆法分辨是否停⽌，它只是⼀种快速的停下然后⽴即开始连接⽽已。
应⽤场景 长连接、长轮询⼀般应⽤与webIM、ChatRoom和⼀些需要及时交互的⽹站应⽤中。
web版微信⼆维码 webQQ HI⽹页版，Facebook IM 等优缺点 轮询：客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息并关闭连接。
优点：后端程序编写⽐较容易。
缺点：请求中有⼤半是⽆⽤，浪费带宽和服务器资源。
实例：适于⼩型应⽤。
长轮询：客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求。
优点：在⽆消息的情况下不会频繁的请求，耗费资源⼩。
缺点：服务器hold连接会消耗资源，返回数据顺序⽆保证，难于管理维护。
实例：WebQQ、Hi⽹页版、Facebook IM。
长连接：在页⾯⾥嵌⼊⼀个隐蔵iframe，将这个隐蔵iframe的src属性设为对⼀个长连接的请求或是采⽤xhr请求，服务器端就能源源不断地往客户端输⼊数据。
HTTP长连接、短连接、长轮巡、短轮巡
HTTP长连接、短连接、长轮巡、短轮巡展开全文1.以前的误解很久之前就听说过长连接的说法，而且还知道HTTP1.0协议不支持长连接，从HTTP1.1协议以后，连接默认都是长连接。
但终究觉得对于长连接一直懵懵懂懂的，有种抓不到关键点的感觉。
今天通过一番研究，终于明白了这其中的奥秘。
而之前，也看过长连接相关的内容，但一直都是云里雾里的。
这次之所以能在这么短的时间里搞清楚，和自己技术的沉淀密不可分。
因此，这里借着这个机会，再次强调一下，千万不要试图去研究你研究了很久都整不明白的东西，或许是你的层次不到，也或许是你从未在实际的应用场景接触过，这种情况下你去研究，只会事倍功半，徒劳一番罢了。
回到正题，既然说是误解，那么的误解到底是什么？那就是一直认为，HTTP连接分为长连接和短连接，而我们现在常用的都是HTTP1.1，因此我们用的都是长连接。
这句话其实只对了一半，我们现如今的HTTP协议，大部分都是1.1的，因此我们平时用的基本上都是长连接。
但是前半句是不对的，HTTP协议根本没有长短连接这一说，也正因为误解了这个，导致对于长连接一直不明不白，始终不得其要领，具体下面一段会说到。
网络上很多文章都是误人子弟，根本没有说明白这个概念。
这里要强调一下，HTTP协议是基于请求/响应模式的，因此只要服务端给了响应，本次HTTP连接就结束了，或者更准确的说，是本次HTTP请求就结束了，根本没有长连接这一说。
那么自然也就没有短连接这一说了。
之所以网络上说HTTP分为长连接和短连接，其实本质上是说的TCP连接。
TCP连接是一个双向的通道，它是可以保持一段时间不关闭的，因此TCP连接才有真正的长连接和短连接这一说。
其实知道了以后，会觉得这很好理解。
HTTP协议说到底是应用层的协议，而TCP才是真正的传输层协议，只有负责传输的这一层才需要建立连接。
一个形象的例子就是，拿你在网上购物来说，HTTP协议是指的那个快递单，你寄件的时候填的单子就像是发了一个HTTP请求，等货物运到地方了，快递员会根据你发的请求把货物送给相应的收货人。
HTTP2之服务器推送（ServerPush）最佳实践
HTTP2之服务器推送（ServerPush）最佳实践商业转载请联系腾讯WeTest获得授权，⾮商业转载请注明出处。
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⽀持，并完成了详细的性能测试。
序⾔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正是基于此原理来提⾼⽹络体验。
http协议及长连接和短连接
http协议及长连接和短连接1. HTTP协议与TCP/IP协议的关系HTTP的长连接和短连接本质上是TCP长连接和短连接。
HTTP属于应⽤层协议，在传输层使⽤TCP协议，在⽹络层使⽤IP协议。
IP协议主要解决⽹络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得⽹络上接收端收到发送端所发出的所有包，并且顺序与发送顺序⼀致。
TCP协议是可靠的、⾯向连接的。
2. 如何理解HTTP协议是⽆状态的HTTP协议是⽆状态的，指的是协议对于事务处理没有记忆能⼒，服务器不知道客户端是什么状态。
也就是说，打开⼀个服务器上的⽹页和上⼀次打开这个服务器上的⽹页之间没有任何联系。
HTTP是⼀个⽆状态的⾯向连接的协议，⽆状态不代表HTTP不能保持TCP连接，更不能代表HTTP使⽤的是UDP协议（⽆连接）。
3. 什么是长连接、短连接？在HTTP/1.0中默认使⽤短连接。
也就是说，客户端和服务器每进⾏⼀次HTTP操作，就建⽴⼀次连接，任务结束就中断连接。
当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript⽂件、图像⽂件、CSS⽂件等），每遇到这样⼀个Web资源，浏览器就会重新建⽴⼀个HTTP会话。
⽽从HTTP/1.1起，默认使⽤长连接，⽤以保持连接特性。
使⽤长连接的HTTP协议，会在响应头加⼊这⾏代码：Connection:keep-alive在使⽤长连接的情况下，当⼀个⽹页打开完成后，客户端和服务器之间⽤于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使⽤这⼀条已经建⽴的连接。
Keep-Alive不会永久保持连接，它有⼀个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。
实现长连接需要客户端和服务端都⽀持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
3.1. TCP连接当⽹络通信时采⽤TCP协议时，在真正的读写操作之前，客户端与服务器端之间必须建⽴⼀个连接，当读写操作完成后，双⽅不再需要这个连接时可以释放这个连接。
HTTP长连接--Keep-Alive
HTTP长连接--Keep-Alive⼀、HTTP/1.0HTTP1.0版本的Keep-alive并不像HTTP1.1那样是默认发送的，所以要想连接得到保持，必须⼿动配置发送connection：keep-alive字段。
若想断开keep-alive连接，需发送Connection:close字段注意：这⾥的连接是HTTP依赖的传输协议TCP，⽽不是HTTP本⾝。
为什么需要长连接？长连接可以提⾼连接的利⽤效率，即HTTP可以复⽤⼀条连接。
例如某个⽤户浏览⼀个⽹站，他很长⼀段时间才跳转到另⼀个链接，似乎保持长连接没有什么好处，很浪费资源。
但如果这个⽹站的并发量很⼤，保持长连接的好处就凸显了。
如果每个请求都需要建⽴新的TCP连接，那对服务器的开销是相当的。
建⽴连接报⽂⾸部格式：Connection:Keep-AliveKeep-Alive：timeout ; max #参数之间⽤；分号隔开参数：max 最⼤处理事务数量timeout 连接保持的时间，单位为秒断开连接报⽂⾸部格式：Connection:closeKeep-Alive的建⽴过程客户端向服务器在发送请求报⽂同时在⾸部添加发送Connection字段》服务器收到请求并处理connection字段》服务器回送Connection:Keep-Alive字段给客户端》客户端接收到connection字段》Keep-Alive连接建⽴成功服务端⾃动断开过程：客户端向服务器只是发送内容报⽂（不包含Connection字段）》服务器收到请求并处理》服务器返回客户端请求的资源并关闭连接》客户端接收资源，发现没有Connection字段，断开连接客户端请求断开连接过程：客户端向服务器发送Connection:close字段》服务器收到请求并处理connection字段》服务器回送响应资源并断开连接》客户端接收资源并断开连接事务：在基于TCP连接的http协议中，⼀个事务表⽰客户端向服务端请求⼀个资源并得到响应返回的过程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
基于客户端套接口的“服务器推”技术
Flash XMLSocket
如果 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行，那么使用 Flash 的 XMLSocket 也是一个可行的方案。
这种方案实现的基础是：
1. Flash 提供了 XMLSocket 类。
2. JavaScript 和 Flash 的紧密结合：在 JavaScript 可以直接调用
Flash 程序提供的接口。
具体实现方法：在 HTML 页面中内嵌入一个使用了 XMLSocket 类的Flash 程序。
JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。
JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。
关于如何去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash 程序，以及如何在 JavaScript 里调用 Flash 提供的接口，我们可以参考 AFLAX（Asynchronous Flash and XML）项目提供的 Socket Demo 以及 SocketJS。
Javascript 与 Flash 的紧密结合，极大增强了客户端的处理能力。
从Flash 播放器 V7.0.19 开始，已经取消了 XMLSocket 的端口必须大于1023 的限制。
Linux 平台也支持 Flash XMLSocket 方案。
但此方案的缺点在于：
1. 客户端必须安装 Flash 播放器；
2. 因为 XMLSocket 没有 HTTP 隧道功能，XMLSocket 类不能自动
穿过防火墙；
3. 因为是使用套接口，需要设置一个通信端口，防火墙、代理服务器
也可能对非 HTTP 通道端口进行限制；
不过这种方案在一些网络聊天室，网络互动游戏中已得到广泛使用。
Java Applet 套接口
在客户端使用 Java Applet，通过.Socket或
.DatagramSocket或.MulticastSocket建立与服务器端的套接口连接，从而实现“服务器推”。
这种方案最大的不足在于 Java applet 在收到服务器端返回的信息后，无法通过 JavaScript 去更新 HTML 页面的内容。
基于 HTTP 长连接的“服务器推”技术
Comet 简介
浏览器作为 Web 应用的前台，自身的处理功能比较有限。
浏览器的发展需要客户端升级软件，同时由于客户端浏览器软件的多样性，在某种意义上，也影响了浏览器新技术的推广。
在 Web 应用中，浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。
AJAX 是浏览器技术发展的成果，通过在浏览器端发送异步请求，提高了单用户操作的响应性。
但 Web 本质上是一个多用户的系统，对任何用户来说，可以认为服务器是另外一个用户。
现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中，将更新的信息实时传送给客户端，从而用户可能在“过时”的信息下进行操作。
而 AJAX 的应用又使后台数据更新更加频繁成为可能。
图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较
“服务器推”是一种很早就存在的技术，以前在实现上主要是通过客户端的套接口，或是服务器端的远程调用。
因为浏览器技术的发展比较缓慢，没有为“服务器推”的实现提供很好的支持，在纯浏览器的应用中很难有一个完善的方案去实现“服务器推” 并用于商业程序。
最近几年，因为 AJAX 技术的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 组件中可以解决 IE 的加载显示问题，一些受欢迎的应用如 meebo，
gmail+gtalk 在实现中使用了这些新技术；同时“服务器推”在现实应用中确实存在很多需求。
因为这些原因，基于纯浏览器的“服务器推”技术开始受到较多关注，Alex Russell（Dojo Toolkit 的项目 Lead）称这种基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推”技术
为“Comet”。
目前已经出现了一些成熟的 Comet 应用以及各种开源框架；一些 Web 服务器如 Jetty 也在为支持大量并发的长连接进行了很
多改进。
关于 Comet 技术最新的发展状况请参考关于 Comet 的 wiki。
下面将介绍两种 Comet 应用的实现模型。
基于 AJAX 的长轮询（long-polling）方式
如图1所示，AJAX 的出现使得 JavaScript 可以调用 XMLHttpRequest 对象发出 HTTP 请求，JavaScript 响应处理函数根据服务器返回的信息对 HTML 页面的显示进行更新。
使用 AJAX 实现“服务器推”与传统的AJAX 应用不同之处在于：
1. 服务器端会阻塞请求直到有数据传递或超时才返回。
2. 客户端 JavaScript 响应处理函数会在处理完服务器返回的信息
后，再次发出请求，重新建立连接。
3. 当客户端处理接收的数据、重新建立连接时，服务器端可能有新的
数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。
图 2. 基于长轮询的服务器推模型
一些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。
相对于“轮询”（poll），这种长轮询方式也可以称为“拉”（pull）。
因为这种方案基于 AJAX，具有以下一些优点：请求异步发出；无须安装插件；IE、Mozilla FireFox 都支持 AJAX。
在这种长轮询方式下，客户端是在 XMLHttpRequest 的 readystate 为4（即数据传输结束）时调用回调函数，进行信息处理。
当 readystate 为 4 时，数据传输结束，连接已经关闭。
Mozilla Firefox 提供了对Streaming AJAX 的支持，即 readystate 为 3 时（数据仍在传输中），客户端可以读取数据，从而无须关闭连接，就能读取处理服务器端返回的信息。
IE 在 readystate 为 3 时，不能读取服务器返回的数据，目前 IE 不支持基于 Streaming AJAX。