HTTPS、SSL/TLS 与网络通信学习笔记

一、核心概念总览

1. 什么是 HTTP？

HTTP（HyperText Transfer Protocol，超文本传输协议）是一种应用层协议，用于客户端与服务器之间交换数据。

例如，浏览器向服务器请求网页：

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

服务器返回：

1
2
3
4
5
6
HTTP/1.1 200 OK
Content-Type: text/html

<html>
  <body>Hello World</body>
</html>

HTTP 本身不负责加密通信。如果直接使用普通 HTTP，传输内容可能被网络中的攻击者读取或篡改。

2. 什么是 HTTPS？

HTTPS（HTTP Secure）是通过 TLS 保护的 HTTP 通信。

可以简单理解为：

HTTPS = HTTP + TLS 安全保护

HTTPS 主要提供三个安全目标：

  1. 机密性：防止第三方直接读取通信内容。
  2. 完整性：防止通信数据被秘密篡改。
  3. 身份认证：帮助浏览器确认服务器的身份。

注意：HTTPS 不能保证网站本身一定可信，也不能保证网站不会泄露用户数据。

3. 什么是 SSL 和 TLS？

  • SSL：Secure Sockets Layer，安全套接层。
  • TLS：Transport Layer Security，传输层安全协议。

TLS 是 SSL 的后继者。

SSL 2.0、SSL 3.0 等旧版本已经不安全，不应使用。现代网站通常使用 TLS 1.2 或 TLS 1.3。

概念 作用
SSL 已淘汰的旧协议系列
TLS 1.2 目前仍广泛使用的安全协议版本
TLS 1.3 更现代的版本，简化握手并移除多种旧式机制
SSL 证书 行业中常用的说法，通常指用于 HTTPS 的 TLS 证书

为什么现在还叫 SSL 证书？

因为这个名称已经被行业广泛使用。实际上，现代 HTTPS 使用的是 TLS，而不是旧版 SSL。

二、加密的基础知识

1. 明文与密文

  • 明文：可以直接理解的数据。
  • 密文：经过加密后，不应被未授权者直接理解的数据。
  • 加密：通过算法和密钥，将明文转换成密文。
  • 解密：通过相应算法和密钥，将密文恢复成明文。

例如：

1
2
3
4
5
明文：Hello World
       ↓ 加密
密文：一串无法直接理解的数据
       ↓ 解密
明文：Hello World

加密并不是简单地把文字换成另一串字符，而是依靠密码算法和密钥实现安全保护。

2. 对称加密

对称加密使用同一个密钥进行加密和解密。

1
2
3
4
5
6
7
8
9
明文
  ↓
使用密钥加密
  ↓
密文
  ↓
使用同一个密钥解密
  ↓
明文

常见算法：

  • AES
  • ChaCha20

优点：

  • 加解密速度快。
  • 适合传输大量数据。

缺点：

  • 通信双方必须安全地获得共享密钥。
  • 如果密钥泄露，攻击者可能解密相关通信。

TLS 建立安全连接后，主要使用对称加密保护实际传输的数据。

3. 非对称加密

非对称密码技术使用一对数学上相关的密钥：

  • 公钥（Public Key）
  • 私钥（Private Key）

公钥可以公开，私钥必须受到保护。

非对称密码技术有不同用途：

公钥加密与私钥解密：

1
2
3
4
5
明文
  ↓ 使用公钥加密
密文
  ↓ 使用对应私钥解密
明文

这种方式可用于某些密钥传输场景，但不是现代 TLS 1.3 的常规密钥协商方式。

数字签名与验证：

1
2
3
4
5
发送方使用私钥签名
          ↓
       数字签名
          ↓
接收方使用对应公钥验证

数字签名主要用于验证签名来源和数据完整性，不是为了隐藏内容。

常见的非对称密码算法包括 RSA、ECDSA 和 EdDSA。现代 TLS 还经常使用椭圆曲线 Diffie-Hellman 密钥交换。

4. 公钥和私钥的作用

名称 主要用途 是否公开
公钥 验证数字签名；在适用的方案中用于加密 可以公开
私钥 生成数字签名；在适用的方案中用于解密 必须保密

