OSI 七层参考模型#

OSI（Open System Interconnection）是国际标准化组织（ISO）制定的网络互联理论参考模型，从上到下共分为 7 层：

• 应用层（Application Layer）：最靠近用户的顶层，直接为用户的应用程序提供网络服务与交互接口。典型协议包括 HTTP、HTTPS、FTP、SMTP、DNS 等；
• 表示层（Presentation Layer）：负责应用层数据格式的定义、语法转换、数据压缩解压以及加密解密。例如将数据从一种编码格式转换为另一种（如 ASCII、UTF-8 编码），处理 SSL/TLS 加密解密等；
• 会话层（Session Layer）：负责在网络节点间建立、管理、同步和终止端到端的通信会话。例如维持会话令牌（Token）、控制通信双方的对话方向等；
• 传输层（Transport Layer）：提供端到端（进程到进程）的通用数据传输服务，负责数据分段、流量控制、差错控制与可靠性保障。核心协议为 TCP（传输控制协议）与 UDP（用户数据报协议）；
• 网络层（Network Layer）：负责将分组数据从源节点通过跨网路由寻址发送至目的节点。核心功能包括逻辑编址（IP 地址分配）与路由选择（Routing）。代表协议有 IP、ICMP、IGMP、OSPF 等；
• 数据链路层（Data Link Layer）：在相邻节点之间的物理链路上提供可靠的帧（Frame）传输。核心功能包括物理寻址（MAC 地址）、成帧、差错检测（CRC 校验）与介质访问控制（MAC）。代表协议包括以太网协议、PPP、ARP 等；
• 物理层（Physical Layer）：在物理介质（双绞线、光纤、无线电波）上传输原始比特流（0 和 1）。规定了接口引脚规格、电气电平、时钟频率与传输速率等物理特性。

TCP/IP 四层模型#

工程实践中广泛采用的是工业标准 TCP/IP 体系架构：

• 应用层：整合了 OSI 的应用层、表示层与会话层，囊括所有面向用户与业务的高级网络协议（如 HTTP、FTP、SMTP、SSH、DNS 等）；
• 传输层：负责端到端进程间的逻辑通信、数据分割组装、可靠性交付与流量控制（TCP、UDP 协议）；
• 网际层（网络层）：负责跨网络路由与 IP 分组的传输寻址（核心协议为 IP 协议，辅助协议有 ICMP、ARP 等）；
• 网络接口层：整合了 OSI 的数据链路层与物理层，负责将 IP 数据报封装为底层网络数据帧，并在物理线缆/无线信道上传输比特流。

五层体系结构（教学折中模型）#

为了便于教学与技术分析，综合 OSI 与 TCP/IP 形成的五层折中模型：

1. 应用层：网络服务与终端用户应用程序之间的接口，提供丰富的高级通信协议；
2. 传输层：提供端到端（进程到进程）的通信管理，确保数据按需、按序、可靠/不可靠传输；
3. 网络层：负责数据包在整个互联网络中的路径规划、路由选择与主机寻址；
4. 数据链路层：负责相邻网络节点之间以“帧”为单位的可靠传输与硬件 MAC 寻址；
5. 物理层：负责网线、光纤、光模块等物理传输媒介上原始比特流的电光信号转换。

浏览器输入 URL 到页面呈现的全过程#

这是前端与后端架构面试中最经典的端到端综合考察题目，全流程可细分为以下 7 个关键步骤：

1. URL 解析：浏览器首先解析用户输入的 URL，识别出访问协议（如 https）、域名主机（如 example.com）、端口号（默认 443 或 80）以及请求路径与查询参数；
2. DNS 域名解析：浏览器需将人类可读的域名转换为目标主机的 IP 地址。依次查询：浏览器 DNS 缓存 $\to$ 操作系统 Hosts 文件及 DNS 缓存 $\to$ 本地 Local DNS 服务器 $\to$ 根域名服务器、顶级域名服务器、权威域名服务器迭代查询，最终获得对应 IP；
3. 建立 TCP 连接：浏览器使用解析得到的目标 IP 与端口，通过 TCP 三次握手 与服务端建立端到端可靠连接；若为 HTTPS 请求，在 TCP 建立后还会发起 TLS/SSL 握手，完成证书校验与会话对称密钥协商；
4. 发送 HTTP 请求：浏览器根据规范构建 HTTP 请求报文（包括请求行、请求头、空行及请求体），通过加密 Socket 通道发送给服务端；
5. 服务器处理请求并返回响应：Web 服务器（如 Nginx、Tomcat）接收并解析请求，经由后端应用程序处理（业务计算、数据库读写等），构造 HTTP 响应报文（状态行、响应头、空行、响应正文数据）并回传给浏览器；
6. 浏览器解析渲染页面：
   • 浏览器接收到响应体中的 HTML 数据，自上而下解析构建 DOM 树；
   • 解析 CSS 文件构建 CSSOM 树；
   • 将 DOM 树与 CSSOM 树合并计算为 渲染树（Render Tree）；
   • 进行 布局计算（Layout / Reflow） 确定各节点几何尺寸与位置；
   • 调用 GPU 绘制管线完成 绘制与复合（Paint & Composite），将像素光栅化呈现在屏幕上；
   • 若遇到 JavaScript 脚本，则依据 async/defer 属性下载并执行；
