第二阶段知识详解：计算机网络面试详解

本文覆盖字节跳动后端面试中计算机网络的高频考点。每个知识点包含原理详解和面试背诵版两部分。

字节网络面试特点

字节网络面试最爱问的三个方向：

TCP 连接管理（三次握手、四次挥手、为什么不是两次/三次）
TCP 可靠传输机制（滑动窗口、拥塞控制）
HTTP/HTTPS（TLS 握手、HTTP/2 多路复用、HTTP/3 QUIC）

追问模式：先问概念 → 追问"为什么这样设计" → 再问"实际遇到过什么问题"

一、网络分层模型

原理详解

OSI 七层	TCP/IP 四层	核心协议	作用
应用层	应用层	HTTP, DNS, MQTT, gRPC	提供应用服务
表示层	↑	TLS/SSL	加密、编码
会话层	↑	—	会话管理
传输层	传输层	TCP, UDP	端到端可靠/不可靠传输
网络层	网络层	IP, ICMP, ARP	路由寻址
数据链路层	网络接口层	Ethernet, WiFi	相邻节点数据帧传输
物理层	↑	—	比特流传输

面试中实际按 TCP/IP 四层模型回答即可。

面试背诵版

网络分层的目的是解耦——每一层只关心自己的职责，通过接口与相邻层交互。实际工程中用 TCP/IP 四层模型：应用层（HTTP/DNS）、传输层（TCP/UDP）、网络层（IP）、网络接口层（以太网）。数据发送时逐层封装（加头部），接收时逐层解封装。

二、TCP 三次握手（最高频）

原理详解

为什么是三次？不是两次？不是四次？

不能两次的原因：

两次握手 = 服务端收到 SYN 就认为连接建立
问题：客户端一个已失效的旧 SYN（网络延迟重传）到达服务端
服务端以为是新连接，分配资源等待数据 → 但客户端不会发数据 → 资源浪费
第三次 ACK 让服务端确认"客户端确实还活着且想建立连接"

不需要四次的原因：

三次已经足够：第三次 ACK 确认了双方都知道对方的初始序列号
本质上三次握手完成了两件事：
1. 双方确认彼此的发送和接收能力正常
2. 交换初始序列号（ISN）

每次握手的目的：

次数	确认了什么
第 1 次（Client→Server）	Server 确认：Client 的发送能力正常
第 2 次（Server→Client）	Client 确认：Server 的发送和接收能力都正常
第 3 次（Client→Server）	Server 确认：Client 的接收能力正常

面试背诵版

TCP 三次握手：①Client 发 SYN(seq=x)；②Server 回 SYN+ACK(seq=y, ack=x+1)；③Client 发 ACK(ack=y+1)。为什么不能两次：两次握手无法防止已失效的旧 SYN 报文建立错误连接——服务端收到旧 SYN 就分配资源，但客户端不会响应，造成资源浪费。第三次 ACK 让服务端确认客户端确实还活着。为什么不需要四次：三次已经足够让双方确认彼此的收发能力正常，并完成初始序列号交换。

三、TCP 四次挥手

原理详解

为什么是四次？不能三次吗？

关闭连接是双向的：A 关了不代表 B 也关了
第二次 ACK 后，Server 可能还有数据没发完（半关闭状态）
Server 数据发完后才发 FIN → 所以 ACK 和 FIN 不能合并
特殊情况：如果 Server 没有数据要发，ACK 和 FIN 可以合并 → 变成"三次挥手"（延迟确认机制）

TIME_WAIT 为什么要等 2MSL？

确保最后一个 ACK 到达：如果丢了，Server 会重发 FIN，Client 需要能重新 ACK
让旧连接的报文在网络中消失：防止新连接收到旧连接的残留报文

TIME_WAIT 过多的问题与解决：

问题：每个 TIME_WAIT 占用一个端口（默认等 60s），高并发短连接场景端口耗尽
解决：
- tcp_tw_reuse：允许复用 TIME_WAIT 连接（安全，只对客户端有效）
- 使用长连接（HTTP Keep-Alive）减少频繁建连
- 服务端让客户端主动断连（谁主动关谁 TIME_WAIT）

面试背诵版

