Web聚合運用跨域通信機制

導語：Web聚合運用跨域通信機制一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

1引言

在傳統的web1.0應用程序中，每個Web站點相互隔離，用戶訪問Web站點僅能得到來自本站點的信息。即使需要訪問其他站點，也是通過編輯拷貝已存儲在本地的信息或者用戶調換網站地址的方式來訪問內容，而不是直接訪問信息源數據。在新的Web2.0潮流之下，希望網站之間打破隔離進行數據融合，使之能夠共享信息。在這種背景下，聚合型網站設計方式應運而生，這就是新型的Web應用程序——聚合應用(mashupapplication)。Mashup這個名詞來源于流行音樂，將不同風格的音樂拼接，混雜在一起，構成自己獨特的新曲子；Mashup在Web環境中代表著整合不同來源的內容以提供交互式體驗的Web站點或應用程序[1]。利用其他網站開放應用接口所提供的內容進行混搭，從而創造出獨特的、具有新價值的Web應用。Mashup把不同源或站點的信息進行融合以保證信息共享，打破站點之間“孤島林立”的現狀，由此瀏覽Web站點更加直觀便捷，用戶體驗更加富。典型的Mashup應用當屬Housingmap，它將第三方網站Craigslist的租房信息和GoogleMaps提供的地圖信息有機地組織起來，讓租房的信息直觀顯示在地圖上，創造出一個嶄新的、互動性強的房屋搜尋站點[2]。根據以上實例背景，本文建立一個Housingmap聚合應用模型，由電子地圖與租房信息2部分組成，如圖1所示。傳統的Web瀏覽器安全機制遵守同源策略(SOP,same-originpolicy)。同源策略規定JavaScript(JS)代碼只能訪問其來自同源服務器上的數據，把來自不同源的內容相互分離。這種策略給JS提供安全保障的同時限制了基于JS的跨域訪問。Mashup是對多個站點資源的優化組合，需要從多個分散的站點獲取信息源，而不要求各個站點之間相互信任。傳統同源策略過渡的安全設計沒有考慮多個站點之間交互時整體的快速通信需求，也沒考慮新的信任模型下的安全問題。如圖1所示，電子地圖與租房信息的數據分別來自www.map-和www.housing-2個不同源的網站，在現有的同源策略下是不能夠相互訪問和通信。怎樣整合相互獨立的第三方數據、實現不同源數據之間的通信是聚合應用需要解決的問題。另外，惡意攻擊者可能重寫來自其他源的網頁屬性，例如來自www.map-的腳本可能重寫www.housing-網頁的location屬性，操縱原頁面跳轉到某個惡意的頁面，而導致框架釣魚攻擊。如何保證不同源數據間通信的安全性與完整性是聚合應用需要解決的另外一個問題。針對上述問題，研究人員在聚合應用跨域交互方面做了大量研究，其中，文獻[3]利用內嵌框架(iframe)實現客戶端通信。這種方法的缺點是不但很難保證消息的完整性，而且攻擊者很容易進行框架釣魚攻擊。文獻[4]提出了一種跨域通信方案，兼容主流瀏覽器。聚合應用能與一個或多個網絡服務應用交互，交互過程包括2個階段：設置階段(建立中間幀，非信任幀，傳輸JS通信對象)與數據交換階段。文獻[5]提出了一種基于值的跨域通信機制，對象序列化后進行傳輸。其中，分批處理數據減少了整合者與小部件之間信息交換次數，由此提升了系統性能。美中不足的是，如何解決跨域通信帶來的安全問題以及如何共享JS對象還有待進一步研究。本文在研究相關工作的基礎上提出了一種適合于聚合應用的安全跨域通信(SCDC，securecross-domaincommunication)系統。首先，從各個不同的域入手，同一信任域的內容封裝為組件表示，建立聚合應用的安全組件；其次，利用分層通信棧實現域間通信，即聚合應用與組件間通信；最后，利用封裝技術安全實現組件間細粒度對象共享。該方案具有安全可靠性強、效率高、支持對象共享的特點，旨在為聚合應用提供一種安全可靠的跨域通信系統。

