基于Web前端開發的即時通信文件傳輸研究

何杰惠

(陜西國防工業職業技術學院 計算機和軟件學院，西安 710300)

0 引言

隨著IM(Instant Messaging)即時通信技術的飛速發展，市場上出現了一系列即時通信客戶端如米聊、移動飛信以及騰訊微信等[1]，即時通信應用能夠為用戶提供即時消息收發以及文件傳輸等一系列即時通信服務。當前的即時通信大都采用XMPP協議[2]進行數據交互，XMPP協議基于TCP傳輸XML數據流，能夠有效保證數據的安全性且易于拓展，在Web應用中集成即時通信服務能夠極大地方便系統用戶的在線交流，增加用戶粘性。

WebRTC(Web Real-Time Communications)定義了一系列標準的JavaScript接口[3]，旨在將多媒體數據的處理能力嵌入到瀏覽器中，使得瀏覽器與瀏覽器之間能夠建立點對點的直連媒體數據通道，在不依賴服務器的情況下進行多媒體數據的傳輸[4]。WebRTC技術由Google 2011年5月開源并率先在Chrome瀏覽器上得到了良好的支持，目前，Firefox及Opera的高版本瀏覽器也已實現了WebRTC技術。

本文提出了一種基于Web前端開發的即時消息通信方案，主要提出基于Web前端開發的用戶單聊、群聊、消息記錄的瀏覽器端存儲以及文件傳輸功能的設計與實現。其中，采用基于XMPP協議的環信服務器作為XMPP服務器用以實現即時消息通信功能；采用IndexedDB非關系型數據庫用于存儲即時消息通信記錄；采用WebRTC技術建立客戶端之間的雙向數據傳輸通道，并在此之上實現客戶端之間的即時文件傳輸功能。

1 相關工作

1.1 即時消息通信技術

即時通信技術[5]能夠為用戶提供即時通信服務，其主要優勢在于即時性和交互性。當前即時通信應用已經發展成為集即時文本通信、文件傳輸、音視頻通信等一系列業務為一體的綜合性應用，為人們的生活帶來了極大的便利。目前XMPP是所有主流的即時通信協議中覆蓋范圍最廣的通信協議，XMPP協議規定了客戶端與服務器之間采用TCP的方式建立連接[6]，并通過傳輸XML格式數據進行消息交互，具有較高的靈活性。

目前，市場上有很多實現了XMPP協議的服務器，如Openfire、環信即時通訊云等等。Openfire服務器[7]的優勢在于是開源的，開發者可以通過下載Openfire的源代碼進行編譯執行并通過修改服務器源代碼實現一些定制化功能；Openfire的缺點在于只實現了基本的即時消息通信功能，需要開發插件以實現其他個性化服務。環信即時通訊云[8]是一個面向開發者的PaaS平臺，后端基于Erlang，能夠支持高并發和高吞吐量的服務器訪問，同時環信即時通訊云為開發者提供可供調用的REST接口和客戶端SDK，能夠方便開發者快速集成和使用。

1.2 文件傳輸技術

目前，基于Web前端開發的文件傳輸大都采用經服務器中轉[9]的方式進行，文件發送方需要將發送的文件上傳到FTP或網盤，文件接收方通過文件鏈接下載文件。采用經服務器中轉的方式進行文件傳輸主要存在三個弊端：首先浪費了大量的帶寬資源和服務器資源，因為服務器不會對文件數據進行操作，只起到中轉的作用；其次文件在服務器端進行緩存的過程中存在數據泄露的安全風險；最后文件的傳輸不是實時的，文件傳輸存在較長的時延。

WebRTC技術[10]的出現解決了上述文件傳輸經過服務器轉發效率低的問題，WebRTC技術提供了一套瀏覽器需實現的能夠操作本地媒體流以及建立點對點連接的接口規范，通過集成ICE框架實現客戶端之間的私網穿越和防火墻穿越并基于JSEP協議完成媒體協商過程。實現了WebRTC技術的瀏覽器之間能夠通過信令服務器進行媒體協商，協商完成后建立點對點的雙向數據傳輸通道，并基于此通道直接傳輸文件數據，而無需經過服務器的轉發，能夠有效提高文件傳輸效率。

2 方案設計

本節主要對即時消息通信方案的架構設計、消息格式設計以及關鍵流程設計進行介紹。

2.1 架構設計

本文提出了一種基于Web前端開發的即時消息通信、即時消息瀏覽器端存儲以及點對點文件傳輸的方案。方案采用環信服務器作為XMPP服務器負責與用戶客戶端建立連接并處理轉發用戶的即時消息，采用HTML5中的IndexedDB非關系型數據庫[11]用于存儲即時消息通信記錄，采用WebRTC技術用于實現基于Web前端開發的文件傳輸，方案的架構設計如圖1所示。

分析圖1的即時消息通信方案的架構設計，方案架構主要包含WebRTC服務器、中央服務器、環信服務器以及用戶客戶端四個網元實體。各個網元的功能分析如下：

(1)WebRTC服務器

