當前位置：首頁 > news >正文

網(wǎng)站入口設計規(guī)范seo優(yōu)化培訓課程

news 2025/7/4 11:19:14

網(wǎng)站入口設計規(guī)范,seo優(yōu)化培訓課程,做網(wǎng)站點擊率賺錢,pb代做網(wǎng)站3．1服務器推送技術(Server Push) 3．1．1服務器推送技術概述服務器推送技術是最近Web技術中最熱門的一個流行術語，它是繼AJAX之后又一個倍受追捧的Web技術。我們可以認為AJAX解決了單用戶響應的問題，而服務器推送則…

3．1服務器推送技術(Server Push)

3．1．1服務器推送技術概述

服務器推送技術是最近Web技術中最熱門的一個流行術語，它是繼AJAX之后又一個倍受追捧的Web技術。我們可以認為AJAX解決了單用戶響應的問題，而服務器推送則解決了在保證性能的前提下進行協(xié)同多用戶的響應問題。由圖3．1和圖3．2的比較可以看出，服務器推送的優(yōu)點在于它可以在任何時候向客戶端發(fā) 送數(shù)據(jù)，而不僅僅只是響應用戶的輸入請求。而發(fā)送數(shù)據(jù)是在一個已有的單連接上進行的，因此可以大大降低發(fā)送數(shù)據(jù)的延遲時間(建立連接的開銷，以及客戶端發(fā) 送請求的等待時間)。

傳統(tǒng)模式的Web系統(tǒng)以客戶端發(fā)出請求、服務器端響應的方式工作。瀏覽器的主要工作是發(fā)送請求、解析服務器的回復消息并顯示。服務器的主要工作是根據(jù)接收瀏覽器發(fā)送的各種請求作出響應。

瀏覽器作為Web應用的前臺，自身的處理功能比較有限。AJAX是瀏覽器技術發(fā)展的成果，通過在瀏覽器端發(fā)送異步請求，提高了單用戶操作的響應性。AJAX 將整個頁面的刷新變成頁面局部的刷新，并且數(shù)據(jù)的傳送是以異步方式進行，這使得網(wǎng)絡延遲帶來的視覺差異將會消失。AJAX還利用DHTML和豐富的 JavasSript語言來模擬桌面系統(tǒng)的各種事件和響應過程，以及平滑滾動和拖拽的效果。在AJAX的世界中，除了傳統(tǒng)的CAD設計軟件和大型游戲軟件等因為對系統(tǒng)硬件的苛刻需求，還離不開桌面系統(tǒng)以外，似乎其他所有的應用都可以變成Web應用了。

但是傳統(tǒng)的Web應用包括基于AJAX的Web應用還是存在一個致命的缺陷，使得Web系統(tǒng)無法滿足傳統(tǒng)桌面系統(tǒng)的需求，那就是：服務器發(fā)起的消息傳遞 (Server-InitiatedMessage Delivery)。在很多的應用當中，服務器端需要向客戶端主動發(fā)送消息或信息。因為服務器掌握著系統(tǒng)的主要資源，能夠最先獲得系統(tǒng)的狀態(tài)變化和事件的發(fā)生。當這些變化發(fā)生的時候，服務器需要主動地向客戶端實時地發(fā)送消息。例如監(jiān)控、即時通信、即時報價系統(tǒng)等都需要將后臺發(fā)生的變化實時傳送到客戶端而無須客戶端不停地刷新頁面、發(fā)送請求。在傳統(tǒng)的桌面系統(tǒng)中，這種需求沒有任何問題，因為客戶端和服務器之間通常存在著持久的連接，這個連接可以雙向傳遞各種數(shù)據(jù)。而基于I-1TrP協(xié)議的傳統(tǒng)Web應用卻不行，在這些系統(tǒng)中，Web服務器總是被動地根據(jù)客戶端的請求發(fā)送數(shù)據(jù)，它無法保證服務器將更新的信息實時地傳送給客戶端，從而用戶可能在“過時”的信息下進行操作。

在傳統(tǒng)的Web系統(tǒng)中，只有當瀏覽器向服務器發(fā)送出請求后，服務器才會發(fā)送出數(shù)據(jù)。而瀏覽器其實并不知道服務器的信息什么時候會有改變，為了模擬實時的交流，或者不想錯過某些信息，只能通過輪詢(Polling)技術不斷刷新頁面來獲得最新的數(shù)據(jù)(見圖3．3)。這種方式不但浪費服務器的資源，最重要的是每次建立或關閉新的Hr】『P連接都有一定的延遲，這種延遲使得頻繁信息傳遞的應用無法忍受。于是就產(chǎn)生了“服務器推送技術刀。