TCP 四次挥手：①主动方发 FIN；②被动方回 ACK（此时可继续发数据）；③被动方发完数据后发 FIN；④主动方回 ACK 并进入 TIME_WAIT。为什么不能三次：被动方收到 FIN 时可能还有数据没发完，ACK 和 FIN 不能合并（除非没有待发数据）。TIME_WAIT 等 2MSL 的原因：①确保最后的 ACK 能到达（丢了对方会重发 FIN）；②让旧报文在网络中过期消失。高并发场景下 TIME_WAIT 过多会端口耗尽，可通过 tcp_tw_reuse、长连接来缓解。

四、TCP 可靠传输机制

4.1 滑动窗口

原理详解

TCP 用滑动窗口实现流量控制：

text

发送方窗口：
已确认 | 已发送未确认 | 可发送 | 不可发送
───────┼─────────────┼───────┼─────────
       │◄── 发送窗口 ──►│

发送窗口大小 = min(接收方通告窗口 rwnd, 拥塞窗口 cwnd)
接收方通过 ACK 中的 Window 字段告知自己还能接收多少数据
窗口为 0 时发送方停止发送（死锁问题通过探测报文解决）

面试背诵版

TCP 通过滑动窗口实现流量控制。发送方维护一个发送窗口，大小等于 min(rwnd, cwnd)。接收方在 ACK 中携带 Window 字段告知剩余接收能力。窗口内的数据可以连续发送而不必逐个等待确认，大幅提高了吞吐量。如果接收方窗口为 0，发送方启动持续计时器，定期发送探测报文，防止死锁。

4.2 拥塞控制（重点）

原理详解

TCP 拥塞控制四个阶段：

阶段	规则	触发条件
慢启动	cwnd 每 RTT 翻倍	连接建立初期
拥塞避免	cwnd 每 RTT +1 MSS	cwnd ≥ ssthresh
快重传	收到 3 个重复 ACK 立即重传	丢包但网络没彻底拥塞
快恢复	ssthresh = cwnd/2, cwnd = ssthresh + 3	配合快重传

超时 vs 三次重复 ACK 的处理差异：

超时（严重拥塞）：ssthresh = cwnd/2，cwnd = 1，重新慢启动
三次重复 ACK（轻度丢包）：ssthresh = cwnd/2，cwnd = ssthresh（快恢复，不从 1 开始）

现代拥塞控制算法：

Reno：经典，快恢复快重传
Cubic：Linux 默认，cwnd 增长函数是三次方
BBR（Google）：不依赖丢包，基于带宽和 RTT 估计 → 字节跳动大量使用

面试背诵版

TCP 拥塞控制四个阶段：慢启动（cwnd 指数增长到 ssthresh）→ 拥塞避免（cwnd 线性增长）→ 丢包时：收到 3 个重复 ACK 触发快重传+快恢复（cwnd 减半继续），超时则 cwnd 重置为 1 重新慢启动。Linux 默认用 Cubic 算法（cwnd 增长是三次方曲线）。Google 的 BBR 算法不依赖丢包信号，而是主动探测瓶颈带宽和最小 RTT，字节跳动在内部广泛使用 BBR 来优化长距离传输。

五、TCP vs UDP

原理详解

维度	TCP	UDP
连接	面向连接（三次握手）	无连接
可靠性	可靠（重传、确认、排序）	不可靠
顺序	保证有序	不保证
流量控制	有（滑动窗口）	无
拥塞控制	有	无
头部开销	20 字节	8 字节
传输模式	字节流	数据报
适用场景	文件传输、HTTP、数据库	视频直播、DNS、游戏、QUIC

为什么视频直播用 UDP？

实时性要求高，丢一帧可以接受，等重传不可接受
TCP 的拥塞控制会降低发送速率 → 卡顿
应用层可以自己做选择性重传（如关键帧重传、非关键帧丢弃）

字节跳动相关： 抖音/TikTok 的实时推流大量使用基于 UDP 的私有协议。

面试背诵版

TCP 是面向连接、可靠的字节流协议，保证有序且不丢包，适合文件传输和 HTTP。UDP 是无连接、不可靠的数据报协议，头部只有 8 字节，适合实时性要求高的场景（直播、游戏、DNS）。选择依据：需要可靠性选 TCP，需要实时性选 UDP。现代趋势是在 UDP 上自建可靠性（如 QUIC = UDP + 可靠传输 + 加密 + 多路复用）。

