网络协议
网络是中级面试必考硬通货,也是你的潜在主场——做风控/抓包对抗,HTTPS、证书、TLS 你比一般应用开发者懂得深,能讲到中间人、证书校验、双向认证的层面。
本篇含知识点讲解 + 高频面试题。
一、HTTP 基础
- 无状态:每次请求独立,靠 Cookie/Session/Token 维持状态。
- 请求结构:请求行(方法 + URL + 版本)+ 请求头 + 空行 + 请求体。
- 常用方法:GET(查,幂等)、POST(增,非幂等)、PUT(全量改,幂等)、DELETE、PATCH(部分改)、HEAD、OPTIONS(预检)。
- GET vs POST:GET 参数在 URL、有长度限制、可缓存、幂等;POST 参数在 body、无长度限制、不可缓存。语义区别 > 技术区别。
状态码
- 1xx 信息;2xx 成功(200、201、204)。
- 3xx 重定向:301(永久)、302(临时)、304(协商缓存命中)。
- 4xx 客户端错:400、401(未认证)、403(无权限)、404、405、429(限流)。
- 5xx 服务端错:500、502(网关错误)、503(不可用)、504(网关超时)。
缓存
- 强缓存:
Cache-Control(max-age)、Expires,不发请求直接用本地。 - 协商缓存:
ETag/If-None-Match、Last-Modified/If-Modified-Since,发请求由服务端判断,命中返 304。
二、HTTP 版本演进
| 版本 | 关键特性 | 解决的问题 |
|---|---|---|
| HTTP/1.0 | 短连接,每次请求新建 TCP | — |
| HTTP/1.1 | 长连接(keep-alive)、管线化、Host 头、分块传输 | 复用连接 |
| HTTP/2 | 二进制分帧、多路复用(一个连接并发多请求)、头部压缩(HPACK)、服务端推送 | 队头阻塞(应用层) |
| HTTP/3 | 基于 QUIC(UDP)、0-RTT、连接迁移 | TCP 队头阻塞、握手延迟 |
- HTTP/1.1 队头阻塞:同一连接请求需按序响应,前一个慢会卡后面。HTTP/2 多路复用在应用层缓解,但 TCP 层仍有队头阻塞;HTTP/3 基于 QUIC/UDP,通过独立 stream 降低 TCP 层队头阻塞影响。
- WebSocket:基于 HTTP 升级(Upgrade)的全双工长连接,用于实时通信(IM、推送)。
三、HTTPS 与 TLS(你的强项,讲深)
HTTPS = HTTP + TLS/SSL,解决三个问题:加密(防窃听)、完整性(防篡改)、身份认证(防冒充)。
TLS 握手:RSA 密钥交换 vs ECDHE
TLS 的核心思想是:先认证身份并协商出对称会话密钥,后续用对称加密传 HTTP 数据。对称加密快,但首次密钥分发困难;非对称/密钥交换负责解决首次协商与身份认证。
| 维度 | RSA 密钥交换(TLS 1.2 旧式) | ECDHE 密钥交换(现代主流) |
|---|---|---|
| 证书公钥用途 | 客户端用证书里的 RSA 公钥加密 pre-master secret | 证书用于验证服务端身份;临时 ECDHE 公钥用于密钥交换 |
| 会话密钥来源 | pre-master secret + 双方随机数派生 | 双方临时椭圆曲线私钥/公钥计算共享秘密 + 随机数派生 |
| 前向保密 | 没有。服务端私钥泄露后,历史抓包可能被解密 | 有。临时私钥握手后丢弃,长期证书私钥泄露也难解历史流量 |
| 面试风险点 | 容易把“证书公钥加密密钥”当成所有 TLS 的固定流程 | 要说清“证书认证身份,ECDHE 协商密钥” |
TLS 1.2 RSA 简化流程
- Client Hello:客户端发支持的 TLS 版本、加密套件、随机数。
- Server Hello:服务端选择套件、返回随机数、下发证书(含公钥)。
- 客户端验证证书(CA 链、域名、有效期、吊销状态等),生成
pre-master secret,用服务端 RSA 公钥加密后发送。 - 服务端用私钥解密,双方用
pre-master secret + client_random + server_random派生对称会话密钥。 - 双方发送 Finished 校验握手完整性,之后用对称加密通信。
TLS 1.2 ECDHE / TLS 1.3 直觉
- ECDHE:服务端发送临时 ECDHE 公钥并用证书私钥签名,客户端验证签名后也生成临时公钥;双方各自用“自己的临时私钥 + 对方临时公钥”算出共享秘密。网络上没有直接传输会话密钥。
- TLS 1.3:移除静态 RSA 密钥交换等旧套件,把常规握手压到 1-RTT:ClientHello 携带 key share,ServerHello 返回 key share 和证书相关消息,双方很快得到密钥。
- 0-RTT:客户端基于上次会话恢复提前发送早期数据,降低重连延迟;边界是早期数据可能被重放,所以只适合幂等 GET/查询类请求,不适合支付、下单、转账、登录态变更等非幂等操作。
面试一句话:旧 RSA 像“用证书公钥包住会话密钥”,现代 ECDHE/TLS 1.3 更像“证书负责证明你是谁,临时密钥交换负责生成本次会话密钥”,因此具备前向保密。
证书与信任链
- 证书由 CA 逐级签发,设备内置根 CA。验证时沿链校验到可信根。
- 为什么不能只用对称加密? 密钥分发难题:首次怎么安全传密钥?用非对称解决。
- 为什么不全用非对称? 慢。所以只用它协商对称密钥。
安全实战(你能讲、别人讲不了)
- 中间人攻击(MITM):攻击者伪造证书。防御靠客户端严格校验证书。
- 证书锁定(SSL Pinning):App 内置服务端证书/公钥指纹,只信任它,防抓包/MITM——风控/金融 App 标配。
- 双向认证(mTLS):服务端也验证客户端证书。
- 抓包对抗:Charles/Fiddler 装根证书抓 HTTPS;App 可用 Pinning + 检测代理对抗。这是你做风控的实战领域。
四、TCP / UDP
TCP 三次握手
- Client → SYN(seq=x)
- Server → SYN+ACK(seq=y, ack=x+1)
- Client → ACK(ack=y+1) 为什么三次? 确认双方收发能力都正常;两次无法确认客户端的接收能力,且防止历史失效连接请求建立连接。
TCP 四次挥手
- Client → FIN 2. Server → ACK 3. Server → FIN 4. Client → ACK 为什么四次? 关闭是双向的,服务端收到 FIN 后可能还有数据要发,所以 ACK 和 FIN 分开。 TIME_WAIT(2MSL):主动关闭方等待,确保最后 ACK 到达 + 让旧报文消散。
可靠性机制
序列号 + 确认应答、超时重传、滑动窗口(流量控制)、拥塞控制。
拥塞控制:看懂 cwnd / ssthresh 转换
- cwnd(congestion window):发送端根据网络拥塞程度维护的拥塞窗口,限制“未确认在途数据量”。
- ssthresh(slow start threshold):慢启动阈值,决定从指数增长切到线性增长。
- 实际发送窗口通常取
min(cwnd, rwnd):拥塞控制看网络承载能力,流量控制看接收端缓存能力。
| 阶段 | 触发/进入条件 | cwnd 变化 | 退出条件 |
|---|---|---|---|
| 慢启动 | 连接刚建立或超时后重新探测 | 每个 RTT 近似翻倍(指数增长) | cwnd >= ssthresh 转拥塞避免;或丢包 |
| 拥塞避免 | cwnd 达到 ssthresh | 每个 RTT 近似 +1 MSS(线性增长) | 丢包/重复 ACK |
| 快重传 | 收到 3 个重复 ACK,推测某段丢失但网络仍有流动 | 不等超时,立即重传疑似丢失段 | 进入快恢复 |
| 快恢复 | 快重传之后 | 通常把 ssthresh 设为丢包前 cwnd 的一半,cwnd 降低后线性恢复 | 新 ACK 到达后回到拥塞避免 |
超时 vs 快重传的区别:
- 超时重传说明网络可能严重拥塞或 ACK 完全回不来,处理更保守:常见做法是
ssthresh = cwnd / 2,然后cwnd回到很小值重新慢启动。 - 3 个重复 ACK说明后续包还能到达,网络没有完全断流,所以只减半窗口并快恢复,比超时温和。
新连接/超时
↓ cwnd 指数增长
慢启动 ── cwnd >= ssthresh ──> 拥塞避免(线性增长)
│ │
└── 超时:ssthresh=cwnd/2,cwnd 重置 ─┘
│
└── 3 dup ACK:快重传 → 快恢复 → 拥塞避免
面试答题流:先区分可靠性(序号/ACK/重传)与拥塞控制(保护网络),再解释 cwnd/ssthresh,最后用“超时更严重、快重传更温和”讲阶段转换。
TCP vs UDP
| TCP | UDP | |
|---|---|---|
| 连接 | 面向连接 | 无连接 |
| 可靠 | 可靠有序 | 不承诺可靠性 |
| 速度 | 慢 | 快 |
| 场景 | HTTP、文件 | 音视频、DNS、QUIC |
高频面试题
Q1:HTTP 和 HTTPS 区别? HTTPS = HTTP + TLS,提供加密、完整性、身份认证。HTTP 明文 80 端口,HTTPS 加密 443 端口,需证书,有握手开销但安全。
Q2:TLS 握手为什么用非对称 + 对称结合?
非对称/密钥交换解决首次协商和身份认证,对称加密负责后续高性能传输。旧 RSA 是客户端用证书公钥加密 pre-master secret;现代 ECDHE/TLS 1.3 用临时密钥交换生成会话密钥,证书主要证明服务端身份,并提供前向保密。
Q3:TCP 为什么三次握手不是两次? 三次才能确认双方收发能力都正常,并防止已失效的历史连接请求突然到达导致错误建连。两次无法确认客户端接收能力。
Q4:TIME_WAIT 是什么?为什么等 2MSL? 主动关闭方在四次挥手后进入 TIME_WAIT,等 2 倍报文最大生存时间:确保最后的 ACK 能到达对端(否则对端重传 FIN),并让本连接的旧报文在网络中消散。
Q5:HTTP/2 相比 1.1 的核心改进? 二进制分帧、多路复用(一个连接并发多请求,解决应用层队头阻塞)、头部压缩 HPACK、服务端推送。
Q6:什么是 SSL Pinning?为什么风控 App 要用?(你的强项) 客户端内置服务端证书或公钥指纹,握手时只信任它而非系统 CA,防止中间人用伪造证书抓包/篡改。金融、风控 App 用它对抗抓包和 MITM。
Q7:输入 URL 到页面展示发生了什么? DNS 解析 → 建立 TCP 连接(三次握手)→ TLS 握手(HTTPS)→ 发 HTTP 请求 → 服务端响应 → 客户端解析渲染 → 关闭/复用连接。
进阶补充:DNS、QUIC、TCP 状态与 TLS 细节
DNS 解析链路
域名访问前通常经历缓存查询、本地 DNS、递归解析。移动端排查网络慢时要区分 DNS、TCP、TLS、请求、响应各阶段。
HTTP/3 与 QUIC
HTTP/3 基于 QUIC(运行在 UDP 上),把传输层和 TLS 1.3 握手整合,改善队头阻塞和弱网迁移。面试不要说“UDP 就不可靠“,QUIC 在用户态实现可靠传输。
TIME_WAIT / CLOSE_WAIT 排障
| 状态 | 常见原因 | 排查方向 |
|---|---|---|
| TIME_WAIT 多 | 主动关闭方等待旧包消失 | 连接复用、服务端参数 |
| CLOSE_WAIT 多 | 本端未 close socket | 代码资源释放、连接池 |
TLS 补充:SNI、ALPN、OCSP、会话恢复
- SNI:客户端握手时告诉服务端目标域名。
- ALPN:协商 HTTP/1.1、HTTP/2 等应用协议。
- OCSP:检查证书吊销状态。
- Session Ticket/PSK:减少重复握手成本。
**追问:**HTTP/2 和 HTTP/3 都解决什么问题?HTTP/2 多路复用仍受 TCP 队头阻塞影响;HTTP/3 基于 QUIC 改善连接迁移和队头阻塞。