跳转至

应用层核心概念解析

本文档旨在系统性地梳理应用层的核心知识点，特别是针对面试中常见的问题，提供清晰、有条理的解答。

一、HTTP 协议基础

HTTP (HyperText Transfer Protocol，超文本传输协议) 是互联网上应用最广泛的一种网络协议，用于客户端和服务器之间的通信。

1.1 URI 与 URL

  • URI (Uniform Resource Identifier, 统一资源标识符)：用于唯一标识互联网上的资源。它是一个字符串标准，是 URL 和 URN 的超集。
  • URL (Uniform Resource Locator, 统一资源定位符)：是 URI 最常见的形式，我们通常称之为“网址”。它不仅标识了资源，还提供了找到该资源的方式（即协议和位置）。
  • URN (Uniform Resource Name, 统一资源名称)：也是 URI 的一种，通过名称来标识资源，而不关心其具体位置。

一个完整的 URL 通常包含以下部分： 协议://域名:端口/路径?查询参数#片段ID

  1. 协议 (Protocol)：如 http, https。
  2. 域名 (Domain)：如 www.example.com。
  3. 端口 (Port)：HTTP 默认 80，HTTPS 默认 443。
  4. 路径 (Path)：资源在服务器上的位置，如 /products/index.html。
  5. 查询参数 (Query Parameters)：向服务器传递的额外信息，如 ?id=123&type=A。
  6. 片段ID (Fragment)：指向页面内部的锚点，如 #section1。

1.2 HTTP 版本演进

HTTP/0.9

  • 最早的版本，功能简单。
  • 只支持 GET 请求方法。
  • 没有请求头和响应头的概念。
  • 服务器响应后立即关闭 TCP 连接。

HTTP/1.0

  • 引入了请求头和响应头。
  • 支持 POST, HEAD 等请求方法。
  • 增加了状态码、协议版本号、缓存等概念。
  • 默认是短连接，每次请求都需要建立一个新的 TCP 连接。

HTTP/1.1

  • 长连接 (Persistent Connection)：默认启用 Connection: keep-alive，一个 TCP 连接可以被多个 HTTP 请求复用，减少了连接建立和关闭的开销。
  • 管道化 (Pipelining)：允许客户端在同一个连接上连续发送多个请求，而无需等待前一个请求的响应。但由于队头阻塞问题，实践中效果不佳。
  • 缓存处理：引入了更强大的 Cache-Control 头部字段。
  • Host 头部：支持虚拟主机，允许一台服务器托管多个域名。
  • 断点传输：支持 Range 头部，允许只请求资源的一部分。

HTTP/2

  • 二进制分帧 (Binary Framing)：将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式编码。
  • 多路复用 (Multiplexing)：在单个 TCP 连接上，客户端和服务器可以同时发送和接收多个请求和响应，彻底解决了队头阻塞问题。
  • 头部压缩 (Header Compression)：使用 HPACK 算法压缩头部，减少了请求的开销。
  • 服务器推送 (Server Push)：服务器可以主动向客户端推送资源，而无需客户端显式请求。

HTTP/1.x 与 HTTP/2 的主要区别

  1. 传输格式：HTTP/1.x 是文本传输，HTTP/2 是二进制传输。
  2. 并发模型：HTTP/1.1 通过管道化尝试解决并发问题，但有队头阻塞；HTTP/2 通过多路复用彻底解决了这个问题。
  3. 头部处理：HTTP/1.x 头部信息是明文传输，每次都有重复；HTTP/2 使用 HPACK 算法进行头部压缩。
  4. 服务器推送：HTTP/2 允许服务器主动推送资源，而 HTTP/1.x 不支持。

1.3 HTTP 请求方法

方法 描述
GET 获取指定的资源。
POST 向指定资源提交数据进行处理，可能导致新资源的创建或已有资源的修改。
PUT 用请求中的有效载荷替换目标资源的所有当前表示。
DELETE 删除指定的资源。
HEAD 与 GET 请求相同，但响应体中没有具体内容，用于获取报头。
OPTIONS 返回服务器针对特定资源所支持的 HTTP 请求方法。
TRACE 回显服务器收到的请求，主要用于测试或诊断。
CONNECT 建立一个到由目标资源标识的服务器的隧道。

