1. OSI 七层模型和 TCP/IP 模型分别是什么？#

面试回答：

OSI 七层模型从上到下是：

1. 应用层
2. 表示层
3. 会话层
4. 传输层
5. 网络层
6. 数据链路层
7. 物理层

TCP/IP 四层模型是：

1. 应用层：HTTP、DNS、SMTP
2. 传输层：TCP、UDP
3. 网际层：IP、ICMP
4. 网络接口层：以太网、Wi-Fi 等

面试中也经常使用“五层模型”，即把网络接口层拆成数据链路层和物理层。

数据发送时会不断封装：

1
应用数据
2
  ↓
3
TCP 段 / UDP 数据报
4
  ↓
5
IP 数据包
6
  ↓
7
以太网帧
8
  ↓
9
比特流

接收端按照相反顺序解封装。TCP/IP 标准体系通常划分为应用层、传输层、网际层和链路层。(RFC 编辑器)

2. TCP 和 UDP 有什么区别？#

面试回答：

TCP 是面向连接、可靠、有序、全双工的字节流协议；UDP 是无连接、尽力而为、保留报文边界的数据报协议。

主要区别如下：

一个常见错误是说“UDP 一定不可靠”。更准确的说法是：

UDP 协议本身不提供可靠性，但应用层可以基于 UDP 实现可靠传输，例如 QUIC 就在 UDP 之上实现了确认、重传、流量控制和拥塞控制。

TCP 提供可靠、按序、面向连接的字节流服务；UDP 提供最小化的、非保证交付的数据报服务。(RFC 编辑器)

3. TCP 是怎么保证可靠传输的？#

面试回答：

TCP 主要通过以下机制保证可靠性：

1. 连接管理：三次握手建立连接。
2. 序列号：每个字节都有序列号，用来排序和去重。
3. 确认机制 ACK：接收方告诉发送方已经收到哪些数据。
4. 校验和：发现数据在传输过程中是否损坏。
5. 超时重传：长时间没有收到 ACK，就重新发送。
6. 快速重传：收到多个重复 ACK 时，不等待超时就重传。
7. SACK：告诉发送方哪些不连续的数据块已经收到。
8. 滑动窗口：允许批量发送，提高吞吐量。
9. 流量控制：避免发送方把接收方缓冲区打满。
10. 拥塞控制：避免发送速度超过网络承载能力。
11. 有序重组和重复数据丢弃。

需要注意：

TCP 的“可靠”是指数据尽量完整、有序、不重复地到达，不代表数据经过了加密，也不代表绝对不会断开连接。

TCP 标准定义了可靠、有序的字节流传输；RTO 根据 RTT 和波动动态计算，SACK 可以报告已经收到的不连续数据块。(RFC 编辑器)

4. TCP 三次握手的过程是什么？#

假设客户端初始序列号是 x，服务端初始序列号是 y。

1
客户端                              服务端
2

3
SYN=1, seq=x
4
   ------------------------------>
5

6
                     SYN=1, ACK=1
7
                     seq=y, ack=x+1
8
   <------------------------------
9

10
ACK=1, seq=x+1, ack=y+1
11
   ------------------------------>

具体过程：

1. 客户端发送 SYN，进入 SYN_SENT。
2. 服务端收到后发送 SYN + ACK，进入 SYN_RECEIVED。
3. 客户端发送 ACK，双方进入 ESTABLISHED。

三次握手不仅是建立连接，还会同步双方的初始序列号。(RFC 编辑器)

5. 为什么 TCP 建立连接需要三次握手，不能两次？#

核心原因是：

双方都需要确认自己的发送能力和接收能力正常，并同步双方的初始序列号。

两次握手之后：

• 客户端知道：自己能发、自己能收、服务端能收、服务端能发。
• 服务端只知道：自己收到了客户端的 SYN，并且自己发出了 SYN+ACK。
• 服务端不知道：客户端是否成功收到自己的 SYN+ACK。

第三次 ACK 能让服务端确认客户端确实收到了服务端的初始序列号。

三次握手还可以降低历史失效 SYN 导致错误建连的风险。假如网络中延迟很久的旧 SYN 到达服务端，服务端返回 SYN+ACK，但当前客户端不会为这条旧连接发送正确 ACK，因此连接无法建立。

至于为什么不需要四次，是因为第三次 ACK 已经完成了双方确认；如果 ACK 也必须被再次确认，就会产生无限确认问题。

