| 层号 | 中文名称 | 英文名称 | 关键职能（一句话） | 代表协议 / 技术 | 生活化比喻 | | --- | ---------- | ------------ | ----------------- | ----------------------------- | ---------------- | | 7 | 应用层 | Application | 面向终端用户提供具体网络应用 | HTTP/HTTPS、FTP、SMTP、DNS、MQTT… | 手机 App / 网页 | | 6 | 表示层 | Presentation | 数据格式转换、压缩、加密/解密 | JPEG、MP3、JSON、TLS 加解密… | 字幕翻译员 | | 5 | 会话层 | Session | 建立、管理、终止会话，保持对话状态 | TLS 握手、RPC 会话控制… | “嘟…嘟…—通话—挂断” | | 4 | 传输层 | Transport | 端到端可靠或高效传输、端口寻址 | TCP、UDP、QUIC | 是否保价 / 签收 | | 3 | 网络层（路由器） | Network | 跨网段寻址与路由选择 | IP、ICMP、OSPF、BGP | 选公路/铁路/空运把包裹送到城市 | | 2 | 数据链路层（交换机） | Data Link | 成帧、MAC 地址、差错检测 | 以太网、PPP、802.11 MAC | 物流园分拣输送带 | | 1 | 物理层 | Physical | 定义电/光信号及传输介质 | 双绞线、光纤、Wi-Fi 射频… | 修公路、铺轨道 | > **记忆口诀**：修路→分拣→选路→保价/签收→接通电话→翻译字幕→用 App。 下面这张 **Markdown 对比表** 从常见开发/运维关注点切入，帮你快速看出 **SSE、WebSocket、gRPC** 三种实时通信技术的差异： |对比维度|SSE（Server-Sent Events）|WebSocket|gRPC (gRPC-HTTP/2)| |---|---|---|---| |**协议栈定位**|应用层，基于 **HTTP/1.1** 的长连接|应用层，先 **HTTP/1.1 Upgrade**，随后自有帧格式|应用层 RPC 框架，默认 **HTTP/2**（可选 HTTP/3）| |**消息方向**|**单向**：服务器 ➜ 浏览器|**双向全双工**|**双向流**；支持单次请求、服务器流、客户端流、双向流四种模式| |**浏览器原生支持**|`EventSource` 接口，几乎所有现代浏览器支持|`WebSocket` 接口，全面支持|需要 **gRPC-Web** 或 Fetch/Protobuf 手动封装；原生支持有限| |**数据编码**|文本流（`text/event-stream`），字段简单|文本或二进制帧，自由度高|默认 **Protocol Buffers**；也可自定义编解码| |**多路复用**|无（1 连接 = 1 订阅流）|无（1 连接 Carry 全流量）|**HTTP/2**/3 自带多路复用，单 TCP 可并发多 RPC| |**保持 & 心跳**|浏览器自动重连；可自定义 retry|`ping/pong` 控制帧；需手动实现重连策略|HTTP/2 keep-alive；gRPC 内置健康探测 & Keepalive| |**对代理/防火墙友好度**|高：纯 HTTP GET，端口 80/443|中：升级握手后非 HTTP，个别代理需放行|高：仍是 HTTP/2/3 流量，CDN & 代理天然兼容| |**负载均衡要求**|建议 **粘性会话**（长连接）|建议 **粘性会话**|通常无需粘性；HTTP/2 流可被 LB 平滑分配| |**典型场景**|新闻/报价实时推送、日志流、简单仪表盘|聊天/游戏、协作编辑、低延迟互动|微服务内部 RPC、移动/IoT 后端、高性能双向流| |**实现门槛**|HTML5 特性，服务端输出符合格式即可|需握手+帧编解码；库生态成熟|需定义 `.proto`、生成 Stub；更偏后端工程| |**带宽/开销**|最低：文本包头极小|适中：自定义帧，少量协议开销|高效：二进制 Protobuf + HPACK 压缩，但头部更复杂| > **速记** > > - **SSE**：轻量“服务器→浏览器”单向推送，HTTP 友好。 > > - **WebSocket**：全双工、低延迟、浏览器原生，需自己管理协议细节。 > > - **gRPC**：基于 HTTP/2 的高性能 RPC 框架，强类型、流式、多语言，偏服务间通信。