计算机网络八股2

常见端口号

1. 端口 21: FTP (文件传输协议)

  • 服务：FTP（File Transfer Protocol）
  • 用途：FTP 用于文件的上传和下载。它通过客户端和服务器之间的连接来传输文件。
  • 工作方式：FTP 默认使用 21 端口进行控制连接，数据传输通过另一个端口（通常是 20）进行。它支持匿名登录，也可以使用用户名和密码进行验证。

2. 端口 22: SSH (安全外壳协议)

  • 服务：SSH（Secure Shell）
  • 用途：SSH 用于加密的远程登录和远程命令执行。它提供了比 Telnet 和 rlogin 更加安全的方式来进行远程管理。
  • 工作方式：SSH 使用加密技术确保数据传输的安全性，防止会话被窃取或篡改。

3. 端口 23: Telnet (远程登录服务)

  • 服务：Telnet
  • 用途：Telnet 用于远程登录服务，允许用户通过网络连接到远程计算机并执行命令。
  • 工作方式：Telnet 默认使用 23 端口，但与 SSH 不同，它不加密数据，容易受到中间人攻击，因此现在很少使用，推荐使用 SSH 替代。

4. 端口 53: DNS (域名系统)

  • 服务：DNS（Domain Name System）
  • 用途：DNS 用于将域名（如 www.example.com）解析为-yh5f055knh2c/) IP 地址（如 192.168.1.1）。
  • 工作方式：DNS 服务通过 UDP 协议在 53 端口上工作。客户端向 DNS 服务器发送查询请求，服务器返回相应的 IP 地址。

5. 端口 80: HTTP (超文本传输协议)

  • 服务：HTTP（HyperText Transfer Protocol）
  • 用途：HTTP 是用于从 Web 服务器传输网页内容到浏览器的协议。它是构建万维网的基础协议。
  • 工作方式：HTTP 通常使用 TCP 连接在 80 端口上传输明文数据，因此不适合传输敏感信息。

6. 端口 443: HTTPS (超文本传输协议安全)

  • 服务：HTTPS（HyperText Transfer Protocol Secure）
  • 用途：HTTPS 是 HTTP 的加密版本，确保 Web 浏览器与服务器之间的数据传输是加密的，从而防止中间人攻击。
  • 工作方式：HTTPS 使用 SSL/TLS 协议加密通信，通过 443 端口进行连接。

7. 端口 1080: Sockets (代理服务)

  • 服务：SOCKS（Socket Secure）
  • 用途：SOCKS 是一个网络协议，用于通过代理服务器进行数据转发。它可以用于绕过网络过滤，提供更为灵活的互联网访问。
  • 工作方式：SOCKS5 是 SOCKS 协议的最新版本，支持 UDP 和 TCP 协议，通常通过 1080 端口运行。

8. 端口 3306: MySQL (数据库服务)

  • 服务：MySQL
  • 用途：MySQL 是一个开源的关系型数据库管理系统（RDBMS）。它广泛用于网站开发和企业应用程序中。
  • 工作方式：MySQL 默认使用 3306 端口进行客户端与数据库之间的连接，通过 SQL 查询语言进行数据库操作。

这些端口和服务在网络通信中扮演着重要角色，不同的服务和端口提供了不同的功能，确保计算机系统的互联互通和数据交换。

状态码

HTTP 状态码概述

HTTP 状态码用于表示服务器处理请求的结果。状态码按功能分类，共分为五类：

  1. 1xx - 信息性状态码 表示服务器接收到请求，需要继续处理。常见的 1xx 状态码有：
    • 100 Continue：服务器接收到请求，客户端应继续发送请求体。
    • 101 Switching Protocols：服务器根据客户端的请求，切换协议。
  2. 2xx - 成功状态码 表示请求成功，服务器已处理并返回所请求的资源。常见的 2xx 状态码有：
    • 200 OK：请求成功，服务器返回所请求的资源。
    • 201 Created：请求成功，且服务器创建了新的资源。
    • 204 No Content：请求成功，但没有返回内容。
  3. 3xx - 重定向状态码 表示需要客户端进一步操作才能完成请求。常见的 3xx 状态码有：
    • 301 Moved Permanently：请求的资源已被永久移动到新位置。
    • 302 Found（曾为 "Moved Temporarily"）：请求的资源临时移动到新位置，客户端继续使用原地址。
    • 304 Not Modified：资源未修改，可以使用缓存的内容。
  4. 4xx - 客户端错误状态码 表示客户端请求有错误，服务器无法处理。常见的 4xx 状态码有：
    • 400 Bad Request：请求格式错误，服务器无法理解。
    • 401 Unauthorized：请求未授权，需登录才能访问。
    • 403 Forbidden：服务器拒绝请求，即使用户已认证。
    • 404 Not Found：请求的资源不存在。
  5. 5xx - 服务器错误状态码 表示服务器发生错误，无法完成请求。常见的 5xx 状态码有：
    • 500 Internal Server Error：服务器内部错误，无法处理请求。
    • 502 Bad Gateway：网关服务器无法获取上游服务器的有效响应。
    • 503 Service Unavailable：服务器暂时无法处理请求，通常是因为过载或维护。

301 和 302 的区别

  • 301 Moved Permanently（永久移动） 说明请求的资源已经永久移动到新的 URL。此时，客户端应该使用新 URL 进行后续请求，并且搜索引擎等也会更新其索引记录。
  • 302 Found（临时移动） 表示请求的资源临时性移动到新的位置，客户端仍然应该使用原地址进行后续请求，除非明确告知后续永久使用新地址。

总结：

  • 1xx：需要继续操作。
  • 2xx：请求成功。
  • 3xx：重定向，进一步操作。
  • 4xx：客户端错误。
  • 5xx：服务器错误。

HTTP请求方式

HTTP协议中定义了多种请求方式，用于指示客户端请求的目的。常见的请求方式有：

  1. GET：用于请求检索指定的资源。GET请求不应有副作用，因此应该只用于获取数据，并且是幂等的，即多次执行相同的GET请求应该返回相同的结果，不会改变资源的状态。
  2. POST：用于向指定资源提交数据，请求服务器进行处理（如提交表单或上传文件）。POST请求的参数通常包含在请求体中。POST请求可能会创建新的资源或修改现有资源。
  3. DELETE：用于删除指定的资源。
  4. PUT：用于替换指定的资源。如果指定的资源不存在，可以创建一个新资源。
  5. HEAD：类似于GET请求，但返回的响应中没有实际内容，只包含响应头部，用于检查资源的存在性或验证资源的更新时间。
  6. OPTIONS：用于获取服务器支持的HTTP请求方法，通常用于跨域请求的预检（CORS）请求。
  7. TRACE：回显服务器收到的请求，主要用于调试和测试。由于安全问题，很多服务器会禁用TRACE请求。
  8. CONNECT：用于在客户端和服务器之间建立一个加密的隧道，通常用于SSL/TLS代理。