注意：公钥和私钥并不总是用于同一套操作。 数字签名与加密是不同的密码学功能。

5. 为什么 HTTPS 同时使用两类密码技术？

因为它们各有优势：

  • 非对称密码技术：可以帮助完成身份认证和密钥协商。
  • 对称加密：速度快，适合保护大量通信数据。

因此，TLS 通过身份认证和密钥协商建立安全连接，再使用协商得到的密钥保护 HTTP 数据。

三、数字证书与 CA

1. 什么是 TLS 证书？

TLS 证书是一种数字文件，用来将特定身份（例如域名）与公钥关联起来。

证书通常包含：

  • 域名或其他身份信息。
  • 服务器公钥。
  • 证书有效期。
  • 证书签发者信息。
  • CA 的数字签名。
  • 其他与证书用途和约束有关的信息。

可以把证书理解为网站的数字身份证明。

2. 什么是 CA？

CA（Certificate Authority，证书颁发机构）负责按照一定的验证规则签发数字证书。

例如，网站希望启用 HTTPS：

1
2
3
4
5
6
7
8
9
网站管理员
    ↓
申请证书
    ↓
CA 验证域名控制权等信息
    ↓
CA 签发证书
    ↓
网站部署证书

常见 CA 包括：

  • Let’s Encrypt
  • DigiCert
  • Sectigo
  • GlobalSign

其中 Let’s Encrypt 提供免费的域名验证型 TLS 证书。

3. CA 为什么值得浏览器信任？

操作系统或浏览器内置了一组受信任的根证书。

浏览器会检查服务器证书能否沿着有效的证书链，连接到受信任的根证书。

简化的证书链：

1
2
3
4
5
6
7
受信任的根 CA
      ↓ 签发
中间 CA
      ↓ 签发
网站证书
      ↓
example.com

根 CA 通常通过根证书建立信任，中间 CA 再签发网站证书。

浏览器验证证书链中的签名和约束，并检查域名、有效期、用途等条件。

4. 什么是数字签名？

数字签名用于验证数据是否由对应私钥持有者签署，以及数据是否发生了未经授权的修改。

在证书场景中：

1
2
3
4
5
6
7
CA 的私钥
    ↓
对证书内容进行签名
    ↓
生成带有数字签名的证书
    ↓
浏览器使用 CA 证书中的公钥验证

如果证书内容被修改，原来的签名通常就无法通过验证。

注意：数字签名并不等于加密。证书内容一般是可以公开读取的。

5. 浏览器如何验证网站证书？

浏览器通常会检查：

  1. 域名是否匹配：证书是否覆盖正在访问的域名。
  2. 有效期是否正确：证书是否尚未生效或已经过期。
  3. 证书链是否可信：是否能够建立到受信任根 CA 的有效路径。
  4. 数字签名是否有效：相关签名能否通过验证。
  5. 用途和约束是否符合要求：例如证书是否适合服务器身份认证。

如果检查失败，浏览器可能显示证书警告。

证书验证通过，意味着浏览器能够在相应信任体系下认证服务器身份，并不意味着网站的业务内容绝对安全。

四、TLS 握手与会话密钥

1. 什么是 TLS 握手？

TLS 握手是客户端和服务器在安全通信开始时进行的协议交互。

主要目的包括：

  • 协商 TLS 版本和密码套件。
  • 进行密钥交换。
  • 认证服务器身份。
  • 派生后续加密通信使用的密钥。

2. TLS 1.3 握手的简化流程

1
2
3
4
5
6
7
8
9
10
11
12
13
客户端                              服务器
  │                                    │
  │──── ClientHello ─────────────────→│
  │                                    │
  │←─── ServerHello ──────────────────│
  │←─── EncryptedExtensions ──────────│
  │←─── Certificate ──────────────────│
  │←─── CertificateVerify ────────────│
  │←─── Finished ─────────────────────│
  │                                    │
  │──── Finished ────────────────────→│
  │                                    │
  │════ 加密的 HTTP 通信 ═════════════│

这是便于理解的简化示意。实际消息内容和发送顺序可能因握手模式、证书验证方式等因素有所不同。