GET vs POST

  1. 目的：GET 用于获取数据，POST 用于提交数据。
  2. 参数位置：GET 的参数附加在 URL 上；POST 的参数放在请求体中。
  3. 安全性：GET 的参数在 URL 中可见，且会留在浏览器历史和服务器日志中，不应用来传输敏感信息。POST 相对更安全，但仍可通过抓包工具查看。
  4. 长度限制：URL 长度有限制（通常为 2048 字节），所以 GET 参数长度受限；POST 无此限制。
  5. 缓存：GET 请求的响应可以被缓存，POST 默认不会。
  6. 幂等性：GET 是幂等的（多次请求结果相同），POST 不是。

OPTIONS 方法详解

OPTIONS 方法主要有两个作用： 1. 检测服务器支持的方法：向服务器发起请求，检测服务器支持哪些 HTTP 方法。 2. CORS 中的预检请求 (Preflight Request)：在跨域请求中，浏览器会先发送一个 OPTIONS 请求，以检测实际请求是否被服务器接受。

1.4 HTTP 状态码

  • 1xx (信息性)：请求已接收，继续处理。
  • 2xx (成功)
    • 200 OK: 请求成功。
    • 201 Created: 请求成功，并且服务器创建了新的资源。
    • 204 No Content: 服务器成功处理了请求，但没有返回任何内容。
  • 3xx (重定向)
    • 301 Moved Permanently: 永久重定向。
    • 302 Found: 临时重定向。
    • 304 Not Modified: 资源未被修改，客户端可以使用缓存的版本。
  • 4xx (客户端错误)
    • 400 Bad Request: 服务器不理解请求的语法。
    • 401 Unauthorized: 请求要求身份验证。
    • 403 Forbidden: 服务器拒绝请求。
    • 404 Not Found: 服务器找不到请求的资源。
  • 5xx (服务器错误)
    • 500 Internal Server Error: 服务器内部错误。
    • 502 Bad Gateway: 作为网关或代理的服务器，从上游服务器收到无效响应。
    • 503 Service Unavailable: 服务器暂时无法处理请求（超载或维护）。

1.5 HTTP 报文结构

常用请求头 (Request Headers)

  • Host: 指定服务器的域名和端口号。
  • User-Agent: 客户端的浏览器和操作系统信息。
  • Accept: 客户端能接收的内容类型。
  • Accept-Encoding: 客户端能接收的编码方式（如 gzip）。
  • Accept-Language: 客户端能接收的语言。
  • Connection: 连接管理，如 keep-alive。
  • Cookie: 客户端存储的 Cookie 信息。
  • Referer: 请求的来源页面。
  • Cache-Control: 缓存控制。
  • If-Modified-Since: 用于协商缓存，值为上次服务器返回的 Last-Modified。
  • If-None-Match: 用于协商缓存，值为上次服务器返回的 ETag。

常用响应头 (Response Headers)

  • Content-Type: 响应资源的媒体类型和字符编码。
  • Content-Length: 响应体的长度。
  • Content-Encoding: 响应资源的压缩编码。
  • Server: 服务器软件信息。
  • Date: 响应产生的日期和时间。
  • Connection: 连接管理。
  • Cache-Control: 缓存控制策略。
  • Expires: 缓存过期时间。
  • Last-Modified: 资源的最后修改时间。
  • ETag: 资源的唯一标识。
  • Access-Control-Allow-Origin: 用于 CORS，指定允许跨域请求的源。

二、HTTP 深入应用

2.1 HTTP 缓存机制

HTTP 缓存是提升 Web 性能的重要手段。它通过复用之前获取的资源，减少延迟和网络流量。缓存策略分为**强制缓存**和**协商缓存**，强制缓存的优先级高于协商缓存。

