企业官网建设流程全解析

一，各种协议的简单介绍

1.TCP （传输层）

① TCP 是互联网最基础的面向连接，可靠，有序的传输层协议。
② 通信前必须经过三次握手建立连接，通信完成后四次挥手释放连接。
③ 内置确认应答，超时重传，拥塞控制，流量控制机制，保证数据无丢失，无重复，按序到达。
④ 缺点：握手开销大，协议头部重，且存在 TCP 层队头阻塞问题，单流丢包后会阻塞后续所有的数据传输。
⑤ 是 HTTP，MQTT 等绝大多数应用层协议的底层承载协议，适用于文件传输，指令交互，日志上报等对可靠性要求较高的场景。
⑥ TCP 是操作系统内核态协议栈，经过多年高度优化，CPU，内存开销低，适合超高并发。

2. UDP（传输层）

① UDP 是无连接，不可靠，极简高效的传输层协议。
② 无需握手，无需维持连接状态，头部开销极小，转发延迟极低。
③ 不提供重传，排序，拥塞控制机制，数据发出去就结束，无法保证送达与顺序。
④极致轻量化，广泛用于实时性优先，可容忍少量丢包的场景，如：直播，实时游戏，语音视频。
⑤ 是 QUIC，CoAP 等新一代轻量化协议的底层载体，是高速自定义传输的基础。

3.QUIC（传输层，基于UDP）

① QUIC 是已经标准化的新一代低延迟可靠传输协议，全程基于 UDP 实现，完美结合 TCP 的可靠性和 UDP 的高效性，
② 优势：支持0-RTT/1-RTT 快速握手，内置TSL1.3 加密，彻底解决 TCP 对头阻塞，支持连接迁移（网络切换不中断连接）。
③ 通过独立流多路复用机制，单条数据流丢包不会影响其他数据流，大幅提升弱网，移动网络下的传输稳定性，是 HTTP3 的唯一底层传输协议。
④ QUIC 大多为用户态协议栈，协议处理逻辑跑在应用进程内；报文解析重传，拥塞控制都占用应用 CPU ，相比内核 TCP，CPU于内存开销更高，高并发下服务器压力更大。
⑤ 虽然现代优化后的 QUIC 库差距在缩小，但相比内核 TCP，资源消耗依旧是短板。

4.HTTP/1.1（应用层）

① HTTP/1.1 是经典的 Web 应用层协议，基于 TCP 传输，采用文本格式，请求响应模式。
② 相比 1.0 新增持久连接（keep-alive 保活机制），缓存优化，管道化请求等特性，大幅提升网页传输效率。
③ 短板：不支持真正多路复用，同一时间同一连接只能处理一个请求，存在严重的应用层对头阻塞，高并发场景性能瓶颈明显。
④ 目前仍是传统网页，接口服务的基础兼容协议。

5.HTTP/2（应用层）

① HTTP/2 在 HTTP/1.1 基础上做了大幅优化，底层仍基于 TCP ，核心改革是二进制帧传输 + 单连接多路复用 + 头部压缩 + 服务端推送。
将文本报文改为二进制帧，解析效率更高；
单 TCP 连接可并行处理多个请求，极大减少连接建立开销。
② 受限于底层 TCP 特性，依然存在传输层对头阻塞，无法彻底解决弱网，高延迟场景的性能问题，是过渡性的高性能 Web 协议。
③ HTTP/2 就是专门用于Web 网页访问场景的传输协议。

6.HTTP/3（应用层）

① HTTP/3 是最新一代 Web 协议，完全摒弃 TCP，基于QUIC 协议构建，保留了 HTTP 语义的同时彻底解决历代 HTTP 协议的核心痛点。
② 继承 HTTP/2 的二进制帧，头部压缩的优势，依托 QUIC 实现无队头阻塞，急速握手，网络无感切换，全程加密。
③ 在移动端，弱网，高并发场景下传输速度，稳定性远超 HTTP1.1/2，是目前互联网大厂主流迭代升级的 Web 协议。

7.MQTT（物联网应用层）

① MQTT 是专为物联网低带宽，弱网，低算力设备设计的轻量级应用层协议，基于TCP 传输，采用发布/订阅架构，区别于 HTTP 的请求响应模式。
② 协议报文头部极小，资源占用极低，适配单片机，嵌入式设备等资源受限场景。
③ 核心特色是三级 QoS 服务质量机制，可灵活适配**“无需确认，必达一次，仅达一次”的各类设备上报场景，是智能家居**，工业物联网，设备云端通信的主流标准协议。

二，核心协议全方位表格对比

三，高频面试题总结

3.1 HTTP/2 已经实现了多路复用，为什么还要升级 HTTP/3？

HTTP/2 的多路复用只是应用层优化，底层依然依赖TCP协议，无法规避TCP的传输层队头阻塞问题。单TCP连接中任意一个数据包丢失，所有并行请求都会被阻塞。而 HTTP/3 基于QUIC协议，通过独立流隔离机制彻底解决队头阻塞，同时支持0-RTT快速建连、网络连接迁移，在弱网、移动端场景性能提升巨大。

3.2 QUIC 基于UDP实现，为什么能做到可靠传输？

UDP只是QUIC的底层承载载体，QUIC在应用层自研了一整套可靠传输机制，包含报文序号、ACK应答、超时重传、拥塞控制、流量控制、数据重组等核心逻辑，本质是跑在UDP之上的新型可靠传输协议，兼顾了UDP的低延迟和TCP的高可靠性。

3.3 物联网设备通信为什么普遍用MQTT，不用HTTP？

第一，MQTT报文头部极小，开销远低于HTTP，适配物联网窄带弱网环境；第二，MQTT基于TCP长连接+心跳保活，支持服务端主动推送消息，无需设备轮询，功耗更低、实时性更强；第三，MQTT具备三级QoS机制，可适配不同数据的可靠传输需求，而HTTP无专属可靠级别配置，设计逻辑完全不适配低功耗嵌入式设备。

3.4 TCP 为什么不适合实时音视频、游戏场景？

TCP核心是保证数据绝对可靠、有序传输，内置超时重传、队头阻塞机制。网络轻微抖动丢包时，TCP会持续重传丢失报文，造成延迟不断堆积，引发画面卡顿、操作滞后、音画不同步等问题。而实时场景优先保证流畅性，可容忍少量丢包，因此必须使用无重传、无阻塞的UDP协议。

3.5 QUIC 有什么短板？为什么没有全面替代TCP？

QUIC算法复杂、代码实现难度高、算力和内存开销更大，无法运行在单片机等资源极度受限的嵌入式设备；同时TCP部署成熟、兼容性全覆盖、生态完善，绝大多数稳定业务无需替换。因此QUIC仅在移动端、外网弱网、高并发Web场景做升级优化，无法全面替代TCP。

3.6 MQTT的QoS0/QoS1/QoS2 核心区别是什么？

QoS0（至多一次）：消息只发送一次，无确认、无重传，适合高频、可丢失的非关键数据；QoS1（至少一次）：保证消息一定送达，可能重复接收，适合大部分常规设备上报数据；QoS2（恰好一次）：通过四次握手保证消息唯一送达、无丢失无重复，逻辑复杂、开销最高，适合设备指令、充值告警等关键数据。

3.7 什么是连接迁移？QUIC如何实现？

连接迁移是指设备网络切换（WiFi/4G切换）时，连接不中断、业务不重启的能力。TCP连接依赖IP+端口四元组，网络切换后四元组改变，连接直接断开；QUIC通过唯一的全局连接ID标识连接，不绑定网络地址，网络切换后只要连接ID不变，即可延续原有连接，实现无感切换。