01. 计算机网络：TCP、UDP、HTTP、HTTPS（深挖版）¶

网络八股最容易犯的错误，是把每个问题都答成"口诀"：

TCP 可靠

UDP 快

三次握手四次挥手

HTTP 无状态，HTTPS 更安全

这种回答在初筛可能够，但一旦面试官追问"为什么""代价是什么""边界条件呢"，就容易露底。这一章的目标，是把网络问题讲到能经受二轮追问的程度。

本章建议按“先理解知识主线，再练问答表达，最后吃透边界条件”的顺序阅读：

先把TCP vs UDP、三次握手四次挥手、HTTP 基础、GET vs POST

再展开粘包拆包、TIME_WAIT、滑动窗口、拥塞控制、HTTPS

最后把HTTP 版本演进、长短连接、TLS 握手细节

先把这一章的知识骨架搭起来¶

这一章真正的主线是：应用层想把数据可靠地、及时地、相对低成本地送到对端时，传输层和应用层协议分别承担什么职责。UDP 偏向轻量、低约束；TCP 偏向有连接、可靠、有序；HTTP/HTTPS 则是在此之上定义语义、状态和安全约束。

所以你读这章时不要把“三次握手”“四次挥手”“TCP 可靠”“HTTPS 更安全”拆开背，而要串起来：连接为什么要建立状态，可靠性靠哪些机制叠出来，挥手为什么比握手复杂，HTTP 为什么无状态但仍能支持会话，HTTPS 为什么不仅仅是“加密一下内容”。

一旦主线清楚，你答题时就能自然从“需求”走到“机制”，而不是只会报术语。

第一部分：先把概念和主线讲清楚¶

进入问答前，先把最小前置知识补齐¶

这一章要先把“协议分层职责”理顺。UDP 和 TCP 都是传输层协议，但它们对上层承诺不同：UDP 只负责尽力而为地发报文，TCP 负责把底层不可靠网络尽量抽象成可靠有序字节流。HTTP/HTTPS 则在传输层之上继续定义请求、响应、状态和安全语义。

所以别把“三次握手”“TCP 可靠”“HTTPS 安全”拆开背，而要先明确：连接为什么要建立状态，可靠性是靠哪些机制叠出来的，应用层又为什么还需要额外定义消息语义和认证加密规则。

1. TCP 和 UDP 的核心区别是什么？¶

标准回答¶

TCP：面向连接、可靠传输、字节流、具备流量控制和拥塞控制
UDP：无连接、不保证可靠、面向报文、头部开销小、时延更低

更深一层的理解¶

TCP 和 UDP 的区别不是简单的"一个快一个慢"，而是：

TCP 把"可靠、有序、重传、拥塞处理"这些复杂度放在协议层
UDP 把复杂度留给应用层自己决定要不要做

也就是说，UDP 并不是"更高级更快的 TCP"，而是"更少承诺、更少机制、更灵活"。

什么时候 UDP 不一定更快？¶

如果你的应用自己还得做：

重传
顺序恢复
丢包处理
流量调节

那未必整体更简单，甚至未必整体更高效。

所以面试里不要把 UDP 神化成"天然高性能方案"。

2. TCP 为什么可靠？¶

标准回答¶

TCP 的可靠性来源于多种机制协同：

序列号：标识字节流位置
确认应答（ACK）：确认数据已收到
超时重传：超时后重新发送
快速重传：收到多个重复 ACK 时提前重传
校验和：检测传输错误
乱序重组：按序重排收到的数据
流量控制：避免接收方被打爆
拥塞控制：避免网络整体过载

为什么这题不能只答"有 ACK 和重传"？¶

因为"可靠"不是某一个机制单独保证的，而是一个系统效果：

只有 ACK 没重传不行
只有重传没序列号也不行
只在端点可靠但不做拥塞控制，网络层面可能崩

面试更强的说法¶

TCP 可靠的本质不是"包不丢"，而是"即便底层网络会丢、乱序、重复、延迟，TCP 仍然尽量把上层抽象成一条可靠有序的字节流"。

