当你在浏览器地址栏输入网址并按下回车，到页面完全呈现，背后是一场精密有序的网络“协奏曲”。本文将深入浅出地为你拆解 HTTP 与 HTTPS 协议的完整通信流程，从建立连接、数据传输到安全加密等等，带你了解每一个幕后细节。

URL解析

当你在地址栏输入任意网址，例如https://blog.wrjcloud.cn，浏览器首先会解析这个 URL，提取出关键信息：

1. 协议：HTTPS

2. 域名：blog.wrjcloud.cn

3. 端口：443(HTTPS)，80(HTTP)

4. 路径：/，访问资源的路径

浏览器并不知道blog.wrjcloud.cn对应哪台物理服务器，所以要先通过DNS（域名系统）来查询其 IP 地址。DNS 查询过程分为多个层级：

• 浏览器缓存：浏览器首先检查自身是否缓存了该域名的解析结果。

• 操作系统缓存：当在浏览器未查询到缓存，则向操作系统发起查询，操作系统会检测hosts 文件以及本地 DNS 缓存。

• 递归查询：如果本地无记录，请求发送到配置的本地 DNS 服务器（通常是 ISP 提供的）。本地 DNS 服务器代表客户端，从根域名服务器开始，依次向顶级域名服务器（如.cn）、权威域名服务器（如 wrjcloud.cn 的 DNS 服务器）发起查询，最终获得目标 IP 地址。

获取 IP 地址后，浏览器便知道了服务器的网络地址，准备建立连接。

建立TCP连接

有了 IP 地址和端口号，浏览器就需要与服务器建立可靠的传输通道，HTTP/HTTPS 协议本身不负责数据的可靠传输，这项任务由底层的TCP 协议完成的。

通过 TCP 协议三次握手，双方确认彼此具备收发数据的能力。

1. SYN：客户端向服务器发送一个SYN（同步序列编号）报文，表示请求建立连接，并进入 SYN_SENT 状态。

2. SYN + ACK：服务器收到请求后，如果同意连接，则回复一个SYN 和 ACK（确认）报文，表示确认并同步自己的序列号。

3. ACK：客户端收到后，再发送一个ACK 报文作为最终确认。此时，TCP 连接正式建立，双方可以开始传输数据。

如果是 HTTP 请求，此时浏览器就可以直接发送 HTTP 请求报文了。但如果是 HTTPS 请求，在 TCP 连接建立之后，还需要进行一个至关重要的步骤：TLS 握手。

TLS握手（HTTPS）

HTTPS 并非新协议，而是 HTTP + SSL/TLS，即在 HTTP 和 TCP 之间插入了一个安全层。TLS 握手的主要目的是：协商加密算法、验证服务器身份、并生成后续通信使用的对称加密密钥。下面以最常见的 RSA 握手为例，详细拆解这一过程。

握手开始

Client Hello：客户端向服务器发送一个 "你好" 消息，包含自己的支持的 TLS 版本、一个加密套件列表（如支持的对称加密算法、密钥交换算法等等），以及一个客户端生成的随机数（称为 Client Random）。

Server Hello：服务器从客户端提供的列表中选出一组加密算法，生成一个服务器随机数（Server Random），连同自己的选择一起返回给客户端。

服务器发送数字证书

紧接着，服务器会发送自己的数字证书给客户端。这个证书是服务器身份的“身份证”，由权威的证书颁发机构（CA） 签发，包含以下关键信息：

• 服务器身份信息：如域名、组织名称、有效期等。

• 服务器的公钥：用于后续的密钥交换。

• 颁发者信息：签发该证书的 CA 机构。

• 数字签名：CA 机构使用自己的私钥对证书内容生成的签名，用于防伪。

客户端验证数字证书

客户端（浏览器）收到证书后，并不会盲目信任，而是执行一系列严格验证：

信任链验证

浏览器内置了一组受信任的根证书（来自全球公认的 CA）。客户端会检查服务器证书的颁发者，逐级向上查找，直到找到一个内置的根证书。如果找不到信任的根，或证书链不完整，浏览器会警告“证书不受信任”。

