从协议本质、工作原理、特点、应用场景等方面详细对比 TCP、HTTP、MQTT 和 WebSocket。
1. TCP（Transmission Control Protocol，传输控制协议）
本质
- 协议类型：传输层协议（OSI模型第4层）。
- 核心功能：提供可靠的、面向连接的、全双工的字节流传输服务。
- 作用：确保数据在不可靠的网络中可靠传输，是互联网通信的基础。
工作原理
- 三次握手建立连接：
- 客户端发送
SYN包。 - 服务端回复
SYN-ACK包。 - 客户端发送
ACK包，连接建立。
- 客户端发送
- 四次挥手断开连接：通过
FIN和ACK包协商关闭连接。 - 流量控制与拥塞控制：通过滑动窗口、慢启动等机制优化传输效率。
- 数据校验：通过校验和（Checksum）确保数据完整性。
特点
- 可靠传输：通过重传机制保证数据不丢失、不重复、有序到达。
- 面向连接：通信前需建立连接，通信后释放连接。
- 全双工：双方可同时发送和接收数据。
- 无状态：仅关注数据传输，不关心应用层协议的具体内容。
应用场景
- 所有需要可靠传输的场景，如文件传输（FTP）、电子邮件（SMTP）、HTTP 等。
2. HTTP（Hypertext Transfer Protocol，超文本传输协议）
本质
- 协议类型：应用层协议（OSI模型第7层）。
- 核心功能：客户端-服务器模型下，用于网页、API等资源的请求与响应。
- 依赖：基于 TCP 传输（通常使用 TCP 80 端口，HTTPS 使用 443 端口）。
工作原理
- 请求-响应模式：
- 客户端发送请求（如
GET /index.html HTTP/1.1）。 - 服务端处理请求并返回响应（如
200 OK和 HTML 内容）。
- 客户端发送请求（如
- 无状态：每次请求独立，需通过 Cookie 或 Token 维持会话。
- 版本演进：
- HTTP/1.1：支持长连接（Keep-Alive），减少握手开销。
- HTTP/2：二进制分帧、多路复用，提升性能。
- HTTP/3：基于 QUIC 协议，减少延迟。
特点
- 无状态：每个请求独立，需额外机制维护会话。
- 文本协议：请求和响应内容为文本格式（如 JSON、XML）。
- 单向通信：客户端主动发起请求，服务端被动响应。
- 高延迟：每次请求需建立 TCP 连接（HTTP/1.1 改善，但仍有开销）。
应用场景
- 网页浏览、API 调用、文件下载等。
3. MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议）
本质
- 协议类型：应用层协议（OSI模型第7层）。
- 核心功能：轻量级、低带宽、高可靠的消息发布-订阅模式协议。
- 设计目标：为物联网（IoT）设备提供高效通信，适合资源受限环境。
工作原理
- 发布-订阅模型：
- Broker（消息代理）：中心服务器，管理主题（Topic）和消息路由。
- Publisher（发布者）：向特定主题发布消息。
- Subscriber（订阅者）：订阅感兴趣的主题，接收消息。
- QoS（服务质量等级）：
- QoS 0：最多一次（尽力而为，可能丢失）。
- QoS 1：至少一次（确保到达，可能重复）。
- QoS 2：恰好一次（严格保证不重复、不丢失）。
- 轻量级：固定报文头仅 2 字节（QoS 0 时），文本主题。
特点
- 低带宽、低开销：适合物联网设备（如传感器、嵌入式设备）。
- 异步通信：发布者与订阅者无需同时在线。
- 可靠消息传递：通过 QoS 级别保证消息可靠性。
- 基于 TCP：默认使用 TCP 1883 端口（加密版 MQTT-SN 使用 8883）。
应用场景
- 物联网设备通信（如智能家居、工业监控）、传感器数据采集、移动推送通知。
4. WebSocket
本质
- 协议类型：应用层协议（OSI模型第7层）。
- 核心功能：全双工、实时通信协议，建立在 TCP 之上。
- 设计目标：解决 HTTP 的单向请求-响应模式，实现实时双向通信。
工作原理
- 基于 HTTP 协议升级：
- 客户端通过 HTTP 请求发起 WebSocket 握手（
Upgrade: websocket）。 - 服务端响应
101 Switching Protocols，切换到 WebSocket 协议。
- 客户端通过 HTTP 请求发起 WebSocket 握手（
- 全双工通信：连接建立后，客户端和服务器可随时发送数据帧。
- 数据格式：二进制或文本帧，支持心跳机制（Ping/Pong）保持连接。
特点
- 持久连接：一次握手后长期保持连接，无需重复建立 TCP 连接。
- 双向通信：服务端可主动推送消息到客户端。
- 低延迟：适合实时性要求高的场景。
- 依赖 TCP：默认使用 80/443 端口（与 HTTP 共享）。
应用场景
- 实时聊天、在线游戏、股票行情推送、协同编辑等需要实时交互的场景。
核心区别总结
| 特性 | TCP | HTTP | MQTT | WebSocket |
|---|---|---|---|---|
| 协议类型 | 传输层（第4层） | 应用层（第7层） | 应用层（第7层） | 应用层（第7层） |
| 通信模式 | 全双工字节流 | 请求-响应（单向） | 发布-订阅（异步） | 全双工（双向） |
| 连接方式 | 面向连接（需握手） | 无连接（HTTP/1.1 支持长连接） | 面向连接（通过 Broker） | 面向连接（持久连接） |
| 可靠性 | 可靠（重传机制） | 可靠（依赖 TCP） | 可靠（QoS 1/2） | 可靠（依赖 TCP） |
| 带宽/开销 | 较低（基础传输层） | 较高（文本协议） | 极低（二进制+轻量） | 中等（二进制帧） |
| 实时性 | 一般（需应用层优化） | 较差（需轮询或长轮询） | 较好（异步推送） | 极佳（全双工） |
| 典型端口 | 80（HTTP）、443（HTTPS） | 80（HTTP）、443（HTTPS） | 1883（MQTT）、8883（MQTT-SN） | 80（WebSocket）、443（WSS） |
| 适用场景 | 所有可靠传输场景 | Web 请求响应 | 物联网、低带宽设备 | 实时双向通信 |
关键区别对比
协议层级
- TCP 是传输层协议，负责底层数据传输；
- HTTP/MQTT/WebSocket 是应用层协议，依赖 TCP 提供可靠传输。
通信模式
- HTTP 是单向请求-响应模式，客户端主动发起；
- MQTT 是异步的发布-订阅模式，通过 Broker 中转；
- WebSocket 是全双工模式，服务端可主动推送。
实时性
- HTTP 需轮询或长轮询（如 SSE）实现近实时，开销大；
- MQTT 和 WebSocket 支持实时推送，延迟更低。
带宽与资源
- MQTT 是最轻量的，适合物联网设备；
- WebSocket 比 HTTP 更高效，但比 MQTT 复杂；
- HTTP 文本协议开销较大。
连接管理
- TCP 需显式建立和关闭连接；
- HTTP 短连接（HTTP/1.1 支持长连接）；
- MQTT/WebSocket 保持持久连接。
选择建议
- 需要可靠传输但无特定应用需求 → TCP
- 网页浏览、API 调用 → HTTP/HTTP/2/HTTP/3
- 物联网设备通信、低带宽环境 → MQTT
- 实时双向通信（如聊天、游戏） → WebSocket