即時聊天系統（IM）發送檔案語音視訊的兩種方式比較

一般情況發送消息，把消息通過流發送給接收方{"MessageBody": "消息内容"}，但是作為聊天系統這樣發送消息存在兩個問題：1，接收方不知道如何解析消息，消息是文本還是圖檔，語音，視訊和檔案消息。2，圖檔語音視訊檔案等消息内容很大，就算現在網絡環境很好，壓縮比例很大，但是現在圖檔視訊品質也越來越高。如果依靠發現送文本的端口和伺服器發送圖檔和語音等消息，會一直占用連接配接，必須等大消息内容發送完畢，才能發送其他消息。

基于上面提出的問題，我們首先要把消息分成兩個類型，第一個文本消息，第二個是圖檔，語音視訊和檔案等大内容的消息，我們把此類型消息歸納成一類檔案消息，文本和檔案消息分開發送。

目前普遍的做法有兩種：

第一方式是檔案消息另外建立一條網絡連接配接，通過新的網絡連接配接來發送消息給伺服器，方式方法都跟發普通檔案消息一樣，弊端就是比如同時發送很多檔案，如果隻建立一個連結會導緻檔案發送堵塞，如果建立很多連結，增加了伺服器維持連接配接的難度。是以現實中采用此方法的聊天軟體中一般都會控制同時發送檔案的數量，比如微信同時隻允許發送9張圖檔，并且微信也不是同時建立9個連接配接，僅僅建立3個連接配接，同時發送的圖檔隻有3張，一個連接配接發完一張圖檔後再發送另一張圖檔。

​

第二方式是通過Http來上傳檔案。以用戶端A發送檔案給用戶端B為例，A首先把檔案通過HTTP方式上傳到伺服器，檔案上傳完成後伺服器服儲存圖檔，并把檔案的全局路徑傳回給上傳的用戶端A，用戶端A把傳回回來的路徑作為文本消息再發送給伺服器，伺服器收到文本消息把消息發送給目标用戶端B，目标用戶端B收到文本消息後解析出檔案的全局路徑然後下載下傳，這時整個檔案傳送過程完成。國外即時通訊系統一般采取此方式，比如WhatsApp。好處是http伺服器天然的請求應答方式很容易滿足需求，壞處是相對于消息體發送多了一次備援的文本消息發送，而且需要對http儲存的檔案全局路徑做權限控制，不然消息内容洩露會導緻檔案被任意下載下傳。

本人傾向選擇第二種模式，畢竟要處理的http和檔案系統權限都有比較成熟的方案去選擇使用。