6. 第三次握手的 ACK 丢失会怎么样？#

客户端发送第三次 ACK 后，客户端通常已经认为连接建立成功，但服务端仍处于 SYN_RECEIVED。

服务端没有收到 ACK，会重新发送 SYN+ACK：

1
客户端收到重传的 SYN+ACK
2
        ↓
3
再次发送 ACK
4
        ↓
5
服务端进入 ESTABLISHED

如果客户端直接发送了携带有效 ACK 的业务数据，服务端也可能根据该 ACK 完成连接建立。

如果服务端始终收不到有效 ACK，经过多次重传和超时后，就会清理这条半连接。TCP 三次握手及 SYN/ACK 重传行为由 TCP 状态机和重传机制共同完成。(RFC 编辑器)

7. TCP 为什么是四次挥手？#

TCP 是全双工通信，两个方向必须分别关闭。

1
客户端                              服务端
2

3
FIN
4
   ------------------------------>
5

6
ACK
7
   <------------------------------
8

9
                         服务端处理完剩余数据
10
                         调用 close()
11

12
FIN
13
   <------------------------------
14

15
ACK
16
   ------------------------------>

过程是：

1. 主动关闭方发送 FIN，表示自己不再发送数据。
2. 被动关闭方返回 ACK，但它可能还有数据没有发送完。
3. 被动关闭方处理完数据后，再发送 FIN。
4. 主动关闭方返回 ACK。

为什么通常比握手多一次？

因为服务端收到 FIN 后，只能立即确认“我知道你不发了”，但服务端自己可能还没有发送完数据，所以 ACK 和 FIN 通常分开发送。

如果服务端收到 FIN 后也立即关闭，ACK 和 FIN 可以合并，因此抓包时有可能看到三次报文完成关闭，并不是所有连接都严格表现为四个独立报文。(RFC 编辑器)

10. TCP 流量控制和拥塞控制有什么区别？#

1
实际发送窗口 = min(rwnd, cwnd)

1
rwnd：保护接收方
2
cwnd：保护整个网络

14. HTTP 长连接、TCP Keepalive 和应用心跳有什么区别？#

1
PING
2
PONG

15. 什么是 SYN Flood？#

攻击者向服务端发送大量 SYN，但不完成第三次握手：

1
攻击者：大量 SYN
2
服务端：创建半连接并返回 SYN+ACK
3
攻击者：不返回 ACK

大量伪造半连接会占满半连接队列，使正常用户无法建立连接。

常见防御：

• SYN Cookie。
• SYN Cache。
• 限制单 IP 建连速率。
• 防火墙、负载均衡器清洗流量。
• 合理增加半连接队列。
• 减少 SYN+ACK 重试时间和次数。
• 源地址过滤。

SYN Flood 的核心就是利用大量伪造半连接占满 backlog。(RFC 编辑器)

16. TCP 和 UDP 可以使用相同端口吗？#

可以。

例如，一个程序可以同时监听：

1
TCP 53
2
UDP 53

因为操作系统区分连接时不仅看端口，还会看传输层协议：

1
协议 + 本地 IP + 本地端口 + 远端 IP + 远端端口

TCP 和 UDP 有各自独立的端口空间。

但是在同一种协议下，两个 Socket 通常不能随意绑定到完全相同的本地 IP 和端口，除非使用特定的地址复用选项并满足操作系统规则。

这个问题曾直接出现在阿里云后端面经中。(牛客网)

18. DNS 域名解析过程是什么？#

假设访问：

1
www.example.com

常见流程是：

1. 浏览器检查自己的缓存。

2. 操作系统检查 DNS 缓存和 hosts 文件。

3. 客户端的 Stub Resolver 向递归 DNS 服务器查询。

4. 递归 DNS 如果有缓存，直接返回。

5. 没有缓存时，递归 DNS 依次查询：

   • 根 DNS。
   • 顶级域 DNS，例如 .com。
   • 权威 DNS。

6. 权威 DNS 返回 A、AAAA 或 CNAME 等记录。

7. 递归 DNS 根据 TTL 缓存结果并返回客户端。

需要注意：

DNS 并没有固定的“必须经过五级缓存”。浏览器、操作系统、递归解析器、企业网关等是否缓存，取决于具体实现。

DNS 经典体系由递归解析器、根服务器、顶级域服务器、权威服务器和缓存共同完成。(RFC 编辑器)