服務器推送技術的基礎思想是將瀏覽器主動查詢信息改為服務器主動發(fā)送信息。服務器發(fā)送一批數(shù)據(jù)，瀏覽器顯示這些數(shù)據(jù)，同時保證與服務器的連接。當服務器需要再次發(fā)送一批數(shù)據(jù)時，瀏覽器顯示數(shù)據(jù)并保持連接。以后，服務器仍然可以發(fā)送批量數(shù)據(jù)，瀏覽器繼續(xù)顯示數(shù)據(jù)，依次類推。這種技術可以被應用在股票實時情報，系統(tǒng)狀態(tài)報告，天氣情況等監(jiān)測系統(tǒng)中。使用服務器推送技術后的系統(tǒng)模型如下圖所示：

3．1．2服務器推送技術的實現(xiàn)方案

服務器推送技術在很久以前就出現(xiàn)過，例如Netscape曾經(jīng)推出適用于Push技術的專用瀏覽器和經(jīng)過修改的HTML語言。但是這僅僅在特定的瀏覽器中才能使用，其他流行的瀏覽器(Ⅲ等)就不兼容這種技術。以前實現(xiàn)服務器推送的方案主要是在瀏覽器端安裝插件，基于套接口傳送信息，自定義TCP／IP信息的 Applet來實現(xiàn)，或是使用RMI、CORBA進行服務器端的遠程調(diào)用。這些技術往往由于復雜而產(chǎn)生諸多不利之處：技術難以實現(xiàn)、存在防火墻限制(因為需要打開非HTTP的通訊端口)、需要額外的Server開發(fā)和維護。并且除了刷新整個頁面或者完全采用Applet展示內(nèi)容之外，很難找到別的方法將客戶端Applet的狀態(tài)和瀏覽器的頁面內(nèi)容集成在一起。

現(xiàn) 在的服務器推送技術是基于HTTP長連接而實現(xiàn)的。它保持原有的H兀P協(xié)議不變，在服務器端改變處理方式，使得服務器能夠使用瀏覽器已經(jīng)打開的冊連接，主動向瀏覽器發(fā)送消息。這里關鍵的技術是要保持原有的HITP連接不斷，一旦擁有持久的連接，服務器就可以根據(jù)自己的數(shù)據(jù)更新，隨時地向客

戶端發(fā)送最新的信息。

Alex Russell(Dojo Toolkit的項目領導人)稱這種基于哪長連接、無須在瀏覽器端安裝插件的服務器推送技術為Comet。目前已經(jīng)出現(xiàn)了一些成熟的Comet應用以及各種開源框架。一些Web服務器如Jetty也在為支持大量并發(fā)的長連接進行了很多改進。根據(jù)客戶端處理長連接技術的不同，常用的有兩種Comet應用的實現(xiàn)模型。

3．1．2．1基于AJAX的長輪詢(10ng-polling)方式

如圖3．4所示，AJAX的出現(xiàn)使得JavaScfipt可以調(diào)用XMLHttpRequest對象發(fā)出的肌’P請求，JavaScript響應處理函數(shù)根據(jù)服務器返回的信息對HTML頁面的顯示進行更新。使用AJAX實現(xiàn)服務器推送與傳統(tǒng)的AJAX應用不同之處在于：

1．服務器端會阻塞請求直到有數(shù)據(jù)傳遞或超時才返回。

2．客戶端JavaScript響應處理函數(shù)會在處理完服務器返回的信息后，再次發(fā)出請求，重新建立連接。

3．當客戶端處理接收的數(shù)據(jù)、重新建立連接時，服務器端可能有新的數(shù)據(jù)到達；這些信息會被服務器端保存直到客戶端重新建立連接，客戶端會一次把當前服務器端所有的信息取回?；陂L輪詢的服務器推模型一些應用及示例如“Meebo”，“Pushlet Chat”都采用了這種長輪詢的方式。相對于上面提到的“輪詢”(polling)，這種長輪詢方式也可以稱為“拉”(pull)。因為這種方案基于 AJAX，具有以下一些優(yōu)點：請求異步發(fā)出；無須安裝插件；IE、FireFox都支持AJAX。

在這種長輪詢方式下，客戶端是在XMLHttpRequest的readystate為4(即數(shù)據(jù)傳輸結(jié)束)時調(diào)用回調(diào)函數(shù)，進行信息處理。當 readystate為4時，數(shù)據(jù)傳輸結(jié)束，連接已經(jīng)關閉。Firefox提供了對StreamingAJAX的支持，即readystate為3時(數(shù) 據(jù)仍在傳輸中)，客戶端可以讀取數(shù)據(jù)，從而無須關閉連接，就能讀取處理服務器端返回的信息。m在readystate為3時，不能讀取服務器返回的數(shù)據(jù)，

