針對 1 萬並發的 H.265 直播場景,協議選型不應單一,而需構建分層協議矩陣:
| 協議層 | 推薦方案 | 適用場景 | 核心優勢 |
|---|---|---|---|
| 推流端→服務器 | RTMP / SRT | 主播端推流 | RTMP 生態成熟;SRT 抗弱網、低延遲、支持 H.265 原生封裝 |
| 服務器內部轉發 | RTP over UDP / QUIC | 集群節點間流轉發 | UDP 低延遲,RTP 支持 NALU 級分片;QUIC 解決隊頭阻塞 |
| 服務器→播放端 | HTTP-FLV / HLS / WebRTC | 大規模分發 | HTTP-FLV 秒開、CDN 友好;HLS 適配弱網/移動端;WebRTC 亞秒級超低延遲互動 |
| 信令控制 | WebSocket / HTTP/2 + gRPC | 房間管理、狀態同步 | 長連接雙向通訊,gRPC 契約化降低協議解析開銷 |
單機 1 萬連接在現代 Linux 內核(epoll/kqueue/IOCP)下輕鬆支撐,關鍵在於架構模式:
主進程 (Main Reactor)
├── Acceptor 線程池:專職 accept(),負載均衡分發新連接
├── Sub-Reactor 線程池 (CPU 核心數 × 1~2):
│ ├── epoll_wait 事件循環
│ ├── 讀寫緩衝區管理(零拷貝 sendfile/splice)
│ ├── 協議解碼/編碼(有限狀態機)
│ └── 業務邏輯分發(無鎖環形隊列 → Worker 進程)
└── Worker 進程池:CPU 密集型任務(轉碼、錄製、截圖、AI 分析)
sendfile、splice、io_uring 減少用戶態/內核態拷貝。結語:萬級並發非單一技術點突破,而是協議分層、Reactor 模式、零拷貝、無狀態集群、可觀測運維系統工程的綜合勝利。建議優先驗證單機 5 萬連接基準線,再推進集群化演進。