实时通信协议对比速查（面试必备）

用途：面试时能脱口而出，背得滚瓜烂熟
适合：项目里有 MQTT / WebSocket / WebRTC / TCP Socket / 阿里云 Push 的同学
核心思想：没有最好的协议，只有最合适的协议

〇、面试速记版（5 分钟版先看这个）

面试前 5 分钟只看这一节，足够应付 80% 的提问。

1. 项目用了哪些协议？—— 5 + 1

一句话：「HTTP 拉数据，MQTT/TCP 管设备，两个 WebSocket 管通知和信令，WebRTC 传音视频，阿里云 Push 做杀进程兜底。」

2. 项目里各协议 → 业务 → 代码位置（一图背完）

3. 3 句必背口诀

1. MQTT 广播站一对多（订阅 Topic），WebSocket 专线电话一对一（连到服务器）
2. HTTP 一问一答断线，WebSocket 长连双向服务器主动推
3. WebRTC P2P 直连传音视频，WebSocket 服务器中转传信令

4. 4 个 WebRTC 名词（必记）

SDP   媒体描述（编解码、分辨率、传输方式）
ICE    NAT 穿透候选（host / srflx / relay）
STUN   拿到公网 IP（srflx）
TURN   中继服务器（relay，最后兜底）

5. 面试 5 句话模板（直接背）

「我们项目用了 5 种通信协议：

1. HTTP 处理 90% 的常规请求；
2. MQTT 用于智能家居外网设备控制和状态推送（订阅 Topic）；
3. TCP Socket 仅内网模式直接连家里主机 8888 端口；
4. WebSocket 两条：一条自家后端推云对讲通知，一条思悦服务器做 WebRTC 信令；
5. WebRTC 跑思悦对讲的音视频。

杀进程兜底用阿里云 Push，系统级通道，App 死了也能收到门口机呼叫。

选型理由：MQTT 天然一对多 + QoS 适合 IoT；WebRTC P2P 传音视频延迟低、服务器压力小；HTTP 简单请求-响应足够；TCP Socket 是内网直连主机的特殊场景。」

6. 何时选哪个？（决策树速查）

高频实时 + 一对多 + Topic 路由 + IoT 设备   → MQTT
高频实时 + 一对一 + 简单消息（聊天/通知）   → WebSocket
高频实时 + 音视频 + P2P                     → WebRTC（+ WebSocket 当信令）
低频 + 请求-响应（拉数据/配置）             → HTTP
原始字节流 + 内网直连特殊场景               → TCP Socket
系统级通知 + 杀进程可达                     → 阿里云 Push / APNs / 厂商通道

7. 思悦 vs 海康 对讲对照（常被问）

一、一句话总结（必背）

项目使用一览（同项目里必然用到的几种）：

二、6 种协议功能对照表

三、三组对照（必背）

对照 1：MQTT vs WebSocket（最常考）

💡 关键区别：MQTT 天然一对多（一个 Topic 可多个订阅者），WebSocket 天然一对一（客户端 ↔ 服务器）。
群聊实现：所有客户端都连同一个 WebSocket 服务器，服务器负责把 A 的消息转发给 B、C。WebSocket 自己不直接多对多。

口诀：

MQTT 是"广播站"（一对多，订阅 Topic 收消息），WebSocket 是"专线电话"（一对一到服务器）。

项目里实际使用对比：

对照 2：HTTP vs WebSocket（最常问）

口诀：

HTTP 是"一问一答、断一次"（发请求、收响应、断开），WebSocket 是"专线、双向、不断"（连上一次保持开着，客户端 ↔ 服务器）。

项目实际使用：

• HTTP → REST API（登录、拿设备列表、开门接口）
• WebSocket → 实时通知（云对讲来电）

💡 群聊怎么实现？ 多客户端通过同一个服务器互相转发消息，每个客户端和服务器都是 WebSocket（一对一的专线），服务器帮客户端之间传话。WebSocket 本身不直接多对多。

对照 3：WebRTC vs WebSocket（音视频专题）

WebRTC 必须配 WebSocket 当信令通道！

WebRTC 必须配 WebSocket 当信令通道（可视化）