2相關跨域通信方案

跨域，簡單的理解就是在JS同源策略的限制，域名下的JS無法操作或是域名下的對象?？缬蛲ㄐ琶媾R著許多挑戰，下面分別介紹3種傳統處理跨域的方案：服務器端、動態創建腳本、段標識通信。跨域請求發送至本地服務器端，然后由服務器端請求相應的數據發送到瀏覽器端。在服務器端的幫助下，瀏覽器端所有請求發送至同一域，實現了跨域通信。此方案適用于幾乎所有的跨域訪問，支持各種類型格式的數據，但是經過了中間，延遲高、開發工作量大，并且加重了本域服務器的負荷。至于動態創建腳本方案，雖然瀏覽器禁止跨域訪問，但仍可以引用其他域的JS文件，由此能夠通過創建script節點完全實現跨域通信。該方案實現非常簡單，但返回的數據格式只能是JSON數據，對于其他格式的數據無能為力。最常見的跨域通信解決方案是利用URL段標識符(fragmentidentifier)[6]交換信息，傳輸的數據一旦超過瀏覽器對URL長度的限制則必須對數據進行分段傳輸。這種方法的優勢在于同一頁面瀏覽不同分段時不必刷新整個頁面。不足之處在于不同瀏覽器URL長度限制有所不同，數據容量都是有限的。數據直接暴露在URL中，一些瀏覽器會刪除段標識符，不能保證應用程序的一致性與可靠性。面對復雜的聚合應用環境，以上這些方案或多或少存在下列問題：首先是開銷問題，服務器方案經過了中間，開發工作量大，因此并不適合于大規模的Mashup應用；其次是靈敏度問題，段標識通信機制中數據容量都是有限的，消息一旦超過當前瀏覽器最大傳輸限制則必須分段進行傳輸。在動態的Mashup網絡環境下，通過輪詢URL探測分段是否變化，響應時間往往不確定，會有一定的延遲；最后一個問題是安全性，無論是動態創建腳本還是段標識通信，消息內容或者不安全或者不是預期的。Mashup應用的通信環境往往是不完全受信任的環境，如不采取特別的安全防范措施容易導致惡意攻擊或私有信息泄漏。隨著瀏覽器跨域通信的需求越來越強烈，HTML標準的下一個版本HTML5新增了跨域通信功能，即提出了跨文檔通信(crossdocumentcom-munication)機制。在希望發送消息的窗口或內嵌框架中調用postMessage方法，接收方設置一個事件處理函數來接收發送過來的消息[7]。為了解決上述問題，本文先將不同源網站視為獨立的信任域，并封裝為可相互直接交互的內部組件，利用HTML5新增的跨文檔通信機制，實現組件間的通信。這種方案主要有如下優勢：①安全系數高，該方案適用于不完全受信任的環境，開發人員可以選擇性接收來自域的消息，如果消息的內容不安全或者不是預期的，則可以放棄相應的消息；②可靠性強，與其他跨域通信方案不同，此方案以一致的方式處理未丟棄的消息；③性能提升，此方案允許雙向通信，具有安全、簡單、快速的特點，不依賴于幀或其他頁面，也不需要輪詢URL查找數據。

3SCDC系統設計與實現

3.1系統概況