WebRTC服務器主要用于與用戶客戶端建立WebSocket連接，并在此連接上傳輸ROAP協議消息進行客戶端之間的媒體協商和連接建立，WebRTC服務器將維護與用戶客戶端之間的連接并負責轉發用戶的信令消息。本文的WebRTC服務器采用集群式部署以能夠為海量用戶提供連接管理和即時消息通信業務，WebRTC服務器與服務器之間會建立Socket連接以保證連接在不同服務器上的用戶客戶端能夠正常通信。

(2)中央服務器

中央服務器用于管理和控制各個WebRTC服務器，每個WebRTC服務器在啟動和關閉時，都會向中央服務器發起注冊和注銷。在系統運行過程中，中央服務器會采用心跳機制定時向所有注冊的WebRTC服務器發送請求用以確認所有WebRTC服務器的運行狀態。在用戶登錄系統時，會向中央服務器發送請求獲取WebRTC服務器的地址，中央服務器會按照一定的負載均衡算法計算得到一個WebRTC的服務器地址并返回給用戶。

圖1 架構設計

(3)環信服務器

環信服務器主要作為XMPP服務器用于與用戶客戶端建立Socket雙向數據連接并維護用戶會話，在用戶使用系統的即時消息通信功能時，客戶端將構造XML格式數據并發送給環信服務器，環信服務器負責轉發消息數據給對端用戶以實現客戶端之間的即時消息交互。此外，環信服務器會維護用戶客戶端的在線離線狀態，當用戶離線時，環信服務器會保存用戶的離線即時消息信息，待用戶上線后再將離線消息推送給用戶。

(4)用戶客戶端

用戶客戶端是本文即時消息系統的重要網元，主要完成三方面的功能。首先用于展示系統并為用戶提供系統操作頁面；其次用戶客戶端會與WebRTC服務器建立WebSocket連接，并基于WebSocket連接傳輸ROAP協議消息以建立客戶端之間的雙向數據傳輸通道，并在此通道上傳輸文件；最后客戶端將與環信服務器建立Socket連接，并在此之上傳輸XMPP協議消息以實現即時消息通信功能，客戶端能夠完成對于XML格式數據的構建和解析。

2.2 消息格式設計

本節將主要對即時消息通信方案中涉及到的自定義消息格式進行設計，主要包含用于媒體協商和建立客戶端之間雙向數據直連通道的ROAP協議[12]自定義消息格式設計以及用于在雙向數據直連通道上進行文件傳輸的自定義消息格式設計。

2.2.1 ROAP協議消息格式設計

ROAP協議主要用于協商搭建媒體通道，采用Offer/Answer的形式交互客戶端的媒體信息，是SIP協議[13]的簡單版本且支持消息的自定義擴展。本文的文件傳輸方案會采用ROAP協議用于建立瀏覽器之間的雙向數據通道，ROAP協議的自定義消息格式如表1所示。

表1 ROAP消息格式

ROAP消息格式中的type字段用于標識ROAP協議消息的類型，主要包括發送會話請求的Offer消息類型、接收會話請求的Answer消息類型、確認Answer請求的Ok消息類型、發送網絡候選地址用于私網穿越的Candidate消息類型、關閉會話的Shutdown消息類型以及錯誤消息類型Error，其中錯誤消息會使用errorType字段用于標識錯誤的具體類型。

2.2.2 文件傳輸消息格式設計

客戶端之間采用ROAP協議建立了雙向數據通道后，就可以基于此通道進行點對點的數據傳輸。由于網絡傳輸過程中對于傳輸數據容量的限制，在文件傳輸時需要對發送的文件進行分塊然后在接收端重組，為了能夠讓文件在傳輸的過程中更加穩定和高效，本文設計了文件傳輸時的消息格式用于描述文件信息、傳輸文件具體內容以及請求重傳文件內容，文件傳輸的消息編碼結構如圖2所示。

圖2 文件傳輸消息編碼結構

分析圖2的文件傳輸過程中的消息編碼結構，消息的首位大小為一個字節，用于表示不同的消息類型，對于不同的消息類型，可自定義其后的字段內容。對于每個字段，前兩個字節用于表示字段的長度，其后的字節用于裝載真實的數據，文件的傳輸消息類型根據消息的不同功能分為描述文件信息類型消息、請求傳輸文件消息類型、傳輸具體文件內容消息類型以及取消某個文件傳輸的消息類型，文件傳輸的消息類型如表2所示。

表2 文件傳輸消息類型

2.3 關鍵流程設計

本節主要對基于Web前端開發的即時消息通信方案中的關鍵流程進行設計，主要包含使用環信服務器作為XMPP服務器進行即時消息通信的流程設計、使用WebRTC技術建立客戶端雙向數據傳輸通道的流程設計以及在數據傳輸通道上傳輸文件數據的流程設計。

(1)基于Web前端開發的即時消息通信方案流程設計如圖3所示。

圖3 即時消息通信流程設計

(2)采用WebRTC技術在客戶端之間建立直連雙向數據傳輸通道的流程設計如圖4所示。

圖4 建立連接流程設計

(3)客戶端建立了數據雙向通道后，在此通道上傳輸文件數據的流程設計如圖5所示。

