即時通訊（IM）需「伺服器主動推送消息到客戶端」，但 HTTP 協議本質是「客戶端請求-伺服器響應」的單向模式。如何在省電、省流量、穩定可靠之間平衡？
| 方案 | 原理 | 優點 | 缺點 | 典型應用 |
|---|---|---|---|---|
| 長連接 | TCP/WebSocket 持久連接，心跳保活 | 真正即時、雙向、低延遲、伺服器主動推送 | 需維持連接狀態、斷網重連複雜、伺服器連接數壓力大 | 微信、WhatsApp、Slack、遊戲 IM |
| HTTP 長輪詢 | 客戶端發請求，伺服器 hold 住直到有數據或超時 | 相容性好、穿透防火牆/代理、無狀態易擴展 | 延遲較高、頻繁建連開銷大、Header 開銷大 | 早期 Gmail、Facebook Chat、部分 Web IM |
| 短輪詢 | 客戶端定時發請求詢問新消息 | 實現極簡、完全無狀態 | 極不即時、空請求浪費頻寬、電量消耗大 | 低頻通知、非即時場景 |
| Server-Sent Events (SSE) | HTTP 單向流，伺服器主動推送文本事件 | 原生斷線重連、輕量、HTTP/2 多路復用 | 單向（僅伺服器→客戶端）、IE 不支援、連接數限制 | 股票行情、直播彈幕、通知流 |
| 系統級推送 | APNs (iOS)、FCM (Android)、華為/小米/OPPO/vivo 廠商通道 | App 進程被殺也能收推、系統級省電、到達率高 | 需適配多廠商、載荷限制、延遲不可控、開發複雜 | 所有商業 App（微信、鉉鉉、抖音等） |
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Client │◄───►│ Gateway │◄───►│ Message │
│ (App) │WS │ Cluster │RPC │ Service │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Local DB │ │ Presence │ │ Offline │
│ (SQLite) │ │ Service │ │ Push (APNs/FCM/廠商) │
└─────────────┘ └─────────────┘ └─────────────┘
PING/PONG 僅 2 字節，或複用業務封包作心跳| 場景 | 推薦方案 | 技術棧參考 |
|---|---|---|
| 啟動期 IM（微信級） | 自建長連接網關 + 系統推送兜底 | Netty/gRPC + Protobuf + Redis Cluster + APNs/FCM/廠商 SDK |
| 中小型 App/快速上線 | 現成 IM 云服務 | 環信、融云、騰訊云 IM、LeanCloud、Firebase |
| Web 主導/跨平台 | WebSocket + Service Worker 離線緩存 | Socket.io、SignalR、Pusher、自建 Node/Go 网关 |
| 物聯網/硬體設備 | MQTT over WebSocket/TCP | EMQX、Mosquitto、AWS IoT Core |
結論：現代 App 即時通訊**不再是二選一**，而是「長連接為主、系統推送兜底、多通道融合」的混合架構。自建長連接門檻高，建議中小團隊優先接入成熟 IM 云服務，專注業務創新。
