Https 和 http 区别

1. HTTP 和 HTTPS

1.1 HTTP 是什么

HTTP（HyperText Transfer Protocol，超文本传输协议）是应用层协议，用于规定：

客户端和服务端如何通信
请求和响应怎么组织
方法、状态码、Header、Body 分别表达什么语义

它最初主要服务于网页传输，但今天早已不只是“传页面”，还广泛用于：

浏览器访问网站
App 调后端接口
服务之间的 API 调用
网关、代理、CDN、对象存储访问

HTTP 本身并不负责：

加密
身份认证
可靠传输

它通常建立在 TCP 之上，由 TCP 负责可靠传输。

1.2 HTTPS 是什么

HTTPS（HTTP Secure）可以理解为：

HTTP + TLS

也就是在 HTTP 和 TCP 之间，增加了一层 TLS（早期常叫 SSL）安全层。

它的目标不是改变 HTTP 的业务语义，而是给 HTTP 通信增加 3 类安全能力：

机密性：防窃听
完整性：防篡改
身份认证：防冒充

所以：

HTTP 解决“怎么传”
HTTPS 解决“怎么安全地传”

2. HTTP 的基本原理

2.1 HTTP 的通信模型

HTTP 最经典的模型是：

请求 - 响应（Request - Response）

也就是：

客户端发请求
服务端处理请求
服务端返回响应

客户端常见有：

浏览器
手机 App
后端服务
爬虫

服务端常见有：

Nginx
Apache
Tomcat
网关
业务服务

2.2 HTTP 报文由什么组成

2.2.1 请求报文

一个 HTTP 请求通常包括：

请求行
方法、路径、协议版本
请求头（Headers）
Host
User-Agent
Cookie
Authorization
Content-Type
Accept
请求体（Body）
常见于 POST、PUT、PATCH

例如：

GET /api/user?id=1 HTTP/1.1
Host: example.com
User-Agent: curl/8.0
Accept: application/json

2.2.2 响应报文

一个 HTTP 响应通常包括：

状态行
协议版本、状态码、状态描述
响应头
Content-Type
Content-Length
Set-Cookie
Cache-Control
Content-Encoding
响应体
HTML
JSON
图片
文件二进制内容

例如：

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 17

{"name":"alice"}

2.3 HTTP 为什么说是“无状态”

HTTP 的“无状态”指的是：

协议层默认不记住上一次请求的业务状态

也就是说：

第 1 次请求和第 2 次请求在协议层天然没有会话上下文

这带来的好处是：

简单
易扩展
服务端更容易水平扩容

但代价是：

登录态、购物车、会话身份这些信息不能靠 HTTP 本身保存

所以工程上通常要借助：

Cookie
Session
Token
JWT

来补足“状态”。

2.4 HTTP 为什么依赖 TCP

HTTP 常见实现建立在 TCP 之上，是因为 Web 场景通常要求：

数据不能乱序
数据不能丢
数据不能重复
大量请求需要稳定可靠到达

这些能力由 TCP 提供：

三次握手建连
序列号和确认应答
重传机制
滑动窗口
拥塞控制

所以 HTTP 关注的是应用层语义，底层可靠性交给 TCP。

3. HTTP 的实现与版本演进

3.1 HTTP/1.0

HTTP/1.0 的特点可以概括为：

默认短连接
一个请求通常对应一条 TCP 连接

这意味着如果页面资源很多：

HTML 一个连接
CSS 一个连接
JS 一个连接
图片又是多个连接

连接建立和关闭开销会很大。

3.2 HTTP/1.1

HTTP/1.1 相比 1.0 的重要改进包括：

默认支持长连接（Keep-Alive）
支持 Host 头
更成熟的缓存控制机制
支持分块传输（Chunked Transfer Encoding）

但 HTTP/1.1 依然有明显问题：

单连接内请求响应基本是串行的
容易出现队头阻塞
浏览器通常仍需为同一域名维护多条连接来提高并发

3.3 HTTP/2

HTTP/2 没有改变 HTTP 的语义，但改变了传输方式：

文本报文改为二进制分帧
单连接多路复用
Header 压缩
支持服务端推送（但实践中使用有限）

它的核心收益是：

减少多连接开销
提升并发传输效率
缓解 HTTP/1.1 的应用层队头阻塞

3.4 HTTP/3

HTTP/3 的关键变化是：