3. TCP 为什么是字节流？¶

标准回答¶

TCP 面向字节流，意味着它传递的是一串连续字节，不保留应用层写入消息的边界。

这句话真正意味着什么？¶

假设发送端：

send("abc");
send("def");

接收端不一定按两次分别收到：

可能一次收到 abcdef
也可能先收到 ab，再收到 cdef

所以会带来什么问题？¶

这正是所谓的：

粘包
拆包

面试里要补的一句¶

粘包/拆包不是 TCP "出 bug"，而是因为应用层误把字节流协议当成了消息边界协议来用。

4. 粘包和拆包怎么解决？¶

常见方案¶

4.1 固定长度协议¶

每个消息长度固定，接收端按固定长度切。

优点：简单缺点：浪费空间，不灵活

4.2 分隔符协议¶

如文本协议用 \n、特殊标记做边界。

优点：直观缺点：要处理转义、内容冲突、性能等问题

4.3 长度字段 + 消息体¶

最常见做法。消息头先写明 body 长度，再按长度读取完整消息。

面试高分点¶

如果岗位偏后端、高并发、游戏服务端，面试官通常希望你能讲出：

半包缓存怎么做
大包攻击怎么防
协议头是不是也要校验
解码状态机怎么设计

5. TCP 为什么需要三次握手？¶

标准回答¶

三次握手的目标是让通信双方确认：

自己的发送能力正常
自己的接收能力正常
对方的发送能力正常
对方的接收能力正常

从而建立一个双方都认可的连接状态。

典型流程¶

客户端发 SYN：我想建立连接
服务端回 SYN + ACK：我收到你的请求，我也同意建立
客户端回 ACK：我收到你的确认，连接正式建立

为什么不是两次？¶

如果只有两次，服务端没法确认客户端是否真的收到了自己的响应，也就无法可靠地知道双向通信状态是否一致。

面试更深入的说法¶

三次握手不只是"确认双方在线"，还涉及：

初始序列号同步
双方状态机达成一致
防止某些历史延迟报文引发错误连接建立

如果你能从"状态机一致性"角度回答，会比口诀式答案更强。

6. TCP 为什么四次挥手？¶

标准回答¶

因为 TCP 是全双工连接，双方关闭发送方向通常是独立动作，因此一般需要四次挥手。

流程¶

A 发 FIN：我这边不再发数据了
B 回 ACK：我知道了
B 发 FIN：我也发完了
A 回 ACK：我知道你也结束了

为什么不像握手那样 3 次？¶

因为握手阶段服务端通常可以把"确认 + 自己也要建立连接"放在一起；而挥手阶段，服务端收到 FIN 后，不一定能立刻关闭自己的发送方向，它可能还有剩余数据要发。

所以 ACK 和 FIN 往往不能合并。

第二部分：围绕高频追问继续展开¶

7. TIME_WAIT 为什么存在？¶

标准回答¶

TIME_WAIT 的主要作用有两个：

保证最后一个 ACK 有机会被对方收到
防止旧连接中的延迟报文污染后续新连接

第一个作用怎么理解？¶

如果主动关闭方发出最后 ACK 后立刻彻底消失，而被动关闭方没收到这个 ACK，就会重发 FIN。但这时主动关闭方已经不存在了，对方会陷入异常状态。

TIME_WAIT 让主动关闭方在一段时间内保留连接信息，能处理这种重传。

第二个作用怎么理解？¶

网络中可能存在延迟到达的旧报文。如果连接很快复用同一四元组，旧报文可能被误当成新连接的数据。TIME_WAIT 能降低这个风险。

面试常见误区¶

不要把 TIME_WAIT 简单说成"浪费资源的坏状态"。

更准确的说法是：

TIME_WAIT 是可靠关闭和旧报文隔离所付出的协议成本。

8. 滑动窗口是什么？¶

标准回答¶

滑动窗口是一种允许发送方在未收到每一个字节/分组确认前，连续发送多个数据的机制，用于提升吞吐量。

为什么不能"发一个等一个 ACK"？¶