3. 各消息的作用

  • ClientHello：客户端提供支持的 TLS 参数，并在常见握手中发送密钥交换相关信息。
  • ServerHello：服务器选择相关参数，并提供自己的密钥交换信息。
  • Certificate：服务器发送证书链。
  • CertificateVerify：服务器使用相应私钥对握手上下文进行签名，证明自己持有对应私钥。
  • Finished：验证握手过程的完整性，并确认相关握手密钥的持有情况。

4. ECDHE 是什么？

ECDHE 是一种基于椭圆曲线 Diffie-Hellman 的临时密钥交换机制。

在现代 TLS 中，客户端和服务器交换公开的密钥交换参数，然后各自计算出相同的共享秘密。

1
2
3
4
5
6
7
8
9
10
11
12
客户端                                  服务器
  │                                        │
  │──── 公开的密钥交换信息 ─────────────→│
  │←─── 公开的密钥交换信息 ──────────────│
  │                                        │
  │ 各自进行数学计算                        │
  │                                        │
  ▼                                        ▼
相同的共享秘密                         相同的共享秘密
  │                                        │
  ▼                                        ▼
派生会话密钥                           派生会话密钥

监听网络的攻击者即使看到公开交换信息，也不能仅凭这些信息轻易计算出共享秘密。

TLS 再利用共享秘密和握手数据派生出相应的加密密钥。

5. 服务器私钥到底负责什么？

在现代 TLS 1.3 的典型证书握手中：

  • 服务器证书提供公钥及身份信息。
  • 服务器私钥用于签署握手数据，证明对相应私钥的持有。
  • ECDHE 等机制负责协商共享秘密。
  • TLS 使用派生出的密钥保护后续通信。

因此，不能简单理解成“浏览器把会话密钥用服务器公钥加密，再发给服务器”。

那是对部分旧式密钥交换方式的描述，不是现代 TLS 1.3 的典型流程。

6. 什么是会话密钥？

会话密钥是 TLS 根据密钥交换结果和握手数据派生出来、用于保护通信的密钥材料。

它可以用于派生不同方向、不同用途的流量密钥。

实际通信时，TLS 通常使用 AES-GCM 或 ChaCha20-Poly1305 等认证加密算法保护数据。

这类算法不仅提供机密性，也能检测密文被篡改的情况。

五、一次真实 HTTPS 请求的完整流程

假设你在 Chrome 地址栏输入：

1
https://example.com/index.html

整个过程可以分成以下步骤。

第 1 步：浏览器解析 URL

URL 可以拆解为：

1
2
3
https://example.com:443/index.html
  │          │       │       │
 协议        域名    端口    路径

其中：

  • https：表示使用 HTTPS。
  • example.com：目标域名。
  • 443：HTTPS 的默认端口。
  • /index.html：请求的资源路径。

如果没有显式指定端口，浏览器通常使用 HTTPS 默认端口 443。

第 2 步：DNS 解析域名

浏览器需要知道目标域名对应的 IP 地址。

1
2
3
example.com
     ↓ DNS 查询
服务器 IP 地址

DNS 查询可能先命中浏览器或操作系统缓存；如果没有缓存答案，则可能向配置的递归 DNS 解析器查询。

递归解析器必要时会通过根 DNS、顶级域 DNS 和权威 DNS 等层次找到答案。

注意：DNS 不负责建立 HTTPS 连接，它主要负责将域名解析为相应的网络记录。

第 3 步：建立传输连接

在传统 HTTP/1.1、HTTP/2 over TLS 的常见场景中，浏览器会与服务器建立 TCP 连接。

例如：

1
2
客户端：192.168.1.100:52341
服务器：93.184.216.34:443

上面是示意地址和端口。

TCP 通过三次握手建立连接：

1
2
3
4
5
6
7
客户端                         服务器

  │──── SYN ─────────────────→│
  │←─── SYN + ACK ────────────│
  │──── ACK ─────────────────→│
  │                            │
  │       TCP 连接建立         │

TCP 主要提供可靠、有序的字节流传输。

注意：HTTPS 并不总是使用 TCP。HTTP/3 使用 QUIC，而 QUIC 基于 UDP。

