企业官网建设流程全解析

新人最容易有的一个误解是：“协议只有 HTTP 和 WebSocket”。实际上，一个现代互联网后台里同时跑着十几种协议，只是它们各自负责不同的层、不同的场景，平时被框架封装起来了，不直接感知。

一、协议分层与全局速览

1.1 先建立一个分层认知

协议不是平级的，而是分层协作的。一个请求从浏览器到后端，往往经过好几层协议：

应用层：HTTP / WebSocket / WebRTC / gRPC / SSE / MQTT / DNS... 传输层：TCP / UDP / QUIC 网络层：IP 链路层：以太网 / Wi-Fi

• 应用层协议决定"消息长什么样、怎么交互"，是后端开发最常打交道的

• 传输层协议决定"数据怎么在网络上端到端传输"

• 上层协议可以建立在不同的下层协议之上，比如 HTTP/3 就建在 QUIC（UDP）之上

理解这一点，后面看具体协议就不会混淆。

1.2 全局速览表

二、应用层协议速览

应用层是后端开发打交道最多的层，下面逐个说清楚特点和使用场景。

2.1 HTTP / HTTPS —— 互联网的通用语言

特点：请求-响应模型，无状态，语义清晰（GET/POST/PUT/DELETE），可缓存、可幂等，基础设施全面支持。

场景：网页加载、API 接口、文件上传下载、几乎所有"查询 + 提交"类交互。

版本演进值得知道：

HTTPS 就是 HTTP + TLS，安全性由 TLS 提供。现在几乎所有网站都是 HTTPS。

Webhook：基于 HTTP 的反向 API / 事件回调模式，不是独立传输协议

2.2 WebSocket / WSS —— 双向实时通信

特点：全双工，长连接，服务端可主动推送，帧头只有 2-14 字节，适合高频小消息。

场景：协同文档、聊天、实时通知、在线游戏、金融行情。

和 HTTP 的关系：握手时借用 HTTP 的 Upgrade 机制，握手成功后升级为独立的帧协议。wss://走的是 TLS，安全性等同 HTTPS。

2.3 SSE（Server-Sent Events）—— 轻量单向推送

特点：基于 HTTP 的单向服务端推送，服务端可以持续往客户端发消息，但客户端不能反向推。协议简单，浏览器原生支持EventSource。

场景：消息通知、日志流、进度推送、股票价格刷新。

和 WebSocket 的区别：SSE 是单向（服务器→客户端），WebSocket 是双向。如果只需要服务端推、客户端不需要频繁发，SSE 比 WebSocket 更轻。

2.4 gRPC —— 微服务之间的高效通信

特点：基于 HTTP/2，使用 Protocol Buffers 序列化，支持四种通信模式（一元、服务端流、客户端流、双向流），性能高、强类型、跨语言。

场景：微服务之间的内部调用、需要高性能和强类型的 RPC 场景。

和 REST 的区别：REST 用 JSON + HTTP 语义，偏"资源"；gRPC 用 Protobuf + HTTP/2，偏"方法调用"，性能更好但可读性差、调试不如 REST 方便。对外 API 常用 REST，内部服务间常用 gRPC。

2.5 GraphQL —— 按需取数据的查询语言

严格说它不是传输协议，而是查询语言 + 运行时，通常跑在 HTTP 之上。

特点：客户端可以精确指定要哪些字段，避免 over-fetching（取多了）和 under-fetching（取少了）。

场景：前端数据需求多变、移动端流量敏感的场景。

2.6 MQTT —— 物联网的轻量协议

特点：基于发布-订阅模型，协议极轻量，适合低带宽、不稳定网络、大量设备连接。

场景：IoT 设备、车联网、智能家居。

2.7 AMQP / STOMP —— 消息队列协议

特点：面向消息中间件的协议，支持可靠投递、事务、路由。

场景：RabbitMQ 用 AMQP，后端异步任务、解耦、削峰。

（Kafka 有自己的二进制协议，不基于 AMQP。）

2.8 DNS —— 把域名翻译成 IP

特点：分布式、层级化的命名系统，通常走 UDP（53 端口），大响应或区域传送走 TCP。

场景：所有网络请求的第一步——把www.example.com解析成 IP。后端会用到 DNS 做服务发现、负载均衡。

2.9 FTP / SFTP / SCP —— 文件传输

特点：三者都是为文件传输设计的协议，但底层机制和安全模型不同。FTP 基于 TCP，采用双连接（控制 + 数据），明文传输，有主动/被动两种模式；SFTP 不是 FTP 的加密版，而是完全独立的协议，跑在 SSH（22 端口）之上，全程加密，单连接，支持断点续传和目录操作；SCP 同样基于 SSH，但只支持纯文件复制，不支持目录列表和续传，命令更轻量。OpenSSH 9.0 之后 SCP 底层已改用 SFTP 协议实现。

场景：运维部署、CI/CD 传构建产物、跨服务器传文件、一次性快速拷贝。公网面向用户的文件传输现在多数被 HTTP 上传下载或对象存储（S3 协议）替代，但需要登录服务器直接操作文件系统的运维场景，SFTP/SCP 仍不可替代。

2.10 拓展：这些常见名词不是协议

新人容易把下面这些名词也当成“协议”，其实它们要么是技术集合、要么是架构模式、要么是框架。单独列出来，避免混淆。