HTTP的GET方法可以实现写操作吗？

从理论上讲，GET 方法可以执行写操作，但不推荐。使用GET方法进行写操作可能导致严重的安全风险，尤其是跨站请求伪造（CSRF）等问题。正确的做法是，使用POST、PUT、DELETE等方法来处理数据的修改或删除操作。

什么是幂等？

幂等（Idempotence）是一个数学概念，表示执行同一个操作多次，其效果与执行一次相同。在HTTP中，幂等方法是指不论操作执行多少次，结果都是一致的，不会改变系统的状态。

  • 幂等的方法：GET、HEAD、PUT、DELETE。
    • 例如，GET /pageX HTTP/1.1 是幂等的。连续多次调用相同的GET请求，客户端接收到的结果应该是一样的。
    • DELETE /idX/delete 是幂等的：即使多次请求删除同一资源，最终的状态也不会发生变化。例如：
      • 第一次请求：返回200（成功删除）。
      • 第二次请求：返回404（已删除，资源不存在）。
  • 非幂等的方法：POST。
    • POST通常用于创建新资源或提交数据，重复执行POST可能导致不同的结果，因此它不是幂等的。

总结：

  • 幂等操作：GET、PUT、DELETE、HEAD。
  • 非幂等操作：POST。

GET 和 POST 请求的区别：

  1. 目的：
    • GET：主要用于从服务器获取数据。它请求的数据通常是公共的，获取后不改变资源的状态。
    • POST：用于向服务器提交数据，通常是用于创建或修改资源。数据被包含在请求体中，可能会改变资源的状态。
  2. 数据传输方式：
    • GET：将数据附加在 URL 后面（通过查询字符串）。例如：GET /search?q=apple
    • POST：数据被包含在请求体中，因此不会暴露在 URL 中。
  3. 数据长度：
    • GET：由于数据附加在 URL 后，URL 的长度有限制（通常为 2048 字符）。因此，适用于小量数据。
    • POST：没有数据长度限制，可以提交大量的数据。数据量取决于服务器和客户端的配置。
  4. 缓存：
    • GET：由于 GET 请求的目的是获取数据，且请求的内容通常是静态的，因此浏览器可以缓存 GET 请求的响应，以提高性能。
    • POST：POST 请求的数据通常会导致服务器状态发生改变，因此不适合缓存。
  5. 安全性：
    • GET：由于数据附加在 URL 后，容易被他人看到，可能会导致安全问题（如泄露敏感信息）。比如，URL 可以被浏览器历史记录、日志记录等方式泄露。
    • POST：POST 请求的数据存放在请求体中，不会直接暴露在 URL 中，因此比 GET 更安全一些。但要注意，POST 请求并不意味着数据加密，敏感数据应该通过 HTTPS 传输。
  6. 幂等性：
    • GET：是幂等的，即多次执行相同的 GET 请求应返回相同的结果，不会改变资源的状态。
    • POST：不是幂等的，重复执行相同的 POST 请求可能导致不同的结果（如多次创建相同资源）。
  7. 用例：
    • GET：适用于获取数据或查询资源。例如，查看网页内容、获取图片等。
    • POST：适用于提交数据或提交表单，例如，用户登录、提交订单、上传文件等。

总结：

特性 GET POST
目的 获取数据 提交数据
数据位置 参数附加在 URL 后 参数包含在请求体中
数据大小 受限于 URL 长度（通常 2048 字符） 没有大小限制
缓存 可缓存，浏览器可能缓存响应 不缓存
安全性 数据暴露在 URL 中，存在安全风险 数据包含在请求体中，相对安全一些
幂等性 是幂等的，多次请求结果相同 不是幂等的，多次请求结果可能不同
用途 用于请求数据（如网页、图片等） 用于提交表单数据、创建或修改资源

总的来说，GET 适用于获取数据，POST 适用于提交数据或进行操作，二者的选择取决于请求的目的和数据的性质。

GET 请求的长度限制：

在 HTTP 协议中，GET 请求是通过 URL 传递数据的，而 URL 本身并没有明确的长度限制。实际上，限制 GET 请求长度 的因素是浏览器和服务器的配置。不同的浏览器和 Web 服务器对 URL 长度有不同的限制。

浏览器的 URL 长度限制：

  1. Internet Explorer (IE)：最大支持的 URL 长度约为 2048 个字符（大约 2KB）。
  2. Firefox：最大支持的 URL 长度为 65536 个字符（大约 64KB）。
  3. Chrome：最大支持的 URL 长度为 8192 个字符（大约 8KB）。
  4. Safari：与 Chrome 类似，最大支持的 URL 长度为 8192 个字符。

实际影响：

  • 限制原因：这些限制并不仅仅是对数据部分的限制，而是对 整个 URL 的长度限制。URL 包括了协议部分（如 http://）、主机名、路径、查询参数等。
  • 浏览器差异：不同的浏览器可能会对 URL 长度有所不同的限制，所以跨浏览器开发时，需要考虑这一差异。
  • 服务器限制：除了浏览器，服务器本身也会限制请求的最大 URL 长度。对于大多数 Web 服务器（如 Apache 或 Nginx），默认的 URL 长度限制通常设置为 8KB 或 16KB，可以在服务器配置中进行调整。

为什么 GET 请求有长度限制：

  • URL 传递数据的方式：由于 GET 请求通过 URL 传递数据，因此 URL 的长度必须有限制。如果数据过长，可能会导致请求失败或无法正确传递数据。
  • 浏览器与服务器的兼容性：不同的浏览器和服务器对 URL 长度的处理能力不同，过长的 URL 可能会导致请求无法被正常处理。

总结：

  • GET 请求的 URL 长度限制通常取决于浏览器和 Web 服务器的配置。
  • 常见的限制：IE 大约 2048 字符，Firefox 和 Chrome 可以支持更多的字符，最多达到 65536 或 8192 字符。
  • 注意事项：由于 GET 请求会将数据附加在 URL 中，传输大量数据时应避免使用 GET 请求，通常建议使用 POST 请求来传递较长的数据。

表格总结：