项目里实际使用对比：

口诀：

WebRTC 是"两台手机 P2P 直连传音视频"，WebSocket 是"两台手机通过服务器中转传信令"。

项目实际使用：

• 思悦对讲：WebRTC 做音视频（P2P）+ 另一个 WebSocket 当信令（通过服务器中转）
• 海康对讲：用海康私有协议（不走 WebRTC）

四、3 个"特殊"的协议

4.1 TCP Socket（最基础）

TCP 是什么？ 传输层"可靠管道"协议。HTTP/MQTT/WebSocket 都跑在它上面。

• 可靠：丢包会自动重传、按顺序到达、不重复
• 字节流：传的是任意字节，没有消息边界
• 管道：应用层协议（HTTP/WS/MQTT）跑在它上面

⚠️ 注意：TCP 是"底层管道"，不是"另一种通信方式"。写代码时几乎不直接用 TCP，而是用 HTTP/WebSocket/MQTT。只有内网直连主机这种特殊场景才直接用 TCP Socket。

项目实际使用：

• 入口：仅在用户主动进入「内网」Tab 时建链，IP 来自 redux 的 intranetIp
• App 端：直连家里主机的 8888 端口（TcpSocket.createConnection({port:8888, host:intranetIp})）
• iOS 专属：用 NetworkInfo.getIPAddress() 拿本机 IP 作为 localAddress，避免多网卡选错出口
• 自定义协议：JSON 对象 + && 作为多帧分隔符（主机主动推送设备状态）
• 半包处理：代码里维护 lastData 变量拼接跨包数据（这一点面试很加分）
• 代码位置：src/pages/Intranet/index.js createSocket()

4.2 WebRTC（音视频专属）

3 大核心 API：

• MediaStream：拿摄像头/麦克风
• RTCPeerConnection：建立 P2P 连接（处理 NAT 穿透）
• RTCDataChannel：P2P 数据传输

WebRTC 走的是什么通道？

💡 重要：WebRTC 的媒体流默认走 UDP，因为音视频实时性强、丢包比延迟好。
但 WebRTC 不是「完全不用 TCP」——DTLS 握手、DataChannel 等控制面会走可靠通道，ICE 候选里也有 tcp 类型。面试说「媒体走 UDP P2P」就够稳。

音视频能力可视化：

项目实际使用：

• 思悦对讲：业主 App 端 getUserMedia({video: false, audio: true})
  • 业主只发音频，不露脸
  • 业主通过 <RTCView> 看门口画面
• 代码位置：src/pages/CloudTalk/SiruisCloudCall.js getLocalStream()

4.3 阿里云 Push（系统级通知）

是什么？ 阿里云提供的系统级推送服务，底层用 MQTT，但提供：

• 系统通知栏显示
• APNs（iOS）+ 厂商通道（Android 华为/小米/OPPO/vivo）
• 离线消息保留 3-7 天

架构图：

项目实际使用：

• 云对讲：业主 App 杀进程时也能收到门口机呼叫通知
• 智能家居：不使用（设备状态用 MQTT 即可）

为什么必须用它？

• App 死了 → MQTT 连接断了 → 收不到任何推送
• 只有系统级推送（APNs/厂商通道）能在 App 死后送达

五、本项目用了哪几种？

各业务对应的协议 + 代码位置：

六、口诀速记（面试脱口而出）

口诀 1：3 个易混对比

MQTT vs WebSocket → "广播站 vs 专线电话"
HTTP vs WebSocket → "一问一答、断线 vs 长连、双向"
WebRTC vs WebSocket → "P2P 直连 vs 服务器中转"

口诀 2：何时用哪个？

高频实时 + 一对多 + Topic 路由 → MQTT
高频实时 + 一对一 + 简单消息 → WebSocket
高频实时 + 音视频 + P2P → WebRTC
低频静态 + 请求-响应 → HTTP
原始字节流 + 自定义 → TCP Socket
系统级通知 + 杀进程可达 → 阿里云 Push / APNs / 厂商通道

口诀 3：项目里各业务用什么