不再基于 TCP
改为基于 QUIC
QUIC 又是构建在 UDP 之上的可靠传输协议

HTTP/3 的工程价值主要体现在：

更快的连接建立
更好的弱网表现
避免 TCP 层队头阻塞

3.5 面试里怎么概括 HTTP 版本差异

可以简单记成：

HTTP/1.0：默认短连接
HTTP/1.1：默认长连接，但并发仍依赖多连接
HTTP/2：单连接多路复用
HTTP/3：基于 QUIC，进一步优化握手与弱网传输

4. HTTP 请求方式（Methods）

HTTP 方法描述的是：客户端想对目标资源执行什么操作。

最常见的方法有：

GET
POST
PUT
DELETE
PATCH
HEAD
OPTIONS

另外还有了解即可的方法：

CONNECT
TRACE

4.1 GET

GET 用于获取资源，是最常见的请求方法。

它的典型特点是：

主要用于读取和查询
参数通常拼在 URL 上
一般是幂等的
一般是安全（Safe）的
更容易被浏览器或代理缓存

典型场景：

获取用户信息
查询商品列表
浏览网页

注意：

参数出现在 URL 中，不适合承载敏感信息
是否安全传输，取决于有没有 HTTPS，而不是取决于它是 GET 还是 POST

4.2 POST

POST 通常用于提交数据，最常见语义是创建资源，也经常用于触发某个服务端动作。

它的典型特点是：

数据通常放在请求体中
通常不是幂等的
默认不以缓存为主
常用于创建、提交、触发动作

典型场景：

用户注册
创建订单
提交评论

4.3 PUT

PUT 通常表示对资源做完整更新或整体替换。

它的典型特点是：

请求体里通常包含完整资源表示
同一个 PUT 重复执行多次，最终状态通常一致
所以它通常被认为是幂等的

典型场景：

完整更新用户资料
用一份新配置整体替换旧配置

4.4 DELETE

DELETE 用于删除资源。

它的典型特点是：

删除同一资源多次，最终状态通常相同
所以通常被认为是幂等的

典型场景：

删除文章
删除订单
删除某条配置

4.5 PATCH

PATCH 用于部分更新资源。

它和 PUT 的区别是：

PUT 更像整体替换
PATCH 更像只改部分字段

是否幂等，要看接口具体语义：

如果多次重放结果一致，那它就是幂等的
如果每次重放都会继续叠加效果，那它就不是幂等的

4.6 HEAD

HEAD 和 GET 语义类似，但：

只返回响应头
不返回响应体

它常用于：

探测资源是否存在
获取 Content-Length
获取缓存相关 Header

4.7 OPTIONS

OPTIONS 用于查询目标资源支持哪些方法和能力。

最典型的工程场景是：

CORS 预检请求

浏览器会先发一个 OPTIONS，确认：

允不允许跨域
允许哪些方法
允许哪些 Header

4.8 CONNECT 与 TRACE

CONNECT
常用于建立代理隧道，尤其是 HTTPS 代理场景
TRACE
用于回显请求链路，安全上通常会禁用

4.9 Safe 和 Idempotent 怎么区分

这两个概念在面试里很常见。

Safe（安全）
指语义上不应修改服务端状态
常见如 GET、HEAD、OPTIONS
Idempotent（幂等）
指同一个请求重复执行多次，最终资源状态相同
常见如 GET、PUT、DELETE

一句话区分：

Safe 强调“不改状态”
Idempotent 强调“重复执行结果一致”

方法	主要用途	是否幂等	是否安全	数据位置
`GET`	查询/获取资源	是	是	URL
`POST`	创建/提交动作	否（通常）	否	请求体
`PUT`	完整更新/替换	是	否	请求体
`DELETE`	删除资源	是	否	URL
`PATCH`	部分更新	取决于语义	否	请求体
`HEAD`	获取元数据	是	是	URL
`OPTIONS`	查询支持方法	是	是	N/A
`CONNECT`	建立隧道	通常是	否	N/A
`TRACE`	回显请求	通常是	通常是	N/A

5. HTTP 响应码（Status Code）

响应码是服务端告诉客户端“这次请求处理结果如何”的标准信号。

它的意义不只是给人看，更重要的是让：

浏览器
客户端 SDK
网关
代理
重试逻辑

都能根据不同结果走不同分支。

5.1 1xx：信息性状态码

这一类表示请求已收到，处理还在继续。

最常见的是：