浏览器 最大支持 URL 长度
Internet Explorer (IE) 2048 字符 (2KB)
Firefox 65536 字符 (64KB)
Chrome 8192 字符 (8KB)
Safari 8192 字符 (8KB)

因此，在开发中，如果需要传递较长的数据，最好避免使用 GET 请求，改用 POST 请求，它没有数据长度限制，适合处理大量数据。

HTTP 请求的过程与原理：

HTTP（超文本传输协议）是基于 TCP/IP 协议 的应用层协议，通常用于客户端与服务器之间的通信。HTTP 请求的过程可以分为几个主要步骤：

HTTP 请求的过程：

  1. DNS 解析：
    • 当客户端（通常是浏览器）在地址栏输入 URL 时，首先需要将该 URL 中的域名解析成 IP 地址。客户端通过 DNS（域名系统）查询来获取服务器的 IP 地址。
  2. 建立 TCP 连接：
    • 通过解析出的 IP 地址，客户端和服务器建立 TCP 连接。此过程包括 TCP 三次握手：客户端发送 SYN 包，服务器回应 SYN-ACK 包，最后客户端再发送 ACK 包，连接建立。
  3. 发送 HTTP 请求：
    • 在建立好 TCP 连接后，客户端向服务器发送 HTTP 请求。请求中包含请求方法（如 GET、POST）、目标资源的路径、请求头等信息。客户端可以通过 HTTP 请求携带一些数据（如表单数据、查询参数等）。
  4. 服务器处理请求：
    • 服务器接收到 HTTP 请求后，解析请求头、请求方法和请求路径等信息。根据请求的内容，服务器执行相应的操作（如查询数据库、处理表单数据、返回文件等）。
  5. 服务器返回 HTTP 响应：
    • 服务器处理完请求后，返回一个 HTTP 响应。响应中包含响应代码（如 200 OK、404 Not Found）、响应头和响应体（通常是请求的资源或错误信息）。
  6. 浏览器渲染页面：
    • 客户端（浏览器）收到 HTTP 响应后，根据响应中的内容进行渲染。比如，如果是 HTML 页面，则会解析 HTML 代码并展示页面内容；如果是图像或其他资源，则会相应地处理和显示。
  7. 关闭 TCP 连接：
    • 一旦响应处理完毕，客户端与服务器通过 TCP 协议断开连接。这个过程通常通过 四次挥手 实现，确保连接的关闭。

HTTP 请求是同步的：

HTTP 请求遵循 客户端-服务器 模型，客户端在发送请求后必须等待服务器的响应，期间不能发送其他请求。因此，HTTP 请求过程是 同步的。客户端会在等待响应时被阻塞。

如何利用多线程进行数据下载：

为了提高下载效率，可以使用 多线程 下载技术，特别是在下载大文件时，可以通过将文件分块下载来加速过程。以下是使用多线程下载文件的基本步骤：

  1. 获取文件大小：
    • 使用 HTTP 请求头中的 HEAD 方法，客户端可以向服务器请求文件的总大小，以便将文件分割成适合多线程下载的大小。
  2. 分块下载：
    • 根据文件的总大小和设置的线程数，客户端将文件分成多个块，每个线程下载文件的一部分。
    • 使用 HTTP 请求头的 Range 字段来指定每个线程下载的字节范围。例如，Range: bytes=0-1023 表示下载文件的前 1024 字节。
  3. 多线程下载：
    • 启动多个线程，每个线程负责下载一个文件块，下载完成后将文件块保存到本地指定位置。
  4. 合并文件：
    • 多线程下载后，所有下载的文件块会合并成一个完整的文件。

📄 HTTP 报文结构详解（请求报文 + 响应报文）

HTTP 报文是浏览器和服务器之间通信的载体，主要分为两类：

  • 请求报文（Request Message）：浏览器发给服务器
  • 响应报文（Response Message）：服务器发给浏览器

一、HTTP 请求报文结构

一个 HTTP 请求报文由以下四部分组成：

1️⃣ 请求行（Request Line）

格式如下：

1
<方法> <请求路径> <协议版本>

示例：

1
GET /login HTTP/1.1

说明：

  • GET：请求方法（如 GET、POST、PUT、DELETE 等）
  • /login：请求的资源路径
  • HTTP/1.1：HTTP 协议版本

2️⃣ 请求头（Request Headers）

格式如下：

1
字段名: 字段值

示例：

1
2
3
Host: www.example.com
User-Agent: MyBrowser/1.0
Accept: text/html

常见字段解释：

  • Host：目标服务器域名和端口
  • User-Agent：客户端信息（浏览器/操作系统）
  • Accept：客户端可以处理的媒体类型（如 text/html）
  • Content-Type：请求体中数据的类型（如 application/json）
  • Range：请求资源的部分内容（如 Range: bytes=0-1023）

3️⃣ 空行（CRLF）

头部结束标志，一行空行表示头部结束，接下来是正文（如果有）。

4️⃣ 消息正文（Body，可能为空）

说明：

  • GET 请求一般没有消息体
  • POST、PUT 请求一般包含消息体，例如表单数据、JSON 等

示例（表单数据）：

1
username=admin&password=123456

二、HTTP 响应报文结构

HTTP 响应报文也由四个部分组成：

1️⃣ 状态行（Status Line）

格式如下：

1
<协议版本> <状态码> <状态描述>

示例：

1
HTTP/1.1 200 OK

说明：

  • 协议版本：通常是 HTTP/1.1
  • 状态码：三位数字表示结果（如 200、404、500）
  • 状态描述：状态码的英文描述（如 OK、Not Found）

2️⃣ 响应头（Response Headers）

格式：

1
字段名: 字段值

示例：

1
2
3
Content-Type: text/html
Content-Length: 256
Server: MyServer/1.0

常见字段解释：

  • Content-Type：响应内容的 MIME 类型
  • Content-Length：响应体的字节长度
  • Server：服务器名称和版本
  • Expires：响应内容的过期时间
  • Last-Modified：内容的最后修改时间

3️⃣ 空行（CRLF）

响应头和响应体之间用一行空行分隔。

4️⃣ 响应正文（Body）

说明：

  • 服务器返回的内容，比如 HTML 页面、JSON 数据等
  • 某些响应（如 204 No Content）不包含消息体

示例：

1
2
3
<html>
  <body>登录成功</body>
</html>

✅ 总结对比表

项目 请求报文 响应报文
起始行 请求行（方法 + 路径 + 版本） 状态行（版本 + 状态码 + 状态描述）
头部字段 请求头（Host、UA、Accept 等） 响应头（Content-Type、Server 等）
空行 分隔头和正文 分隔头和正文
消息正文 可选，POST 中常有 可选，返回的网页/数据