19. ARP 是什么？访问不同网段的服务器时 ARP 谁？#

ARP 用来根据 IPv4 地址查询同一链路上的 MAC 地址。

1
目标 IP → 目标 MAC

1
默认网关 IP → 默认网关 MAC

1
IP 地址负责端到端定位
2
MAC 地址负责当前这一跳的链路传输

20. 浏览器输入 URL 后发生了什么？#

这是最重要的综合题之一。

以 HTTPS 网站为例，可以按下面的顺序回答。

1
协议、域名、端口、路径、查询参数

1
HTTP/1.1、HTTP/2：
2
TCP 三次握手 → TLS 握手
3

4
HTTP/3：
5
QUIC + TLS 1.3 握手

1
请求方法
2
路径
3
请求头
4
Cookie/Token
5
可选请求体

1
CDN
2
→ 负载均衡
3
→ Nginx / 网关
4
→ 后端服务
5
→ Redis / MySQL / RPC

1
解析 HTML 构建 DOM
2
解析 CSS 构建 CSSOM
3
生成渲染树
4
布局
5
绘制
6
合成

21. HTTP 和 HTTPS 有什么区别？#

HTTPS 本质上是：

1
HTTP + TLS

HTTP 负责请求方法、状态码、请求头、响应体等语义；TLS 负责：

• 机密性：防止内容被窃听。
• 完整性：防止内容被篡改。
• 身份认证：通常验证服务端身份。

常见默认端口：

1
HTTP：80
2
HTTPS：443

但端口只是默认约定，并不是协议本质。

HTTPS 不能解决所有安全问题，例如：

• 用户访问的本身就是钓鱼网站。
• 服务端已经被入侵。
• 客户端主动忽略证书错误。
• Token 或密码在应用层被泄露。

TLS 1.3 的设计目标包括防窃听、防篡改和防消息伪造。(RFC 编辑器)

22. HTTPS 的 TLS 1.3 握手过程是什么？#

可以使用下面这个简化版本回答。

1
客户端                              服务端
2

3
ClientHello
4
版本、加密套件、随机数、
5
key_share、SNI、ALPN
6
   ------------------------------>
7

8
                     ServerHello
9
                     选择参数和 key_share
10
   <------------------------------
11

12
双方计算共享密钥，后续握手开始加密
13

14
                     EncryptedExtensions
15
                     Certificate
16
                     CertificateVerify
17
                     Finished
18
   <------------------------------
19

20
Finished
21
   ------------------------------>
22

23
开始传输加密的 HTTP 数据

主要步骤：

1. 客户端发送 ClientHello。

2. 服务端发送 ServerHello，双方根据临时密钥交换计算共享密钥。

3. 服务端发送证书和证书签名证明。

4. 客户端验证：

   • 证书链。
   • CA 签名。
   • 域名。
   • 有效期。

5. 双方发送 Finished，确认握手没有被篡改。

6. 使用对称 AEAD 算法加密业务数据。

需要纠正一个过时的八股答案：

现代 TLS 1.3 通常不是“服务端给 RSA 公钥，客户端生成对称密钥并用 RSA 加密”。TLS 1.3 通常通过临时的 ECDHE 等方式协商共享密钥，证书主要用于身份认证和签名证明，业务数据再使用高效的对称加密算法保护。

TLS 1.3 标准定义了 ClientHello、ServerHello、Certificate、CertificateVerify 和 Finished 等握手消息，并将大部分握手内容加密。(RFC 编辑器)

23. 如何把 HTTP 服务升级为 HTTPS？#

面试可以回答下面几步：

1. 申请可信 CA 签发的证书。
2. 安全保存私钥和完整证书链。
3. 在 Nginx、负载均衡器或应用服务器配置 TLS。
4. 监听 HTTPS 端口。
5. 将 HTTP 请求重定向到 HTTPS。
6. 清理页面中的 HTTP 混合内容。
7. 配置证书自动续期。
8. 服务稳定后再考虑 HSTS。
9. 禁用过时 TLS 版本和弱密码套件。
10. 保证内部回源、网关和服务间调用的安全策略一致。

字节后台面经曾直接询问“如何把 HTTP 服务器升级成 HTTPS”。(牛客网)

24. HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3 有什么区别？#

25. HTTP/2 是否彻底解决了队头阻塞？#

没有。

27. GET 和 POST 有什么区别？#