目前Ⅲ不支持基于Streaming AJAX。

3．1．2．2基于iframe及htmlfile的流(streaming)方式

iframe 是很早就存在的一種HTML標記，通過在HTML頁面里嵌入一個隱葳幀，然后將這個隱葳幀的SRC屬性設為對一個長連接的請求，服務器端就能源源不斷地往客戶端輸入數(shù)據(jù)。上面提到的 AJAX方案是在JavaScript里處理XMLHttpRequest從服務器取回的數(shù)據(jù)，然后Javascript可以很方便的去控制HTML頁面的顯示。同樣的思路用在iframe方案的客戶端，iframe服務器端并不返回直接顯示在頁面的數(shù)據(jù)，而是返回對客戶端Javascript函數(shù)的調(diào) 用，如：<script type=”text／javascript”>js_func(”data from server”)<／script>。服務器端將返回的數(shù)據(jù)作為客戶端JavaScript函數(shù)的參數(shù)傳遞；客戶端瀏覽器的 Javascript引擎在收到服務器返回的JavaScript調(diào)用時就會去執(zhí)行代碼。簡而言之，其基本原理就是從Servlet把 JavaScript代碼作為H兀P流推送到瀏覽器。這些代碼被瀏覽器的JavaScript引擎解釋并完成相應的工作，于是便完成了從服務器端的 Java到瀏覽器中的JavaScript的回調(diào)。

從圖3．5可以看到，每次數(shù)據(jù)傳送不會關閉連接，連接只會在通信出現(xiàn)錯誤時，或是連接重建時關閉(一些防火墻常被設置為丟棄過長的連接，服務器端可以設置一個超時時間，超時后通知客戶端重新建立連接，并關閉原來的連接)。

使用iframe請求一個長連接會有一個不足之處：IE、Morzilla Firefox下端的進度欄都會顯示加載沒有完成，而且Ⅲ上方的圖標會不停的轉(zhuǎn)動，表示加載正在進行。一個被稱為“htmlfile”的ActiveX解決了在正中的加載顯示問題，gmail+gtalk產(chǎn)品中使用了這個解決方案。

3．2開源的服務器推送一Pushlets ·

3．2．1 Pushlets概述

Pushlets 是一個開源的Comet框架，在Servlet機制下，數(shù)據(jù)從服務器端的Java對象直接推送(push)到動態(tài)HTML頁面，而無需任何 JavaApplet或者插件的幫助。它使服務器端可以主動地更新客戶端的web頁面。瀏覽器為兼容JavaScriptl．4版本以上的瀏覽器(如 Intemet Explorer、FireFox)，并使用JavaScript／DynamicHTML特性【5】。Pushlets支持上一小節(jié)提到的兩種服務器推送的實現(xiàn)方式，既提供了基于AJAX的JavaScript庫文件用于實現(xiàn)長輪詢方式的服務器推送，也提供了基于iframe的JavaScript庫文件用于實現(xiàn)流方式的服務器推。原則上，Pushlets框架能夠運行在任何支持Servlet的服務器上、防火墻的后面?！甈ushlets通過標準 Java特性中Object的wait()和notify()實現(xiàn)了觀察者模型：客戶端發(fā)送請求，訂閱感興趣的事件；服務器端為每個客戶端分配一個會話 ID作為標記，事件源會把新產(chǎn)生的事件以多播的方式發(fā)送到訂閱者的事件隊列里。瀏覽器只需要發(fā)送兩個請求，一個是連接請求事件，一個是對后臺事件進行監(jiān)聽訂閱的請求，如果后臺對應的數(shù)據(jù)發(fā)生了變化，則這個變化會反應到訂閱者的事件隊列中，這種機制是輕量級的。

3．2．2 Pushlets架構(gòu)

Pushlets 框架允許客戶端訂閱在服務器端的主題(subject)，而服務器則接收訂閱，然后在服務器端的訂閱主題所對應的數(shù)據(jù)變化時推送數(shù)據(jù)到客戶端。此框架的基本設計模式是發(fā)布／訂閱(Publish／Subscribe)，也被稱為觀察者模式(Observer)。它由Server和Client兩部分組建而成。

3．2．2．1 Server端架構(gòu)