六、HTTP/HTTPS

6.1 HTTP 版本演进

原理详解

版本	核心改进	问题
HTTP/1.0	每次请求建一个 TCP 连接	频繁建连开销大
HTTP/1.1	Keep-Alive 长连接、管线化	队头阻塞（响应必须按序返回）
HTTP/2	二进制分帧、多路复用、头部压缩、服务端推送	TCP 层队头阻塞（丢一个包阻塞所有流）
HTTP/3	基于 QUIC（UDP）、无队头阻塞、0-RTT 建连	部署复杂、中间件支持不完善

HTTP/2 多路复用原理：

text

单一 TCP 连接
┌─────────────────────────────────┐
│  Stream 1: GET /index.html      │
│  Stream 2: GET /style.css       │  ← 并行，不互相阻塞
│  Stream 3: GET /app.js          │
└─────────────────────────────────┘

把请求/响应拆成帧（Frame），不同 Stream 的帧可以交错发送。

HTTP/3 为什么用 UDP？

TCP 层丢包导致所有 Stream 阻塞（TCP 保证有序，一个包丢了后面全等）
QUIC 在 UDP 上实现了独立的 Stream，丢包只影响对应 Stream
QUIC 内建 TLS 1.3，0-RTT 恢复连接

面试背诵版

HTTP/1.1 通过 Keep-Alive 复用连接但仍有队头阻塞。HTTP/2 在单一 TCP 连接上实现多路复用（多个 Stream 并行传输），通过二进制分帧和头部压缩（HPACK）提升性能。但 TCP 层的丢包仍会阻塞所有 Stream。HTTP/3 基于 QUIC（UDP），每个 Stream 独立，丢包只影响对应 Stream，且内建 TLS 1.3 支持 0-RTT 恢复。字节跳动的 CDN 和短视频分发已大规模使用 QUIC/HTTP3。

6.2 HTTPS 与 TLS 握手

原理详解

HTTPS = HTTP + TLS

TLS 1.2 握手流程（2-RTT）：

TLS 1.3 握手（1-RTT，更快更安全）：

合并了多个步骤，只需 1 个 RTT
去掉了不安全的加密套件（RSA 密钥交换）
只支持前向安全的密钥交换（ECDHE）
支持 0-RTT 恢复（有重放风险，需应用层幂等）

对称加密 vs 非对称加密：

	对称加密	非对称加密
速度	快（AES: ~GB/s）	慢（RSA: ~MB/s）
密钥	加解密同一把	公钥加密，私钥解密
用途	数据传输	密钥协商、签名

HTTPS 为什么同时用两种？

非对称加密用来安全地协商对称密钥
数据传输用对称加密（性能）
相当于：非对称加密解决"密钥分发"问题，对称加密解决"高效传输"问题

面试背诵版

HTTPS 在 HTTP 和 TCP 之间加了 TLS 层。TLS 握手过程：①Client 发送支持的加密套件和随机数；②Server 回复选择的套件、证书、公钥参数；③双方通过 ECDHE 算法协商出对称密钥；④后续用对称加密通信。为什么同时用对称和非对称加密：非对称加密慢但能安全交换密钥；对称加密快用于实际数据传输。TLS 1.3 只需 1-RTT（甚至 0-RTT 恢复），去掉了所有不安全的套件，只保留前向安全的 ECDHE。

七、DNS 解析

原理详解

DNS 解析完整流程：

递归查询 vs 迭代查询：

客户端 → 本地 DNS：递归（本地 DNS 负责查到底）
本地 DNS → 各级 DNS：迭代（各级只返回下一步该问谁）

DNS 用 TCP 还是 UDP？

默认用 UDP（快，53 端口）
响应超过 512 字节时切换到 TCP（区域传输也用 TCP）

面试背诵版

DNS 解析流程：浏览器缓存 → OS 缓存 → 本地 DNS（递归查询）→ 根 DNS → 顶级域 DNS → 权威 DNS → 返回 IP。客户端到本地 DNS 是递归查询（本地 DNS 全权负责），本地 DNS 到各级 DNS 是迭代查询。默认使用 UDP 协议（端口 53），响应超过 512 字节时改用 TCP。

八、经典面试题："从输入 URL 到页面显示"

完整流程

面试背诵版（精简版，覆盖网络部分）