缓存决策流程

  1. 浏览器发起请求，首先检查本地是否有该资源的**强制缓存**。
  2. 如果强制缓存有效（未过期），则直接从本地读取资源，HTTP 状态码为 200 (from memory/disk cache)，不与服务器通信。
  3. 如果强制缓存无效（已过期），则执行**协商缓存**。浏览器在请求头中带上缓存标识（If-Modified-Since 或 If-None-Match）。
  4. 服务器根据缓存标识判断资源是否有更新。
    • 若无更新，返回 304 Not Modified，浏览器使用本地缓存。
    • 若有更新，返回 200 OK 和最新的资源内容，浏览器使用新资源并更新本地缓存。

强制缓存 (Strong Cache)

强制缓存通过响应头中的 Expires 和 Cache-Control 字段来控制。

  • Expires (HTTP/1.0)
    • 指定一个绝对的过期时间。
    • 缺点：受客户端本地时间影响，如果客户端时间不准，可能导致缓存失效。
  • Cache-Control (HTTP/1.1)
    • 使用相对时间 max-age=... (单位秒) 来指定缓存有效期，解决了 Expires 的问题。
    • 优先级高于 Expires。
    • 常用指令：
      • public: 客户端和代理服务器都可以缓存。
      • private: 只有客户端可以缓存（默认值）。
      • no-cache: 不使用强制缓存，需要进行协商缓存。
      • no-store: 禁止任何缓存。

协商缓存 (Negotiation Cache)

协商缓存依赖于服务器和客户端之间的一次通信，来验证缓存是否仍然有效。

  • Last-Modified / If-Modified-Since (HTTP/1.0)
    • Last-Modified: 服务器在响应中告知资源的最后修改时间。
    • If-Modified-Since: 客户端在下一次请求时，通过此字段将上次收到的 Last-Modified 值发送给服务器。
    • 缺点：
      1. 时间戳只能精确到秒，一秒内多次修改无法识别。
      2. 只要文件被编辑，即使内容没变，时间戳也会更新。
  • ETag / If-None-Match (HTTP/1.1)
    • ETag: 服务器为资源生成的唯一标识（通常是文件内容的哈希值）。
    • If-None-Match: 客户端在下一次请求时，通过此字段将上次收到的 ETag 值发送给服务器。
    • 解决了 Last-Modified 的缺点，更加精确。
    • 优先级高于 Last-Modified。

如何确保资源更新？

在实际开发中，为了确保用户能及时获取更新后的静态资源（如 JS, CSS），通常采用以下策略： 1. URL 版本号：在文件名中加入版本号，如 style.v1.css。 2. 文件哈希值：在文件名中加入文件内容的哈希值，如 style.a1b2c3d4.css。这是现代前端工程化中最常用的方式。 3. 查询参数：在 URL 后附加查询参数，如 style.css?v=1.0。但部分代理服务器可能会忽略查询参数，导致缓存问题。

三、HTTPS 与网络安全

3.1 HTTP vs HTTPS

特性 HTTP HTTPS
安全性 明文传输，不安全 使用 SSL/TLS 加密，安全
端口 默认 80 默认 443
证书 不需要 需要向 CA 申请证书
连接过程 简单，无状态 包含 SSL/TLS 握手，更复杂
开销 较小 协议握手和加解密会消耗更多服务器资源和时间

HTTPS 的主要作用： 1. 内容加密：保证数据传输的机密性。 2. 身份认证：确认网站的真实性，防止钓鱼网站。 3. 数据完整性：防止内容被第三方篡改。

3.2 HTTPS 加密原理：混合加密

由于**非对称加密**非常耗时，而**对称加密**的密钥分发困难，HTTPS 采用了**混合加密**的机制，兼顾了安全性和效率。

  1. 对称加密：使用同一个密钥进行加密和解密。速度快，但密钥传输过程容易被窃取。
  2. 非对称加密：使用一对密钥：公钥和私钥。公钥加密的内容只能用私钥解密。安全性高，但速度慢。
  3. 混合加密流程：
    • 阶段一：使用非对称加密协商会话密钥
      1. 服务器将自己的**公钥**（包含在数字证书中）发送给客户端。
      2. 客户端生成一个随机的**对称密钥**（也称会话密钥）。
      3. 客户端用服务器的**公钥**加密这个**对称密钥**，然后发送给服务器。
    • 阶段二：使用对称加密传输数据
      1. 服务器用自己的**私钥**解密，获取到**对称密钥**。
      2. 之后，双方就使用这个**对称密钥**进行加密通信。

