第 4 卷

钥”的协商过程：

• 握手阶段，SSL/TLS会协商确定加密算法（如对称加密算法AES、非对称加密算法RSA/ECC等）；
• 通过非对称加密方式安全传输会话密钥，确保密钥在传输过程中不被窃听（即使被截获，没有服务端

私钥也无法解密）。

1. 数据加密与完整性校验角色：保障传输数据安全

SSL/TLS为后续的HTTP数据传输提供加密和校验能力：

• 加密：所有HTTP数据在发送前，都会通过握手阶段协商好的会话密钥进行对称加密，形成密文后传

输；

• 完整性校验：SSL/TLS会为每个传输的数据包生成“消息认证码（MAC）”，接收方通过验证MAC确

认数据是否被篡改（若篡改，MAC会不一致）；

• 防重放：通过添加“随机数”和“序列号”，防止攻击者截取数据包后重复发送（即“重放攻

击”）。

✅ 补充要点

SSL/TLS协议工作在“传输层（TCP）”和“应用层（HTTP）”之间，对应用层透明⸺HTTP协议无需修改任何逻辑，只需将数据交给SSL/TLS层处理即可实现安全传输；同时，SSL/TLS不仅可用于

HTTP，还可用于FTP、SMTP等其他应用层协议（如FTPS、SMTPS）。

1. 证书颁发机构(CA)在HTTPS中起什么作用？

证书颁发机构（CA，Certificate Authority）是受信任的第三方权威机构，核心作用是“为HTTPS服务提供身份认证保障”，解决“客户端如何信任服务端身份”的问题⸺没有CA的参与，HTTPS的身

份验证机制会失效，无法避免“中间人攻击”，具体作用如下：

一、核心作用：颁发并验证数字证书（身份“介绍信”）

CA的核心工作是为服务端（网站）颁发“数字证书”，该证书是服务端的“网络身份凭证”，包含以下关键信息：服务端域名、服务端公钥、证书有效期、CA机构的数字签名、CA机构名称等。其作用机

制分为两步：

1. 颁发证书（“身份认证+签名背书”）

网站运营者需向CA机构提交申请，提供域名所有权证明、服务器信息等材料，CA机构审核通过后：

• 生成包含网站公钥和身份信息的证书；
• 用CA机构自己的“私钥”对证书进行数字签名（相当于CA的“公章”，证明该证书是合法有效

的）；

验证证书合法性（核心依赖CA的“公钥”）：

• 浏览器内置了主流CA机构的“公钥”（如Symantec、Let's Encrypt等）；
• 用CA的公钥解密证书中的“CA数字签名”，得到证书内容的“哈希值A”；
• 客户端重新计算当前接收证书内容的“哈希值B”；
• 对比哈希值A和哈希值B：若一致，说明证书未被篡改，且确实是该CA颁发的，服务端身份合法；若

不一致，说明证书被篡改或伪造，浏览器提示“网站不安全”。

二、关键作用：防止中间人攻击

没有CA时，攻击者可在客户端和服务端之间实施“中间人攻击”：拦截服务端的公钥，替换为自己的公钥，客户端后续加密的会话密钥会被攻击者获取，进而窃取数据。

CA的存在避免了这一问题：攻击者无法伪造CA的数字签名（没有CA的私钥），其伪造的证书会被客户端验证失败，从而阻止攻击。

三、其他辅助作用

1. 证书管理：提供证书的更新、吊销服务（如证书过期前需重新申请，证书私钥泄露后需申请吊销，

客户端会通过“证书吊销列表（CRL）”或“在线证书状态协议（OCSP）”查询证书状态）；

1. 分级信任：CA采用“分级结构”（根CA→二级CA→终端证书），根CA是最高信任级别，浏览器内

置根CA的公钥，二级CA由根CA授权，可颁发终端证书，实现大规模证书发放。

✅ 补充要点

• CA的核心价值是“信任背书”⸺客户端信任CA，因此信任经过CA签名的证书，进而信任服务端

身份；

• 目前有免费CA（如Let's Encrypt，支持自动续期）和付费CA（如Symantec，提供更高等级的验证

和保障），不同等级的CA审核严格程度不同（如EV证书需验证企业真实身份，浏览器地址栏会显示绿色企业名称）；

• 若网站使用“自签名证书”（未经过CA颁发），客户端无法验证其合法性，浏览器会直接提示“不

安全”，仅适用于内部测试场景，不可用于公网服务。

1. HTTP/2相比于HTTP有哪些主要改进？

HTTP/2（全称为HyperText Transfer Protocol version 2）是HTTP/1.1的重大升级版本，核心设计目标是“提升性能”，解决HTTP/1.1在高并发、大资源加载场景下的效率问题，主要改进围绕“多路复

用、头部压缩、服务器推送”等核心特性展开，具体如下：

• HTTP/1.1的缺陷：同一条TCP连接中，只能串行发送HTTP请求，若前一个请求阻塞（如大文件加

载），后续请求需排队等待（即“队头阻塞”）；为解决此问题，浏览器需建立多个TCP连接（同域名默认6个），但过多连接会增加开销；

• HTTP/2的改进：引入“帧（Frame）”和“流（Stream）”的概念，实现多路复用：

• 帧：HTTP/2的最小传输单位，每个帧包含“流标识”（Stream ID），用于区分属于哪个请求；
• 流：每个HTTP请求对应一个独立的流，多个请求的帧可在同一条TCP连接中并行传输，接收方通

过流标识重组数据；

• 优势：同一条TCP连接可承载无数个HTTP请求，无队头阻塞，减少TCP连接数量，降低开销。

二、头部压缩（减少请求头传输开销）

HTTP/1.1的请求头（如User-Agent、Cookie、Accept等）每次请求都会重复发送，且多为文本格式，传输体积大；HTTP/2通过“HPACK”算法对请求头和响应头进行压缩：

1. 建立“静态字典”：包含常见的请求头字段（如Host、User-Agent）和值，用固定索引表示，无

需重复传输完整字段名和值；

1. 建立“动态字典”：记录当前连接中已传输的头部信息，后续重复的头部可直接引用索引，进一步

减少传输量；

1. 压缩效果：头部体积可减少60%-80%，尤其对移动端（带宽有限）场景提升明显。

三、服务器推送（提前加载资源，提升页面渲染速度）

HTTP/1.1中，服务端只能被动响应客户端的请求；HTTP/2新增“服务器推送”特性：

• 核心逻辑：服务端在响应客户端的主请求（如请求HTML页面）时，可预判客户端后续需要的资源

（如CSS、JS、图片），主动将这些资源推送到客户端缓存中；

• 优势：客户端后续请求这些资源时，无需再向服务端发起请求，直接从本地缓存获取，减少网络往

返时间（RTT），提升页面加载速度；

• 注意：服务器推送可被客户端拒绝（通过设置`SETTINGS_ENABLE_PUSH`参数），避免推送不

必要的资源浪费带宽。

四、其他重要改进

1. 二进制传输：HTTP/1.1的请求/响应报文是文本格式（易读但解析效率低，易出错），HTTP/2采用

二进制格式传输帧数据，解析速度更快，容错性更强；

1. 流量控制：支持客户端和服务端双向流量控制，可根据双方的处理能力调整数据传输速率，避免接

收方因资源不足无法处理数据（如客户端缓存满时，可通知服务端暂停推送）；

1. 优先级设置：客户端可为不同的请求设置优先级（如HTML优先于图片，核心JS优先于非核心