分类： 云计算
2022-08-24 13:58:55
一般来说，Web端即时通讯技术因受限于浏览器的设计限制，一直以来实现起来并不容易，主流的Web端即时通讯方案大致有4种：传统Ajax短轮询、Comet技术、WebSocket技术、SSE（Server-sent Events）。
服务器推送事件（Server-sent Events），简称SSE，是 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 服务器推送事件（SSE技术）之前，首先介绍一些上面提到的几种服务器端数据推送技术。
第一种是 WebSocket。WebSocket 规范是 HTML 5 中的一个重要组成部分，已经被很多主流浏览器所支持，也有不少基于 WebSocket 开发的应用。正如名称所表示的一样，WebSocket 使用的是套接字连接，基于 TCP 协议。使用 WebSocket 之后，实际上在服务器端和浏览器之间建立一个套接字连接，可以进行双向的数据传输。WebSocket 的功能是很强大的，使用起来也灵活，可以适用于不同的场景。不过 WebSocket 技术也比较复杂，包括服务器端和浏览器端的实现都不同于一般的 Web 应用。
除了 WebSocket 之外，其他的实现方式是基于 HTTP 协议来达到实时推送的效果。第一种做法是简易轮询，即浏览器端定时向服务器端发出请求，来查询是否有数据更新。这种做法比较简单，可以在一定程度上解决问题。不过对于轮询的时间间隔需要进行仔细考虑。轮询的间隔过长，会导致用户不能及时接收到更新的数据；轮询的间隔过短，会导致查询请求过多，增加服务器端的负担。
综合比较上面提到的 4 种不同的技术，简易轮询由于其本身的缺陷，并不推荐使用。Comet 技术并不是 HTML 5 标准的一部分，从兼容标准的角度出发，也不推荐使用。WebSocket 规范和服务器推送技术都是 HTML 5 标准的组成部分，在主流浏览器上都提供了原生的支持，是推荐使用的。不过 WebSocket 规范更加复杂一些，适用于需要进行复杂双向数据通讯的场景。对于简单的服务器数据推送的场景，使用服务器推送（SSE技术）事件就足够了。
在浏览器支持方面，服务器推送事件（SSE技术）已经在除 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 的支持，在下面的章节中有详细的介绍。
与WebSocket的比较
简单不说，SSE适用于更新频繁、低延迟并且数据都是从服务端到客户端。
它和WebSocket的区别：
便利，不需要添加任何新组件，用任何习惯的后端语言和框架就能继续使用，不用为新建虚拟机弄一个新的IP或新的端口号而劳神。
服务器端的简洁。因为SSE能在现有的HTTP/HTTPS协议上运作，所以它能够直接运行于现有的代理服务器和认证技术。
WebSocket相较SSE最大的优势在于它是双向交流的，这意味着服务器发送数据就像从服务器接受数据一样简单，而SSE一般通过一个独立的Ajax请求从客户端向服务端传送数据，因此相对于WebSocket使用Ajax会增加开销。因此，如果需要以每秒一次或者更快的频率向服务端传输数据，就应该用WebSocket。
SSE（Server-sent Events）在HTML 5中的技术规范和定义
Server-sent Events 规范是 HTML 5 规范的一个组成部分，具体的规范文档见参考资源。该规范比较简单，主要由两个部分组成：第一个部分是服务器端与浏览器端之间的通讯协议，第二部分则是在浏览器端可供 JavaScript 使用的 EventSource 对象。通讯协议是基于纯文本的简单协议。服务器端的响应的内容类型是“text/event-stream”。响应文本的内容可以看成是一个事件流，由不同的事件所组成。每个事件由类型和数据两部分组成，同时每个事件可以有一个可选的标识符。不同事件的内容之间通过仅包含回车符和换行符的空行（“\r\n”）来分隔。每个事件的数据可能由多行组成。代码清单 1 给出了服务器端响应的示例。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
SSE实战示例：服务器端和浏览器端实现
从上一节中对通讯协议的描述可以看出，服务器端推送事件是一个比较简单的协议。服务器端的实现也相对比较简单，只需要按照协议规定的格式，返回响应内容即可。在开源社区可以找到各种不同的服务器端技术相对应的实现。自己开发的难度也不大。本文使用 Java 作为服务器端的实现语言。相应的实现基于开源的 jetty-eventsource-servlet 项目，见参考资源。下面通过一个具体的示例来说明如何使用 jetty-eventsource-servlet 项目。示例用来模拟一个物体在某个限定空间中的随机移动。该物体从一个随机位置开始，然后从上、下、左和右四个方向中随机选择一个方向，并在该方向上移动随机的距离。服务器端不断改变该物体的位置，并把位置信息推送给浏览器，由浏览器来显示。
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”类型的参数进行解析；处理请求中包含的用户认证相关的信息。