WebRTC 之所以不是单一协议，是因为它包含这些子协议：

这些子协议负责“怎么连、怎么加密、怎么传媒体”，但它们不负责“双方怎么找到对方、怎么交换这些参数”。这件事叫信令。

信令需要一条双向、实时、长连接的通道。WebSocket 正好满足：全双工、长连接、轻量。所以典型做法是：

• WebSocket 做信令：交换 SDP、ICE 候选地址，以及呼叫/接听/挂断等控制消息。

• WebRTC 做媒体：协商成功后，音视频数据走 WebRTC 的 P2P 通道（UDP + DTLS-SRTP），不再经过 WebSocket。

三、传输层协议速览

应用层协议的"底座"通常就是这三种，理解它们的区别，比记协议名更重要。

3.1 TCP —— 可靠的字节流

特点：面向连接、可靠、有序、有流量控制和拥塞控制。三次握手建连，四次挥手断连。

场景：HTTP/1.1、HTTP/2、WebSocket、gRPC、数据库连接、SSH……绝大多数要求可靠传输的场景。

3.2 UDP —— 不可靠的数据报

特点：无连接、不保证顺序、不保证到达，但延迟低、开销小。

场景：实时音视频、在线游戏、DNS 查询、直播。

关键认知：UDP 不是"差"，而是"把可靠性交给上层决定"。需要低延迟时，宁可丢一帧也不要卡顿，就用 UDP。

3.3 QUIC —— 下一代传输协议

特点：基于 UDP，但自己实现了可靠传输、多路复用、0-RTT 建连、连接迁移。是 HTTP/3 的底层。

场景：HTTP/3、部分 gRPC 场景、移动网络优化。

关键点：为什么用 UDP 而不是 TCP：因为 TCP 的队头阻塞无法在用户态解决，QUIC 直接在 UDP 上重建一套更灵活的传输机制。

TCP 给上层提供的是一个可靠、有序的字节流。为了做到"有序"，它必须保证：前面的字节没到齐，后面的字节就不能交给应用层。

假设你发了三个 TCP 段：

段1：字节0-999 段2：字节1000-1999 ← 丢了 段3：字节2000-2999

段 2 丢了，段 3 即使已经到了，内核也必须扣住不交给应用，等段 2 重传成功，才能按序把 0-2999 一起交付。这就是队头阻塞（Head-of-Line Blocking，HOL Blocking）：一个包的丢失，阻塞了它后面所有已到达的数据。

并且在应用层面无法解决TCP队头阻塞。因为TCP 是操作系统内核实现的，不是用户态代码。

┌─────────────────────────────┐ │ 你的应用（用户态） │ ← 只能看到内核交付的字节流 ├─────────────────────────────┤ │ TCP 协议栈（内核态） │ ← 排序、重传、拥塞控制都在这里 ├─────────────────────────────┤ │ IP 层（内核态） │ └─────────────────────────────┘

四、选型建议与常见误区

4.1 按场景选协议：一张速查表

4.2 几个容易混淆的点

① HTTP 和 WebSocket 不是替代关系

HTTP 管"请求-响应"，WebSocket 管"双向实时"。单个功能或数据通道，通常二选一；但一个完整的业务系统，几乎总是 HTTP 和 WebSocket 并存——HTTP 负责请求-响应式的查询、提交、资源加载，WebSocket 负责实时协同、聊天、推送。二者不是替代关系，而是按场景分工。

② gRPC 不是"更好的 REST"

gRPC 强在性能、强类型、流式；REST 强在通用、可读、易调试。对外 API 用 REST，内部服务用 gRPC，是常见组合。

③ SSE 和 WebSocket 都能推送，怎么选

只需服务端推（客户端不频繁发）→ SSE；需要双向、高频 → WebSocket。

④ TCP 和 UDP 不是"好"和"坏"

TCP 保证可靠但延迟高，UDP 不保证可靠但延迟低。选哪个取决于业务是"可靠优先"还是"延迟优先"。

⑤ HTTPS 和 WSS 的安全性一样

都是 HTTP/WebSocket + TLS，加密强度没有区别。

⑥ 大多数网站为什么不用 WebSocket 而用 HTTP
不是因为 WebSocket 不安全（wss://同样走 TLS），而是因为大多数交互是请求-响应式的，HTTP 更匹配、更轻、基础设施支持更好。只有实时协同、聊天、推送这类场景才需要 WebSocket。

4.3 学习路径建议

不用一上来就全都学，按这个顺序即可：

1. 先吃透 HTTP/HTTPS：这是 90% 后端工作的基础

2. 再理解 TCP/UDP 的区别：搞懂"可靠 vs 低延迟"的取舍

3. 按需学 WebSocket：做实时功能时再深入

4. 微服务阶段学 gRPC：服务间通信用得上

5. 其余按场景补：MQTT、AMQP、SSE 用到再学

4.4 一句话总结

HTTP 是互联网的通用语言，WebSocket 是实时协同的双向通道，gRPC 是微服务的高效 RPC，SSE 是轻量单向推送，MQTT 是物联网的轻量协议，AMQP 是消息队列协议；TCP 保证可靠，UDP 追求低延迟，QUIC 是下一代传输。协议选型看的是场景，不是先进程度。