在各種BS架構的應用程式中，往往都希望服務端能夠主動地向客戶端推送各種訊息，以達到類似郵件、訊息、待辦事項等通知。
往BS架構本身存在的問題就是，伺服器一直採用的是一問一答的機制。這就意味著如果客戶端不主動地向伺服器發送訊息，伺服器就無法得知如何向客戶端推播訊息。
隨著HTML、瀏覽器等各項技術、標準的發展，依序產生了不同的手段與方法能夠實現服務端主動推播訊息，它們分別是：AJAX，Comet，ServerSent以及WebSocket。
本篇文章將對上述提及到的各種技術手段進行直白化的解釋。
AJAX
正常的一個頁面在瀏覽器中是這樣運作的：
使用者給予瀏覽器一個需要存取的位址
瀏覽器根據這個位址存取伺服器，並與伺服器之間建立一個TCP連接（HTTP請求）
伺服器根據這個位址和一些其它數據，組成一段HTML文本，將寫入TCP連接，然後關閉連接
瀏覽器得到了來自伺服器的HTML文本，解析並呈現了瀏覽器上給用戶瀏覽
此時，用戶點擊了網站上任何一個或觸發任何一個
瀏覽器根據form的參數或a的參數，作為訪問的地址
#與伺服器建立TCP連線
伺服器組成HTML文本，然後關閉連接
瀏覽器將當前顯示的頁面摧毀，並按照新的HTML文本呈現一個新的頁面給用戶
我們不難發現的是整個過程中間，一旦建立了一個連接，頁面就無法再維護住了。整個過程看起來有點強買強賣，也許我只要一杯新的可樂，但你非要給我一整個套餐組合。
此時我們可以了解XmlHttpRequest元件，這個元件提供我們手動建立一個HTTP請求，發送我們想要的數據，伺服器也可以只回傳我們想要的結果，最大的好處是，當我們收到伺服器的回應時，原來的頁面沒有被摧毀。這就好比，我喊一句"我的咖啡喝完了，我要續杯"，然後服務員就拿了一杯咖啡過來，而不是會把我沒吃完的套餐全部倒掉。
當我們利用AJAX實現伺服器推送時，其實質是客戶端不停地向伺服器詢問"有沒有給我的消息呀？"，然後伺服器回答"有"或"沒有"來達到的實現效果。它的實作方法也很簡單，利用jQuery框架封裝好的AJAX呼叫也很方便：
function getMessage(fn) {
$.ajax({
url: "Handler.ashx", //一个能够提供消息的页面
dataType: "text", //响应类型，可以是JSON，XML等其它类型
type: "get", //HTTP请求类型，还可以是post
success: function (d, s) {
fn(d); //得到了正常的响应时，利用回调函数通知外部 },
complete: function (x, s) {
setTimeout(function () {
getMessage(fn);
}, 5000); //无论响应成功或失败，在若干秒后再询问一次服务器 }
});
}透過上面的程式碼，可以每隔5秒詢問一次伺服器是否有需要處理的訊息，透過這種方式可以達到推送的效果，但是會存在一個問題：
間隔時間越快，推送的及時性越好，伺服器的消費越大；
間隔時間越慢，推送的及時性越低，伺服器的消費越小。
而且嚴格來說，這種實際方式，並不是真正意義上的伺服器主動推播訊息，但由於早期技術手段缺乏，所以AJAX輪循成為了一種很普遍的手段。
下面對伺服器推送事件的規範進行具體的說明。
規格
Server-sent Events 規格是 HTML 5 規範的一個組成部分，具體的規範文件請參閱參考資源。此規範較簡單，主要由兩個部分組成：第一個部分是伺服器端與瀏覽器端之間的通訊協議，第二部分則是在瀏覽器端可供JavaScript 使用的EventSource對象。通訊協定是基於純文字的簡單協定。伺服器端的回應的內容類型是「text/event-stream」。回應文字的內容可以看成是一個事件流，由不同的事件所組成。每個事件由類型和資料兩部分組成，同時每個事件可以有一個可選的識別碼。不同事件的內容之間透過僅包含回車符和換行符的空白行（“\r\n”）來分隔。每個事件的資料可能由多行組成。程式碼清單 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，表示該行用來聲明瀏覽器在連線中斷之後進行再次連線之前的等待時間。
在上面程式碼中，第一個事件只包含資料“first event”，會產生預設的事件；第二個事件的識別碼是100，資料為“second event 」；第三個事件會產生類型為「myevent」的事件；最後一個事件的資料為「fourth event\nfourth event continue」。當有多行資料時，實際的資料由每行資料以換行符號連接而成。
如果伺服器端傳回的資料包含了事件的標識符，瀏覽器會記錄最近一次接收到的事件的標識符。如果與伺服器端的連線中斷，當瀏覽器端再次進行連線時，會透過 HTTP 頭「Last-Event-ID」來宣告最後一次接收到的事件的識別碼。伺服器端可以透過瀏覽器端發送的事件標識符來確定從哪個事件開始來繼續連線。
對於伺服器端傳回的回應，瀏覽器端需要在 JavaScript 中使用 EventSource 物件來處理。 EventSource 使用的是標準的事件監聽器方式，只需要在物件上新增對應的事件處理方法即可。 EventSource 提供了三個標準事件，如表 1 所示。
表1. EventSource 物件提供的標準事件
name | ||
| 說明 | 事件處理方法 | |
| 當成功與伺服器建立連線時產生 | onopen | |
如之前所述，服务器端可以返回自定义类型的事件。对于这些事件，可以使用 addEventListener 方法来添加相应的事件处理方法。代码清单 2 给出了 EventSource 对象的使用示例。
EventSource 对象的使用示例
var es = new EventSource('events');
es.onmessage = function(e) {
console.log(e.data);
};
es.addEventListener('myevent', function(e) {
console.log(e.data);
});如上所示，在指定 URL 创建出 EventSource 对象之后，可以通过 onmessage 和 addEventListener 方法来添加事件处理方法。当服务器端有新的事件产生，相应的事件处理方法会被调用。EventSource 对象的 onmessage 属性的作用类似于 addEventListener( ‘ message ’ )，不过 onmessage 属性只支持一个事件处理方法。在介绍完服务器推送事件的规范内容之后，下面介绍服务器端的实现。
服务器端和浏览器端实现
从上一节中对通讯协议的描述可以看出，服务器端推送事件是一个比较简单的协议。服务器端的实现也相对比较简单，只需要按照协议规定的格式，返回响应内容即可。在开源社区可以找到各种不同的服务器端技术相对应的实现。自己开发的难度也不大。本文使用 Java 作为服务器端的实现语言。相应的实现基于开源的 jetty-eventsource-servlet 项目，见参考资源。下面通过一个具体的示例来说明如何使用 jetty-eventsource-servlet 项目。示例用来模拟一个物体在某个限定空间中的随机移动。该物体从一个随机位置开始，然后从上、下、左和右四个方向中随机选择一个方向，并在该方向上移动随机的距离。服务器端不断改变该物体的位置，并把位置信息推送给浏览器，由浏览器来显示。
服务器端实现
服务器端的实现由两部分组成：一部分是用来产生数据的 org.eclipse.jetty.servlets.EventSource 接口的实现，另一部分是作为浏览器访问端点的继承自 org.eclipse.jetty.servlets.EventSourceServlet 类的 servlet 实现。下面代码给出了 EventSource 接口的实现类。
EventSource 接口的实现类 MovementEventSource
public class MovementEventSource implements EventSource {
private int width = 800;
private int height = 600;
private int stepMax = 5;
private int x = 0;
private int y = 0;
private Random random = new Random();
private Logger logger = Logger.getLogger(getClass().getName());
public MovementEventSource(int width, int height, int stepMax) {
this.width = width;
this.height = height;
this.stepMax = stepMax;
this.x = random.nextInt(width);
this.y = random.nextInt(height);
}
@Override
public void onOpen(Emitter emitter) throws IOException {
query(emitter); //开始生成位置信息
}
@Override
public void onResume(Emitter emitter, String lastEventId)
throws IOException {
updatePosition(lastEventId); //更新起始位置
query(emitter); //开始生成位置信息
}
//根据Last-Event-Id来更新起始位置
private void updatePosition(String id) {
if (id != null) {
String[] pos = id.split(",");
if (pos.length > 1) {
int xPos = -1, yPos = -1;
try {
xPos = Integer.parseInt(pos[0], 10);
yPos = Integer.parseInt(pos[1], 10);
} catch (NumberFormatException e) {
}
if (isValidMove(xPos, yPos)) {
x = xPos;
y = yPos;
}
}
}
}
private void query(Emitter emitter) throws IOException {
emitter.comment("Start sending movement information.");
while(true) {
emitter.comment("");
move(); //移动位置
String id = String.format("%s,%s", x, y);
emitter.id(id); //根据位置生成事件标识符
emitter.data(id); //发送位置信息数据
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
logger.log(Level.WARNING, \
"Movement query thread interrupted. Close the connection.", e);
break;
}
}
emitter.close(); //当循环终止时，关闭连接
}
@Override
public void onClose() {
}
//获取下一个合法的移动位置
private void move() {
while (true) {
int[] move = getMove();
int xNext = x + move[0];
int yNext = y + move[1];
if (isValidMove(xNext, yNext)) {
x = xNext;
y = yNext;
break;
}
}
}
//判断当前的移动位置是否合法
private boolean isValidMove(int x, int y) {
return x >= 0 && x <= width && y >=0 && y <= height;
}
//随机生成下一个移动位置
private int[] getMove() {
int[] xDir = new int[] {-1, 0, 1, 0};
int[] yDir = new int[] {0, -1, 0, 1};
int dir = random.nextInt(4);
return new int[] {xDir[dir] * random.nextInt(stepMax), \
yDir[dir] * random.nextInt(stepMax)};
}
}类 MovementEventSource 需要实现 EventSource 接口的 onOpen、onResume 和 onClose 方法，其中 onOpen 方法在浏览器端的连接打开的时候被调用，onResume 方法在浏览器端重新建立连接时被调用，onClose 方法则在浏览器关闭连接的时候被调用。onOpen 和 onResume 方法都有一个 EventSource.Emitter 接口类型的参数，可以用来发送数据。EventSource.Emitter 接口中包含的方法包括 data、event、comment、id 和 close 等，分别对应于通讯协议中各种不同类型的事件。而 onResume 方法还额外包含一个参数 lastEventId，表示通过 Last-Event-ID 头发送过来的最近一次事件的标识符。
MovementEventSource 类中事件生成的主要逻辑在 query 方法中。该方法中包含一个无限循环，每隔 2 秒钟改变一次位置，同时把更新之后的位置通过 EventSource.Emitter 接口的 data 方法发送给浏览器端。每个事件都有对应的标识符，而标识符的值就是位置本身。如果连接断开之后，浏览器重新进行连接，可以从上一次的位置开始继续移动该物体。
与 MovementEventSource 类对应的 servlet 实现比较简单，只需要继承自 EventSourceServlet 类并覆写 newEventSource 方法即可。在 newEventSource 方法的实现中，需要返回一个 MovementEventSource 类的对象，如下所示。每当浏览器端建立连接时，该 servlet 会创建一个新的 MovementEventSource 类的对象来处理该请求。
servlet 实现类 MovementServlet
public class MovementServlet extends EventSourceServlet {
@Override
protected EventSource newEventSource(HttpServletRequest request,
String clientId) {
return new MovementEventSource(800, 600, 20);
}
}在服务器端实现中，需要注意的是要添加相应的 servlet 过滤器支持。这是 jetty-eventsource-servlet 项目所依赖的 Jetty Continuations 框架的要求，否则的话会出现错误。添加过滤器的方式是在 web.xml 文件中添加代码如下所示的配置内容。
Jetty Continuations 所需 servlet 过滤器的配置
<filter>
<filter-name>continuation</filter-name>
<filter-class>org.eclipse.jetty.continuation.ContinuationFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>continuation</filter-name>
<url-pattern>/sse/*</url-pattern>
</filter-mapping>浏览器端实现
浏览器端的实现也比较简单，只需要创建出 EventSource 对象，并添加相应的事件处理方法即可。下面代码给出了相应的实现。在页面中使用一个方块表示物体。当接收到新的事件时，根据事件数据中给出的坐标信息，更新方块在页面上的位置。
浏览器端的实现代码
var es = new EventSource('sse/movement');
es.addEventListener('message', function(e) {
var pos = e.data.split(','), x = pos[0], y = pos[1];
$('#box').css({
left : x + 'px',
top : y + 'px'
});
});在介绍完基本的服务器端和浏览器端实现之后，下面介绍比较重要的 IE 的支持。
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 瀏覽器也進行了具體的分析。
以上是html5伺服器推送的詳細介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！