Server 端由圍繞著Pushlet類的Java類集合構(gòu)成。下面的UML圖表示了幾個最重要的類之間的關系，包括Publisher、Subscriber和 Event?？蛻舳送ㄟ^HTTP請求連接到Pushlet servlet，訂閱并接收消息。請求中包含了要求訂閱的主題和接收消息的方式(JavaScript調(diào)用、XML或者Java序列化對象，默認為 JavaScript調(diào)用)。Publisher對象中記錄了它的所有Subscriber，可以將Event發(fā)送到相應的Subsciber中。

對照圖3．6，簡要說明一下幾個關鍵的類：Pushlet是一個Servlet，接收來自客戶端的請求，并創(chuàng)建一個訂閱者(Pushlet Subscriber)，然后調(diào)用初始化方法訂閱一個主題，最后由該訂閱者保持客戶請求，返回內(nèi)容。

PushletSubscriber 是與每個客戶端對應的訂閱者，首先根據(jù)客戶端的請求建立客戶端適配器ClientAdapter，并將自己注冊到一個特定的Pub lisher那里，然后保持這個http連接，并將其自身阻塞于一個事件隊列之上，事件則對應于一個主題：如果有事件入隊列，則被喚醒，并調(diào)用 ClientAdapter向客戶端推送數(shù)據(jù)：

C1ientAdapter：屏蔽了不同的客戶端協(xié)議的差異，將從PushletSubscriber獲取到的事件轉(zhuǎn)換為JavaScript格式并將它推送到客戶端瀏覽器：

Publisher：采用單實例模式，提供靜態(tài)接口供其他類訂閱／發(fā)布消息，它維護著一組訂閱者的列表：事件到來時，通過比較訂閱者的主題和事件的主題，可將事件放入相應的事件隊列，喚醒所有在此事件隊列上等待的客戶端訂閱者(PushletSubscriber)：

Postlet：類似于Pushlet，其所處位置和Pushlet相同，用于客戶端主動服務器端發(fā)送消息。

Eventer source：事件源，通過監(jiān)聽外部事件而產(chǎn)生Pushlet事件，并調(diào)用Publisher發(fā)布事件。

3．2．2．2 Client端架構(gòu)

Client 端由腳本與頁面組成。如果選擇使用基于iframe的服務器推送方式，有可重用的JavaScript庫(pushlet．js)和用來在DHTML client(這里指瀏覽器)中接收事件的HTML(pushlet．html)。pushlet．html實現(xiàn)了一個隱藏的iframe來接收來自 server的消息，它的父頁面要實現(xiàn)一個名為push()的方法做為來自服務器端的JavaScript回調(diào)。在pushlet．js中實現(xiàn)了這個方法，可以為所有的瀏覽器客戶端所重用。如果選擇使用基于AJAX長輪詢的方式，則有可重用的JavaScript庫(ajax—pushlet．is)。不管使用哪種方式，只需在客戶端實現(xiàn)一個onData()的JavaScript函數(shù)就能實現(xiàn)個性化的操作，處理服務器推送過來的數(shù)據(jù)。

Client端Java類：JavaPushletClient和JavaPushletClientListener，負責在Java client中接收事件。

．2．3 Pushlets優(yōu)點

與基于CORBA／RMI的Java applet解決方案相比，Pushlets具有以下一些優(yōu)點。

1．直接與瀏覽器中的DHTML集成：服務器產(chǎn)生的數(shù)據(jù)可以立即發(fā)送到瀏覽器的頁面內(nèi)容中。HTML的所有布局均可應用。

2．標準的HTTP端口和協(xié)議：消息和蹦I／CORBA使用非標準端口(相對HTTP標準端口而言)，遇到“防火墻”、“禁止回調(diào)’’、“禁止接收UDP數(shù)據(jù)”的瀏覽器安全限制時可能無法工作。

3．客戶端負載：基于CoRBA／蹦I的Java applet使客戶端在啟動時更加沉重，并消耗更多的資源。

4．無需額外的server：消息和跚I／CORBA需要單獨的server產(chǎn)品。Pushlets理論上可以在任何server引擎上運行，并具備連接管理和多線程能力。

3．3 F Monitor項目中的服務器推送

下面將以F Monitor系統(tǒng)為例，具體說明如何在一個Web系統(tǒng)中實現(xiàn)服務器推送。

3．3．1 F Monitor中服務器推送的設計

服務器推送主要由三個部分組成：消息、消息的發(fā)送方、消息的接受方。

