3.5 Communication API 95 在上述代碼中，用到了EventSource接口，該接口的相關內容見表3-6a 表3-6Bvent Source接口 EventSource接口的工作步驟如下所示。 (1)解析URL地址，如果不能正常解析，則拋出SYNTAX_ERR異常。 (2)返回一個新的EventSource對象，并在后臺繼續下面的步驟。 (3)如果源絕對地址與當前腳本不是同一個地址，則發生網絡錯誤，提示連接失敗，同時放 棄后續步驟。 (4)如果地址匹配成功，則向客戶端發出成功狀態，并開始接收數據。 ●移動端服務器端推送 由于移動端的方案越來越多，我們在這里特意對基于移動設備的服務器端事件的詳細通信步 驟和管理過程進行了解析。 基于移動端設備的瀏覽器在發起一個連接后，將檢測是否支持代理網絡接管網絡連接，其通 信過程如下所示。 (1)瀏覽器連接到一個遠程HTTP服務器，請求源返回一個EventSource結構的信息。 (2)服務器發出臨時消息。 (3)在兩個消息之間，瀏覽器除了保持必要的動態連接外，將自動切換到休眠模式以節省 電力。 (4)瀏覽器從服務器端斷開。 (5)瀏覽器聯系上一個網絡中的服務，并請求那個服務烈“推送代理”的形式代替連接。 (6)推送代理服務聯系到遠程主機，并請求源以Event Source結構作出反應（也許還包括 Last-Event．ID HTTP頭）o (7)瀏覽器允許移動設備休眠。 (8)服務器發出另一個消息。 (9)推送代理服務用一個像OMA推送的技術傳送事件到移動設備端，喚醒并執行此事件進 程，然后進入休眠。 ．服務器端推送事件應用方案濟南網站建設公司建議當開發人員在實際工程中，有那種只需要服務器向客戶端推送，而不需要客戶端太多反饋的 技術需要時，可以考慮采用這樣的技術方案。與WebSocket相比，SSE的優勢在于，可以用緩存， 96 第3章 劃時代的Web API 可以用服務器代理，僅服務器到瀏覽器單向。這個事件對環境要求不高，在特殊情況下可以發揮 非常重要的作用，例如新聞、音頻廣播、事務數據流等的定時推送。 3．管道消息傳送 管道消息傳送（channel messaging），允許用戶在一個事件上，以獨立的兩條管道進行通信， 這是本機一對多的通信。較之目前所有的HTTP通信方式而言，這種通信方式還是比較罕見的。 目前它還是WHATWGO的內容，尚未成為正式標準，但是技術新穎，因此本節只對代碼實現進行 概要性的介紹，供讀者預覽和參考。 同上例一樣，為了讓大家有個較為直觀的認識，我們給出了一部分示例代碼，最完整的代碼 請從本書配套網站上下載： ／／建立一個帝雙端口的通信連接 var channel =new MessageChannel(); ／／其中一個是本地的端口，另一個是發送到遠程的端口 otherWindow.postMessageI’hello’， ’http://example.com’， 【channel.port2】）； ／／使用postMessage方法在1號端口發遞消息 channel. portl. postMessage(’hello‘); ，／在I號甍口接收消息或者苴聽消息事件 channel. portl. onmessage=handleMessage; function handleMessage (event)t ／／信息在event．data數據中 ) 管道消息傳送非常類似于Web Worker，但又不是Web Worker，它主要是兩個端口的數據交換， 非常類似于通信路由和交換節點。 若是想得再遠一些，只要發起這個管道通信的機器有獨立的IP，架起一個Web服務，就可 以用這個方式切入網絡，使自己成為一臺數據交換和服務的節點。圖3-8是管道消息通信的圖 形解釋。 圖 3-8 ①WHATWG( Web HyWtcxt Application Tecbnology working Group．網頁超文本技術工作小組)是一個以推動HTML5 標準為目的而成立的組織。——編者注