跳至主要內容
Skip to content

WebRTC 實戰 (2) —— 信令伺服器與連線中心

在上一篇中,我們成功獲取了本地的影音串流。現在問題來了:我要如何把我的影音傳給住在隔壁的朋友?

WebRTC 雖然是「點對點 (P2P)」通訊,但在連線建立之前,雙方其實完全不知道對方的 IP、媒體格式或網路環境。這就需要一個「中間人」來傳遞小撇步。這個過程就叫做 信令 (Signaling)


一、 信令:為什麼 P2P 需要伺服器?

想像你要和一個陌生人打電話,但你沒有對方的電話號碼。你們需要透過一個共同的朋友(信令伺服器)來交換彼此的聯絡方式。

1. 信令交換的流程 (Signaling Flow)

在 WebRTC 的連線建立階段,信令伺服器負責轉送以下三種資訊:

  1. 會話描述 (SDP):我是誰?我有什麼樣的影音編碼?
  2. 網路路徑 (ICE Candidates):我在哪裡?我的 IP 是什麼?
  3. 控制訊息:誰想打給誰?誰掛斷了?

二、 實作:極簡 WebSocket 信令伺服器

我們使用 Node.js 的 ws 庫來建立一個簡單的轉發中心:

javascript
const WebSocket = require("ws");
const wss = new WebSocket.Server({ port: 8080 });

const clients = new Map();

wss.on("connection", (ws) => {
  ws.on("message", (message) => {
    const data = JSON.parse(message);
    const { type, to, from, payload } = data;

    switch (type) {
      case "login":
        clients.set(from, ws);
        break;
      case "offer":
      case "answer":
      case "candidate":
        const targetSocket = clients.get(to);
        if (targetSocket) targetSocket.send(JSON.stringify(data));
        break;
    }
  });
});

三、 實作細節:JSON 封裝規範

為了讓信令能準確轉發,前端傳送的訊息格式至少需要包含:

  • type:訊息種類 (offer, answer, candidate, login)。
  • from:發送者 ID。
  • to:接收者 ID。
  • payload:實際的數據內容 (SDP 或 ICE 資料)。

總結

今天我們學會了為什麼 P2P 連線需要先經過信令伺服器,以及信令交換的三大核心資訊。

下一篇,我們將深入探討當中最關鍵的「秘密協議」:RTCPeerConnection 與 SDP 交換。


️ 進階挑戰

試著修改 server.js,增加一個功能:當某個使用者斷線時,自動通知所有正在與他通訊的對象。這需要你在 clients Map 中記錄更複雜的對應關係。


延伸閱讀與資源

← 上一章:瀏覽器影音採集 | 返回專案首頁 | 下一章:SDP 交換與媒體協商