3.3 HTTPS 握手过程 (TLS 1.2 简化版)

  1. Client Hello: 客户端向服务器发起请求，包含支持的 TLS 版本、加密套件列表、一个随机数 Client Random。
  2. Server Hello: 服务器响应，确认使用的 TLS 版本和加密套件，并返回另一个随机数 Server Random。
  3. Certificate: 服务器将自己的**数字证书**（包含公钥）发送给客户端。
  4. Server Key Exchange (可选): 如果证书中的公钥不足以完成密钥交换，服务器会发送额外的数据。
  5. Server Hello Done: 服务器告知客户端，初始协商结束。
  6. Client Key Exchange: 客户端验证证书后，生成一个随机数 Pre-master Secret，用服务器的公钥加密后发送给服务器。
  7. Change Cipher Spec: 客户端通知服务器，后续通信将使用协商好的密钥进行加密。
  8. Encrypted Handshake Message: 客户端将之前所有握手消息的摘要加密后发送给服务器，供服务器验证。
  9. Change Cipher Spec: 服务器同样通知客户端，后续通信将使用加密。
  10. Encrypted Handshake Message: 服务器也将之前所有握手消息的摘要加密后发送给客户端，供客户端验证。

握手结束后，双方都拥有了 Client Random、Server Random 和 Pre-master Secret，它们会使用这三个随机数生成最终的**会话密钥**，用于后续的数据加密。

3.4 中间人攻击 (MITM)

攻击原理： 攻击者介入客户端和服务器之间，伪装成双方，窃取或篡改信息。

  1. 客户端发起请求，被攻击者拦截。
  2. 攻击者伪装成服务器，向客户端发送自己的**伪造公钥**。
  3. 客户端用伪造的公钥加密会话密钥，发送后被攻击者截获。
  4. 攻击者用自己的私钥解密，获得会话密钥。
  5. 攻击者伪装成客户端，与真实的服务器完成握手，建立加密通道。
  6. 之后，攻击者就可以用会话密钥解密双方的所有通信内容。

如何防范： HTTPS 通过**数字证书 (Digital Certificate)** 来防范中间人攻击。证书由权威的 CA (Certificate Authority) 机构颁发，包含网站的公钥、域名、有效期等信息，并由 CA 的私钥签名。

客户端（浏览器）内置了受信任的 CA 列表。当收到服务器的证书时，会用对应的 CA 公钥来验证证书的签名是否有效。如果证书是伪造的（没有受信任的 CA 签名），浏览器就会发出安全警告，从而阻止了中间人攻击。

四、DNS 域名解析

4.1 DNS 解析流程

DNS (Domain Name System) 是一个应用层协议，负责将人类可读的域名解析为机器可读的 IP 地址。

  1. 浏览器缓存：浏览器首先检查自身缓存中是否有该域名对应的 IP 地址。
  2. 操作系统缓存：如果浏览器缓存中没有，则检查操作系统的缓存（包括 hosts 文件）。
  3. 本地 DNS 服务器：如果本地缓存都没有，则向配置的本地 DNS 服务器（通常由 ISP 提供）发起请求。
  4. 根 DNS 服务器：本地 DNS 服务器会向根 DNS 服务器查询，根服务器会返回负责该顶级域名（如 .com）的 TLD (Top-level Domain) 服务器地址。
  5. TLD DNS 服务器：本地 DNS 服务器再向 TLD 服务器查询，TLD 服务器会返回负责该权威域名（如 example.com）的权威 DNS 服务器地址。
  6. 权威 DNS 服务器：本地 DNS 服务器最后向权威 DNS 服务器查询，获取到最终的 IP 地址。
  7. 返回与缓存：本地 DNS 服务器将获取到的 IP 地址返回给客户端，并自身进行缓存，以便下次快速响应。

4.2 hosts 文件

hosts 是一个没有扩展名的系统文件，用于在本地建立域名和 IP 地址的映射关系。当进行域名解析时，系统会优先检查 hosts 文件。因此，我们可以通过修改 hosts 文件来手动指定某个域名的 IP 地址，常用于开发和测试。