智能家居 → MQTT（云端）+ TCP Socket（家里）
云对讲通知 → WebSocket（自家后端）
云对讲兜底 → 阿里云 Push
云对讲通话 → 海康 SDK / WebRTC + WebSocket 信令
通用 API → HTTP

口诀 4：5 个协议层级记忆

HTTP/1.1 应用层
WebSocket 应用层（基于 HTTP 升级）
MQTT 应用层（基于 TCP）
WebRTC 应用层（基于 UDP）
TCP 传输层（所有协议的管道）

七、面试常见问题速答

Q1：WebSocket 和 Socket 的区别？

• Socket 是编程接口（API），不是协议
• WebSocket 是协议（基于 TCP）
• 我们用的 react-native-tcpSocket 是用 Socket API 实现 TCP 连接

Q2：MQTT 为什么适合 IoT？

• 头部小（2 字节），适合低带宽
• Pub/Sub 模式天然支持一对多
• QoS 保证消息到达
• Topic 路由天然支持隔离
• 离线消息保留

Q3：WebRTC 必须配 WebSocket 当信令？

✅ 是的。WebRTC 自己不带信令通道，SDP/ICE 候选交换必须用 WebSocket / Socket / HTTP 等其他通道。

Q4：阿里云 Push 和 MQTT 都是推送，区别？

• 阿里云 Push = 系统级（杀进程可达，走 APNs / 厂商通道）
• MQTT = 应用层（App 死了就断了）
• 阿里云 Push 在 Android 上确实用「类 MQTT 的自建长连接」，但不是直接复用业务的 MQTT Broker（业务 MQTT 是 post-cn-45909szlj0u.mqtt.aliyuncs.com，推送通道是另一套），主要靠厂商系统通道送达

Q5：HTTP 轮询 vs WebSocket vs MQTT 选哪个？

Q6：MQTT 和 Kafka 的区别？

• MQTT = 物联网消息协议（轻量，IoT 设备用）
• Kafka = 分布式消息队列（重型，服务端日志流处理用）
• 完全不同的应用场景

Q7：智能家居为什么用 MQTT 不用 HTTP？

• 设备状态高频变化，HTTP 轮询效率低
• MQTT Topic 天然支持一对多（一个设备状态推送给所有订阅者）
• QoS 保证消息到达
• 头部小，IoT 设备带宽友好

七点五、TCP/IP 5 层架构（谁跑在谁上面）

很多人搞不清"谁跑在谁上面"，用这张 5 层架构图一图讲清楚：

5 层模型记忆口诀：

┌─────────────────────────────────────────────────────────────┐
│  应用层    ← 程序员写代码的地方（HTTP/WS/MQTT/WebRTC） │
│  传输层    ← TCP（可靠）/ UDP（快）                   │
│  网络层    ← IP 协议（IP 地址寻址）                  │
│  数据链路层 ← 以太网、Wi-Fi、4G/5G                  │
│  物理层    ← 网线、光纤、无线电波                  │
└─────────────────────────────────────────────────────────────┘

关键 3 点：

1. 每层只关心自己的事：上层"看不见"下层细节（HTTP 不需要懂 TCP 怎么重传）
2. 每层给上层提供服务：TCP 给 HTTP 提供"可靠字节流"服务
3. 协议依赖关系是单向的：应用层协议（HTTP）依赖传输层（TCP），TCP 依赖网络层（IP），IP 依赖链路层

本项目用到的协议分别在哪一层：

八、一张图速查

记住这张图的 3 个要点：

1. 应用层有 5 种协议（HTTP / WebSocket / MQTT / WebRTC / 阿里云 Push）
2. 传输层有 1 种主力 + 1 种辅助（TCP Socket + UDP）
3. 大多数协议都跑在 TCP 上（WebRTC 例外，走 UDP）

九、一句话总结

口诀：

选哪个？看场景！

面试前 5 分钟过一遍：看这张图就能脱口而出所有对比。
面试时背 3 个口诀：

1. "MQTT 广播站一对多，WebSocket 专线电话一对一"
2. "WebRTC P2P 直连传音视频，WebSocket 服务器中转传信令"
3. "HTTP 一问一答断开，WebSocket 长连双向"