①DNS 解析：逐级查询浏览器缓存、OS 缓存、本地 DNS、根/顶级/权威 DNS，得到 IP 地址。②TCP 三次握手建立连接。③TLS 握手（HTTPS）协商对称密钥。④发送 HTTP 请求，服务器处理后返回响应。⑤浏览器解析 HTML、加载资源、渲染页面。⑥后续请求复用同一连接（HTTP/2 多路复用），最后四次挥手关闭。

九、其他高频考点

	Cookie	Session	JWT Token
存储位置	客户端浏览器	服务端（内存/Redis）	客户端
安全性	容易被篡改/窃取	相对安全	签名防篡改
跨域	受同源策略限制	依赖 Cookie 传 SessionID	可放 Header，不受同源限制
服务端压力	无	有（存储 Session 数据）	无（无状态）
适用场景	记住登录状态	传统 Web 应用	分布式系统、API 认证

9.2 GET vs POST

	GET	POST
语义	获取资源（幂等）	创建/修改资源（非幂等）
参数位置	URL 查询字符串	请求体
长度限制	浏览器有 URL 长度限制（~2KB-8KB）	理论无限制
缓存	可被浏览器缓存	默认不缓存
安全性	参数暴露在 URL	参数在 body 中（仍需 HTTPS）

9.3 HTTP 状态码

范围	含义	常见
2xx	成功	200 OK, 201 Created, 204 No Content
3xx	重定向	301 永久, 302 临时, 304 未修改（缓存有效）
4xx	客户端错误	400 参数错误, 401 未认证, 403 禁止, 404 未找到
5xx	服务端错误	500 内部错误, 502 网关错误, 503 服务不可用, 504 网关超时

十、高频面试问题速查

Q1: TCP 和 UDP 的区别？

TCP 面向连接、可靠、有序、字节流、有流量控制和拥塞控制，头部 20 字节。UDP 无连接、不可靠、数据报、头部 8 字节。需要可靠性选 TCP，需要实时性选 UDP。

Q2: 为什么 TCP 握手是三次？

防止已失效的旧 SYN 报文建立错误连接。三次握手让双方确认彼此的收发能力正常，并安全交换初始序列号。两次不够（无法防止旧报文），四次不必要。

Q3: 为什么挥手是四次？

因为 TCP 是全双工的，关闭是双向独立的。被动方收到 FIN 后可能还有数据没发完，所以 ACK 和 FIN 要分开发。

Q4: TIME_WAIT 的作用？为什么是 2MSL？

①确保最后一个 ACK 能到达对方（丢了对方会重发 FIN）；②让本连接的旧报文在网络中消失，防止影响新连接。2MSL 是报文最大生存时间的两倍，保证一个来回都能覆盖。

Q5: TCP 怎么保证可靠传输？

五个机制：①序列号和确认号；②超时重传；③滑动窗口（流量控制）；④拥塞控制（慢启动、拥塞避免、快重传、快恢复）；⑤校验和。

Q6: HTTPS 比 HTTP 安全在哪？

HTTPS 在 TCP 之上加了 TLS 层，提供三个安全保障：①加密（防窃听）；②认证（防冒充，通过证书验证服务器身份）；③完整性（防篡改，通过 MAC 校验）。

Q7: HTTP/2 的改进？

①二进制分帧（解析更高效）；②多路复用（单连接并行多个请求）；③头部压缩（HPACK）；④服务端推送。解决了 HTTP/1.1 的队头阻塞问题，但 TCP 层仍有队头阻塞。

Q8: HTTP/3 为什么用 UDP？

TCP 层丢包会阻塞所有 Stream（因为 TCP 保证有序）。QUIC 基于 UDP 实现了独立的 Stream，丢包只影响对应 Stream。同时 QUIC 内建 TLS 1.3，支持 0-RTT 恢复。

Q9: TCP 粘包问题是什么？怎么解决？

TCP 是字节流，没有消息边界，接收方可能一次收到多个或部分消息。解决方法：①定长消息；②特殊分隔符（\r\n）；③消息头声明长度（最常用：Length + Body 格式）。

Q10: 什么是 SYN Flood？怎么防？

攻击者发大量伪造源 IP 的 SYN 包，服务端为每个半连接分配资源，队列满后拒绝正常连接。防御：①SYN Cookie（不保存半连接状态，用加密 Cookie 验证）；②增大半连接队列；③缩短 SYN_RECV 超时。

