—

作者:

隨著網站功能越來越多元，WebSocket 已成為即時通訊的首選協議。它以單一 TCP 連線維持持久化雙向通訊，省去 HTTP 的多次握手開銷，對聊天室、即時訊息、股市行情推播、遠端監控等場景尤為適合。然而，傳統的 WebSocket 實作往往將所有工作交給主執行緒，如果佔用過大，可能導致 WordPress 主機的回應時間拉長，甚至被惡意用戶利用造成 DoS 攻擊。

為了解決這些瓶頸，WebSocket Worker 概念被提出：將 WebSocket 連線的讀寫操作交由瀏覽器的 Web Worker 或伺服器端的多執行緒 (Node.js Worker Threads) 處理，從而隔離負載，提升頁面流暢度與伺服器韌性。以下將以 WordPress 為例，說明 WebSocket Worker 的原理、實作方式，以及安全考量。

1. WebSocket 的基礎與優勢

WebSocket 與 HTTP 的最大差別在於：當建立連線後，雙方可以隨意發送資料，連線保持開啟，無需每次請求都進行握手。其語法簡潔，支援二進制與文字資料，並且透過 Sec-WebSocket-Key 等欄位提供握手驗證，確保安全。

然而，WebSocket 的同步資料傳輸若由主執行緒處理，JavaScript 的單執行緒模型會導致 UI 鈍化，尤其在高併發情境下更為明顯。此時，Worker 的介入就能有效分散工作。

2. Worker 的概念與類型

Web Worker（前端）：在瀏覽器中以獨立執行緒執行 JavaScript，避免主執行緒被阻塞。可用於執行計算密集的邏輯或維持 WebSocket 連線。
Service Worker：提供快取、背景同步、離線支援等功能，也能攔截 WebSocket 連線，用於實作推播資料的分發。
Node.js Worker Threads（後端）：Node 10+ 之後引入的多執行緒模型，可將 WebSocket 服務器的讀寫分散到獨立執行緒，減少單進程負擔。

3. 在 WordPress 中實作 WebSocket Worker

3.1 前端 WebSocket Worker 範例

將以下程式碼放至主題目錄下的 js/ws-worker.js，並在頁面載入時啟動 Worker：

/* js/ws-worker.js */
let socket = new WebSocket('wss://example.com/ws');

socket.addEventListener('open', () => {
  postMessage({ type: 'connected' });
});

socket.addEventListener('message', (event) => {
  // 將資料傳回主執行緒
  postMessage({ type: 'message', data: event.data });
});

socket.addEventListener('close', () => {
  postMessage({ type: 'closed' });
});

self.addEventListener('message', (event) => {
  if (event.data.type === 'send') {
    socket.send(event.data.payload);
  }
});

在主題的 header.php 加載並啟動 Worker：

<script src="js/ws-worker.js"></script>
<script>
  const wsWorker = new Worker('js/ws-worker.js');
  wsWorker.onmessage = function(e) {
    const { type, data } = e.data;
    if (type === 'message') {
      console.log('收到訊息：', data);
    }
  };

  function sendMessage(msg) {
    wsWorker.postMessage({ type: 'send', payload: msg });
  }
</script>

這樣即使 WebSocket 收發大量資料，主執行緒依然維持正常渲染，提升使用者體驗。

3.2 伺服器端 Node.js Worker Threads 範例

若你的 WordPress 架構中包含聊天、即時通知、遠端監控（如DeamjTech A-Share WebRTC 系統）、或 AI 推播（如 DreamJ AI 回應訊息提示），可採用 Node.js 作為 WebSocket Gateway，再透過 Worker Threads 分散負載。

以下示範使用 ws 套件搭配 Node.js Worker：

主執行緒：server.js


// server.js
const { Worker } = require('worker_threads');
const WebSocket = require('ws');

// 建立 WebSocket Server
const wss = new WebSocket.Server({ port: 8080 });

// 建立 Worker Thread
const worker = new Worker('./ws-handler.js');