不要只回答“GET 参数在 URL、POST 参数在请求体”，这只是常见使用方式，不是最本质区别。

28. 常见 HTTP 状态码有哪些？#

29. HTTP 请求和响应报文由什么组成？#

以 HTTP/1.1 为例。

1
POST /orders HTTP/1.1
2
Host: example.com
3
Content-Type: application/json
4
Content-Length: 18
5

6
{"productId":100}

1
HTTP/1.1 200 OK
2
Content-Type: application/json
3
Content-Length: 15
4

5
{"status":"ok"}

30. HTTP 为什么是无状态协议？Cookie、Session、Token 有什么关系？#

HTTP 无状态表示：

协议本身不要求服务端必须记住前一次请求的信息，每个请求都可以被独立理解。

1
服务端：Set-Cookie
2
浏览器：保存
3
后续请求：Cookie

1
Session ID → 用户登录信息

1
Cookie：浏览器保存和发送数据的机制
2
Session：服务端保存的会话状态
3
Token：用于证明身份或权限的凭证

32. WebSocket 和 HTTP 长连接有什么区别？#

HTTP 长连接只是复用连接：

1
客户端请求 → 服务端响应
2
客户端请求 → 服务端响应

它仍然主要遵循请求—响应模型。

WebSocket 在握手阶段通常先发送 HTTP Upgrade 请求，升级成功后变成独立的双向帧协议：

1
客户端 ⇄ 服务端

特点：

• 全双工。
• 服务端可以主动推送。
• 长时间保持连接。
• 使用帧区分消息。
• 支持 Ping/Pong。
• 适合聊天、实时通知、协同编辑、游戏等。

长轮询则是服务端暂时不返回 HTTP 响应，等有数据或超时后再响应，然后客户端重新发起下一次请求。它依旧是 HTTP 请求响应模式，不等同于 WebSocket。

腾讯和美团面经中都出现了 WebSocket 与 HTTP、HTTP 长连接的区别。(牛客网)

33. 什么是跨域？什么是 CORS 预检请求？#

浏览器同源通常要求以下三项全部相同：

1
协议 + 主机 + 端口

例如：

1
https://a.example.com
2
https://b.example.com

主机不同，因此是跨域。

CORS 是服务端通过响应头告诉浏览器，允许哪些来源读取响应：

1
Access-Control-Allow-Origin: https://a.example.com
2
Access-Control-Allow-Methods: GET, POST
3
Access-Control-Allow-Headers: Authorization

对于非 CORS Safelist 范围内的方法、请求头或内容类型，浏览器通常先发送 OPTIONS 预检：

1
OPTIONS 预检
2
    ↓
3
服务端允许
4
    ↓
5
发送真实请求

需要注意：

1. CORS 主要是浏览器安全机制，后端服务之间调用、curl 通常不受浏览器同源策略约束。
2. CORS 不是身份认证机制。
3. CORS 也不能代替 CSRF 防护。
4. 对于不触发预检的跨域请求，请求可能已经到达服务端，只是浏览器不允许 JavaScript 读取响应。

Fetch 标准定义了预检请求、允许方法、允许请求头和预检缓存等行为。(Fetch Specification)

35. CDN 的基本原理是什么？#

CDN 的核心是：

把内容缓存到离用户更近的边缘节点，减少访问延迟和源站压力。

常见流程：

1
用户访问域名
2
     ↓
3
DNS / CDN 调度系统选择合适边缘节点
4
     ↓
5
用户请求边缘节点
6
     ↓
7
缓存命中：直接返回
8
缓存未命中：向源站回源
9
     ↓
10
边缘节点缓存并返回结果

CDN 的收益：

• 降低网络延迟。
• 减少源站带宽。
• 降低源站 QPS。
• 缓解突发流量。
• 提高静态资源可用性。
• 可以承担 DDoS 清洗、TLS 终止等功能。

适合缓存：

• 图片。
• CSS。
• JavaScript。
• 视频分片。
• 安装包。
• 不经常变化的接口结果。

不适合直接公共缓存：

• 用户个人订单。
• 强实时库存。
• 带隐私数据的响应。
• 每个用户结果都不同的动态接口。

DNS、CDN、QUIC 和完整访问链路在字节及拼多多相关面经中都有出现；CDN 缓存行为仍要遵守具体的 HTTP 缓存和鉴权策略。(牛客网)