有效期与域名验证

检查证书是否在有效期内，以及证书中的域名是否与当前访问的域名完全匹配。

数字签名验证（最关键的防伪步骤）

这一步确保证书没有被篡改，且确实是CA 机构签发的。过程如下：

• 获取 CA 公钥：浏览器从内置的根证书中获取对应 CA 的公钥（根证书自带了 CA 的公钥）。

• 解密签名：使用 CA 公钥解密证书上的数字签名，得到一串字符，这串字符是 CA 当初为证书内容计算的原始摘要。

• 重新计算摘要：浏览器使用与 CA 相同的哈希算法（如 SHA-256），对当前收到的证书内容（除签名外的部分）重新计算，得到一个新的当前摘要。

• 比对摘要：如果两个摘要完全一致，说明证书未被篡改，且确实是该 CA 签发的（因为只有 CA 的私钥才能加密出可以被其公钥解密的签名）。如果不一致，则验证失败，浏览器显示“证书无效”或“不安全”警告。

生成会话密钥

证书验证通过后，客户端从证书中取出服务器的公钥。此时，客户端生成第三个随机数，称为预主密钥，并使用服务器的公钥将其加密后发送给服务器。服务器用自己私钥解密，获得预主密钥。

至此，客户端和服务器都拥有了三个随机数：Client Random、Server Random、Pre-master Secret。双方使用协商好的算法，将这些随机数混合计算出最终的会话密钥（一种对称加密密钥）。

握手完成

客户端发送一条用会话密钥加密的消息，告知握手完成。

服务器也发送一条加密消息作为回应，并切换至加密通信。

之后，所有的应用层数据（即 HTTP 请求和响应）都将使用这个会话密钥进行对称加密传输，确保通信的机密性、完整性和身份认证。

HTTP请求与响应

TLS 握手完成后，浏览器和服务器就建立了一条可靠的安全通道，可以开始正式的 HTTP 通信了。

具体步骤：

• 客户端加密发请求：客户端先把普通的 HTTP 请求（比如想访问某个网页的 GET /index.html 请求），用双方约定好的 “会话密钥” 加密，再通过 TLS 协议打包发给服务器。

• 服务器解密处理请求：服务器拿到加密的请求后，用同一个密钥解开，就能看到原始的 HTTP 请求，接着按正常流程处理这个请求（比如查找对应的网页内容）。

• 服务器加密发响应：服务器把处理结果（比如 “请求成功” 的 200 状态码、网页内容）同样用会话密钥加密，再发回给客户端。

• 客户端解密看网页：客户端解开加密的响应数据，得到完整的 HTTP 响应，最后由浏览器把网页内容展示出来。

关闭TCP连接

HTTP/1.1 默认启用持久连接（Connection: keep‑alive），允许在同一个 TCP 连接上传输多个 HTTP 请求与响应，减少频繁建立和断开 TCP 连接带来的性能开销。当数据传输完成，或客户端、服务器主动关闭连接时，会通过TCP 四次挥手断开连接：

1. 一方发送 FIN 报文，表明不再发送数据；

2. 对端回复 ACK 报文，确认收到关闭请求；

3. 对端也发送 FIN 报文，表明自身也无数据需要发送；

4. 最初发送方回复 ACK 报文，TCP 连接正式关闭。

完整流程图

总结

一次完整的 HTTP/HTTPS 通信始于用户输入 URL，浏览器首先通过 DNS 解析将域名转换为目标服务器的 IP 地址，随后与服务器进行 TCP 三次握手建立可靠的传输通道；若使用 HTTPS，则在 TCP 连接之上进行 TLS 握手，服务器发送包含公钥和 CA 签名的数字证书，浏览器验证证书的信任链及数字签名的有效性以确认服务器身份，并协商生成会话密钥用于后续对称加密，接着浏览器通过加密连接发送 HTTP 请求报文，服务器处理请求后返回 HTTP 响应报文，最后通过 TCP 四次挥手关闭连接，释放资源。