本文系統為聚合應用及其各個組件(component)實現了SCDM系統的JS庫，解決了跨域通信與域間對象共享的難題。SCDM系統把不同信任域的內容封裝到不同組件，且每個組件有其輸入輸出端口，為組件通信提供了接口；事件中心維護系統通信，通過建立分層通信棧來實現組件間的通信，跨域通信依賴于跨文檔通信機制；對象共享是聚合應用域間通信的高級應用。系統支持多個較新版本的瀏覽器，InternetExplorer8.0+(IE8.0及以上版本)，Firefox3.1+，Safari4.0+，Opera9.5+，GoogleChrome1.0+。對于不同的瀏覽器，實現代碼大體上類似。圖2以2個組件之間的通信為例說明系統的整體框架，多個組件之間通信時架構與此類似。SCDC系統包含3個主要模塊：域封裝模塊、域間通信模塊、細粒度對象共享模塊。域封裝模塊是系統的入口和核心。聚合應用由不同源(域)的內容組成。鑒于安全性考慮，不同信任域的內容封裝到不同組件中以起到域間隔離的作用，并且組件的輸入輸出端口為域間通信模塊提供接口。域間通信模塊為組件模塊和對象共享模塊提供服務。判別通信雙方是否處于同一個域，完成域間通信識別的任務，并且為不同域之間通信搭起橋梁，完成系統跨域通信的任務。細粒度對象共享模塊是系統的高級應用模塊。目前組件間并不能直接跨域共享對象，但是借助基于值傳輸的跨文檔通信機制能在對象序列化為字符串后能進行對象的共享。為了更好地安全地實現信息共享，本模塊根據域封裝模塊所提供的組件，及域間通信模塊提供的服務獲取通信狀態，實現組件間細粒度的對象共享。細粒度對象共享的過程是先建立封裝對象，并且由策略系統明確定義策略以控制對象共享，然后對象序列化后通過域間通信模塊進行傳輸。

3.2域封裝模塊

信任域(trustdomain)[8]可認為是處于聚合應用完全控制下的安全域(域指的是DNS域或IP地址)。信任域與DNS域有著密切聯系，前者在后者的基礎上加入了安全防范措施。組件可以定義為同一信任域內容的封裝。組件源由第三方提供，每個組件邏輯上相互獨立。組件擁有獨特的輸入端口和輸出端口，為后面的異步傳輸消息墊定基礎。為了安全性考慮，系統需要隔離各個組件以防止惡意攻擊。解決方法是將不同的組件置入不同的內嵌框架iframe中以達到隔離目的，任意組件不能改變domain屬性以攻擊其他組件。對于上例，Housingmap聚合應用模型組合了來自www.map-的電子地圖與www.housing-的租房信息，分別把這2個來自不同信任域的內容封裝為電子地圖組件與租房信息組件。然后，電子地圖組件與租房信息組件分別置入各自的iframe起到域間隔離的作用。對于來自同一服務器的數據，但屬于不同信任域，也可以建立多重DNS域從而保證組件間隔離。例如，對于來自服務器www.map-與信任域為t1、t2的數據，能夠建立2個DNS域t1.map-和t2.map-，分別封裝到不同的組件，為下文的域間通信打下基礎。

3.3域間通信模塊

