网络HTTPS协议

Https

HTTPS（Hypertext Transfer Protocol Secure）是 HTTP 协议的加密版本，它使用 SSL/TLS 协议来加密客户端和服务器之间的通信。具体来说：

• 加密通信：在用户请求访问一个 HTTPS 网站时，客户端（如浏览器）和服务器通过 SSL/TLS 握手 来建立一条加密的通道。这个过程包括证书验证、密钥交换等步骤，最终生成一个用于加密的会话密钥。

• 数据加密：一旦加密通道建立，浏览器和服务器之间的所有通信数据都会使用对称加密技术（如 AES）加密。这意味着即使中间人（例如攻击者）截获了通信数据，他们也无法轻易解密这些数据，因为没有会话密钥。

为什么抓包工具能解密流量？

抓包工具（如 Charles, Fiddler, Wireshark 等）能够解密 HTTPS 流量，通常是因为它们 充当了一个代理服务器，而这个代理需要安装在用户的设备上并且信任其证书。

具体来说：

• 代理模式：这些抓包工具通过设置为用户的代理（HTTP 或 HTTPS 代理），让所有的流量首先经过这些工具，然后由工具转发到目标服务器。

• 证书安装和信任：抓包工具会在本地生成自己的 中间人证书，并要求用户安装该证书到浏览器或操作系统的受信任根证书列表中。这样，抓包工具就可以解密和重新加密数据。

• 解密流量：

用户请求 HTTPS 网站时，抓包工具充当一个中间人（man-in-the-middle）。
抓包工具与目标服务器建立 HTTPS 连接（此时它会验证服务器证书并加密通信）。
抓包工具与用户的浏览器之间再建立一个 HTTPS 连接（并使用抓包工具自己的证书加密通信）。
由于用户信任抓包工具的证书，浏览器认为它与真正的服务器建立了加密通道，因此不会警告或报错。

谷歌浏览器的开发者工具（F12）

浏览器的开发者工具（如谷歌 Chrome 的 F12）也能抓取 HTTPS 请求，但这并不是因为它解密了流量，而是因为浏览器本身 能够查看请求和响应的元数据。

• 浏览器在发送 HTTPS 请求时，会将数据加密并发送到目标服务器，但服务器的响应会被加密并发送回浏览器。此时，浏览器解密响应并显示在开发者工具中。

• 所以，当你在 开发者工具的 Network 面板 查看请求时，你看到的是 浏览器已解密后的数据，而不是中间人攻击的结果。这里的流量是浏览器自己解密的，目的是供开发者查看。

请求

发送了一个简单的 HTTP POST 请求，但在背后会涉及到一些额外的网络层级的操作，包括 TCP 三次握手 和 四次挥手，还有 SSL/TLS 握手 的过程。这些操作会稍微增加请求的延迟。

TCP 三次握手（Three-Way Handshake）

当你发出一个 HTTP POST 请求时，它首先会建立一个 TCP 连接。TCP 是一个面向连接的协议，所以在客户端与服务器之间建立连接时，会经过三次握手：

客户端 -> 服务器：客户端发送一个 SYN（同步）包来请求建立连接。
服务器 -> 客户端：服务器响应一个 SYN-ACK（同步-确认）包，表示它准备好与客户端通信。
客户端 -> 服务器：客户端再发送一个 ACK（确认）包，表示连接建立成功。

这三次握手完成后，客户端和服务器之间就可以开始数据传输了。

SSL/TLS 握手（建立加密通道）

在 HTTPS（而不是 HTTP）中，所有的 HTTP 请求都会先通过 SSL/TLS 握手 来加密通信。这个过程也需要一定的时间，但它是为了确保通信的安全性。具体过程如下：

客户端 -> 服务器：客户端发送一个包含自己支持的加密算法和其他配置信息的 ClientHello 消息。

客户端（浏览器、curl 或其他工具）会发送一个 ClientHello 消息给服务器，包含：
• 支持的加密算法（如 AES、RSA、ECDHE 等）。
• 支持的 SSL/TLS 版本。
• 随机数，用于加密密钥的生成。
• 支持的扩展（例如 SNI，服务器名称指示）。

加密套件的选择：不同客户端会支持不同的加密算法。

• TLS 版本：例如，Chrome 可能会首先尝试使用最新的 TLS 版本（如 TLS 1.3），而 curl 可能会允许更多的 TLS 版本（如 TLS 1.2 或 1.3）。

