亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

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

        2018-11-22 00:47:46何杰惠
        微型電腦應(yīng)用 2018年11期
        關(guān)鍵詞:用戶

        何杰惠

        (陜西國防工業(yè)職業(yè)技術(shù)學(xué)院 計算機(jī)和軟件學(xué)院,西安 710300)

        0 引言

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

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

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

        1 相關(guān)工作

        1.1 即時消息通信技術(shù)

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

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

        1.2 文件傳輸技術(shù)

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

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

        2 方案設(shè)計

        本節(jié)主要對即時消息通信方案的架構(gòu)設(shè)計、消息格式設(shè)計以及關(guān)鍵流程設(shè)計進(jìn)行介紹。

        2.1 架構(gòu)設(shè)計

        本文提出了一種基于Web前端開發(fā)的即時消息通信、即時消息瀏覽器端存儲以及點對點文件傳輸?shù)姆桨?。方案采用環(huán)信服務(wù)器作為XMPP服務(wù)器負(fù)責(zé)與用戶客戶端建立連接并處理轉(zhuǎn)發(fā)用戶的即時消息,采用HTML5中的IndexedDB非關(guān)系型數(shù)據(jù)庫[11]用于存儲即時消息通信記錄,采用WebRTC技術(shù)用于實現(xiàn)基于Web前端開發(fā)的文件傳輸,方案的架構(gòu)設(shè)計如圖1所示。

        分析圖1的即時消息通信方案的架構(gòu)設(shè)計,方案架構(gòu)主要包含WebRTC服務(wù)器、中央服務(wù)器、環(huán)信服務(wù)器以及用戶客戶端四個網(wǎng)元實體。各個網(wǎng)元的功能分析如下:

        (1)WebRTC服務(wù)器

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

        (2)中央服務(wù)器

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

        圖1 架構(gòu)設(shè)計

        (3)環(huán)信服務(wù)器

        環(huán)信服務(wù)器主要作為XMPP服務(wù)器用于與用戶客戶端建立Socket雙向數(shù)據(jù)連接并維護(hù)用戶會話,在用戶使用系統(tǒng)的即時消息通信功能時,客戶端將構(gòu)造XML格式數(shù)據(jù)并發(fā)送給環(huán)信服務(wù)器,環(huán)信服務(wù)器負(fù)責(zé)轉(zhuǎn)發(fā)消息數(shù)據(jù)給對端用戶以實現(xiàn)客戶端之間的即時消息交互。此外,環(huán)信服務(wù)器會維護(hù)用戶客戶端的在線離線狀態(tài),當(dāng)用戶離線時,環(huán)信服務(wù)器會保存用戶的離線即時消息信息,待用戶上線后再將離線消息推送給用戶。

        (4)用戶客戶端

        用戶客戶端是本文即時消息系統(tǒng)的重要網(wǎng)元,主要完成三方面的功能。首先用于展示系統(tǒng)并為用戶提供系統(tǒng)操作頁面;其次用戶客戶端會與WebRTC服務(wù)器建立WebSocket連接,并基于WebSocket連接傳輸ROAP協(xié)議消息以建立客戶端之間的雙向數(shù)據(jù)傳輸通道,并在此通道上傳輸文件;最后客戶端將與環(huán)信服務(wù)器建立Socket連接,并在此之上傳輸XMPP協(xié)議消息以實現(xiàn)即時消息通信功能,客戶端能夠完成對于XML格式數(shù)據(jù)的構(gòu)建和解析。

        2.2 消息格式設(shè)計

        本節(jié)將主要對即時消息通信方案中涉及到的自定義消息格式進(jìn)行設(shè)計,主要包含用于媒體協(xié)商和建立客戶端之間雙向數(shù)據(jù)直連通道的ROAP協(xié)議[12]自定義消息格式設(shè)計以及用于在雙向數(shù)據(jù)直連通道上進(jìn)行文件傳輸?shù)淖远x消息格式設(shè)計。

        2.2.1 ROAP協(xié)議消息格式設(shè)計

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

        表1 ROAP消息格式

        ROAP消息格式中的type字段用于標(biāo)識ROAP協(xié)議消息的類型,主要包括發(fā)送會話請求的Offer消息類型、接收會話請求的Answer消息類型、確認(rèn)Answer請求的Ok消息類型、發(fā)送網(wǎng)絡(luò)候選地址用于私網(wǎng)穿越的Candidate消息類型、關(guān)閉會話的Shutdown消息類型以及錯誤消息類型Error,其中錯誤消息會使用errorType字段用于標(biāo)識錯誤的具體類型。

        2.2.2 文件傳輸消息格式設(shè)計

        客戶端之間采用ROAP協(xié)議建立了雙向數(shù)據(jù)通道后,就可以基于此通道進(jìn)行點對點的數(shù)據(jù)傳輸。由于網(wǎng)絡(luò)傳輸過程中對于傳輸數(shù)據(jù)容量的限制,在文件傳輸時需要對發(fā)送的文件進(jìn)行分塊然后在接收端重組,為了能夠讓文件在傳輸?shù)倪^程中更加穩(wěn)定和高效,本文設(shè)計了文件傳輸時的消息格式用于描述文件信息、傳輸文件具體內(nèi)容以及請求重傳文件內(nèi)容,文件傳輸?shù)南⒕幋a結(jié)構(gòu)如圖2所示。

        圖2 文件傳輸消息編碼結(jié)構(gòu)

        分析圖2的文件傳輸過程中的消息編碼結(jié)構(gòu),消息的首位大小為一個字節(jié),用于表示不同的消息類型,對于不同的消息類型,可自定義其后的字段內(nèi)容。對于每個字段,前兩個字節(jié)用于表示字段的長度,其后的字節(jié)用于裝載真實的數(shù)據(jù),文件的傳輸消息類型根據(jù)消息的不同功能分為描述文件信息類型消息、請求傳輸文件消息類型、傳輸具體文件內(nèi)容消息類型以及取消某個文件傳輸?shù)南㈩愋停募鬏數(shù)南㈩愋腿绫?所示。

        表2 文件傳輸消息類型

        2.3 關(guān)鍵流程設(shè)計

        本節(jié)主要對基于Web前端開發(fā)的即時消息通信方案中的關(guān)鍵流程進(jìn)行設(shè)計,主要包含使用環(huán)信服務(wù)器作為XMPP服務(wù)器進(jìn)行即時消息通信的流程設(shè)計、使用WebRTC技術(shù)建立客戶端雙向數(shù)據(jù)傳輸通道的流程設(shè)計以及在數(shù)據(jù)傳輸通道上傳輸文件數(shù)據(jù)的流程設(shè)計。

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

        圖3 即時消息通信流程設(shè)計

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

        圖4 建立連接流程設(shè)計

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

        圖5 文件數(shù)據(jù)傳輸流程設(shè)計

        分析即時消息通信方案中的關(guān)鍵流程設(shè)計,為了實現(xiàn)客戶端之間的即時消息通信功能,客戶端會與環(huán)信服務(wù)器建立Socket 連接并通過環(huán)信服務(wù)器轉(zhuǎn)發(fā)XMPP即時消息以實現(xiàn)客戶端之間的即時消息交互;為了實現(xiàn)基于Web前端開發(fā)的文件傳輸功能,客戶端會與信令服務(wù)器建立WebSocket全雙工通道,并基于WebSocket連接傳輸ROAP協(xié)議用于媒體協(xié)商和私網(wǎng)穿越,然后建立客戶端之間的雙向數(shù)據(jù)傳輸通道??蛻舳酥g能夠基于此數(shù)據(jù)傳輸通道直接傳輸文件數(shù)據(jù),傳輸文件數(shù)據(jù)使用自定義的文件傳輸消息格式,能夠?qū)崿F(xiàn)對于文件的分塊和重組,同時實現(xiàn)對丟失文件塊的請求重傳機(jī)制。

        3 方案實現(xiàn)

        本文的基于Web前端開發(fā)的即時消息通信方案采用環(huán)信即時通訊云服務(wù)器作為XMPP服務(wù)器,并在客戶端實現(xiàn)了對于XMPP協(xié)議消息格式的構(gòu)建和解析,根據(jù)本文的即時消息通信方案實現(xiàn)的系統(tǒng)群聊效果圖如圖6所示。

        圖6 群聊效果圖

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

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

        本文提出的基于Web前端開發(fā)的文件傳輸方案能夠?qū)崿F(xiàn)客戶端之間點對點的文件傳輸功能,并能夠同時支持單文件以及多文件的傳輸,根據(jù)本文的即時消息通信方案實現(xiàn)的系統(tǒng)的文件傳輸效果圖分析,如圖8所示。

        系統(tǒng)能夠根據(jù)文件塊的接收情況在系統(tǒng)頁面中顯示文件傳輸?shù)倪M(jìn)度。

        圖7 即時消息存儲效果圖

        4 文件傳輸方案測試

        本文提出的基于Web前端開發(fā)的文件傳輸方案實現(xiàn)了客戶端之間的直連數(shù)據(jù)傳輸通道,客戶端能夠通過網(wǎng)絡(luò)直接傳輸文件數(shù)據(jù)而無需經(jīng)過服務(wù)器的轉(zhuǎn)發(fā),能夠大大提高文件的傳輸效率。在實現(xiàn)了本文方案的即時消息系統(tǒng)中,對文件傳輸?shù)男阅苓M(jìn)行測試。在網(wǎng)絡(luò)狀況良好的情況下,隨著系統(tǒng)用戶量的增加,傳輸1MB文件客戶端之間建立數(shù)據(jù)雙向通道連接的傳輸時延測試結(jié)果如圖9所示。

        圖9 建立連接性能測試

        分析圖9的性能測試結(jié)果,在網(wǎng)絡(luò)狀況良好的情況下,隨著系統(tǒng)并發(fā)用戶量的增加,用戶客戶端之間建立雙向數(shù)據(jù)傳輸通道連接的時間會稍有增加。這是因為用戶間建立連接的信令消息需要經(jīng)過信令服務(wù)器的轉(zhuǎn)發(fā),在用戶量逐漸增加時會相應(yīng)地增加信令服務(wù)器的負(fù)載,使得連接建立的時間稍有增加。在建立好客戶端之間的數(shù)據(jù)傳輸通道后,基于此通道傳輸數(shù)據(jù)的時延測試結(jié)果如圖10所示。

        圖10 數(shù)據(jù)傳輸性能測試

        分析圖10的測試結(jié)果,在網(wǎng)絡(luò)穩(wěn)定的情況下,當(dāng)系統(tǒng)用戶量逐漸增大時,文件數(shù)據(jù)傳輸時延不會發(fā)生太大的變化,這是因為在建立好客戶端之間的數(shù)據(jù)傳輸通道后,客戶端之間可以直接傳輸文件數(shù)據(jù)而無需經(jīng)過服務(wù)器的轉(zhuǎn)發(fā),因此當(dāng)用戶量增加時,文件數(shù)據(jù)的傳輸時延基本保持不變?;谝陨系姆治?,本文提出的文件傳輸方案能夠有效提高基于Web的文件傳輸效率,并且在系統(tǒng)用戶量逐漸增加的情況下,能夠保證良好的性能。

        5 總結(jié)

        本文研究了基于Web前端開發(fā)的即時消息通信、即時消息記錄瀏覽器端存儲以及文件傳輸功能的方案設(shè)計以及實現(xiàn)。首先提出了使用環(huán)信即時通訊云服務(wù)器作為XMPP服務(wù)器以實現(xiàn)即時消息通信功能的方案,同時提出了使用HTML5中IndexedDB數(shù)據(jù)庫進(jìn)行即時消息瀏覽器端存儲的實現(xiàn)方案。此外,本文提出了使用WebRTC技術(shù)建立客戶端之間的直連雙向數(shù)據(jù)傳輸通道以傳輸文件的方案并對此方案進(jìn)行了測試,測試結(jié)果表明本文的文件傳輸方案能夠有效提高基于Web前端開發(fā)的即時文件傳輸?shù)男屎涂煽啃浴?/p>

        猜你喜歡
        用戶
        雅閣國內(nèi)用戶交付突破300萬輛
        車主之友(2022年4期)2022-08-27 00:58:26
        您撥打的用戶已戀愛,請稍后再哭
        關(guān)注用戶
        商用汽車(2016年11期)2016-12-19 01:20:16
        關(guān)注用戶
        商用汽車(2016年5期)2016-11-28 09:55:15
        兩新黨建新媒體用戶與全網(wǎng)新媒體用戶之間有何差別
        關(guān)注用戶
        商用汽車(2016年6期)2016-06-29 09:18:54
        關(guān)注用戶
        商用汽車(2016年4期)2016-05-09 01:23:12
        挖掘用戶需求尖端科技應(yīng)用
        Camera360:拍出5億用戶
        100萬用戶
        少妇高潮免费在线观看| 亚洲国产精品成人久久久| 亚洲中文字幕在线综合| 日韩精品视频一区二区三区| 成年女人毛片免费视频| 国产精品国产午夜免费福利看| 亚洲国产色图在线视频| 中文字幕一二三四五六七区| 青春草免费在线观看视频| 国产高清av首播原创麻豆| 无码少妇一区二区三区芒果| 青春草在线视频精品| 粉嫩的18在线观看极品精品| 自拍偷拍 视频一区二区| 麻豆精品国产精华精华液好用吗| 香蕉成人啪国产精品视频综合网 | 日本一区二区不卡视频 | 91精品国产乱码久久中文| 粗大猛烈进出白浆视频| 色婷婷综合中文久久一本| 78成人精品电影在线播放| 一区二区三区国产偷拍| 中文字幕有码在线人妻| 久久久久人妻精品一区二区三区 | 妺妺窝人体色www看人体| 亚洲国产区男人本色| 国产精品白浆无码流出| 在线观看黄片在线播放视频| 午夜少妇高潮在线观看视频| 亚洲精品无码av人在线观看| 中文字幕人妻偷伦在线视频| 蜜桃一区二区三区自拍视频| 精品日韩在线观看视频| 手机看黄av免费网址| 国产色诱视频在线观看| 绿帽人妻被插出白浆免费观看| 99视频一区二区日本| 中国精品18videosex性中国| 日韩无码视频淫乱| 一本色道久久88综合亚洲精品| 久草视频这里只有精品|