7. 连接断开：数据传输完成后，通过 TCP 四次挥手 安全释放连接；若 HTTP 启用了 Connection: keep-alive，则该连接会被复用以承载后续资源请求。

DNS 解析详细查询流程#

当用户在浏览器中访问某个域名时，系统按以下阶梯顺序查询 IP 地址：

1. 浏览器自身缓存：检查浏览器近期的 DNS 缓存，若命中且未过期则直接返回；
2. 操作系统缓存与 Hosts 文件：检查本机操作系统的 DNS Client 缓存和本地 hosts 静态映射文件；
3. 请求本地 DNS 服务器（Local DNS）：向本地运营商配置的 Local DNS 服务器发起递归查询请求；
4. Local DNS 迭代查询全过程：若 Local DNS 本地未命中，则代替客户端发起迭代查询：
   • 向根域名服务器（Root Server）发起查询：根域名服务器返回负责该顶级域（如 .com）的**顶级域名服务器（TLD Server）**地址；
   • 向顶级域名服务器发起查询：顶级域名服务器返回负责该二级域名的**权威域名服务器（Authoritative Server）**地址；
   • 向权威域名服务器发起查询：权威服务器最终返回该域名对应的真正目标主机 IP 地址；
5. 缓存并返回：Local DNS 将该 IP 结果在本地缓存（遵循 TTL 有效期），并将其返回给浏览器，浏览器即可发起后续网络连接。

TCP 三次握手（Three-way Handshake）#

TCP 是面向连接的可靠传输协议，在正式传输数据之前，双方必须通过“三次握手”同步初始序列号并确认双方具备双向收发能力：

1
客户端 (Client)                                  服务端 (Server)
2
    |                                                |  [LISTEN]
3
    | -------- 1. SYN=1, seq=x --------------------> |  [SYN_RCVD]
4
    |          (客户端进入 SYN_SENT)                  |
5
    |                                                |
6
    | <------- 2. SYN=1, ACK=1, seq=y, ack=x+1 ----- |
7
    |          (客户端进入 ESTABLISHED)              |
8
    |                                                |
9
    | -------- 3. ACK=1, seq=x+1, ack=y+1 ---------> |  [ESTABLISHED]
10
    |                                                |

• 第一次握手（SYN）：客户端向服务端发送连接请求报文。标志位 $SYN=1$，随机选择一个初始序列号 $seq = x$。客户端由 CLOSED 进入 SYN_SENT 状态。服务端确认了：客户端具有发送能力，服务端具有接收能力。
• 第二次握手（SYN + ACK）：服务端收到请求后同意建连，发送确认应答报文。标志位 $SYN=1, ACK=1$，随机选择服务端的初始序列号 $seq = y$，确认号设为 $ack = x + 1$。服务端由 LISTEN 进入 SYN_RCVD 状态。客户端确认了：服务端具有收发能力，客户端具有收发能力。
• 第三次握手（ACK）：客户端收到确认后，再次向服务端发送最终确认报文。标志位 $ACK=1$，序列号为 $seq = x + 1$，确认号为 $ack = y + 1$。客户端进入 ESTABLISHED 状态；服务端接收到该报文后也进入 ESTABLISHED 状态，连接成功建立。

TCP 四次挥手（Four-way Handshake）#

断开一个 TCP 连接需要通过“四次挥手”完成。由于 TCP 是全双工通信，每个方向的连接都必须单独关闭：

1
主动关闭方 (Client)                              被动关闭方 (Server)
2
    |                                                |  [ESTABLISHED]
3
    | -------- 1. FIN=1, seq=u --------------------> |  [CLOSE_WAIT]
4
    |          (主动方进入 FIN_WAIT_1)                |
5
    |                                                |
6
    | <------- 2. ACK=1, seq=v, ack=u+1 ------------ |
7
    |          (主动方进入 FIN_WAIT_2)                |  (服务端处理未发完的数据)
8
    |                                                |
9
    | <------- 3. FIN=1, ACK=1, seq=w, ack=u+1 ----- |  [LAST_ACK]
10
    |                                                |
11
    | -------- 4. ACK=1, seq=u+1, ack=w+1 ---------> |  [CLOSED]
12
    |          (主动方进入 TIME_WAIT，等待 2MSL)       |