域間通信模塊負責各個信任域之間的通信。該模塊借鑒與結合了瀏覽器安全模型的實現方法，在組件端口與事件通道之間通過發送/接收消息方式實現聚合應用與組件間的內容交互。事件中心(eventhub)由仲裁域間通信的事件通道(channel)組成，是維護系統通信的核心部件。事件中心實際上是在多對多通道上發送與接收消息的pub/sub系統，但又不同于傳統的pub/sub系統。事件中心管理連接組件端口與事件通道之間的通信，組件端口與事件通道的命名空間相互隔離，由此避免了組件端口的沖突，提高了組件的重用性。組件有其輸入端口(讀端口)與輸出端口(寫端口)，從組件的輸出端口發送消息到與之相連的事件通道上；組件的輸入端口從與之相連的事件通道接收消息，由此構成了組件與聚合應用，以及組件與組件之間的通信。如圖3所示，組件1發送消息到事件通道1、3，組件1從事件通道3接收到消息。在一般情況下，組件可發送消息到多個事件通道，同時也可從多個事件通道接收消息。如何保證組件之間通信順暢，文獻[8]中采用的方法是借助于URL段標識符實現域間通信。消息一旦超過當前瀏覽器最大傳輸限制則必須分段進行傳輸，直到上一分段讀取完畢后才能讀取下一個分段。圖3簡化通信本文的解決思路是通過跨文檔通信機制實現聚合應用與組件的域間通信。對于聚合應用，組件在域封裝模塊已置入iframe幀中，以組件幀表示。而且每個組件均包括隱藏的通道幀，通道幀與聚合應用主頁面()屬于同一個域，因此通道幀與聚合應用主頁面實現域內同步通信。而通道幀與組件幀通過跨文檔通信機制實現域間通信。具體實現架構利用JS庫底層實現聚合應用與組件的域間通信，實現架構類似分層通信棧，由事件中心層、事件通信層及跨文檔通信層3部分組成，在組件及聚合應用中的同等層使用較低層進行通信。如圖4所示，事件中心層管理組件端口與事件通道，對于聚合應用，事件中心層的主要任務是裝載組件與卸載組件，建立事件通道與刪除事件通道，連接組件端口與事件通道等；對于組件，這一層負責處理該組件各端口發送與接收的事件。事件通信層負責多路傳送多個組件端口的消息?？缥臋n通信層是為聚合應用與組件實現跨域通信，也就是通道幀與組件幀的通信過程。下面列出實現域間通信的常用API，如表1所示，重點描述下組件狀態的生命周期，參照getComponentState函數。從loaded到wired狀態轉換由聚合應用控制，意味著組件能夠開始發送消息；從wired到startedCleanup狀態也是由聚合應用所控制，意味著開始卸載組件；而從startedCleanup到doneCleanup狀態則是由于超時或組件處理不當引發的，這個過程由組件所控制；剩下的狀態轉換則是由系統自身初始化的。為了避免輪詢組件狀態，在組件及聚合應用狀態轉換時注冊監聽函數。組件與聚合應用都通過發送與接收消息方式進行通信。用一個簡單的例子描述利用分層通信棧的通信過程。首先，聚合應用主頁面中裝載2個組件，初始化通信，發送消息message給組件，主要調用如下API：

3.4細粒度對象共享模塊