🌐 URI 和 URL 的区别详解

一、定义

✅ URI（Uniform Resource Identifier）统一资源标识符

作用：在 Web 中标识某个资源的“统一名称”或“身份标识”。

它只需要唯一标识这个资源，不一定说明在哪里，也不一定说明怎么访问它。

✅ URL（Uniform Resource Locator）统一资源定位符

作用：是 URI 的一个子集，不仅标识了资源，还指明了资源的位置和访问方式（协议）。 URL 不仅告诉你“是哪个资源”，还告诉你“在哪里”以及“怎么访问”。

二、通俗比喻

项目 比喻 说明
URI 身份证 唯一标识一个人，但不告诉你他在哪
URL 家庭住址 + 开门方式 不仅知道是张三，还知道张三在哪、怎么找到他（比如走路、打车、打电话）

三、自编示例

🌟 示例 1：URI（可能不包含访问方式）

1
student:张三

说明：这里标识了一个叫“张三”的学生资源，但不知道怎么访问。

🌟 示例 2：URL（提供完整的访问路径）

1
https://university.edu/students/zhangsan

说明：这是一个标准的 URL，包含：

  • 协议：https（表示通过 HTTPS 协议访问）
  • 主机名：university.edu
  • 路径：/students/zhangsan

我们可以通过这个地址，访问到张三的学生资料页面。

四、组成结构对比