因为那会浪费大量 RTT 时间。特别是高延迟链路，吞吐会非常差。

滑动窗口带来的价值¶

提高链路利用率
支持流量控制
支持累积确认
减少等待时间

面试追问¶

发送窗口和接收窗口分别代表什么？¶

发送窗口：我当前最多还能发多少未确认数据
接收窗口：对方还能接收多少数据

真正有效窗口通常取决于多个约束共同作用，而不是一个固定值。

9. 什么是流量控制？¶

标准回答¶

流量控制是端到端机制，用于防止发送方速度过快，超过接收方处理能力。TCP 通过接收窗口（rwnd）等机制告诉发送方"我还能接多少"。

核心目标¶

不是防网络崩，而是防接收端被打爆。

为什么它和拥塞控制不同？¶

因为流量控制解决的是"对端处理不过来"，而拥塞控制解决的是"网络中间路径承载不了"。

这是特别爱考的区别题。

10. 什么是拥塞控制？¶

标准回答¶

拥塞控制是 TCP 为避免网络整体过载而设计的一组发送速率调节机制。典型阶段包括：

慢启动
拥塞避免
快速重传
快速恢复

为什么需要拥塞控制？¶

即使接收方扛得住，如果网络链路、交换设备、路由缓冲扛不住，也会整体拥塞，导致丢包、重传、时延飙升，最终所有连接都变差。

面试里建议的说法¶

流量控制是"别把接收方打爆"，拥塞控制是"别把网络打爆"。

这句话很短，但很好用。

11. HTTP 是什么？它和 TCP 是什么关系？¶

标准回答¶

HTTP 是应用层协议，规定了客户端和服务器如何交换请求与响应语义；TCP 是传输层协议，负责在两端之间可靠传输字节流。HTTP 通常运行在 TCP 之上。

面试容易错的地方¶

不要把 HTTP 和 TCP 并列成"谁比谁更可靠/更快"。它们不是同一层的协议，职责不同。

更完整地说¶

TCP 提供可靠字节流通道
HTTP 定义这条通道上传什么内容、怎么组织、怎么解释

12. HTTP 为什么说是无状态？¶

标准回答¶

无状态指 HTTP 协议本身不会自动记住前一个请求和后一个请求之间的业务上下文，每次请求从协议语义上都是相对独立的。

这不代表什么？¶

它不代表：

服务端不能记住用户登录状态
网站不能做会话
请求之间完全无关联

因为实际系统会借助：

Cookie
Session
Token
JWT
数据库存储

在"HTTP 之上"维护状态。

面试高分点¶

HTTP 的"无状态"是协议层属性，不等于业务系统不能有状态。

13. GET 和 POST 的区别是什么？¶

不要只答"GET 放 URL，POST 放 body"¶

这是最容易被追问击穿的浅层答案。

更好的回答¶

从语义上看¶

GET：获取资源
POST：向服务端提交资源/触发处理

从工程实践看¶

GET 通常更适合幂等读取
POST 常用于创建/提交/触发动作
GET 更容易被缓存、预取、收藏
POST 通常不被默认当作可缓存安全读操作

常见误区¶

"GET 不能有 body" -- 过于绝对
"POST 比 GET 更安全" -- 也不准确

更准确的说法是：

URL 暴露位置不同确实会影响日志、缓存、代理、浏览器历史等行为
但安全性本质不取决于 GET/POST 本身，而取决于 HTTPS、鉴权、服务端校验、敏感信息管理等整体设计

14. HTTP 状态码怎么答才不空？¶

高频状态码¶

200 OK
301 Moved Permanently
302 Found
304 Not Modified
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

高分点：不要只背编号¶

例如：

401 更偏"你还没通过认证"
403 更偏"你身份可能已知，但没有权限"
502 常发生在网关/代理转发下游失败
504 常是下游超时导致网关等待失败

如果你是后端岗，状态码最好和网关、反向代理、微服务调用一起讲。

第三部分：把难点、边界和代价吃透¶

15. HTTPS 比 HTTP 多了什么？¶