圖5 文件數據傳輸流程設計

分析即時消息通信方案中的關鍵流程設計，為了實現客戶端之間的即時消息通信功能，客戶端會與環信服務器建立Socket 連接并通過環信服務器轉發XMPP即時消息以實現客戶端之間的即時消息交互；為了實現基于Web前端開發的文件傳輸功能，客戶端會與信令服務器建立WebSocket全雙工通道，并基于WebSocket連接傳輸ROAP協議用于媒體協商和私網穿越，然后建立客戶端之間的雙向數據傳輸通道。客戶端之間能夠基于此數據傳輸通道直接傳輸文件數據，傳輸文件數據使用自定義的文件傳輸消息格式，能夠實現對于文件的分塊和重組，同時實現對丟失文件塊的請求重傳機制。

3 方案實現

本文的基于Web前端開發的即時消息通信方案采用環信即時通訊云服務器作為XMPP服務器，并在客戶端實現了對于XMPP協議消息格式的構建和解析，根據本文的即時消息通信方案實現的系統群聊效果圖如圖6所示。

圖6 群聊效果圖

本文提出了一種即時消息記錄存儲方案，用于實現用戶即時消息的瀏覽器端存儲功能。方案提出使用HTML5中的localStorage技術用于存儲用戶近期聯系人列表，主要包括近期聯系的好友列表以及群組列表，同時方案提出使用IndexedDB非關系型數據庫用于存儲具體的即時消息內容。localStorage技術以及IndexedDB技術均采用鍵值對的方式存儲數據，在localStorage中存儲的key值為即時消息發送方以及接收方的名稱，value值為即時消息的收發時間；在IndexedDB數據庫中存儲的key值為即時消息的收發時間，value值為即時消息的具體內容對象，對象包括即時消息的發送方名稱、消息接收方名稱、消息的收發時間、消息類型以及消息的具體內容。此外，方案提出在IndexedDB數據庫中為消息的收發時間以及消息類型等普通字段添加索引，以有效增加數據庫查詢消息記錄的效率。

實現了即時消息記錄瀏覽器端存儲方案的系統，能夠為用戶提供在線以及離線的消息記錄查詢管理服務。用戶能夠在系統頁面中查詢近期聯系人列表，并按照時間順序分頁查看與某位聯系人的即時消息通信記錄，根據本文提出的即時消息瀏覽器端存儲方案實現的系統的即時消息記錄管理效果圖如圖7所示。

本文提出的基于Web前端開發的文件傳輸方案能夠實現客戶端之間點對點的文件傳輸功能，并能夠同時支持單文件以及多文件的傳輸，根據本文的即時消息通信方案實現的系統的文件傳輸效果圖分析，如圖8所示。

系統能夠根據文件塊的接收情況在系統頁面中顯示文件傳輸的進度。

圖7 即時消息存儲效果圖

4 文件傳輸方案測試

本文提出的基于Web前端開發的文件傳輸方案實現了客戶端之間的直連數據傳輸通道，客戶端能夠通過網絡直接傳輸文件數據而無需經過服務器的轉發，能夠大大提高文件的傳輸效率。在實現了本文方案的即時消息系統中，對文件傳輸的性能進行測試。在網絡狀況良好的情況下，隨著系統用戶量的增加，傳輸1MB文件客戶端之間建立數據雙向通道連接的傳輸時延測試結果如圖9所示。

圖9 建立連接性能測試

分析圖9的性能測試結果，在網絡狀況良好的情況下，隨著系統并發用戶量的增加，用戶客戶端之間建立雙向數據傳輸通道連接的時間會稍有增加。這是因為用戶間建立連接的信令消息需要經過信令服務器的轉發，在用戶量逐漸增加時會相應地增加信令服務器的負載，使得連接建立的時間稍有增加。在建立好客戶端之間的數據傳輸通道后，基于此通道傳輸數據的時延測試結果如圖10所示。

圖10 數據傳輸性能測試

分析圖10的測試結果，在網絡穩定的情況下，當系統用戶量逐漸增大時，文件數據傳輸時延不會發生太大的變化，這是因為在建立好客戶端之間的數據傳輸通道后，客戶端之間可以直接傳輸文件數據而無需經過服務器的轉發，因此當用戶量增加時，文件數據的傳輸時延基本保持不變。基于以上的分析，本文提出的文件傳輸方案能夠有效提高基于Web的文件傳輸效率，并且在系統用戶量逐漸增加的情況下，能夠保證良好的性能。

5 總結

本文研究了基于Web前端開發的即時消息通信、即時消息記錄瀏覽器端存儲以及文件傳輸功能的方案設計以及實現。首先提出了使用環信即時通訊云服務器作為XMPP服務器以實現即時消息通信功能的方案，同時提出了使用HTML5中IndexedDB數據庫進行即時消息瀏覽器端存儲的實現方案。此外，本文提出了使用WebRTC技術建立客戶端之間的直連雙向數據傳輸通道以傳輸文件的方案并對此方案進行了測試，測試結果表明本文的文件傳輸方案能夠有效提高基于Web前端開發的即時文件傳輸的效率和可靠性。