Socket.IO - 內部機制

本章將討論回退機制、使用 Socket.IO 的連線、事件和訊息。

回退機制

Socket.IO 具有許多底層的傳輸機制，這些機制處理由於跨瀏覽器問題、WebSocket 實現、防火牆、埠阻塞等引起的各種約束。

雖然 W3C 為 WebSocket API 定義了規範，但其實現仍然不足。Socket.IO 為我們提供了回退機制，可以處理此類問題。如果我們使用原生 API 開發應用程式，則必須自己實現回退機制。Socket.IO 按以下順序涵蓋了大量的回退機制：

• WebSockets
• FlashSocket
• XHR 長輪詢
• XHR 多部分流
• XHR 輪詢
• JSONP 輪詢
• iframes

使用 Socket.IO 的連線

Socket.IO 連線始於握手。這使得握手成為協議的特殊部分。除了握手之外，協議中的所有其他事件和訊息都透過套接字傳輸。

Socket.IO 旨在與 Web 應用程式一起使用，因此假設這些應用程式將始終能夠使用 HTTP。正是由於這個原因，Socket.IO 握手透過 HTTP 使用對握手 URI（傳遞給連線方法）的 POST 請求進行。

事件和訊息

WebSocket 原生 API 僅傳送跨訊息。Socket.IO 在這些訊息之上提供了一個附加層，這允許我們建立事件，並再次幫助我們透過分離傳送的不同型別的訊息來輕鬆開發應用程式。

原生 API 僅以純文字形式傳送訊息。Socket.IO 也處理了這個問題。它為我們處理資料的序列化和反序列化。

我們有一個用於 Web 的官方客戶端 API。對於其他客戶端，例如原生手機、其他應用程式客戶端，我們也可以使用以下步驟使用 Socket.IO。

• 步驟 1 - 需要使用上面討論的相同連線協議建立連線。

• 步驟 2 - 訊息需要與 Socket.IO 指定的格式相同。此格式使 Socket.IO 能夠確定訊息的型別以及訊息中傳送的資料以及對操作有用的某些元資料。

訊息格式為：

[type] : [id ('+')] : [endpoint] (: [data]

上面命令中的引數解釋如下：

• 型別 是一個一位整數，指定它是哪種型別的訊息。

• ID 是訊息 ID，一個用於確認的增量整數。

• 端點 是預期將訊息傳遞到的套接字端點……

• 資料 是要傳遞到套接字的關聯資料。對於訊息，它被視為純文字；對於其他事件，它被視為 JSON。

在下一章中，我們將用 Socket.IO 編寫一個聊天應用程式。