标准回答¶

HTTPS = HTTP + TLS（历史上常说 SSL/TLS）。它在 HTTP 之上增加了加密和身份认证能力，主要提供：

机密性：别人看不懂内容
完整性：内容没被篡改
身份认证：你连接的目标更可信

更深入一点¶

HTTPS 不是"把 HTTP 变快/变慢"的简单变体，而是在传输层之上建立一层安全会话，使应用层数据在通道中被保护。

16. HTTPS 的握手过程大致是怎样的？¶

简化版本回答¶

客户端发起 TLS 握手请求
服务端返回证书、公钥相关信息、协商参数
客户端验证证书是否合法
双方协商出会话密钥
后续应用数据使用对称加密传输

为什么不是一直用公钥加密？¶

因为公钥加密开销大，不适合大规模数据传输；公钥体系更适合做：

身份认证
密钥交换

真正的大量业务数据一般用对称加密传输。

面试注意¶

TLS 1.2 和 TLS 1.3 握手细节不同，不要把某一个版本细节说成所有 HTTPS 的唯一流程。

17. 什么是长连接和短连接？¶

短连接¶

每次请求都建立连接，用完即关。

长连接¶

多个请求复用同一连接，减少握手和挥手开销。

为什么长连接重要？¶

因为 TCP 建连和关闭都是有成本的；如果每个请求都重新建连，时延和系统开销会显著上升。

面试高分点¶

长连接不仅降低时延，也会带来新的系统问题：

连接保活成本
空闲连接管理
连接泄漏
负载均衡策略变化
服务端 FD 资源占用

18. HTTP/1.1、HTTP/2、HTTP/3 的关键区别是什么？¶

HTTP/1.1¶

文本协议
支持长连接
存在应用层队头阻塞问题

HTTP/2¶

二进制分帧
多路复用
头部压缩
多个 stream 可复用同一 TCP 连接

HTTP/3¶

基于 QUIC（跑在 UDP 上）
改善传输层队头阻塞问题
更适合移动网络和连接迁移场景

面试不要说错的一点¶

HTTP/2 解决了应用层并发复用问题，但仍然跑在 TCP 上，所以底层一旦丢包，TCP 层面的队头阻塞影响仍然存在。HTTP/3/QUIC 的一个重要改进就是在这里。

19. 一组典型追问链¶

TCP 和 UDP 区别？
TCP 为什么可靠？
TCP 为什么是字节流？
粘包拆包怎么处理？
三次握手为什么不能两次？
四次挥手为什么不是三次？
TIME_WAIT 为什么存在？
滑动窗口、流量控制、拥塞控制分别是什么？
HTTP 为什么无状态？
HTTPS 比 HTTP 多了什么？
HTTP/2 和 HTTP/3 核心改进是什么？

这是一整条特别标准的后端面试路径。

20. 一份更像面试现场的总结回答¶

网络题最重要的不是背流程图，而是理解协议为什么这样设计。TCP 的价值在于，它把一个不可靠的网络环境抽象成"尽量可靠、有序的字节流"，背后靠序列号、ACK、重传、窗口、流控和拥塞控制协同完成。三次握手和四次挥手本质上是在完成双方状态同步与可靠关闭，TIME_WAIT 则是协议正确性成本的一部分。HTTP 是运行在 TCP 之上的应用层语义协议，HTTPS 则通过 TLS 在此基础上增加了机密性、完整性和身份认证。真正好的回答，不只是会说"是什么"，而是能说清"为什么需要它、它带来了什么代价、边界条件又是什么"。

21. 复习建议¶

如果你想把这一章练到面试可打，至少做到：

不把 TCP/UDP 说成"一个可靠一个不可靠"就结束
能解释字节流与粘包拆包
能讲清三次握手、四次挥手、TIME_WAIT 的设计原因
能区分流量控制和拥塞控制
能说明 HTTPS 的安全目标和 TLS 的大概角色
能比较 HTTP/1.1、2、3 的核心差异

这样你的网络题就不再是几句口诀，而是完整的协议理解。