02. 网络进阶：重传、拥塞控制、长连接、WebSocket（深挖版）¶
如果说上一章更偏"网络基础面试必答题"，这一章更像二面三面常见的追问区：
- TCP 丢包后到底怎么重传？
- 拥塞控制和流量控制到底差在哪？
- 长连接是不是只有好处没有代价？
- HTTP/2 已经多路复用了，为什么还会卡？
- WebSocket 和 HTTP、TCP 各是什么关系？
这些问题最怕答成术语堆砌。真正有说服力的回答，应该能把"机制、触发条件、收益、代价"串起来。
本章建议按“先理解知识主线，再练问答表达，最后吃透边界条件”的顺序阅读：
- 先把TCP 重传机制、拥塞控制、慢启动
- 再展开长连接/短连接、HTTP 版本差异、队头阻塞、WebSocket
- 最后把HTTP/2 多路复用原理、QUIC/HTTP/3、长连接工程判断
先把这一章的知识骨架搭起来¶
这章是在前一章基础上继续追问：连接建立之后，数据在不稳定网络中究竟怎样被重传、限速、复用和长期维护。所以重传、流量控制、拥塞控制、长连接、HTTP/2、WebSocket 看似跨越 TCP 和 HTTP，实际上都在围绕“高效又稳定地传输数据”展开。
读这章时，可以先把问题分成三类：第一类是“包丢了怎么办”，对应超时重传、快速重传、滑动窗口；第二类是“网络和接收方承受不了怎么办”，对应拥塞控制与流量控制；第三类是“连接要长期复用怎么办”，对应 keep-alive、HTTP/2 多路复用、WebSocket 持久双向通信。
这样你既能答网络机制，也能落到服务性能与用户体验。
第一部分：先把概念和主线讲清楚¶
进入问答前，先把最小前置知识补齐¶
这一章是在前一章基础上继续深挖“连接建立以后，数据如何稳定高效地传”。因此要先把三个问题分清：包丢了怎么办、接收方或网络扛不住怎么办、连接要长时间复用怎么办。
超时重传和快速重传回答的是“数据丢了怎么办”；滑动窗口和流量控制回答的是“接收方处理不过来怎么办”；拥塞控制回答的是“整个网络扛不住怎么办”；长连接、HTTP/2 多路复用和 WebSocket 则在处理“同一条连接如何反复复用”。
把这三层看清楚，后面的细节才不容易混。
1. TCP 重传机制有哪些？¶
标准回答¶
常见包括：
- 超时重传（RTO）
- 快速重传（收到多个重复 ACK 时触发）
更深入的理解¶
TCP 不可能假设网络永不丢包，所以它必须在"包可能丢、ACK 可能丢、时延可能抖动"的情况下，尽量恢复可靠传输。
重传的核心问题不是"会不会重发"，而是：
- 什么时候判断该重发
- 重发哪一段
- 如何尽量别把网络打得更堵
1.1 超时重传（RTO）¶
如果发送方在一定时间内没有收到 ACK，就会认为对应数据可能丢失，触发重传。
为什么 RTO 不能设死？¶
因为网络 RTT 是动态变化的：
- 太短：容易误判，导致不必要重传
- 太长：恢复太慢，吞吐受影响
所以 RTO 通常会基于历史 RTT 估算动态调整。
1.2 快速重传¶
如果发送方连续收到多个针对同一位置的重复 ACK，通常意味着：
- 后面的数据到了
- 但中间某段丢了
这时不必等 RTO 超时，可以提前重传缺失段。
为什么常说"3 个重复 ACK"？¶
这是经典实现中的经验阈值：
- 太少可能只是乱序
- 达到一定重复次数，丢包概率更大
面试高分点¶
TCP 重传的目标不是"无脑重发"，而是在可靠恢复和避免额外拥塞之间找平衡。RTO 偏保守，快速重传偏激进，两者是互补关系。
2. 什么是拥塞控制？¶
标准回答¶
拥塞控制是 TCP 为防止网络整体过载而采取的一组发送速率调节机制。
为什么它和流量控制不是一回事？¶
- 流量控制：别把接收方打爆
- 拥塞控制：别把网络打爆
流量控制看的是对端接收能力；拥塞控制看的是整条网络路径承载能力。
常见阶段¶
- 慢启动
- 拥塞避免
- 快速重传
- 快速恢复
2.1 慢启动¶
刚开始不知道网络能承受多少数据，所以先小心试探发送速率，然后指数级增长。
为什么叫"慢启动"，但增长其实挺快？¶
"慢"不是指数值增长慢，而是相对于一上来就把链路打满来说，它是逐步探测网络容量。
2.2 拥塞避免¶
当窗口增长到某个阈值后，不再指数增长，而改为更平缓的线性增长。
目的：
- 降低一下子冲爆网络的风险
- 更稳地逼近可用带宽
2.3 快速重传 + 快速恢复¶
当检测到疑似丢包时：
- 不一定退回最小发送窗口重新来
- 而是适度收缩，再继续传
这比"每丢一次就回到原点"更高效。
一句总结¶
拥塞控制本质是在持续探测网络容量：有余量就加速，疑似拥塞就减速。
3. 为什么丢包不一定等于网络差？¶
这是很适合拉开理解深度的追问。
原因¶
丢包可能来自：
- 网络拥塞
- 设备缓存溢出
- 无线链路抖动
- 校验失败
- 路由切换
- 接收端处理不过来
所以：
丢包是现象，不是单一原因。
面试更强表达¶
不要把"发现丢包 → 一定是网络拥塞"说得太绝对。更准确是：
- TCP 往往把丢包当作拥塞信号来处理
- 但现实中丢包成因可能更复杂
第二部分：围绕高频追问继续展开¶
4. 长连接和短连接区别？¶
短连接¶
每次请求都新建连接，用完即断开。
长连接¶
多个请求复用同一连接，减少握手和挥手开销。
长连接为什么重要？¶
因为建连和断连都不是免费的：
- TCP 三次握手、四次挥手有时延
- TLS 握手也有成本
- 频繁创建 socket 会增加系统开销
对于高频请求场景，长连接通常能显著改善：
- 延迟
- 吞吐
- CPU 开销
- 连接管理效率
但长连接不是没有代价¶
它会引入新的问题：
- 空闲连接占资源
- 连接保活与心跳管理
- 服务端 FD 压力
- 负载均衡不再"每请求重新分配"
- 长期连接上的单点抖动更明显
面试高分点¶
长连接的本质是用"连接常驻成本"换"频繁建连成本下降"。是否划算，取决于请求频率、连接规模和服务端资源上限。
5. HTTP/1.1、HTTP/2、HTTP/3 有什么区别？¶
HTTP/1.1¶
- 文本协议
- 默认长连接
- 支持 Keep-Alive 语义
- 存在应用层队头阻塞问题
HTTP/2¶
- 二进制分帧
- 多路复用
- 头部压缩
- 同一 TCP 连接上并发多个流
- 允许服务端推送（但现实使用有限）
HTTP/3¶
- 基于 QUIC（运行在 UDP 上）
- 把连接建立、可靠传输、加密协商做了更紧密整合
- 改善 TCP 层丢包导致的跨流阻塞问题
- 连接迁移更友好
面试最容易说浅的地方¶
很多人只会说：
- 1.1 文本
- 2 多路复用
- 3 基于 UDP
这不够。更强的说法是：
HTTP/2 主要解决应用层并发复用效率问题，但底层仍受 TCP 队头阻塞影响；HTTP/3/QUIC 则进一步把问题下探到传输层，减少单个丢包对整条连接所有流的拖累。
6. 什么是队头阻塞？¶
标准回答¶
队头阻塞指前面的数据包或请求未处理完成，导致后续请求即使准备好了也无法继续处理。
场景区分¶
6.1 HTTP/1.1 层面的队头阻塞¶
即使同一连接上后面的请求逻辑上已经准备好了，也可能被前一个响应卡住。
6.2 TCP 层面的队头阻塞¶
TCP 要保证有序交付。如果前面某段丢了，后面的段即使到了，也不能先直接交给上层完整消费。
为什么这点重要？¶
因为很多人误以为 HTTP/2 多路复用后就彻底没阻塞了。实际上：
- HTTP/2 解决了一部分应用层问题
- 但 TCP 层有序字节流的限制还在
这也是 HTTP/3/QUIC 重要的背景之一。
7. WebSocket 是什么？¶
标准回答¶
WebSocket 是在单个 TCP 连接上进行全双工通信的协议，适合实时通信场景，如聊天、推送、实时协作。
它和 HTTP 的关系¶
- 建立阶段通常基于 HTTP Upgrade
- 完成升级后，不再是传统的一问一答式 HTTP 响应模型
- 连接变成可双向主动收发的持久通道
它解决了什么问题？¶
传统 HTTP 更适合：
- 请求-响应
- 客户端主动拉取
而很多实时场景需要：
- 服务端主动推送
- 高频低延迟消息交换
- 双向通信
这时 WebSocket 更自然。
面试高分点¶
WebSocket 并不是"替代 HTTP"，而是补足 HTTP 在实时双向通信上的不足。
8. WebSocket 和长轮询有什么区别？¶
长轮询¶
客户端发请求后，服务端先挂着，等有消息再返回；然后客户端再发下一次请求。
WebSocket¶
一次建立连接后，双方都能随时发消息。
差异¶
- 长轮询本质仍是多次 HTTP 请求
- WebSocket 是持久双向通道
- 高并发实时场景下，WebSocket 通常更省开销、更自然
但长轮询也不是完全没价值：
- 部署更简单
- 兼容性可能更容易
- 某些弱实时场景够用
9. 长连接是不是一定比短连接好？¶
不是。¶
这是非常典型的面试反问。
长连接适合：¶
- 高频访问
- 实时交互
- 建连成本高
- 连接可以被稳定复用
短连接可能更合适：¶
- 低频请求
- 海量客户端但不常活跃
- 中间网络设备对长连接不友好
- 业务模型就是轻量短请求
一句总结¶
连接模型的选择不是教条，而是频率、规模、资源占用和网络环境的综合权衡。
第三部分：把难点、边界和代价吃透¶
10. HTTP/2 一定比 HTTP/1.1 快吗？¶
不一定。¶
虽然 HTTP/2 在大多数现代场景下更先进，但性能表现仍依赖：
- 请求规模
- 网络质量
- 服务端实现
- 代理链路
- 是否发生丢包
为什么不一定？¶
如果场景非常简单：
- 请求少
- 连接短
- 头部很小
- 网络很好
那 HTTP/2 的协议复杂度未必带来明显收益。
此外，如果单条 TCP 连接丢包明显，HTTP/2 的多个流也会一起受影响。
更强表达¶
HTTP/2 的优势通常在并发复用和头部压缩上，但它不是在所有小规模场景都无条件碾压 HTTP/1.1。
11. QUIC / HTTP/3 为什么更适合移动网络？¶
原因一：连接迁移更友好¶
移动网络下，用户可能从 Wi-Fi 切到蜂窝网络，底层 IP/端口发生变化。
传统 TCP 连接对这种变化更脆弱；QUIC 通过连接 ID 等机制让迁移更自然。
原因二：把传输和加密协商整合得更紧¶
能减少握手时延，改善弱网体验。
原因三：降低跨流相互拖累¶
某个流出问题，不一定把整条连接上所有流都一起卡死得那么严重。
12. 一组典型追问链¶
- TCP 怎么重传？
- RTO 和快速重传分别解决什么问题？
- 拥塞控制和流量控制差别是什么？
- 为什么网络一丢包，吞吐可能明显下降？
- 长连接和短连接各自适用什么场景？
- HTTP/2 为什么已经多路复用还会受阻塞影响？
- HTTP/3 / QUIC 的核心改进到底在哪？
- WebSocket 和 HTTP/长轮询是什么关系？
这条链很适合后端、基础架构、网关、中间件岗位继续往深处问。
13. 一份更像面试现场的总结回答¶
网络进阶题的关键，不是背出"RTO、快重传、慢启动、HTTP/2、WebSocket"这些名词，而是把它们放回协议设计目标里理解。TCP 重传解决的是在不可靠网络里恢复可靠传输，拥塞控制解决的是别把整个网络打爆，长连接解决的是频繁建连成本，HTTP/⅔ 则是在并发复用和阻塞控制上持续演进。WebSocket 的价值也不是替代 HTTP，而是提供更适合实时双向交互的通信模型。真正好的回答，是既能说清机制，也能说清代价和适用边界。
14. 复习建议¶
如果你想把这一章练到能扛追问，至少做到：
- 能解释 RTO 和快速重传的区别
- 能区分流量控制与拥塞控制
- 能把长连接的收益和代价都说出来
- 能讲清 HTTP/2 仍受 TCP 队头阻塞影响
- 能说明 HTTP/3 / QUIC 为什么出现
- 能把 WebSocket 放回"实时双向通信"语境里理解
做到这里，这一章就不再只是术语背诵，而是真正开始接近协议理解。