100 Continue
表示服务端已经收到请求头，可以继续发送请求体
常用于大文件上传前的协商优化

5.2 2xx：成功状态码

这类表示请求已被成功接收、理解并处理。

200 OK
最常见成功码
表示请求成功，通常响应体中有结果
201 Created
表示成功创建了新资源
通常会配合 Location 头返回新资源地址
202 Accepted
表示请求已接收，但还没处理完
常见于异步任务
204 No Content
表示请求成功，但响应体为空
很适合删除成功、更新成功但不需要返回内容的场景

5.3 3xx：重定向状态码

这类表示客户端还需要继续做动作，通常是访问另一个 URL。

301 Moved Permanently
永久重定向
常见于域名迁移、HTTP 跳 HTTPS
302 Found
临时重定向
常见于未登录跳转登录页
304 Not Modified
资源未变化
告诉客户端可以直接使用本地缓存
是缓存协商非常关键的状态码

5.4 4xx：客户端错误状态码

这类状态码说明：

服务端理解了请求
但问题出在客户端请求本身

常见的有：

400 Bad Request
参数格式错误、请求体不合法
401 Unauthorized
更准确地说是“未认证”
服务端还不知道你是谁
403 Forbidden
服务端知道你是谁
但你没权限访问
404 Not Found
资源不存在
405 Method Not Allowed
资源存在，但这个方法不被允许
409 Conflict
请求与当前资源状态冲突
常见于重复创建、版本冲突

5.5 5xx：服务端错误状态码

这类状态码说明：

请求本身看起来是合法的
但服务端内部处理失败了

常见的有：

500 Internal Server Error
服务端内部异常
最通用的兜底错误码
502 Bad Gateway
网关或代理从上游收到无效响应
常见于 Nginx -> 应用服务链路异常
503 Service Unavailable
服务当前不可用
可能是过载、限流、维护
504 Gateway Timeout
网关等待上游超时
常见于上游接口过慢

5.6 一张表记住最常用响应码

状态码	含义	常见场景
`200`	请求成功	普通查询成功
`201`	资源已创建	创建用户、创建订单
`202`	已接受，异步处理中	提交导出任务
`204`	成功但无响应体	删除成功
`301`	永久重定向	域名迁移、HTTP 跳 HTTPS
`302`	临时重定向	未登录跳登录页
`304`	资源未修改	协商缓存命中
`400`	请求错误	参数格式错误
`401`	未认证	未登录、Token 缺失
`403`	无权限	普通用户访问管理接口
`404`	资源不存在	URL 错误、对象不存在
`405`	方法不允许	用 POST 调只支持 GET 的接口
`409`	资源冲突	重复提交、版本冲突
`500`	服务端异常	代码报错
`502`	网关错误	代理到上游失败
`503`	服务不可用	过载、维护、限流
`504`	网关超时	上游响应太慢

5.7 401 和 403 的区别

这是面试高频点。

401
你还没有完成认证
服务端不知道你是谁
403
服务端知道你是谁
但你没有权限访问

所以：

未登录，更像 401
已登录但没权限，更像 403

6. HTTPS 的基本原理

6.1 为什么 HTTP 不安全

HTTP 明文传输，意味着链路中的中间节点理论上都可能看到内容。

它主要有 3 类风险：

窃听
别人能看到你传的内容
篡改
别人能改你传输中的数据
冒充
你以为你连的是服务端，其实可能连到了攻击者

这也是 HTTPS 出现的根本原因。

6.2 HTTPS 解决的核心问题

HTTPS 要解决的核心问题是：

如何确认“对方真的是我要访问的服务端”
如何安全地协商出一个双方都知道、别人不知道的密钥
如何用这个密钥高效加密后续海量 HTTP 数据

6.3 为什么 HTTPS 不直接全程用非对称加密

因为非对称加密虽然安全，但太慢。

它适合：

身份认证
密钥交换

不适合：

加密大量业务数据

所以 HTTPS 采用的是混合加密：

用非对称加密解决密钥交换问题
用对称加密解决高吞吐数据传输问题

7. HTTPS 的实现：TLS 是怎么工作的

7.1 TLS 在 HTTPS 里的位置

从分层角度看，可以近似理解为：

HTTP 在上
TLS 在中
TCP 在下

也就是：

HTTP
TLS
TCP
IP

HTTP 不感知底层加密细节，它只负责把请求和响应交给 TLS 层处理。

