[TOC] ### 一些對IM架構的思考 #### 短連接 HTTP協議擴展，運行8080 端口，http?body為二進制（protobuf）。 ?主要用途（接口）： ``` 用戶登錄驗證; 好友關系（獲取，添加）； 消息sync?(newsync)，自有sync機制； 獲取用戶圖像； 用戶注銷； 行為日志上報。 朋友圈發表刷新 ``` #### 長連接 ?tcp?長連接，端口為8080，類似微軟activesync的二進制協議。 ?主要用途（接口）： ``` 接受/發送文本消息； 接受/發送語音； 接受/發送圖片； 接受/發送視頻文件等。 ``` ### 報文 #### 分三種： ``` 請求報文（request，后簡稱為為R）； 應答報文（acknowledge，后簡稱為A）； 通知報文（notify，后簡稱為N）。 R：客戶端主動發送給服務器的報文 A：服務器被動應答客戶端的報文，一個A一定對應一個R N：服務器主動發送給客戶端的報文 ```` #### 普通消息投遞流程 ``` * client-A向im-server發送一個消息請求包，即msg:R * im-server在成功處理后，回復client-A一個消息響應包，即msg:A * 如果此時client-B在線，則im-server主動向client-B發送一個消息通知包，即msg:N（當然，如果client-B不在線，則消息會存儲離線） ``` #### 應用層確認+im消息可靠投遞的六個報文 >UDP是一種不可靠的傳輸層協議，TCP是一種可靠的傳輸層協議，TCP是如何做到可靠的？答案是：超時、重傳、確認。（即時通訊網注：實際上IM中，數據通訊層無論用的是UDP還是TCP協議，都同樣需要消息送達保證（即QoS）機制，原因在于IM的通信是A端-Server-B端的3方通信，而非傳統C/S或B/S這種2方通信) 要想實現應用層的消息可靠投遞，必須加入應用層的確認機制，即：要想讓發送方client-A確保接收方client-B收到了消息，必須讓接收方client-B給一個消息的確認，這個應用層的確認的流程，與消息的發送流程類似： ``` * client-B向im-server發送一個ack請求包，即ack:R * im-server在成功處理后，回復client-B一個ack響應包，即ack:A * 則im-server主動向client-A發送一個ack通知包，即ack:N ``` 至此，發送“你好”的client-A，在收到了ack:N報文后，才能確認client-B真正接收到了“你好”。 你會發現，一條消息的發送，分別包含（上）（下）兩個半場，即msg的R/A/N三個報文，ack的R/A/N三個報文。一個應用層即時通訊消息的可靠投遞，共涉及6個報文，這就是im系統中消息投遞的最核心技術（如果某個im系統不包含這6個報文，不要談什么消息的可靠性) #### 協議 ``` 傳輸層協議:tcp 應用層協議: protobuf 安全協議:ssl ``` #### 數據庫 數據存儲:mysql-mongodb 緩存:redis ### 離線消息 ### 萬人群