十一、网络 + Go 结合考点

考点	字节面试常见问法
net/http 底层	"Go 的 HTTP Server 是怎么处理并发的？" → 每个连接一个 goroutine
TCP 长连接管理	"如何实现连接池？超时怎么处理？"
gRPC vs HTTP	"为什么微服务用 gRPC？和 HTTP/2 什么关系？" → gRPC 基于 HTTP/2
DNS 解析	"Go 的 net.Resolver 是怎么工作的？CGO vs Pure Go?"
零拷贝	"Go 怎么实现 sendfile？" → `io.Copy` + `*net.TCPConn`
WebSocket	"WebSocket 和 HTTP 的关系？" → HTTP Upgrade 升级

第二阶段知识详解：计算机网络面试详解 ​

一、网络分层模型 ​

原理详解 ​

面试背诵版 ​

二、TCP 三次握手（最高频） ​

原理详解 ​

面试背诵版 ​

三、TCP 四次挥手 ​

原理详解 ​

面试背诵版 ​

四、TCP 可靠传输机制 ​

4.1 滑动窗口 ​

原理详解 ​

面试背诵版 ​

4.2 拥塞控制（重点） ​

原理详解 ​

面试背诵版 ​

五、TCP vs UDP ​

原理详解 ​

面试背诵版 ​

六、HTTP/HTTPS ​

6.1 HTTP 版本演进 ​

原理详解 ​

面试背诵版 ​

6.2 HTTPS 与 TLS 握手 ​

原理详解 ​

面试背诵版 ​

七、DNS 解析 ​

原理详解 ​

面试背诵版 ​

八、经典面试题："从输入 URL 到页面显示" ​

完整流程 ​

面试背诵版（精简版，覆盖网络部分） ​

九、其他高频考点 ​

9.1 Cookie / Session / Token ​

9.2 GET vs POST ​

9.3 HTTP 状态码 ​

十、高频面试问题速查 ​

Q1: TCP 和 UDP 的区别？ ​

Q2: 为什么 TCP 握手是三次？ ​

Q3: 为什么挥手是四次？ ​

Q4: TIME_WAIT 的作用？为什么是 2MSL？ ​

Q5: TCP 怎么保证可靠传输？ ​

Q6: HTTPS 比 HTTP 安全在哪？ ​

Q7: HTTP/2 的改进？ ​

Q8: HTTP/3 为什么用 UDP？ ​

Q9: TCP 粘包问题是什么？怎么解决？ ​

Q10: 什么是 SYN Flood？怎么防？ ​

十一、网络 + Go 结合考点 ​

推荐学习顺序 ​

参考资源 ​

第二阶段知识详解：计算机网络面试详解

一、网络分层模型

原理详解

面试背诵版

二、TCP 三次握手（最高频）

原理详解

面试背诵版

三、TCP 四次挥手

原理详解

面试背诵版

四、TCP 可靠传输机制

4.1 滑动窗口

原理详解

面试背诵版

4.2 拥塞控制（重点）

原理详解

面试背诵版

五、TCP vs UDP

原理详解

面试背诵版

六、HTTP/HTTPS

6.1 HTTP 版本演进

原理详解

面试背诵版

6.2 HTTPS 与 TLS 握手

原理详解

面试背诵版

七、DNS 解析

原理详解

面试背诵版

八、经典面试题："从输入 URL 到页面显示"

完整流程

面试背诵版（精简版，覆盖网络部分）

九、其他高频考点

9.1 Cookie / Session / Token

9.2 GET vs POST

9.3 HTTP 状态码

十、高频面试问题速查

Q1: TCP 和 UDP 的区别？

Q2: 为什么 TCP 握手是三次？

Q3: 为什么挥手是四次？

Q4: TIME_WAIT 的作用？为什么是 2MSL？

Q5: TCP 怎么保证可靠传输？

Q6: HTTPS 比 HTTP 安全在哪？

Q7: HTTP/2 的改进？

Q8: HTTP/3 为什么用 UDP？

Q9: TCP 粘包问题是什么？怎么解决？

Q10: 什么是 SYN Flood？怎么防？

十一、网络 + Go 结合考点

推荐学习顺序

参考资源