13
    |                                                |
14
    |  [CLOSED] (2MSL 计时结束)                       |

• 第一次挥手（FIN）：主动方发送连接释放报文，$FIN=1, seq=u$。主动方停止发送应用数据，进入 FIN_WAIT_1 状态；
• 第二次挥手（ACK）：被动方收到后发出确认报文，$ACK=1, seq=v, ack=u+1$，进入 CLOSE_WAIT 状态。主动方收到后进入 FIN_WAIT_2 状态。此时连接处于半关闭状态，主动方不再发送数据，但被动方若仍有数据需发送，主动方仍需接收；
• 第三次挥手（FIN + ACK）：被动方应用层数据全部发送完毕后，向主动方发送释放连接报文，$FIN=1, ACK=1, seq=w, ack=u+1$，进入 LAST_ACK 状态；
• 第四次挥手（ACK）：主动方收到释放报文后发出最终确认包，$ACK=1, seq=u+1, ack=w+1$，主动方进入 TIME_WAIT 状态。被动方收到该 ACK 后立即进入 CLOSED 状态；主动方在 TIME_WAIT 状态等待 2MSL 后彻底进入 CLOSED 状态。

TCP 如何保证传输可靠性#

TCP 是在不可靠的 IP 网络之上构建的端到端可靠协议，核心通过以下机制保障可靠性：

• 连接管理：三次握手与四次挥手确保连接的可靠建立与优雅销毁；
• 校验和（Checksum）：首部与数据部分均参与校验，在传输层端到端检测数据比特差错。若接收方计算校验和错误，直接丢弃报文段且不发送 ACK；
• 序列号与确认应答（ACK）：TCP 为每个发送的数据字节按序编号（Sequence Number），接收方按序回复确认号（ACK Number），保证数据不重复、不遗漏、失序可重排；
• 超时重传（Retransmission）：发送方发出数据后启动 RTO 定时器，若在超时时间内未收到 ACK 则重新发送该数据包；
• 最大报文段长度（MSS）：双方在三次握手阶段协商最大段长度 MSS（通常为 MTU - 40 = 1460 字节），避免在底层 IP 层发生二次切片；
• 流量控制（Flow Control）：通过滑动窗口机制协调发送方与接收方的处理速率，防止发送过快导致接收端缓冲区溢出；
• 拥塞控制（Congestion Control）：动态感知整个网络的拥塞状况，在网络发生拥塞时主动减速，避免通信崩溃。

TCP 流量控制（滑动窗口）#

流量控制的目的是让发送端的发送速率与接收端的处理能力相匹配：

• TCP 通过滑动窗口（Sliding Window）实现流量控制。接收方在每次回复 ACK 时，会在 TCP 首部的窗口字段（Window Size）中带上当前接收缓冲区的剩余可用大小，即接收窗口 rwnd；
• 发送方根据接收到的 rwnd 限制自身连续可发送的未经确认的数据量，使得未确认数据字节数永远不超过 rwnd；
• 零窗口死锁与窗口探测：当接收方缓冲区满时会通告 rwnd = 0，发送方暂停发送。此时发送方会启动一个持续计时器（Persistence Timer），定期向接收方发送仅含 1 字节的窗口探测报文（Zero Window Probe），防止接收方后续通知窗口恢复的 ACK 报文在网络中丢失而导致双方互相永久等待的死锁。

TCP 拥塞控制四大算法#

流量控制考虑的是点对点端主机的接收能力，而**拥塞控制（Congestion Control）**则是考虑整个网络承载能力，防止因全网过载导致大量丢包。

发送方维护一个状态变量——拥塞窗口（cwnd, Congestion Window）。发送方的实际发送窗口大小受控于：

$\text{swnd} = \min(\text{cwnd}, \text{rwnd})$

TCP 重传机制演化#

• 超时重传（RTO）：设定超时时间 RTO（Retransmission TimeOut）。RTO 依据动态计算的平滑往返时间 RTT（Round-Trip Time）进行加权评估，略大于 RTT。缺点是超时周期相对较长。
• 快速重传（Fast Retransmit）：以数据为驱动的快速机制。当发送方发出报文 1、2、3、4、5，其中 2 丢失而 3、4、5 到达时，接收方连续回复 3 次针对报文 1 的重复确认（$ACK = 2$）。发送方连续收到 3 个相同的冗余 ACK 时，立即在超时计时器到期前快速补发报文 2。
• 带选择确认的重传（SACK, Selective Acknowledgment）：在 TCP 首部选项字段中添加已收到的非连续离散数据块区间（如收到 100200、300500，缺失 200~300）。发送方根据 SACK 精准且只重传缺失的数据段，避免全盘重传。
• 重复选择确认（D-SACK, Duplicate SACK）：借助 SACK 头部反向告知发送方某些数据包已被重复接收。帮助发送方准确判断是网络发生了失序、ACK 丢失还是伪重传，以便作出更智能的拥塞窗口决策。

