SRWebSocket

之前有個項目裏有作聊天室，就是用的SRWebSocket。如今整理下資料，主要是對網上搜索到的資料進行整合。

 

WebSocket介紹，與Socket的區別

https://blog.csdn.net/wwd0501/article/details/54582912

WebSocket protocol 是HTML5一種新的協議。它實現了瀏覽器與服務器全雙工通訊(full-duplex)。一開始的握手須要藉助HTTP請求完成。

在WebSocket中，只須要服務器和瀏覽器經過HTTP協議進行一個握手的動做，而後單獨創建一條TCP的通訊通道進行數據的傳送。

WebSocket同HTTP同樣也是應用層的協議，可是它是一種雙向通訊協議，是創建在TCP之上的。

WebSocket則是一個典型的應用層協議。

 

Socket其實並非一個協議，而是爲了方便使用TCP或UDP而抽象出來的一層，是位於應用層和傳輸控制層之間的一組接口。

 

iOS平臺有哪些WebSocket和Socket的開源框架

Socket開源框架有：CocoaAsyncSocket，socketio/socket.io-client-swift
WebSocket開源框架有:facebook/SocketRocket，tidwall/SwiftWebSocket

• WebSocket協議是基於TCP的一種新的網絡協議。它實現了瀏覽器與服務器全雙工(full-duplex)通訊——能夠通俗的解釋爲服務器主動發送信息給客戶端。

• 區別於MQTT、XMPP等聊天的應用層協議，它是一個傳輸通信協議。它有着本身一套鏈接握手，以及數據傳輸的規範。

 

SRWebSocket 源碼分析：https://www.jianshu.com/p/cdb7a886789a

 

 

QOS機制

QoS（Quality of Service，服務質量）指一個網絡可以利用各類基礎技術，爲指定的網絡通訊提供更好的服務能力, 是網絡的一種安全機制， 是用來解決網絡延遲和阻塞等問題的一種技術。

 

它提供了三個選項

最多發送一次，至少發送一次，精確只發送一次

• QOS(0),最多發送一次：若是消息沒有發送過去，那麼就直接丟失。
• QOS(1),至少發送一次：保證消息必定發送過去，可是發幾回不肯定。
• QOS(2),精確只發送一次：它內部會有一個很複雜的發送機制，確保消息送到，並且只發送一次。

 

 

心跳機制：

心跳就是用來檢測TCP鏈接的雙方是否可用

 

這裏咱們須要說明的是TCP的KeepAlive機制只能保證鏈接的存在，可是並不能保證客戶端以及服務端的可用性.

 

如：某臺服務器由於某些緣由致使負載超高，CPU 100%，沒法響應任何業務請求，可是使用 TCP 探針則仍舊可以肯定鏈接狀態，這就是典型的鏈接活着但業務提供方已死的狀態。

 

這時候心跳機制就起到做用了：

咱們客戶端發起心跳Ping（通常都是客戶端），假如設置在10秒後若是沒有收到回調，那麼說明服務器或者客戶端某一方出現問題，這時候咱們須要主動斷開鏈接

 

服務端也是同樣，會維護一個socket的心跳間隔，當約定時間內，沒有收到客戶端發來的心跳，咱們會知道該鏈接已經失效，而後主動斷開鏈接。

 

 

PingPong機制：

1. ping

• Ping幀操做碼（opcode）0x9。能夠包含「應用數據
• 當收到一個Ping幀時，接收方必須在響應中發送一個Pong幀，除非它早已接收到一個關閉幀。它應該儘量快地以Pong幀響應。（也用來驗證遠程端點是否可響應）

1. Pong
• Pong幀操做碼（opcode）0x9。
• 一個Pong幀必須攜和被響應的Ping幀中相同的數據
• 若是再一個ping到達服務端，服務端還沒有響應前，由到達同源的ping幀，則能夠只響應最新的ping幀，
• 未收到ping也能夠發送一個Pong幀。這個充當單向的心跳（heartbeat），另外一方不須要響應。

當服務端發出一個Ping，客戶端沒有在約定的時間內返回響應的ack，則認爲客戶端已經不在線，這時咱們Server端會主動斷開Scoket鏈接，而且改由APNS推送的方式發送消息。

一樣的是，當客戶端去發送一個消息，由於咱們遲遲沒法收到服務端的響應ack包，則代表客戶端或者服務端已不在線，咱們也會顯示消息發送失敗，而且斷開Scoket鏈接。

 

CocoaSyncSockt的例子所講的獲取消息超時就斷開嗎？其實它就是一個PingPong機制的客戶端實現。咱們每次能夠在發送消息成功後，調用這個超時讀取的方法，若是一段時間沒收到服務器的響應，那麼說明鏈接不可用，則斷開Scoket鏈接

 

 

 

重連機制：

理論上，咱們本身主動去斷開的Scoket鏈接（例如退出帳號，APP退出到後臺等等），不須要重連。其餘的鏈接斷開，咱們都須要進行斷線重連。

通常解決方案是嘗試重連幾回，若是仍舊沒法重連成功，那麼再也不進行重連。

 

 

心跳機制、PingPong機制、斷線重連機制、還有咱們後面所說的QOS機制。這些被用來保證鏈接的可用，消息的即時與準確的送達等等。

上述內容保證了咱們IM服務時的可靠性，其實咱們能作的還有不少：好比咱們在大文件傳輸的時候使用分片上傳、斷點續傳、秒傳技術等來保證文件的傳輸。

 

咱們一般還須要一些安全機制來保證咱們IM通訊安全。

例如：防止 DNS 污染、賬號安全、第三方服務器鑑權、單點登陸等等

 

 

相似微信，服務器不作聊天記錄的存儲，只在本機進行緩存，這樣能夠減小對服務端數據的請求，一方面減輕了服務器的壓力，另外一方面減小客戶端流量的消耗。咱們進行http鏈接的時候儘可能採用上層API，相似NSUrlSession。而網絡框架儘可能使用AFNetWorking3。由於這些上層網絡請求都用的是HTTP/2 ，咱們請求的時候能夠複用這些鏈接。