Web主體間共享資源通常有2種處理方案：共享所有資源，或者相互隔離，實現零共享[9]。通常各個主體共享所有資源容易導致跨站腳本攻擊(XSS)，由此研究人員提出了多種方法來隔離各個主體。進一步，如何在各個隔離的主體間共享部分對象，針對這個問題，提出了細粒度共享對象策略。首先，利用SCDC系統的JS庫中對象封裝策略，建立與原對象一致的、可控制的封裝對象view[10]。一致性表示封裝對象view可以取代原對象進行訪問；可控制性意味著可以定義策略限制接收方訪問共享對象的某些屬性或方法。其次，建立細粒度策略(基于通知的策略)約束訪問共享對象。細粒度策略由方面系統(aspectsystem)實現，能控制對象的行為。如圖5所示，為對象map建立封裝對象map_control.view來取代原對象的訪問，并通過為原對象的屬性與方法引入getters、setters、caller訪問器利用map_control.definePolicy設置策略以控制訪問封裝對象view。view可以看作是與策略的組合體，相當于一個封裝器，策略即為一個函數。為每個不同的對象建立一個新的封裝對象。同樣地，對于一個函數對象，相應地定義一個新的封裝函數以取代對原函數的訪問，并為其定義策略函數。如圖5所示，電子地圖組件與租房信息組件共享某一對象，如地圖類型(包括普通地圖、衛星地圖、地形地圖等類型)。首先，電子地圖組件建立其封裝對象view(map_control.view)以代替原對象。然后通過定義策略控制對封裝對象的訪問，如定義策略即編碼白名單，租房信息組件只能讀其屬性Type，調用方法getType，但不能重定義方法或屬性，也不能操作電子地圖組件的其他對象。建立封裝對象view后，怎樣實現組件間view對象的共享。針對這一問題，瀏覽器并未為跨域傳送消息設定特定的事件通道，但能夠借助于跨文檔通信機制與分層通信棧結構，對象能夠序列化后實現共享傳輸。如圖6所示，組件1與組件2共享封裝對象時，利用SCDC的JS庫發送方序列化對象后通過分層通信棧發送給對方；接收方收到消息后把字符串反序列化為對象。由此，當租房信息組件要請求map_control.view的屬性Type時，首先發送請求給電子地圖組件，依據view策略得到結果，然后返回給租房信息組件。圖6封裝對象view共享過程示例細粒度對象共享一定程度上解決了對象傳輸的安全性，同時也引入了一些新的問題，如異步問題。1)封送處理庫負責序列化與反序列化對象，并對基本的JS操作如調用函數、讀寫屬性、拋出異常等進行譯碼。如果組件1遠程共享一個表格對象table給組件2，組件2請求封送處理庫獲取table.parentNode.parentNode.parentNode.cookie的值，這將泄露了文檔的cookie值；如果組件1遠程共享其封裝對象table_control.view，view能執行策略代碼僅能訪問table對象的白名單屬性或方法。封裝對象機制限制訪問對象，解決了遠程對象共享帶來的部分安全問題。2)瀏覽器的同源策略規定每個框架有獨自的類型鏈與全局對象集合，一定程度上確保了框架間的隔離。由于聚合應用需要跨域訪問對象，同源策略受到限制。SCDC系統的細粒度對象共享模塊在訪問對象之前進行檢查，以確認是發送方對象的封裝對象view或接收方對象的。如果get、set、call等觸發某個對象既不是veiw也不是，則拒絕此對象，進一步保證對象傳輸的安全性。3)由于跨文檔通信機制本身的異步性，通過分層通信棧實現的遠程對象共享引入了異步問題。如圖7所示，圖7(a)中轉化為遠程對象的封裝對象view，調用2個“.”則是異步調用。這就需要轉化代碼結構，調用者必須提供一個回調函數以保持傳輸的完整性與連續性，這就是連續傳遞模式(CPS，continuationpassingstyle)。如圖7(c)所示，客戶端自動全局轉化為CPS形式進行交互，在調用y()與z()時，為了保持連續性注冊回調函數以控制當前線程。

4安全策略

4.1SCDC系統整體安全策略

上文已經提到組件隔離及組件間通信，至于哪些組件之間可以交互，哪些組件之間禁止交互，則由SCDC系統的安全策略所定義。具體的策略來自多種高級策略，例如企業級聚合應用，安全策略則可能是企業級策略、部門策略、終端用戶策略的組合。一方面，組件提供方明確它們的組件怎樣整合到聚合應用中；另一方面，聚合應用提供方可能不同等看待各個組件，可能會阻止部分組件相互交互?？傊?，安全策略依賴于具體的實體應用程序，包括組件間訪問控制策略與組件到服務器端的訪問控制策略。組件間訪問控制策略包括建立與刪除組件、建立與刪除事件通道、哪個組件能在某個事件通道上發送或接收事件等。事件中心負責執行策略，一種方式可以在聚合應用的代碼中明確定義策略；另一種方式為事件中心定義一個配置策略文件，可以從中讀取安全策略，這樣分離了策略定義與聚合應用中真正的代碼實現。組件到服務器端的訪問控制策略包括認證組件與受限訪問權限。在組件裝載之前，必須先核實認證，并且根據組件所在域確保組件裝載到合適的iframe幀中，使其不易受到人為攻擊。這種方式不管是客戶端聚合應用還是服務器端聚合應用都有統一的訪問控制策略。上述定義了SCDC系統的整體安全策略，但是跨域通信容易導致框架釣魚攻擊，共享信息容易泄露個人隱私信息，針對這2個問題本文特別加入了針對性的安全策略。