TCP 与 UDP 的核心区别#

UDP 如何在应用层保证数据不丢失#

UDP 本身协议层不提供重传与防丢包保障，但在特定场景（如游戏同步、QUIC 协议、KCP 协议）下，可以通过在应用层自行实现可靠传输机制：

1. 引入序列号与确认机制（Seq & ACK）：在应用层报文头部自定义递增的序列号字段，接收方收到报文后回传应用层确认包；
2. 应用层超时重传：发送方维护待确认队列与定时器，若超时未收到对应的 ACK 确认则触发应用层重发；
3. 滑动窗口与乱序重排：在接收端维护乱序重组缓冲区，根据应用层序列号拼接完整的数据包流；
4. 报文持久化与断点续传：将重要交互消息在本地或服务器端进行临时持久化存储，在网络抖动或异常重连后重新拉取补齐差量。

IP 协议的核心功能#

IP（Internet Protocol）是 TCP/IP 体系网际层的核心协议，属于不可靠、无连接的数据报传输协议：

• 寻址与路由转发：在 IP 数据报首部携带源 IP 地址与目的 IP 地址。数据报在互联网络各路由器之间传输时，中间路由器根据内部动态维护的路由表计算最佳下一跳路径，逐跳转发直至抵达目标主机；
• 分段与重组：不同链路层物理介质支持的最大传输单元（MTU）不同（以太网通常为 1500 字节）。当上层数据报大小超过当前链路 MTU 时，IP 协议负责对其进行分片（Fragmentation），并在首部填充标识符、标志位与片偏移量；所有分片在抵达最终目标主机后由目标主机的 IP 层完成组装。

ARP 地址解析协议（IP $\to$ MAC）#

在局域网内进行实际数据链路层通信时，数据帧首部填写的必须是网卡的硬件 MAC 地址，ARP（Address Resolution Protocol）负责将已知的 32 位 IP 地址解析为对应的 48 位物理 MAC 地址。

GET 与 POST 的核心区别#

HTTP 报文结构#

HTTP 协议基于纯文本或二进制帧传输，其报文结构分为请求报文与响应报文：

HTTPS 工作原理与加密架构#

HTTP 采用明文传输，存在被窃听、篡改和伪装的三大安全风险。HTTPS（HTTP over SSL/TLS）在 HTTP 与 TCP 之间插入了 SSL/TLS 加密安全层。

Cookie 与 Session 的区别与协同#

常见 HTTP 状态码归类#

• 1xx（信息性状态码）：表示请求已接收，正在进一步处理：
  • 100 Continue：客户端可继续发送请求主体；
  • 101 Switching Protocols：协议升级转换（如从 HTTP 升级为 WebSocket 通信）。
• 2xx（成功状态码）：请求已被成功接收、理解并处理：
  • 200 OK：请求处理成功并返回对应内容；
  • 204 No Content：请求成功，但响应报文中不包含任何实体内容主体；
  • 206 Partial Content：客户端发起了带有 Range 头的分块请求，服务器成功返回了指定范围的部分资源（用于大文件断点续传或分段下载）。
• 3xx（重定向状态码）：需客户端采取进一步动作以完成请求：
  • 301 Moved Permanently：永久重定向，请求的资源已被永久分配了新 URI，搜索引擎会自动更新权重与索引；
  • 302 Found：临时重定向，资源临时使用新 URI 访问，搜索引擎不转移原有权重；
  • 304 Not Modified：协商缓存命中。服务器告知客户端本地缓存依然有效，客户端直接复用本地缓存资源，无需重新下载数据体。
• 4xx（客户端错误状态码）：客户端发送的请求包含语法错误或无法被满足：
  • 400 Bad Request：通用请求错误（如参数格式不匹配、JSON 语法错误）；
  • 401 Unauthorized：未经过身份认证，需要提供登录凭据；
  • 403 Forbidden：服务器已理解请求但拒绝执行，通常表示权限不足；
  • 404 Not Found：服务器找不到客户端请求的 URL 资源。
• 5xx（服务端错误状态码）：服务器在处理请求过程中发生内部错误：
  • 500 Internal Server Error：通用的服务器内部未捕获异常或程序崩溃；
  • 501 Not Implemented：服务器不支持当前请求所需的功能方法；
  • 502 Bad Gateway：作为网关或反向代理的服务器（如 Nginx）从上游应用服务器收到无效响应；
  • 503 Service Unavailable：服务器当前超载或处于停机维护中，暂时无法响应请求；
  • 504 Gateway Timeout：网关/代理服务器未能在预设时间内收到上游服务器的响应（网关超时）。