7.2 TLS 握手的核心目标

TLS 握手不是单纯“打个招呼”，它至少要完成这些事：

协商 TLS 版本
协商密码套件
服务端出示证书
客户端验证证书
双方协商出会话密钥
后续使用对称加密保护 HTTP 数据

7.3 TLS 握手流程

面试里讲 TLS 握手，最好先说明：

本质是“认证 + 密钥协商”过程
前几步主要解决“你是谁”
后几步主要解决“后续通信用什么密钥加密”

从工程实践看，现在主流应优先理解 TLS 1.2（基于 ECDHE） 和 TLS 1.3。

7.3.1 以 TLS 1.2 为例的典型握手过程

如果忽略极少数扩展字段，可以把 TLS 1.2 握手理解成下面几步：

ClientHello
ServerHello + Certificate + ServerKeyExchange
客户端验证证书并生成预主密钥材料
双方推导出会话密钥
ChangeCipherSpec + Finished
后续 HTTP 数据开始加密传输

可以结合每一步理解。

7.3.2 第一步：ClientHello

客户端先发 ClientHello，主要带上这些信息：

支持的 TLS 版本
支持的密码套件列表
一个客户端随机数 Client Random
支持的扩展能力，比如 SNI、ALPN

这一步的目标是告诉服务端：

我支持哪些协议能力
我希望和你协商出哪种安全参数

7.3.3 第二步：ServerHello 与服务端身份证明

服务端收到后，会返回一组关键信息：

ServerHello
确认选用的 TLS 版本
确认选用的密码套件
返回一个服务端随机数 Server Random
Certificate
把服务端证书链发给客户端
ServerKeyExchange
如果使用 ECDHE 这类密钥交换算法，还会发送临时公钥参数
ServerHelloDone
表示服务端这一阶段消息发送结束

这里最重要的是两件事：

服务端出示证书，证明“我是这个域名对应的服务端”
服务端给出密钥交换所需参数，准备和客户端协商会话密钥

7.3.4 第三步：客户端验证证书

客户端拿到证书后，不是“看一眼就信”，而是要做一系列校验：

证书链是否能追溯到受信任的根 CA
证书签名是否有效
证书是否过期
证书中的域名是否和访问域名匹配
证书是否被吊销（工程上可能结合 CRL、OCSP）

如果这些校验失败，浏览器通常会直接报证书错误。

这一步解决的是：

身份认证问题

也就是确认：

当前拿到的公钥，确实属于目标服务端，而不是中间人伪造的

7.3.5 第四步：协商预主密钥并生成会话密钥

接下来客户端会根据选定的密钥交换算法，生成密钥协商材料。

如果是现代最常见的 ECDHE：

客户端生成自己的临时密钥对
把客户端临时公钥通过 ClientKeyExchange 发给服务端
客户端和服务端分别基于各自私钥、对方公钥，计算出同一份共享秘密

这里一定要注意：

私钥不会在网络上传输
会传输的只有公钥或证书中的公钥信息

更准确地说：

服务端会把自己的证书发给客户端，证书里包含服务端长期公钥
如果使用 ECDHE，服务端还会在握手里发送自己的临时公钥参数
客户端会把自己的临时公钥通过 ClientKeyExchange 发给服务端
客户端临时私钥始终只保存在客户端本地
服务端临时私钥始终只保存在服务端本地

所以整个过程中，双方并不是“把私钥传给对方”，而是：

各自保留私钥不外传
交换彼此的公钥
再在本地用“自己的私钥 + 对方的公钥”各自算出同一份共享秘密

之所以双方能算出相同结果，本质上依赖的是椭圆曲线 Diffie-Hellman 的数学性质，而不是私钥被传来传去。

然后双方再结合：

Client Random
Server Random
共享秘密

通过约定的密钥派生函数，推导出本次会话真正使用的对称密钥。

这里要强调一个高频面试点：

后续真正加密 HTTP 数据的，不是证书公钥，而是握手阶段协商出来的对称会话密钥

7.3.6 第五步：切换到加密通信

当双方都推导出会话密钥后，会进入“开始启用加密”的阶段。

典型流程是：

客户端发送 ChangeCipherSpec
客户端发送 Finished
服务端发送 ChangeCipherSpec
服务端发送 Finished

其中 Finished 消息已经使用新协商出的密钥进行保护，它的意义是：