F Monitor系統(tǒng)中的服務器推送依賴于開源項目Pushlets來實現(xiàn)。在Pushlets的框架中，服務器推送的消息是一個名為Event的Java 類對象，該對象包含了一個Map來包含消息中的具體內(nèi)容，以及一個String類型的Topic來表示消息的主題，只有訂閱了該主題的消息接受者才會收到該消息，類似于JMS的Topic。在F Monitor中，不同的事件通過不同的主題發(fā)送給客戶端，事件的Topic命名采用層次化的樹命名結(jié)構(gòu)。比如： “／Monitor／ssb／finishEvent”這個topic就表示名為ssb這個賣方機構(gòu)下的finishEvent類型的事件，只要訂閱了 “／Monitor／ssb”這個topic，客戶端就可以收到其下屬的所有類型的事件消息，如果訂閱了“／”則表示訂閱所有Topic的消息。

其次需要設計消息的發(fā)送者，Pushlets支持三種不同類型的消息發(fā)送方式：直接發(fā)送消息、使用事件源發(fā)送消息、使用Pushlets的協(xié)議發(fā)送消息。直接發(fā)送方式只要調(diào)用Dispatcher．getInstance 0．multicast 0，Dispatcher．getlnstance()．unicast()或 Dispatcher．getInstance()．broadcast()等方法就可以將構(gòu)建好的消息以廣播、多播或者單播的方式發(fā)送出去。使用事件源發(fā)送消息的方法，則需要實現(xiàn)一個繼承于EventSource的Java類，通過在配置文件中聲明的方式由Pushlets框架來統(tǒng)一管理事件源，這種發(fā) 送方式比較適用于需要定時發(fā)送事件的發(fā)送源。使用Pushlets協(xié)議發(fā)送消息則提供了一種可以在Pushlets線程之外使用Pushlets協(xié)議發(fā)送消息的方式，系統(tǒng)可以在任何Java應用中實現(xiàn)服務器推送。在F Monitor系統(tǒng)中，直接發(fā)送是比較合適的方式，因為我們的事件來源于所監(jiān)測的系統(tǒng)F，F Monitor隨時可能需要推送事件給瀏覽器，因此事件的發(fā)送是隨時的，而不是定時的，因此直接發(fā)送的方式比使用事件源定時發(fā)送的方式更適合于F Monitor的系統(tǒng)。

有了消息的發(fā)送者，接下來需要設計消息的接收者。接收者需要申明其接受消息的格式(JavaScript、XML、Java序列化對象三種格式)和其訂閱的消息Topic。在我們的F Monitor系統(tǒng)中，將使用基于AJAX的瀏覽器客戶端作為接受者。Pushlets提供了一些可重用的JavaScript文件支持DHTML和 AJAX的客戶端(主要是ajax—pushlet．js，pushlet．js和pushlet．html)。ajax—pushlet．js提供了瀏覽器端的JavaScript庫實現(xiàn)基于AJAX的服務器推送。只需將這些文件集成到我們的系統(tǒng)中，就能很方便的實現(xiàn)服務器推送的接收方。

3．3．2 F Monitor中服務器推送的具體實現(xiàn)

3．3．2．1系統(tǒng)消息的實現(xiàn)

在 F Monitor中，服務器推送的事件都是Event對象，不同的事件具有不同的Topic和Map屬性。需要說明的是Topic的結(jié)構(gòu)設計，如上-d,節(jié) 所說，Topic是個樹狀的結(jié)構(gòu)，F Monitor中將Topic的結(jié)構(gòu)劃分為機構(gòu)名稱、消息類型、貨幣對三個層次，具體結(jié)構(gòu)如圖3．7所示。一個典型的Topic是這樣：／Monitor／SSB／FinishEvent／USD／ARS。

3．3．2．2消息發(fā)送方(服務器端)的實現(xiàn)

將pushlet．jar文件置于F Monitor項目的web文件夾下，同時在web．xml文件中聲明pushlet的servlet。

消息的發(fā)送方，在服務器端，實現(xiàn)以下代碼，只需在需要推送消息的時候調(diào)用該代碼，就能將消息發(fā)送到指定的Topic上。

3．3．2．3消息接收方(瀏覽器端)的實現(xiàn)

在html文件中引入pushlets提供的客戶端支持文件：ajax-pushier．js。

3．4本章小結(jié)

在本章中，介紹了服務器推送技術的概念和原理，及其兩種比較常見的實現(xiàn)方案。并且從實際應用角度出發(fā)，研究它適合何種項目，以及會帶來的好處。另外，還介紹了一個開源的服務器推送框架Pushlets，包括它的架構(gòu)和特點，因為在F Montior中將使用這個開源項目。最后，詳細介紹了F Monitor項目中如何

使用Pushlets實現(xiàn)服務器推送，包括其設計與具體實現(xiàn)。通過本章的介紹，我們對服務器推送的技術以及其在實際項目中的應用有了比較清晰的認識。