类型 格式结构 含义
URI scheme:[//authority]path[?query][#fragment] 资源标识符格式
URL 协议://主机/路径?查询参数#片段标识符 更具体的资源位置和访问方式

五、总结表格

对比点 URI URL
全称 Uniform Resource Identifier Uniform Resource Locator
是否唯一标识 ✅ 是 ✅ 是（因为是 URI 子集）
是否包含访问方式 ❌ 不一定包含 ✅ 包含（如 http、ftp、mailto）
是否指明位置 ❌ 不一定 ✅ 提供资源位置
关系 更通用，父集 更具体，子集

六、额外说明：还有 URN

  • URN：Uniform Resource Name，统一资源名称，仅用于标识资源，不含位置信息。
  • 示例：urn:isbn:978-7-302-13389-9 → 标识某本图书的国际标准书号

所以我们有如下包含关系： URL ⊆ URI，**URN ⊆ URI

🌐 HTTP/1.0 vs HTTP/1.1 vs HTTP/2.0 区别详解

一、背景介绍

HTTP（HyperText Transfer Protocol）是万维网上的基础协议。随着互联网发展，为了解决性能瓶颈和资源浪费问题，HTTP 协议经历了三个关键版本的演进：

  • HTTP/1.0（1996）
  • HTTP/1.1（1997）
  • HTTP/2.0（2015）

二、对比总览表

特性 HTTP/1.0 HTTP/1.1 HTTP/2.0
是否持久连接 ❌ 默认短连接 ✅ 默认长连接（Keep-Alive） ✅ 多路复用，不再区分长短连接
请求并发 ❌ 无法并发 ❌ 有队头阻塞 ✅ 真正并发请求（多路复用）
编码格式 文本（ASCII） 文本（ASCII） 二进制
头部压缩 ❌ 无 ❌ 无 ✅ 支持（HPACK 算法）
服务端推送 ❌ 无 ❌ 无 ✅ 支持 Server Push
管道化（Pipelining） ❌ 不支持 ✅ 支持（但实际使用较少） ❌ 不需要此机制，已被多路复用替代
状态保持 ❌ 无 ✅ 支持 Cache/ETag 等 ✅ 更强（加密、压缩、复用）

三、版本详解

✅ HTTP/1.0

  • 无状态协议：每次请求彼此独立，服务器不会记住前一次请求的任何信息。

  • 短连接（非持久连接）：每次请求-响应后，TCP 连接即关闭。

  • 缺点：

    • 同一网页多资源（HTML + CSS + JS + 图片）需要多次建立连接，浪费带宽与延迟时间。

  • 举例：

    1
    2
    GET /index.html HTTP/1.0
    Host: example.com

✅ HTTP/1.1

  • 持久连接：默认启用 Connection: keep-alive，多个请求可复用一个 TCP 连接，降低延迟和资源浪费。
  • 请求流水线（Pipelining）：客户端可以并行发送多个请求，但仍需按顺序接收响应。
  • 缓存机制：支持 ETag、Cache-Control 等缓存控制字段。
  • 分块传输（Chunked Transfer Encoding）：可以边生成边发送内容，不用提前知道内容长度。
  • 虚拟主机支持：通过 Host 头区分同 IP 下多个网站。
  • 缺点：
    • 仍存在 队头阻塞（Head-of-line Blocking）：前一个请求未完成，后面的响应无法返回。

✅ HTTP/2.0

  • 二进制分帧（Binary Framing Layer）：
    • 所有请求和响应都分为帧（Frame），并用流（Stream）编号，性能更高。
  • 多路复用（Multiplexing）：
    • 同一 TCP 连接上并发多个请求/响应，互不干扰，彻底消除队头阻塞。
  • 头部压缩（HPACK 算法）：
    • 减少冗余的请求头大小，降低网络带宽使用。
  • 服务器推送（Server Push）：
    • 服务器可以主动发送客户端可能需要的资源，提升首屏加载速度。
  • 举例（简化）：
    • 浏览器请求 index.html 后，服务器主动推送 style.css 和 script.js，无需客户端再发请求。

四、通俗类比

类比 HTTP/1.0 HTTP/1.1 HTTP/2.0
派送快递 每送一个快递都重新建一次路（短连接） 送完一个快递，不拆路，继续派下一个（长连接） 同一条路多个车道并行派快递，互不阻塞（多路复用）

五、总结记忆口诀

“一短一长二复用，二进二压二推送。”

  • HTTP/1.0：短连接
  • HTTP/1.1：长连接 + 管道化
  • HTTP/2.0：多路复用 + 二进制 + 头部压缩 + 服务端推送

🌐 HTTP/3 知识

一、HTTP/3 是什么？

  • HTTP/3 是最新一代超文本传输协议
  • 与前代最大的不同是：
    • HTTP/1.1 和 HTTP/2 基于 TCP
    • HTTP/3 基于 QUIC（Quick UDP Internet Connections）协议，这是一个基于 UDP 的新型传输层协议。

二、为什么从 TCP 改用 QUIC？

原因一：TCP 的队头阻塞（Head-of-line Blocking）

  • 在 HTTP/2 中，虽然支持多路复用，但底层用的是 TCP。
  • 一旦某个 TCP 包丢了，必须等待这个包重传，整个连接都要等，其他流也被阻塞。
  • 类比：一辆货车轮胎爆了，后面所有车都堵着动不了。

原因二：TCP + TLS 握手过程复杂、慢

  • 建立一个 HTTPS 连接，需要至少：
    • 3 次 TCP 握手
    • 1~2 次 TLS 握手
    • 总共 至少 3~4 个往返时间（RTT）

三、HTTP/3 的关键特性

特性 描述
✅ 基于 QUIC 协议 QUIC 是运行在 UDP 之上的传输协议，替代了 TCP
✅ 真正无队头阻塞 每个流独立传输，一个包丢了不会影响其他流
✅ 集成 TLS 加密 建立连接时就完成 TLS 加密握手（TLS 1.3）
✅ 0-RTT 连接恢复 再次连接同一服务器时可跳过握手，几乎“秒连”
✅ 更低延迟 减少了连接建立时间，对移动网络更友好
✅ 支持多路复用 和 HTTP/2 一样，也支持多路复用（更彻底）

四、HTTP 协议版本演进图

1
2
3
HTTP/1.0 → HTTP/1.1 → HTTP/2.0 → HTTP/3.0
    TCP       TCP        TCP         UDP + QUIC
   短连接     长连接     多路复用     多路复用 + 无阻塞 + TLS整合

五、QUIC vs TCP 对比

对比项 TCP QUIC
协议类型 面向连接，基于 IP 基于 UDP，自定义连接层
多路复用 存在队头阻塞问题 真正无阻塞
加密机制 TLS 分离，需要额外握手 内置 TLS 1.3，零延迟加密
首次连接延迟 高（需要多轮握手） 更低（握手即加密）
应用场景 普遍使用 更适合高延迟/弱网场景

六、当前 HTTP 协议的使用情况（数据参考：w3techs）

  • 截止 2022 年初：
    • HTTP/2 使用率约为 46.9%
    • HTTP/3 使用率正在快速增长
  • 原因是：
    • 许多浏览器（Chrome、Firefox、Edge）和大型服务商（Google、Facebook、Cloudflare）已部署 HTTP/3。
    • 但许多小网站/企业服务器未启用 QUIC，还在使用 HTTP/1.1 或 HTTP/2。

七、通俗类比

  • TCP 就像高速公路，一旦前车出事故，后面全堵住（队头阻塞）
  • QUIC 就像高空无人机快递，每架都独立飞行，互不干扰

🔗 HTTP 长连接（Keep-Alive）

一、什么是 HTTP 长连接？

  • HTTP 长连接（Persistent Connection）：指客户端和服务器之间，在一次 HTTP 请求响应完成后，连接不立即关闭，而是保留连接用于后续请求复用。
  • 核心目的：节省 TCP 连接开销（建立/关闭代价高）。
  • 也称为：HTTP Keep-Alive

二、长连接的演进版本支持

HTTP 版本 长连接支持情况
HTTP/1.0 默认关闭，需要手动添加 Connection: keep-alive 才开启
HTTP/1.1 默认开启长连接，除非显式设置 Connection: close
HTTP/2 默认长连接 + 支持多路复用（多个流共用一条连接）
HTTP/3 基于 QUIC，天然支持多流 + 保持连接

三、如何开启长连接？

在 HTTP 请求头中添加字段：

1
Connection: keep-alive

示例：

1
2
3
GET /index.html HTTP/1.1
Host: example.com
Connection: keep-alive

服务端响应中也应包含：

1
2
Connection: keep-alive
Keep-Alive: timeout=5, max=100
  • timeout=5 表示连接保持 5 秒
  • max=100 表示最多处理 100 个请求后关闭

四、为什么需要长连接？

  1. 减少连接建立开销
    • TCP 建立连接需要三次握手，关闭需要四次挥手
    • 每次请求都建立/关闭连接非常浪费资源
  2. 提高性能
    • 多个资源（如 HTML + JS + CSS + 图片）可以复用同一连接
  3. 避免端口资源耗尽
    • 短连接会频繁占用新的端口，可能导致端口耗尽

五、HTTP 长连接的超时机制

连接不能永远保持，操作系统与服务器都会设置连接超时时间：

1. HTTP 层的 keep-alive timeout

  • 由服务器（如 Apache/Nginx）控制，称为 KeepAliveTimeout

  • 超时时间内若无新请求，就关闭连接

  • 示例配置：

    1
    2
    3
    KeepAlive On
    MaxKeepAliveRequests 100
    KeepAliveTimeout 5

六、TCP 层的 Keep-Alive 机制（更底层）

长连接依赖的 TCP 连接也可能由于网络故障被“静默断开”。为避免资源浪费，TCP 有自己的 探活机制：

Linux 系统中三个关键参数：

参数 含义
tcp_keepalive_time = 1800（秒） 连接空闲多长时间后开始探测（默认30分钟）
tcp_keepalive_intvl = 15（秒） 两次探测包之间的间隔
tcp_keepalive_probes = 5 最多探测几次无响应就放弃连接

举例说明：

  • TCP 连接空闲 30 分钟后，开始每 15 秒发送一次探测包
  • 如果连续 5 次无回应，系统会关闭该连接

设置方法示例（Linux）：

1
2
3
sysctl -w net.ipv4.tcp_keepalive_time=1800
sysctl -w net.ipv4.tcp_keepalive_intvl=15
sysctl -w net.ipv4.tcp_keepalive_probes=5

八、面试常问点总结 ✅

问题 答案
长连接如何实现？ Connection: keep-alive，HTTP/1.1 默认开启
和 TCP keepalive 有什么关系？ TCP keepalive 是底层机制，防止连接“死挂”，不属于 HTTP 协议内容
长连接是否一直存在？ 否，会在空闲超时、达到最大请求数、主动关闭时断开
长连接与多路复用关系？ HTTP/1.1 长连接只能串行处理，HTTP/2 支持多路复用，多个请求并发处理

🔐 HTTP 与 HTTPS 区别

一、基础定义

协议 全称 简要说明
HTTP HyperText Transfer Protocol 超文本传输协议，明文传输
HTTPS HTTP Secure / HTTP over TLS 加密的 HTTP，基于 SSL/TLS

二、核心区别总结（常考）

区别项 HTTP HTTPS
安全性 不安全，明文传输 安全，使用 TLS/SSL 加密传输
默认端口 80 443
URL 开头 http:// https://
加密机制 无 TLS：非对称 + 对称混合加密
证书机制 无 有，依赖 CA 签发的数字证书
性能开销 低 稍高（握手耗时 + 加解密运算）
SEO 无利好 对排名友好，Google 建议使用 HTTPS
应用场景 普通网站 涉及登录、支付、隐私信息的网站

三、为什么需要 HTTPS？

HTTP 存在三大安全问题：

  1. 内容被窃听：中间人可监听通信内容（抓包分析）
  2. 内容被篡改：可劫持请求，替换网页、注入广告
  3. 身份伪造：攻击者伪装成目标服务器骗取敏感信息

✅ HTTPS 可有效解决以上三点，提供：

  • 加密：内容加密传输，防监听
  • 校验：内容校验，防篡改
  • 认证：通过数字证书验证服务器身份，防伪造

四、HTTPS 的加密机制

HTTPS 并不是使用一种加密方式，而是两种配合使用：

1. 非对称加密（用于密钥协商）

  • 服务器有一对密钥：公钥（公开）、私钥（保密）
  • 客户端用公钥加密“随机对称密钥”
  • 服务器用私钥解密，得出这个密钥

优点：安全传输密钥 缺点：效率低（加密慢）

2. 对称加密（用于实际通信）

  • 客户端与服务器用协商出的对称密钥进行加密通信
  • 加解密速度快，适合大量数据传输

五、HTTPS 建立连接的过程（握手流程）

1
2
3
4
5
6
7
8
9
10
客户端：你好，我要访问你，请把你的数字证书发给我
服务端：这是我的证书（含公钥、签名、有效期等）

客户端验证证书是否合法（CA 签发、是否过期等）

验证通过：
客户端：我用你的公钥加密了一个“随机对称密钥”，你收好
服务端：收到，用私钥解密得到了对称密钥

之后双方使用“对称密钥”开始安全通信

六、HTTPS 中的数字证书（SSL 证书）

内容包括：

  • 网站公钥
  • 证书颁发机构（CA）
  • 有效期
  • 域名
  • 签名等

作用：

  • 保证公钥属于目标网站
  • 避免中间人伪造服务器身份

颁发流程：

企业申请证书 → CA 审核 → 生成证书 → 配置到服务器

七、HTTPS 的性能开销问题

  • 首次连接耗时更高（TLS 握手 + 证书验证）
  • 加解密有计算成本
  • 可使用会话复用（Session Resumption）和 HTTP/2 多路复用 减少影响

八、HTTP → HTTPS 迁移常见问题

问题 解法
HTTPS 证书要钱？ 有免费证书（Let’s Encrypt）
会导致网站变慢？ 否，只影响首次握手，使用缓存、优化TLS配置可规避
所有资源都要 HTTPS？ 是，混合内容会被浏览器拦截
是否支持 HTTP/2？ 是，主流浏览器只有 HTTPS 才支持 HTTP/2

九、常见面试问法总结 ✅

面试问题 快速要点回答
HTTP 和 HTTPS 区别？ 是否加密、端口、证书、安全性等
为什么 HTTPS 更安全？ SSL/TLS 加密 + 证书校验
HTTPS 是对称还是非对称？ 两者结合：协商密钥用非对称，传输数据用对称
HTTPS 的握手流程？ 客户端验证证书 → 生成对称密钥 → 加密通信
HTTPS 一定安全吗？ 证书可信、TLS 配置合理、安全防御措施完善才安全

🌐 HTTPS 建立连接与安全通信详解笔记

一、HTTPS 连接建立的两阶段

HTTPS 连接基于 SSL/TLS 协议，包含两个阶段：

1️⃣ 握手阶段（建立安全信道）

确保双方协商一个安全的 对称密钥，并验证服务器身份。

  1. 客户端 → 服务器：发起连接请求，包含支持的加密算法、TLS 版本等。
  2. 服务器 → 客户端：返回 数字证书（含公钥、公钥算法、证书颁发机构 CA 签名等信息）。
  3. 客户端验证证书：
    • 检查是否被可信 CA 签发
    • 检查域名是否匹配
    • 检查是否在有效期内
  4. 客户端生成一个随机会话密钥（称为 Pre-Master Secret），并使用服务器公钥加密，发送给服务器。
  5. 服务器使用私钥解密，获得 Pre-Master Secret，并生成对称加密所用的 Session Key。
  6. 客户端和服务器确认加密参数一致，握手完成。

握手过程中的加密：非对称加密（RSA 或 ECDHE）

2️⃣ 数据传输阶段（使用对称加密）

  • 使用刚刚协商的 Session Key 进行数据加密和完整性校验（HMAC）。
  • 传输的内容如：HTTP 请求头、请求体、响应头、响应体，全部都被加密。

传输过程使用：对称加密（如 AES、ChaCha20）

二、HTTPS 会加密 URL 吗？

✅ 是的，但要分清楚：

部分 是否加密 说明
URL 的路径和参数 ✅ 属于 HTTP 报文的一部分，会被 TLS 加密
域名（Host） ❌ 在 TLS 握手前就发送，明文暴露（用于 SNI）
IP 地址 ❌ 由 DNS 查询获取，和 TLS 无关，明文传输
浏览器历史/服务器日志中的 URL ❌ 本地或服务器端保存，需额外保护（如脱敏）

🔺结论：不要在 URL 参数中放敏感信息，如密码、token！

三、中间人攻击（MITM）

✅ 定义：

攻击者截获并修改客户端与服务器之间的通信，伪装成通信双方，以窃听或篡改信息。

🚨 场景：

  1. 公共 WiFi 热点（伪造 DNS 或网关）
  2. 安装了伪造 CA 的浏览器或手机
  3. 没有校验证书的客户端（如部分移动端）

🛡️ HTTPS 的防护措施：

  • 使用由可信 CA 签发的数字证书
  • 客户端必须验证证书合法性
  • 若验证失败，浏览器会报“证书不可信”并阻止连接

四、HTTPS 是否可以抓包？

✅ 可以，但通信内容是加密的。

抓包工具无法直接看到明文，除非有以下条件之一：

抓包方法一：中间人方式 + 安装伪造 CA 证书

  • 工具：Charles、Fiddler、Burp Suite 等
  • 原理：
    1. 工具伪装为服务器签发伪造证书
    2. 客户端信任这个工具的证书（你手动安装了它的 CA）
    3. 工具解密客户端请求，转发真实请求

抓包方法二：导入浏览器私钥（Chrome Debug 模式）

用于调试用途，不适合实际环境。

🧨 注意：

正常的 HTTPS 是不能被抓到明文数据的，除非你控制客户端设备或证书信任链被破坏。

五、HTTPS 如何保证通信安全？

安全要素 实现机制
机密性 对称加密（AES、ChaCha20）
完整性 消息摘要（HMAC、SHA）
身份认证 服务器证书（CA 签发）
防重放 TLS 内建序列号机制
防中间人 验证证书 + 加密密钥协商

六、握手流程总结图（简化版）

1
2
3
4
5
6
7
Client Hello  →  Server Hello + 证书
       ↓                ↓
生成随机密钥   ←   解密随机密钥（服务器私钥）
       ↓                ↓
生成对称加密密钥 Session Key
       ↓                ↓
双方用对称密钥加密通信内容

七、常见面试问法总结

面试问题 简要回答
HTTPS 是怎么建立连接的？ 先握手协商会话密钥（非对称），再用对称密钥加密传输
HTTPS 会加密 URL 吗？ 会加密路径和参数，不加密域名
什么是中间人攻击？HTTPS 如何防御？ 伪装通信双方窃取信息，HTTPS 通过证书防伪装
HTTPS 可以抓包吗？ 可以抓，但抓到的是加密数据；需信任伪造 CA 才能解密
HTTPS 安全机制有哪些？ 加密、校验、认证三位一体
HTTPS 会话密钥如何产生？是否安全？ 客户端生成，用公钥加密传输，私钥解密，确保只有服务器能获取

✅ HTTPS 客户端校验证书合法性

一、证书的由来：谁发的？

  • 数字证书（Certificate） 是由受信任的 CA（Certificate Authority）证书颁发机构 签发。
  • CA 的角色就像网络世界的“公安局”：
    • 对申请者（如网站）的身份信息进行验证；
    • 使用自己的 私钥 签发证书；
    • 保证该证书的真实性、不可伪造性。

二、数字证书的内容（结构）

一个完整的数字证书一般包含如下内容：

字段 含义
公钥 网站的公钥，用于加密客户端传过来的随机密钥
持有者信息 网站名称、域名、公司等
有效期 证书的开始时间和结束时间
颁发机构（Issuer） 谁签发的，CA 名称
用途 证书用途，比如用于服务器身份认证、加密等
签名算法 如 SHA256WithRSA
签名（Signature） 用 CA 的私钥加密后的摘要，验证证书是否被篡改

三、CA 是如何签发证书的？

签发过程本质是生成并签名证书数据：

  1. CA 收到申请者（网站）的公钥等信息。
  2. 将这些信息（公钥、持有者、用途、有效期、颁发者）打包并 做哈希，得到一个摘要 Hash(H1)。
  3. 用 CA 自己的私钥 对摘要加密，得到 Signature（签名）。
  4. 最终形成一个完整的证书，交给申请者使用。

四、客户端如何验证服务器证书？

浏览器或操作系统会内置多个 受信任 CA 的公钥（称为根证书列表），验证过程如下：

✅ 校验证书合法性的完整步骤：

  1. 读取证书信息
    • 浏览器收到服务器的证书，提取出其中的域名、颁发者、有效期、公钥、签名等字段。
  2. 检查域名是否匹配
    • 客户端检查证书中的 CN/Common Name 或 SAN 字段是否与当前访问的网站域名一致。
  3. 检查证书是否过期
    • 校验当前时间是否在 notBefore 和 notAfter 有效期之间。
  4. 查找颁发者 CA 是否受信任
    • 在系统或浏览器的内置 CA 列表中查找是否包含该颁发者的 公钥。
  5. 校验签名是否匹配
    • 用找到的 CA 公钥解密证书中的签名 Signature，得到 Hash(H2)
    • 对证书的实际内容（除签名外）再次做哈希，得到 Hash(H1)
    • 比较 H1 和 H2 是否一致：
      • 如果一致 → 证书未被篡改，合法 ✅
      • 如果不一致 → 签名被伪造或内容被篡改 ❌

🔐 图示说明（简化）：

1
2
3
4
5
6
7
浏览器校验证书：

1. 获取服务器证书
2. 检查域名和时间
3. 使用 CA 公钥解密 Signature → 得到 H2
4. 对证书内容重新 hash → 得到 H1
5. 比较 H1 与 H2 是否一致

五、为什么中间人不能伪造证书？

即使攻击者（中间人）伪造了证书内容：

  • 他无法伪造签名，因为没有 CA 的私钥
  • 浏览器在校验签名时一定会失败，提示“此证书不可信”、“连接不安全”

六、客户端验证举例（以 Chrome 浏览器为例）

Chrome 访问一个 HTTPS 网站时会自动执行上述验证流程：

  1. 收到证书
  2. 校验域名与站点一致性
  3. 校验有效期
  4. 校验签名是否由受信任 CA 签发
  5. 成功后显示“锁”图标，连接建立

如果失败，用户会看到如下警告页面：

1
2
您的连接不是私密连接 (Your connection is not private)
NET::ERR_CERT_AUTHORITY_INVALID

七、常见面试总结

问题 答案简要
客户端如何校验证书合法性？ 校验域名、时间、是否由受信 CA 签发、签名是否匹配
数字证书中最关键的部分是？ 公钥 + 签名（由 CA 私钥生成）
签名是如何生成和验证的？ 对内容做 hash → 私钥加密（签名） → 公钥解密验证
中间人能伪造证书吗？为什么不能？ 不能。因为没有 CA 的私钥，无法生成合法签名
浏览器是如何识别“可信 CA”？ 浏览器/操作系统预置了多个受信任 CA 公钥（根证书）
如果 CA 被攻破了，怎么办？ 浏览器或操作系统会更新根证书列表，吊销失效证书

✅ HTTP 是无状态协议

一、什么叫“无状态”？

定义： HTTP 协议是无状态（stateless）的，意思是：

每一个请求都是完全独立的，服务器在处理当前请求时不会记住这个客户端曾经发送过什么请求。

二、形象比喻理解

就像你去快餐店点餐：

  • 每来一个人都重新点餐；
  • 服务员不记得你上次来吃过什么；
  • 你每次都得说清楚你是谁、你要点什么；

三、无状态的表现

特性 描述
请求独立 每个请求都包含了服务器所需的完整信息，与之前请求无关联
不记录历史 服务器不会保存用户的登录状态、操作记录、上一个请求的上下文等
简单高效 实现简单，占用资源少，服务器处理一个请求后即可释放所有资源
不便于状态管理 比如购物车、登录状态、访问记录都不会自动保存，需要额外机制处理

四、无状态的影响

由于 HTTP 无状态，所以你会发现：

  • 用户登录后页面跳转就“忘了登录”，需要“重新验证”。
  • 网站购物车、浏览记录等都不能自动保存。
  • 不能在服务器中轻松识别“这个请求来自哪个用户”。

五、怎么弥补无状态的缺陷？（状态保持机制）

✅ 1. Cookie（客户端保存）

  • 浏览器保存服务端发送的 Set-Cookie 信息；
  • 后续每次请求自动携带这个 Cookie；
  • 可以包含登录凭证、用户 ID、语言偏好等。

特点：

  • 状态保存在客户端；
  • 服务器仍然是无状态的，但通过 Cookie 识别用户；
  • 存在安全风险（可能被伪造、窃取）。

✅ 2. Session（服务端保存）

  • 登录时服务器生成一个Session ID；
  • 把这个 ID 存到客户端的 Cookie；
  • 服务器维护一个映射表 SessionID → 用户数据。

特点：

  • 状态保存在服务器；
  • 用户每次请求通过 Session ID 找回状态；
  • 更安全，但服务器压力较大。

✅ 3. Token（如 JWT）

  • 登录成功后服务器生成一个加密的 Token；
  • 客户端保存在 Cookie 或 LocalStorage 中；
  • 每次请求携带 Token，服务器解析后获取状态。

特点：

  • 状态数据由客户端保存；
  • 服务器无需记录状态信息（“真正的无状态认证”）；
  • 适用于分布式系统、移动端等。

六、表格总结三种状态保持机制对比

特性 Cookie Session Token（JWT）
状态存储位置 客户端 服务器 客户端
安全性 较低（易被盗用） 较高（存于服务端） 较高（有加密签名）
跨服务支持 差 差（难以共享 Session） 好（可跨域跨服务验证）
扩展性 一般 差（内存或集中式存储） 好（分布式友好）

七、常见面试题总结

问题 答案简要
HTTP 是无状态协议是什么意思？ 每个请求都是独立的，服务器不会保存客户端的请求状态
为什么 HTTP 设计成无状态？ 简单、高效、易扩展，但需要额外机制保存状态
无状态协议下如何记录用户状态？ 使用 Cookie、Session 或 Token
Cookie 和 Session 的区别？ Cookie 保存在客户端，Session 保存在服务器
Token 比 Session 的优势？ 支持分布式、不需要服务器记录状态，更适合微服务架构

✅ Session 与 Cookie 的联系与区别

一、概念简介

  • 定义：Cookie 是存储在客户端浏览器中的一小块文本数据，主要用于保存用户信息及状态。
  • 存储位置：客户端浏览器。
  • 工作原理：服务端向客户端发送 Cookie，客户端在后续请求中携带该 Cookie 回服务器，服务器根据 Cookie 来识别用户状态。

Session：

  • 定义：Session 是指服务器与客户端之间的会话过程。服务器用来存储用户状态的数据（如用户登录信息）。
  • 存储位置：服务器端。
  • 工作原理：客户端发起请求时，服务器生成一个 Session，将用户状态保存在服务器上，并将 Session 的唯一标识（SessionID）发送给客户端。客户端之后每次请求都会携带这个标识，服务器通过 SessionID 来查找对应的用户状态。

二、Cookie 与 Session 的区别

特性 Cookie Session
存储位置 存储在客户端浏览器中 存储在服务器端
存储内容 只能保存简单的 ASCII 数据 可以存储任意数据类型（如对象、数组等）
有效期 可设置较长有效期，长期保存 一般较短，客户端关闭或超时即失效
隐私安全性 存储在客户端，容易被篡改或窃取 存储在服务器，安全性较高
存储大小 单个 Cookie 的大小限制为 4K 存储容量更大，受限于服务器资源
使用场景 客户端需要长期保存用户信息，如记住用户名、密码等 适用于短期的会话数据，如登录状态、购物车信息等
传输方式 每次请求都会自动携带至服务器 需要 SessionID 作为标识，在请求中传递

三、Cookie 与 Session 的联系

  • SessionID 存储在 Cookie 中：
    • 在用户第一次访问服务器时，服务器会为其生成一个 Session 并分配一个唯一的 SessionID；
    • 服务器将 SessionID 返回给客户端，浏览器将其存储在 Cookie 中；
    • 在之后的请求中，客户端会携带 Cookie（包含 SessionID），服务器通过该 SessionID 找到对应的 Session，识别用户状态。

常规流程：

  1. 用户第一次请求： 服务器为用户生成 Session，并生成一个 SessionID； 服务器将该 SessionID 存储到 Cookie 中并返回给客户端。
  2. 用户第二次请求： 客户端发送请求时自动携带 Cookie，服务器从中提取 SessionID； 服务器根据 SessionID 获取存储在服务器上的 Session 数据，从而识别用户身份。

五、分布式环境下的 Session 处理

问题：

  • 在分布式架构下，负载均衡可能导致请求被路由到不同的服务器。如果不同服务器之间的 Session 数据不共享，可能会导致用户状态丢失或无法识别。

解决方案：

  1. 使用 Redis 或其他分布式缓存：
    • 通过 Redis 等缓存系统存储 Session 数据，在多台服务器间共享用户状态。
  2. 基于 Cookie 的 SessionID：
    • 在各服务器之间保持一致的 SessionID 标识，让所有服务器都能访问同一份 Session 数据。

有时候，客户端可能禁用了 Cookie（如浏览器禁用、移动客户端等），此时需要另一种方法来存储和传递 SessionID。

解决方案：

  1. 使用 sessionStorage：
    • 将 SessionID 存储在浏览器的 sessionStorage 中（仅在当前浏览器会话中有效）。
  2. 将 SessionID 放入 URL：
    • 直接将 SessionID 作为 URL 请求参数，随请求一起发送（例如：https://example.com?sessionid=xxxx）。
  3. 将 SessionID 放入 HTTP 请求头：
    • 将 SessionID 放在请求的 Authorization 或自定义请求头中（例如：Authorization: Bearer xxxx）。

七、总结

特性 Cookie Session
存储位置 客户端（浏览器） 服务器
数据类型 ASCII 文本数据 任意数据类型
有效期 可设置长时间 短期有效（会话结束即失效）
安全性 较低（容易被盗取） 较高（存储在服务器）
存储大小限制 4KB 左右 更大存储空间
适用场景 长期存储数据（记住我、偏好设置等） 临时存储数据（登录状态、购物车等）