验证前面整个握手过程没有被篡改
证明双方确实拿到了同一套密钥材料

如果 Finished 校验通过，握手就完成了。

7.3.7 第六步：开始传输加密后的 HTTP 数据

到这里，HTTPS 才真正进入业务数据传输阶段。

后续流程就是：

HTTP 请求报文交给 TLS
TLS 使用会话密钥进行加密和完整性保护
服务端收到后解密，再交给 HTTP/应用层处理

所以从抓包角度看：

在 TCP 建连之后，先看到 TLS 握手报文
握手完成后，才会出现被加密保护的应用数据

7.3.8 为什么现代 TLS 更偏向 ECDHE

面试里经常会继续追问：为什么现在不推荐旧式 RSA 密钥交换，而更推荐 ECDHE？

核心原因是：

ECDHE 可以提供 前向安全性（Forward Secrecy）

这意味着：

即使未来服务端长期私钥泄露，也不能直接解密过去抓到的所有会话流量

因为每次握手都会使用一次性的临时密钥，历史会话密钥不会被长期私钥直接复原。

7.3.9 TLS 1.3 相比 TLS 1.2 的变化

如果面试官继续深入，可以补一句：

TLS 1.3 不是推翻 TLS，而是在握手流程和安全性上进一步简化与加强

它的典型特点包括：

去掉了很多不安全或过时的算法
默认采用更现代的密钥交换方式
握手往返次数更少，建连更快
更适合现代互联网高性能场景

可以粗略理解为：

TLS 1.2：握手更复杂，兼容历史包袱更多
TLS 1.3：握手更短，默认安全性更强

7.3.10 面试里怎么一句话讲清 TLS 握手

可以这样概括：

TLS 握手的本质，是客户端和服务端先协商协议参数，再由服务端出示证书完成身份认证，最后双方协商出对称会话密钥，供后续 HTTP 数据加密传输使用

如果再压缩成更口语化的一句：

先验明身份，再协商密钥，最后用对称加密传数据

8. 证书、CA 和信任链

8.1 为什么需要证书

如果服务端只把公钥直接发给客户端，会有一个问题：

客户端怎么知道这个公钥真的是服务端的，而不是攻击者伪造的

这就是证书存在的意义。

证书本质上是：

“某个公钥属于某个域名/主体”的身份证明

8.2 CA 是什么

CA（Certificate Authority，证书颁发机构）是受信任第三方。

它的职责是：

审核申请者身份
给证书签名
建立信任关系

浏览器和操作系统通常预置了一批受信任根 CA。

8.3 证书链是怎么建立信任的

浏览器验证的不是单张证书，而是一整条链：

站点证书
中间 CA 证书
根 CA 证书

只要这条链能追溯到本地信任的根 CA，并且各环节签名都成立，证书就被认为可信。

8.4 证书解决了什么问题

证书主要解决的是：

身份认证

它回答的是：

“你拿到的这个公钥，是否真的属于这个域名对应的服务端”

8.5 用私钥签名、公钥验签是什么意思

可以用一句话概括：

私钥签名是“盖章”，公钥验签是“验章”

它主要证明两件事：

这份内容确实来自私钥持有者
内容在传输过程中没有被篡改

最简流程是：

发送方先对原文做哈希，得到摘要
发送方用私钥对摘要做签名，得到签名值
接收方用公钥验证签名，得到或确认摘要信息（可记为摘要 B）
接收方再对原文做哈希，得到摘要 A
比较摘要 A 和摘要 B，一致则验签通过

注意区分：

签名关注的是身份认证 + 完整性
加密关注的是机密性

8.6 CA 为什么能防范中间人攻击

核心不是“CA 让攻击者无法拦截流量”，而是：

CA 让攻击者难以伪造一个会被客户端信任的服务端身份

中间人攻击成立的前提通常是：

攻击者把自己伪装成目标站点
客户端还误以为“这就是目标站点”

CA 体系通过以下机制阻断这个前提。

证书由受信任 CA 签名
服务端证书不是自说自话，而是由 CA 用私钥签名
客户端本地预置了受信任根 CA 公钥
客户端会验证证书链签名是否成立

攻击者即使能截获流量，也很难伪造出一张“签名可验证且被系统信任”的目标站点证书。

域名绑定校验
客户端会校验证书里的域名（CN/SAN）是否与访问域名一致

即使攻击者拿到的是自己域名的合法证书，也无法冒充别人的域名。