• SNI（服务器名称指示）：浏览器和工具通常会带上 SNI 信息来告诉服务器想访问的虚拟主机名。（例如 Chrome），它会通过多次优化过的策略来减少加密握手的时间和带宽消耗。例如，Chrome 可能会在一定条件下使用 Session Resumption 或 TLS 0-RTT 来加速后续请求，避免每次都重新进行握手。

服务器 -> 客户端：服务器根据客户端的请求选择一种加密算法并发送 ServerHello 消息，并发送自己的证书（包含公钥）来让客户端验证服务器身份。

回复一个 ServerHello 消息，包含：
• 选择的加密算法和协议。
• 服务器证书（公钥）用于加密。
• 随机数。

客户端 -> 服务器：客户端生成一个 Pre-Master Secret，用服务器的公钥加密后发送给服务器。然后，客户端和服务器通过这个 Pre-Master Secret 计算出加密会话密钥。

•	如果是对称加密（例如使用 RSA 或 ECDHE），客户端会使用服务器的公钥加密一个共享密钥（pre-master secret）。
•	服务器解密并生成最终的对称加密密钥。

服务器 -> 客户端：服务器解密这个 Pre-Master Secret，并且确认双方可以使用相同的会话密钥进行加密通信。

一旦 SSL/TLS 握手 完成后，数据的加密和解密可以开始，通信将使用 对称加密（如 AES）进行。

TCP 四次挥手（Four-Way Handshake）

当通信结束时，连接需要关闭。这个过程需要 四次挥手 来完成：

客户端 -> 服务器：客户端发送一个 FIN（结束）包，表示它要关闭连接。
服务器 -> 客户端：服务器确认收到 FIN 包，并发送一个 ACK（确认）包，表示连接半关闭。
服务器 -> 客户端：服务器发送一个 FIN 包，表示服务器也准备关闭连接。
客户端 -> 服务器：客户端确认收到服务器的 FIN 包，并发送一个 ACK 包，表示连接完全关闭。

每个新的连接都会进行一次握手：如果浏览器或工具每次都建立新的连接（没有复用连接），每次请求都会重新进行 SSL/TLS 握手。

• 连接复用：在 HTTP/2 或 HTTP/1.1 keep-alive 下，多个请求可以复用同一个连接，减少握手的频率。

http1.1 与http 2

HTTP（Hypertext Transfer Protocol，超文本传输协议）是 Web 通信的基础，目前主要使用的版本有 HTTP/1.1 和 HTTP/2

如果你没有配置 keepalive_timeout，Nginx 使用默认值：

• keepalive_timeout 默认 75 秒

• keepalive_requests 默认 100 【nginx -T | grep keepalive】