第 4 步：进行 TLS 握手

在 TCP 上运行 TLS 的场景中，TCP 连接建立后，客户端开始 TLS 握手。

双方协商协议参数、执行密钥交换，并完成必要的身份认证。

第 5 步：验证证书和服务器身份

浏览器检查证书的域名、有效期、证书链、数字签名及用途等信息。

服务器还会通过握手签名证明自己持有证书对应的私钥。

验证成功后，客户端可以确认当前连接的服务器身份符合预期的证书验证规则。

第 6 步：建立加密通信

双方从握手中派生出通信密钥，随后使用 TLS 记录层的保护机制传输数据。

1
2
3
4
5
HTTP 数据
    ↓
TLS 加密及完整性保护
    ↓
网络传输

第 7 步：浏览器发送 HTTP 请求

例如：

1
2
3
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html

实际请求还可能包含 Cookie、User-Agent、Accept-Encoding 等请求头。

在常规 HTTPS 连接中，这些 HTTP 内容由 TLS 保护后再传输。

第 8 步：服务器返回 HTTP 响应

例如：

1
2
HTTP/1.1 200 OK
Content-Type: text/html

响应正文可能是 HTML。

数据在网络上传输时由 TLS 保护，浏览器收到数据后进行解密和验证，再把 HTTP 响应交给浏览器的相关组件处理。

第 9 步：浏览器解析和渲染页面

浏览器解析 HTML，构建页面结构，并根据需要继续请求 CSS、JavaScript、图片等资源。

例如：

1
2
3
<link rel="stylesheet" href="/style.css">
<script src="/app.js"></script>
<img src="/logo.png">

浏览器会根据页面内容发起后续请求，最终完成网页渲染。

完整流程图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
输入 HTTPS URL
      ↓
解析 URL
      ↓
DNS 解析域名
      ↓
获得服务器 IP
      ↓
建立 TCP 连接
      ↓
进行 TLS 握手
      ↓
验证证书与服务器身份
      ↓
协商并派生通信密钥
      ↓
发送加密的 HTTP 请求
      ↓
服务器处理请求
      ↓
返回加密的 HTTP 响应
      ↓
浏览器解密并解析 HTML
      ↓
请求 CSS、JS、图片等资源
      ↓
渲染网页

六、IP、端口、TCP、UDP、路由器与 NAT

1. IP 地址是什么？

IP 地址用于标识 IP 网络中的网络接口，并让数据包能够被路由到目标网络。

例如：

1
2
192.168.1.100
93.184.216.34

IP 地址与域名不同：

  • 域名：方便人类记忆的名称。
  • IP 地址：网络层使用的地址。

域名通常通过 DNS 解析到 IP 地址，但一个域名可能对应多个 IP，一个 IP 也可能承载多个域名。

2. 端口是什么？

端口用于在一台主机上区分不同的传输层服务端点。

常见默认端口：

服务 默认端口
HTTP 80
HTTPS 443
SSH 22
DNS 53
MySQL 3306
Redis 6379

这些是常见默认值，不意味着每个服务都必须使用对应端口。

可以记住：

IP 地址帮助找到目标主机；端口帮助找到目标传输层服务。

3. 为什么客户端也有端口？

客户端连接服务器时，通常使用一个临时端口。

例如：

1
2
3
客户端 192.168.1.100:52341
                ↓
服务器 93.184.216.34:443

其中：

  • 客户端端口 52341：示例临时端口。
  • 服务器端口 443：HTTPS 默认端口。

TCP 连接通常可以用以下四项来区分：

1
源 IP + 源端口 + 目标 IP + 目标端口

此外还需要考虑传输层协议，例如 TCP 或 UDP。

4. TCP 是什么？

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的传输层协议。

主要特点：

  • 提供可靠、有序的字节流传输。
  • 通过确认、重传等机制处理丢包。
  • 使用流量控制和拥塞控制。
  • 通过连接建立与关闭管理通信状态。

TCP 本身不负责加密，也不验证网站证书。

5. UDP 是什么？

UDP（User Datagram Protocol，用户数据报协议）是一种无连接的传输层协议。