私钥持有证明
服务端在握手中需要证明自己持有与证书公钥对应的私钥

只有真正持有该私钥的一方，才能完成对应握手签名/密钥协商步骤。仅有证书副本但没有私钥，仍无法冒充。

证书失效与吊销机制（补强）
客户端可结合证书有效期、吊销信息（如 CRL、OCSP）进一步降低风险

这能减少“证书泄露后长期可被利用”的窗口期。

可以在面试里这样总结：

CA 的价值在于把“公钥属于谁”这件事变成可验证的信任链，客户端只信任链路可验证且域名匹配的证书，从而显著抬高中间人伪造身份的成本。

9. HTTP 和 HTTPS 的区别

9.1 最核心区别：是否有 TLS 安全层

HTTP
明文传输
不提供加密、完整性校验和身份认证
HTTPS
在 HTTP 基础上增加 TLS
提供机密性、完整性和身份认证

9.2 默认端口不同

HTTP 默认端口：80
HTTPS 默认端口：443

注意：

这是默认端口，不是强制端口
也可以部署在 8080、8443 等端口

9.3 建连成本不同

HTTP：
通常只需要 TCP 握手
HTTPS：
需要 TCP 握手 + TLS 握手

所以：

HTTPS 首次建连成本通常更高
但通过连接复用、TLS 会话复用、HTTP/2、HTTP/3，这种差距已经被缩小很多

9.4 性能特征不同

HTTP 协议开销更低
HTTPS 有额外握手与加解密成本

但工程上不能简单说“HTTPS 一定更慢”，因为：

CPU 已比早期强很多
TLS 优化很成熟
HTTP/2/3 通常实际部署在 HTTPS 上
CDN、会话复用、硬件加速会进一步缩小差距

9.5 运维与部署复杂度不同

HTTP 不需要证书
HTTPS 需要：
申请证书
部署证书
管理续期
配置 TLS 版本和密码套件

9.6 HTTP 与 HTTPS

维度	HTTP	HTTPS
本质	应用层协议	HTTP + TLS
传输内容	明文	密文
机密性	无	有
完整性	无	有
身份认证	无	有
默认端口	`80`	`443`
建连成本	TCP 握手	TCP 握手 + TLS 握手
证书	不需要	需要
典型场景	内网调试、低安全场景	互联网正式业务

10. Keep-Alive、连接复用与 HTTP 性能

10.1 Keep-Alive 是什么

Keep-Alive 的核心思想是：

一个 TCP 连接建立后，不要请求一次就立刻关闭，而是尽量复用这条连接处理后续多个 HTTP 请求

它的主要价值是：

减少重复三次握手
减少重复 TLS 握手
降低延迟
降低 CPU 和系统调用成本
降低 TIME_WAIT 压力

10.2 HTTP Keep-Alive 和 TCP Keepalive 不是一回事

HTTP Keep-Alive
应用层连接复用
TCP Keepalive
传输层空闲探测

一句话区分：

HTTP Keep-Alive 偏复用
TCP Keepalive 偏保活

10.3 HTTP/1.0 和 HTTP/1.1 的差异

HTTP/1.0 默认短连接
HTTP/1.1 默认长连接

所以：

HTTP/1.0 常见 Connection: keep-alive
HTTP/1.1 常见 Connection: close

10.4 Keep-Alive 不是万能优化

Keep-Alive 只能降低重复建连成本，但不能解决全部性能问题，例如：

HTTP/1.1 的队头阻塞
慢接口本身的耗时
回源慢
数据库慢
代理层空闲超时

真正的优化常常还要结合：

连接池
TLS 会话复用
HTTP/2 多路复用
HTTP/3

11. HTTP 和 HTTPS 的实现链路

11.1 一次 HTTP 请求的大致过程

解析 URL
DNS 解析域名
建立 TCP 连接
发送 HTTP 请求
服务端处理
返回 HTTP 响应

11.2 一次 HTTPS 请求的大致过程

解析 URL
DNS 解析域名
建立 TCP 连接
进行 TLS 握手
发送加密后的 HTTP 请求
服务端解密、处理、返回加密响应

11.3 HSTS 是什么

HSTS（HTTP Strict Transport Security）的作用是：

告诉浏览器，这个站点未来一段时间内必须强制使用 HTTPS

它可以降低：

用户手动输入 http://
首次明文跳转
某些降级攻击风险