4.2防范框架釣魚攻擊

框架釣魚攻擊，對于利用iframe來隔離不同信任內容的網站來說是很常見的漏洞，也是比較嚴重的攻擊類型[11]。它一定程度上破壞了應用程序的完整性，但并不意味著應用程序被惡意組件所控制。框架釣魚攻擊還能竊取輸入的信息，包括個人認證信息或密碼等。在聚合應用中，這種攻擊不僅能改變組件幀的location屬性，也能作用于事件通道幀與聚合應用主頁面之上。對于聚合應用，組件、事件通道、聚合應用主頁面三者易發生框架釣魚攻擊。由于URL欄僅能提供微弱的釣魚保護能力，而且不像傳統的釣魚攻擊，聚合應用中框架釣魚攻擊的時機是任意的。本文在各個頁面中利用onunload事件處理器，超時設置及通道幀三者相結合共同防范框架釣魚攻擊。首先，當組件受到攻擊時觸發onunload事件并發送通知消息給聚合應用，然而組件與聚合應用通過事件通道進行異步通信，不能保證在組件卸載完之前通知消息傳送完畢。換個角度考慮，替換某個組件時將會觸發通道幀的onunload事件，通過調用JS函數通道幀與聚合應用實現同步通信，因此在onunload事件完成之前必能成功通知聚合應用。根據上述分析得知，可以用統一的方法來處理針對組件與事件通道的攻擊。其次，另一種可能的情況是在通道幀裝載完畢之前取代組件，這時在聚合應用中設置一個超時處理成功初始化事件通道通信。一旦超時，觸發錯誤處理程序以決定是卸載或重載組件。利用事件通道的onunload事件處理程序面臨一個挑戰，當用戶操作離開聚合應用頁面時，該事件也被觸發。為了避免錯誤判斷，可以延遲計時器的警告時間，如果用戶仍停留在聚合應用中，超時則通知聚合應用存在潛在的框架釣魚攻擊。最后，檢測聚合應用主頁面的框架釣魚攻擊。有時很難區分是框架釣魚攻擊還是用戶任意操作離開這個網頁。針對這個問題，設計一個警告框來通知用戶URL的變化，沒有瀏覽器的支持很難區分上述2種情形。雖然這種方法對系統性能有一定的影響，但是這是唯一一種確保用戶安全性的方法。

4.3對象共享安全性

隨著計算系統的不斷發展，資源共享變得越來越重要，而由此導致的安全問題也變得不容忽視。SCDC系統的對象共享模塊容易泄露私有信息，所以做好安全防范工作顯得尤為重要[12]。為了保證私有信息不被泄露，遞歸封裝對象是理想的選擇。遞歸封裝即為某個對象的所有屬性（包括繼承的屬性）及返回值定義訪問器或函數，并且建立封裝對象須遵循引用一致性策略。引用一致性指以對象ID為索引存儲一個原對象與封裝對象的關聯表，如果請求的對象不在表中則生成一個新的封裝對象，否則返回同一個對象以保持引用對象的一致性。同時，雙重的輸入輸出封裝構筑另一道安全屏障。除了不允許原對象引用泄漏(exporting)外，同時不允許不受信任的代碼進入(importing)訪問。輸入封裝是為第三方對象(參數和重定義的屬性)設計的，即當一個封裝對象的某個方法接收參數或某個屬性重賦值時都必須進行輸入封裝。下面舉個實例說明怎樣保證對象共享安全性，例如定義對象obj，包含一個屬性prop與一種方法proc，其中方法proc可讀寫，屬性prop則不可讀寫。

5實驗