它不提供 TCP 那样的可靠、有序字节流保证。

UDP 开销较小，适合需要自行实现传输机制的协议。QUIC 就在 UDP 之上实现了连接管理、可靠传输、拥塞控制和 TLS 1.3 安全机制的集成。

6. 路由器是什么？

路由器负责在不同网络之间转发 IP 数据包。

在家用网络中：

1
2
3
4
5
6
7
电脑
  ↓
家用路由器
  ↓
互联网
  ↓
目标服务器

路由器可能同时提供 Wi-Fi、DHCP、NAT 和防火墙等功能，但这些功能并不是路由本身的定义。

7. 什么是私有 IP？

常见 IPv4 私有地址范围包括：

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

例如：

1
2
电脑：192.168.1.100
路由器：192.168.1.1

这些地址通常用于局域网，不能直接作为全球公网中的普通目的地址进行路由。

8. 什么是 NAT？

NAT（Network Address Translation，网络地址转换）会转换 IP 地址，有些场景还会同时转换端口。

家用路由器常使用 NAPT，也称 PAT，让多个内网设备共享一个公网 IPv4 地址。

示意：

1
2
3
4
5
6
7
8
9
10
内网连接：
192.168.1.100:52341
        ↓
路由器进行地址和端口转换
        ↓
公网连接：
203.0.113.10:62001
        ↓
目标服务器：
93.184.216.34:443

上面的公网地址和端口仅为示意。

路由器会记录映射关系，以便收到返回数据时，将数据转回对应的内网设备。

NAT 不等于加密，也不能代替 TLS 的身份认证和数据保护。

七、HTTP、TLS、TCP、IP 分别处于什么层次？

在传统 HTTPS over TCP 场景中，可以这样理解：

1
2
3
4
5
6
7
8
9
10
11
应用层：HTTP
    ↓
安全协议：TLS
    ↓
传输层：TCP
    ↓
网络层：IP
    ↓
链路层：以太网 / Wi-Fi
    ↓
物理传输介质

各层职责不同：

协议或技术 主要职责
HTTP 定义请求、响应、请求头和响应正文等
TLS 身份认证、密钥协商、加密和完整性保护
TCP 可靠、有序的字节流传输
UDP 无连接的数据报传输
IP 寻址与数据包路由
DNS 将域名解析为 IP 等 DNS 记录
NAT 在适用的网络设备上转换地址，常伴随端口转换

注意：DNS 通常需要在建立目标网站的 TCP/TLS 连接前完成，但 DNS 自身可以使用 UDP、TCP 或其他传输方式。实际网络中还可能涉及代理、VPN、缓存、CDN 等机制。

八、HTTP/1.1、HTTP/2 与 HTTP/3

HTTP 版本与 TLS 版本不是同一个概念。

HTTP 版本 常见传输方式 主要特点
HTTP/1.1 TCP，可通过 TLS 使用 HTTPS 传统的 HTTP 协议版本
HTTP/2 TCP + TLS 是主流部署方式 支持多路复用、头部压缩等
HTTP/3 QUIC（基于 UDP） 将传输层机制与 TLS 1.3 安全机制整合

传统 HTTPS 常见路线：

1
2
3
4
5
6
7
HTTP
  ↓
TLS
  ↓
TCP
  ↓
IP

HTTP/3 路线：

1
2
3
4
5
6
7
HTTP/3
  ↓
QUIC（集成 TLS 1.3 握手与安全机制）
  ↓
UDP
  ↓
IP

为什么 HTTP/3 使用 QUIC？

  • QUIC 将可靠传输、拥塞控制和 TLS 1.3 安全机制整合在一起。
  • QUIC 支持多个独立的数据流，减少一个流的丢包对其他流造成的传输阻塞。
  • 在适用场景中，连接建立和网络切换可以更高效。

因此，不能简单地说 HTTPS 必须使用 TCP。HTTPS 可以使用 HTTP/1.1、HTTP/2 或 HTTP/3 等不同组合。

九、常见网络问题与排查方向

排查网络问题时，可以从基础连接逐步向上检查。

1. DNS 解析失败

典型提示：