wss.on('connection', (ws) => {
  console.log('新連線建立');

  ws.on('message', (msg) => {
    // 所有訊息交給 Worker 做處理
    worker.postMessage({ type: 'incoming', message: msg });
  });

  // Worker 回傳結果後再回送給 Client
  worker.on('message', (msg) => {
    if (msg.type === 'broadcast') {
      ws.send(JSON.stringify(msg.data));
    }
  });
});

Worker Thread：ws-handler.js


// ws-handler.js
const { parentPort } = require('worker_threads');

parentPort.on('message', (event) => {
  if (event.type === 'incoming') {
    const data = event.message.toString();

    // 假設這裡是計算密集或 I/O 大量操作...
    const output = {
      received: data,
      timestamp: Date.now(),
      message: "處理完成"
    };

    parentPort.postMessage({
      type: 'broadcast',
      data: output
    });
  }
});

這種方式的好處:

技術層級	說明
主執行緒	專心處理 WebSocket 連線，不被封包影響效能
Worker Threads	處理資料轉換、推播判斷、事件分發
WordPress	完全不用承受 WebSocket 連線壓力，避免 PHP-FPM 被拖垮

4. 安全性強化：避免 WebSocket 成為 WordPress 弱點

WebSocket 是一把雙面刃，性能強，但“永遠開著”，因此也容易被用來：

發動 DoS / Flooding
嘗試暴力登入（Brute Force）
Inject 惡意 JSON
持續探測 WordPress REST API
多設備繞過驗證（例如你之前遇到的 shareId session 覆蓋問題）

以下為必要安全措施：

4.1 檢查連線來源（防止未授權連線）

前端 Worker 必須加入 Token 宣告：


const socket = new WebSocket("wss://example.com/ws?token=YOUR_JWT");

伺服器端解析：


const url = new URL(req.url, "http://localhost");
const token = url.searchParams.get("token");
// 驗證 JWT 或 WordPress Nonce

4.2 限流（Rate-Limiting）

針對每個 IP 或 userId：


// 每秒最多 10 封訊息
if (rate[ip] > 10) {
  ws.close();
}

4.3 JSON 驗證（防止 Injection）


let data;
try {
  data = JSON.parse(message);
} catch(e) {
  return ws.send(JSON.stringify({ error: "Invalid JSON" }));
}

4.4 斷線重連間隔（避免惡意重連）


if (lastReconnect[ip] && Date.now() - lastReconnect[ip] < 1000) {
  ws.close();
}

4.5 Service Worker 用來隔離推播分發（高安全解法

如果你啟用 PWA（如 DreamjTech A-Share），
可以讓 Service Worker 成為 WebSocket → 前端的安全中繼層


Client <-> Service Worker <-> WebSocket Server

可實作：

分流多來源資料
過濾惡意 payload
Queue 離線訊息

5. 架構建議：WordPress + WebSocket Worker 最佳實務

以下是可直接採用的完整架構圖（文字描述版，可轉為 mermaid）：


             ┌─────────────────────┐
             │      WordPress      │
             │  PHP-FPM / REST API │
             └─────────┬──────────┘
                       │
                       │ JSON
                       ▼
         ┌─────────────────────────────┐
         │      WebSocket Gateway      │
         │     (Node.js + ws 套件)     │
         └───────┬─────────────────────┘
                 │ Worker Threads 分流
     ┌───────────┴───────────────────────┐
     │  ws-handler.js │  notify-worker.js│
     └───────────┬────┴───────────────┘
                 │
                 ▼
        ┌────────────────────┐
        │ Browser Web Worker │
        │  (ws-worker.js)    │
        └────────────────────┘

6. 適用場景：哪些 WordPress 功能最該使用 WebSocket Worker？

WordPress 應用	是否推薦使用 WebSocket Worker	原因
即時聊天室	✔ 強烈推薦	數據密集、connection 多
AI 即時回答	✔	減少主執行緒延遲
A-Share WebRTC	✔ 必須	WebRTC signaling 本質就是 WebSocket
監測後台登入	✔	可即時推播管理警報
一般文章網站	✘ 不需要	HTTP/REST 即可