實驗平臺：全部實驗在頻率為1.5GHz的IntelCeleronM的處理器，512MB內存的機器上實現的，所用的操作系統是WindowsXP，采用服務器ApacheTomcat5.5發送數據到瀏覽器(InternetEx-plorer8.0，Firefox3.6.3，Safari4.0.5，Opera10.54，GoogleChrome6.0.401.1)。服務器端需要修改服務器，對服務器不透明；動態創建script節點，需要引用其他域的JS文件且支持的數據格式有限；而段標識通信機制是傳統跨域通信方案中最常見的通信方案，應用廣泛，對服務器透明且不需引入其他JS文件等，可比性強，所以本文選擇采用段標識跨域通信機制的系統(FIC系統)與本文系統進行測試，對比了兩者在數據吞吐率(datathroughput)和事件發生率(eventrate)以及組件裝載延遲(componentloadlatency)3方面的實驗數據，同時還測試比較了SCDC系統支持對象共享前后的JS執行時間開銷。

5.1數據吞吐率

組件數從1、2遞增到32個，輪詢時間間隔取10ms、20ms、40ms、80ms不等，測試數據吞吐率(橫縱坐標為對數刻度)。開始從聚合應用傳輸4KB，8KB等小數據量到各個組件中，耗時非常短。然后傳送1MB的數據，對比系統所用的時間。所有的實驗數據都是測驗5次后取平均值得到的，減少了隨機因素的影響。實驗結果表明隨著組件數目的增加，SCDC系統的吞吐率隨之增長，只是組件數越大，吞吐率增長幅度越小些。由于篇幅限制，在此只給出Firefox、GoogleChrome2個常用瀏覽器的測試結果，如圖8(a)和圖8(b)所示。同時對比SCDC系統與FIC系統，比較圖8(a)與圖8(c)，實驗結果顯示SCDC系統比FIC系統的吞吐率高出5倍之多。主要原因在于FIC系統受到瀏覽器URL長度的限制，當傳輸數據量比較大時，則要分段進行傳輸，而SCDC系統則無此限制，由此數據吞吐率明顯提高。

5.2事件發生率

事件發生率，衡量對于小事件，系統所能支持的最大事件率。對于許多聚合應用來說，組件之間需要交換小事件以響應用戶行為。事件發生率系統傳輸15個字符的小負載(簡單的名/值對)進行測試事件發生率。測試結果如圖9(a)和圖9(b)所示，對于各個瀏覽器，存在一定的差異，隨著組件的數量，輪詢時間間隔的變化，事件發生率呈現上升的增長趨勢，主要緣于跨文檔通信機制是異步傳輸的機制。同時對比SCDC系統與FIC系統，實驗結果顯示，SCDC系統的事件發生率比FIC系統提高了5倍左右，如圖9(a)和圖9(c)所示。事件發生率系統傳輸1MB的大負載進行測試事件發生率。大負載測試結果如圖10所示，比較圖9(a)與圖10，可以發現與小負載測試結果相似。由此可知，事件發生率與負載的大小無關。

6結束語

聚合應用組合了來自不同源的信息，由此信息的交互就成為一個瓶頸。本文在分析比較傳統跨域通信方案優缺點的基礎上，利用HTML5新增特性跨文檔通信機制以及借助于分層通信棧結構實現了適合聚合應用的安全跨域通信系統；并且在系統中引入了細粒度的對象共享，通過封裝對象及定義策略來約束控制對象，以代替對原對象的訪問。同時，跨域通信與對象共享導致的安全問題也不容忽視，相應地增加了針對性的安全防范措施。通過一系列實驗及對其結果進行比較分析可知，運用該SCDC系統的聚合應用程序，性能有了大幅度的提升，事件發生率、吞吐率明顯較之前的通信方案提高了5倍以上；減少了組件裝載延遲時間；同時，對象共享也僅引入很小的開銷。今后的研究工作包括在聚合應用環境下進一步完善跨域通信系統的安全性，研究更全面的安全措施。同時在對象共享方面有所突破，使得所有瀏覽器本身支持細粒度對象共享。