1
DNS_PROBE_FINISHED_NXDOMAIN

可能原因：

  • 域名拼写错误。
  • 域名不存在或 DNS 记录配置错误。
  • DNS 缓存或解析器出现问题。

排查方向：先检查域名与 DNS 解析结果。

2. TCP 连接失败

可能提示：

1
2
Connection refused
Connection timed out

可能原因：

  • 服务器端口没有服务监听。
  • 防火墙或安全组阻止连接。
  • 网络路径不通。
  • 服务主动拒绝连接。

排查方向：检查目标 IP、端口、服务监听状态和网络策略。

3. 证书错误

例如：

1
ERR_CERT_DATE_INVALID

可能原因：

  • 证书过期或尚未生效。
  • 客户端系统时间不正确。

其他证书错误也可能涉及域名不匹配、证书链不完整或不受信任的 CA。

排查方向：检查系统时间、证书有效期、域名和证书链。

4. HTTP 502 Bad Gateway

502 表示服务器作为网关或代理时，从上游服务器收到了无效响应。

常见排查方向：

  • Nginx 或其他反向代理配置。
  • 后端服务是否运行。
  • 代理目标地址与端口。
  • 上游连接和响应情况。

502 不一定是 TLS 证书问题。

5. 常见排查顺序

1
2
3
4
5
6
7
8
9
10
11
① 检查域名与 DNS
       ↓
② 检查目标 IP 与网络连通性
       ↓
③ 检查 TCP 端口与服务监听
       ↓
④ 检查 TLS 握手与证书
       ↓
⑤ 检查 HTTP 状态码与响应
       ↓
⑥ 检查应用代码和网页资源

实际排查时应结合错误类型；这是一种思考框架，不是每个问题都必须严格执行的固定步骤。

十、核心概念对照表

概念 一句话理解
HTTP 客户端和服务器交换 Web 数据的应用层协议
HTTPS 使用 TLS 保护的 HTTP 通信
SSL 已淘汰的旧安全协议
TLS 为通信提供认证、加密和完整性保护的协议
证书 将身份信息与公钥关联起来的数字文件
CA 按照验证规则签发证书的机构
证书链 从网站证书到受信任根证书的验证路径
公钥 可公开的密码学密钥
私钥 必须受到保护的密码学密钥
数字签名 验证签名来源与数据完整性的密码学机制
对称加密 使用共享密钥进行加密和解密
ECDHE 用于协商共享秘密的临时密钥交换机制
会话密钥 TLS 根据握手结果派生的通信密钥材料
DNS 将域名解析为 IP 等记录的系统
IP 网络层寻址与路由所使用的协议
端口 区分传输层服务端点的编号
TCP 提供可靠、有序字节流的传输层协议
UDP 提供无连接数据报传输的协议
NAT 转换网络地址，常用于多个内网设备共享公网 IPv4
QUIC 基于 UDP、集成 TLS 1.3 安全机制的现代传输协议

十一、最后需要记住的 10 个知识点

  1. HTTPS = HTTP + TLS 安全保护。
  2. 现代 HTTPS 使用 TLS，而不是已经淘汰的 SSL。
  3. 证书把域名等身份信息与公钥关联起来；CA 帮助建立信任。
  4. 数字签名用于验证签名来源和数据完整性，不等于加密。
  5. 对称加密适合大量数据传输；TLS 通过握手建立和派生通信密钥。
  6. 在现代 TLS 1.3 的典型证书握手中，服务器私钥用于握手签名，ECDHE 用于密钥交换。
  7. DNS 负责解析域名；IP 负责网络寻址；端口用于区分传输层服务。
  8. TCP 负责可靠传输，不负责加密；TLS 负责通信安全保护。
  9. NAT 可以转换地址和端口，但不能替代 TLS。
  10. HTTP/3 使用 QUIC over UDP，不要求使用传统的 TCP 传输路线。

用一句话概括一次 HTTPS 请求：

浏览器先解析域名并找到目标服务器，再通过相应的传输协议建立连接，完成 TLS 身份认证与密钥协商，随后发送受保护的 HTTP 请求、接收 HTTP 响应，最后解析和渲染网页。