server {listen 443 ssl http2;server_name model.abc.com;ssl_certificate /home/ubuntu/crt_ssl/model.abc.com.crt;ssl_certificate_key /home/ubuntu/crt_ssl/model.abc.com.key;ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305-SHA256';ssl_protocols TLSv1.2 TLSv1.3;ssl_prefer_server_ciphers on;# 配置 `keep-alive`keepalive_timeout 65;   # 65 秒内可以复用 TCP 连接keepalive_requests 100; # 允许 100 次请求复用同一个连接location / {proxy_pass http://localhost:3000;  # Django 后端容器proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}}server {listen 443 ssl http2;server_name abc.com;ssl_certificate /home/ubuntu/crt_ssl/abc.com.crt;ssl_certificate_key /home/ubuntu/crt_ssl/abc.com.key;ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305-SHA256';ssl_protocols TLSv1.2 TLSv1.3;ssl_prefer_server_ciphers on;location / {proxy_pass http://localhost:8004;  # Django 后端容器proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}}

在这里插入图片描述

HTTP/1.1

HTTP/1.1 是 HTTP 协议的一个改进版本，解决了 HTTP/1.0 存在的一些问题：

• 支持持久连接（Keep-Alive）：HTTP/1.0 每次请求都需要建立新的 TCP 连接，而 HTTP/1.1 通过 Connection: keep-alive 允许一个 TCP 连接复用多个 HTTP 请求。【在请求头有这个keep-alive】

• 支持分块传输（Chunked Transfer Encoding）：允许服务器分块传输数据，提高大文件的传输效率。

• 增加 Host 头：HTTP/1.1 允许同一 IP 托管多个网站，因此 Host 头变为必填项。

FastAPI 默认是基于 Uvicorn 运行的，而 Uvicorn 默认使用的是 HTTP/1.1，但是：

• 如果你用 HTTPS（TLS 加密），并且启用了 HTTP/2，Uvicorn 也可以支持 HTTP/2。

• 但是如果你是在 Nginx 代理 FastAPI，那么 HTTP/2 主要由 Nginx 负责，FastAPI 依然是 HTTP/1.1。

HTTP/1.1 默认是长连接，即：

• 服务器返回 Connection: keep-alive[ Keep-Alive: timeout=5, max=100，表示 5 秒后关闭连接。]

• 只要客户端愿意，TCP 连接可以复用，不用每次请求都新建一个连接

• 但是 HTTP/1.1 仍然有队头阻塞问题，所以浏览器一般会开多个 TCP 连接（每个域名 6-8 个）

HTTP/2

HTTP/2 主要目标是提升 Web 性能，它在 HTTP/1.1 的基础上做了大量优化，最重要的特性包括：

多路复用（Multiplexing）

• HTTP/2 通过 “帧”（Frame） 的概念，将 HTTP 请求拆分成多个流（Stream），在一个 TCP 连接中可以同时发送多个请求。 HTTP/2 解决了 HTTP/1.1 在应用层的队头阻塞，但仍然依赖 TCP 连接【流式】。如果 TCP 层丢包，会导致整个 HTTP/2 连接受影响。所以 HTTP/3 进一步采用 QUIC 协议，彻底规避了这个问题。

• 这样就解决了 HTTP/1.1 的队头阻塞问题，一个请求的慢速不会影响其他请求。

头部压缩（HPACK）

• HTTP/2 采用 HPACK 算法，对头部进行哈夫曼编码（Huffman Coding），避免重复传输相同的 Header 信息，大幅减少带宽消耗。

服务器推送（Server Push）

• 服务器可以主动将客户端可能需要的资源推送到浏览器，而不需要客户端先请求，减少延迟。例如，在请求 index.html 时，服务器可以提前推送 CSS、JS 文件。

流优先级控制

• HTTP/2 允许客户端为请求分配不同的优先级，保证关键资源（如 CSS、JavaScript）优先加载，提高页面渲染速度。

• 依赖 TLS（HTTPS）：虽然 HTTP/2 协议本身并不强制加密，但主流浏览器要求 HTTP/2 必须使用 TLS（HTTPS）。

因为 HTTP/2 本身就是长连接！

• HTTP/2 默认复用 TCP 连接，不需要 Connection: keep-alive 这个标识。

• 浏览器只要发现服务器支持 HTTP/2，它就会一直复用这个连接，直到服务器主动关闭。

• 因此，在 HTTP/2 响应头中，你不会看到 Connection: keep-alive

浏览器访问 API 时：如果 HTTP/2 可用，TCP 连接是可以复用的。

• 非浏览器环境（比如 Python requests、Postman、curl）：

• 默认不会复用，因为每次请求都会重新创建连接。

• 但是如果你使用 HTTP/1.1 且加了 keep-alive，则有可能复用（但这取决于 HTTP 客户端是否支持）。

• 使用 httpx、requests 这些库时，你需要手动启用连接池来复用连接。

连接复用

TCP 连接复用 本质上就是 在一定时间内，浏览器或客户端不会每次都重新建立 TCP 连接（或者 SSL/TLS 握手），而是复用现有的连接进行 HTTP 请求。

在 HTTP/1.1 下，TCP 连接默认是持久连接，也就是：

• 服务器默认不会立即关闭连接

• 浏览器会在一段时间内复用这个连接

如果客户端在 5 秒内发送了新请求，它会直接复用现有 TCP 连接，而不是重新握手。

HTTP/1.1 200 OK
Connection: keep-alive
Keep-Alive: timeout=5, max=100(	•	timeout=5：表示服务器会等待 5 秒，如果客户端没有新的请求，就关闭连接。•	max=100：最多允许复用 100 次请求。)

• 浏览器的 TCP 连接复用 是 基于 (源 IP, 源端口, 目标 IP, 目标端口) 的四元组。

• 只要 源 IP + 源端口 + 目标 IP + 目标端口 不变，连接就能复用。

• 浏览器不会复用 已经关闭的 TCP 连接，但会尽可能在 keep-alive 时间内重用它。

• NAT 设备（如家庭路由器） 会将你的内网 IP（如 192.168.1.100:54321）映射到 公网 IP（如 203.0.113.10:34567）。

• 服务器只知道 公网 IP + 端口（203.0.113.10:34567），而不知道你的本地 IP。

• NAT 设备会在内存里维护连接表，确保返回的数据包能够正确映射到你的设备。

题目

1、HTTP/2 多路复用（Multiplexing）是如何避免 HTTP/1.1 的队头阻塞（HOL Blocking）的？但为什么仍然可能存在 HOL Blocking？

在 HTTP/1.1 中，一个 TCP 连接只能串行处理请求：

• 浏览器默认最多 6-8 个 TCP 连接，但是每个连接里请求是 串行执行，导致 队头阻塞（HOL Blocking）。

• 如果前一个请求耗时较长，后续请求 必须等待，即使它们本身处理很快。

HTTP/2 解决方案：

• 引入多路复用（Multiplexing），允许一个 TCP 连接同时处理多个请求和响应，每个请求都分配一个流 ID。

• 请求之间不再是严格的顺序执行，即使前一个请求慢，后面的请求仍然可以并行传输。

但 HTTP/2 仍然可能存在 HOL Blocking：

• TCP 层的队头阻塞：HTTP/2 仍然是基于 TCP 传输的，如果 TCP 层丢包，整个 TCP 连接需要等待丢失的数据包重传，导致所有 HTTP/2 请求阻塞。

• HTTP/2 不能解决 TCP 层的 HOL Blocking，而 HTTP/3 采用 QUIC（基于 UDP），完全消除了这一问题。

2、 服务器是如何验证复用的连接是否真的来自同一个客户端？

服务器会使用 TLS 会话恢复（TLS Session Resumption） 机制：

• Session Ticket（TLS 1.2）：服务器在第一次握手时生成一个加密票据（Session Ticket），存储在客户端，下次请求时客户端带上这个票据，服务器就知道它是同一个会话。

• Session ID（TLS 1.2）：服务器给每个 TLS 会话分配一个 ID，客户端后续请求时可以用相同 ID 进行恢复。

• TLS 1.3 采用 PSK（Pre-Shared Key）：客户端和服务器可以在 0-RTT（Zero Round Trip Time）模式下恢复会话。

这意味着：

• 即使 IP 变了，服务器仍然可以识别客户端是否是同一个会话（只要 Session Ticket 没有过期）。

• 攻击者即使伪造 IP 和端口，也无法绕过 TLS 认证。

3、连接复用时，为什么还需要 SYN-ACK？

同一个 TCP 连接在 keep-alive 时间内的请求可以共享，但一旦连接关闭，新的连接仍然需要重新握手（SYN -> SYN-ACK -> ACK）。

客户端（浏览器）建立 TCP 连接

• Client → SYN → Server

• Server → SYN-ACK → Client

• Client → ACK → Server

• TCP 连接建立后，客户端发送 HTTP 请求：

Client → GET /index.html HTTP/1.1 → Server

如果 keep-alive 生效，连接不会立即关闭

• 服务器返回 Connection: keep-alive，表示 TCP 连接仍然可用。

• 后续请求不会重新握手，直接复用 TCP 连接：

Client → GET /api/data HTTP/1.1 → Server

攻击者不可能劫持现有的 TCP 连接

• 连接复用是客户端和服务器维护的，攻击者无法直接插入现有的 TCP 连接，因为 TCP 连接在 NAT 内部，攻击者无法获取 NAT 的端口映射状态。

• NAT 设备有 状态表，它只允许 真正发起连接的设备 接收服务器的数据。

• 攻击者无法强行加入 NAT 设备已经维护的连接，除非 NAT 设备本身被攻破。

攻击者只能尝试伪造新的 TCP 连接

• 伪造 IP + 端口并不会让攻击者进入原连接，而是必须发起新的 SYN。

• 但服务器发送的 SYN-ACK 不会送到攻击者手里，而是回到 NAT 设备，导致握手无法完成。

• 这就是TCP 伪造攻击失败的核心原因。

即使 TCP 伪造成功，TLS 仍然会保护数据

• 在 HTTPS（TLS）连接里，TCP 连接的建立并不代表攻击成功，因为攻击者还需要完成 TLS 握手。

• TLS 握手涉及服务器证书、公私钥加密，攻击者无法伪造

• 即使攻击者能劫持 TCP 连接，他仍然无法解密数据。