一文讲清网络协议：从打开网页到理解 HTTP、HTTPS 与 TLS

你在浏览器输入：

text 复制代码

https://example.com/products?id=42

然后页面出现了。这个过程看起来像"浏览器把网页打开了"，但背后其实有一组协议在协作。

先记住本文最重要的一句话：

HTTP 规定浏览器和网站服务器"怎么说话"；HTTPS 则是在 HTTP 外面加上 TLS，让这段对话更难被偷看、篡改或冒充。

所以，HTTPS 不是把 HTTP 替换掉的全新网页协议。它仍然在传 HTTP 请求和 HTTP 响应，只是把传输过程放进了更安全的 TLS 通道里。

先理解：什么是网络协议？

网络协议就是通信双方共同遵守的一套规则。

两个人打电话，至少要约定：

谁先说话；
用什么语言；
一句话怎样表示结束；
听不清时怎么重说；
怎样确认对方确实是想联系的人。

计算机网络也一样。设备之间传递的不是"自然语言"，而是字节和数据包；但它们同样需要明确规则：数据格式是什么、先发什么后发什么、收到后如何解释、出错后如何处理。

例如，当浏览器向网站请求一张图片时，它需要知道：

图片在哪个网站、哪个路径；
自己希望获取它，而不是删除它；
服务器是否成功找到图片；
返回的数据到底是图片、HTML 页面还是一段错误提示。

HTTP 就是处理这类"网页资源请求与响应"的规则。

类比只能帮助建立直觉。真实网络中，数据并不是一封完整信件原样飞过去，而是会经过分层封装、拆分、传输和重组。

打开一个 HTTPS 网站时，发生了什么？

把一次访问网页理解成一条流水线即可。不同协议各司其职，而不是互相替代。

浏览器解析 URL：看懂你输入的网址包含什么。
DNS 查地址 ：把 example.com 这样的域名解析为可连接的网络地址。
建立传输通道：通常由 TCP 或 QUIC 负责传送数据。TCP 提供可靠的字节流；QUIC 也可提供可靠的数据流，并支持其他传输方式。
建立 TLS 安全保护 ：如果是 https://，浏览器会验证服务器证书，并协商加密所需的密钥。HTTP/3 使用 QUIC 时，TLS 1.3 的握手与 QUIC 建连过程紧密结合。
发送 HTTP 请求：例如"请给我首页"。
服务器返回 HTTP 响应：例如"成功，这是 HTML 内容"。
浏览器继续请求其他资源并渲染：HTML 往往还引用 CSS、JavaScript、字体、图片、视频等资源，浏览器会继续请求它们，最后把页面显示出来。

可以用下面这个记忆框架理解各层分工：

| 组件或协议 | 主要负责什么 | |---|---| | URL | 告诉浏览器要访问什么资源 | | DNS | 把域名转换为可连接的网络地址 | | IP | 让数据能在网络中找到目的地 | | TCP 或 QUIC | 提供网络传输能力 | | TLS | 保护传输过程：加密、完整性校验和身份认证 | | HTTP | 定义网页请求和响应的含义 |

URL 里有什么？

以这个地址为例：

text 复制代码

https://example.com:443/products?id=42#reviews

可以粗略拆成：

| 部分 | 示例 | 含义 | |---|---|---| | 协议方案 | https | 告诉浏览器使用 HTTPS 方式访问 | | 域名 | example.com | 网站的人类可读名称 | | 端口 | 443 | 服务器上提供服务的"入口编号"；省略时 HTTPS 通常默认使用 443 | | 路径 | /products | 网站中的具体资源位置 | | 查询参数 | ?id=42 | 附加条件，例如请求编号为 42 的商品 | | 片段 | #reviews | 通常由浏览器在页面内部定位到"评论"位置，不会作为 HTTP 请求内容发送给服务器 |

HTTP 常见默认端口是 80 ，HTTPS 常见默认端口是 443。不过端口只是惯例，不是 HTTP 和 HTTPS 安全性的根源。

HTTP：浏览器和服务器到底怎样交流？

HTTP 是一种客户端---服务器协议：

浏览器、手机 App、命令行工具等通常扮演客户端；
提供网站、接口或文件的程序扮演服务器；
客户端发出请求；
服务器返回响应。

HTTP 的核心不是"网页"三个字，而是：客户端如何表达自己的意图，服务器如何说明处理结果并返回内容。

请求：客户端在说"我想做什么"

一个简化的 HTTP 请求大致像这样：

http 复制代码

GET /products?id=42 HTTP/1.1
Host: example.com
Accept: text/html
Cookie: session=abc123

逐行看：

GET：请求方法，表示希望读取资源；
/products?id=42：希望访问的路径和条件；
HTTP/1.1：使用的 HTTP 版本；
Host: example.com：要访问哪个主机；
Accept: text/html：客户端希望得到 HTML 类型的内容；
Cookie: ...：浏览器带上此前保存的一小段状态信息，例如会话标识。

响应：服务器在说"结果是什么"

服务器可能返回：

http 复制代码

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: theme=dark; Secure

<h1>商品详情</h1>

其中：

200 OK：状态码，表示请求成功；
Content-Type：告诉浏览器响应体是什么类型；
Set-Cookie：让浏览器保存一个 Cookie；
空行之后的 HTML：这次真正返回的内容，也叫响应体。

最常见的 HTTP 方法

| 方法 | 常见含义 | 例子 | |---|---|---| | GET | 获取资源 | 打开文章、获取商品信息 | | POST | 提交数据，让服务器处理 | 提交登录表单、发布评论 | | PUT | 整体更新某个资源 | 更新用户资料 | | DELETE | 删除资源 | 删除一条记录 |

方法表达的是"意图"，不等于服务器一定会按你想的方式执行。服务器仍会检查身份、权限、参数和业务规则。

最常见的状态码

状态码的第一位可以帮你快速判断结果：

| 类别 | 含义 | 常见例子 | |---|---|---| | 1xx | 信息性状态 | 较少直接遇到 | | 2xx | 成功 | 200 OK、201 Created | | 3xx | 重定向 | 301、302 | | 4xx | 请求方有问题 | 401 Unauthorized、403 Forbidden、404 Not Found | | 5xx | 服务器处理失败 | 500 Internal Server Error、503 Service Unavailable |

注意：404 不是"整个网站不存在"，而是服务器没有找到你请求的那个资源。

HTTP 的设计是无状态的：从协议语义上说，每个请求都可以被单独理解，服务器不会天然记得"这次请求是不是刚才那个用户发来的"。

但网站通常需要维持登录、购物车、语言偏好等状态。Cookie 就是一种常见机制：

服务器在响应中通过 Set-Cookie 让浏览器保存数据；
浏览器以后访问匹配的域名和路径时，会按 Cookie 规则把相关 Cookie 放进请求头；
服务器据此识别会话或读取偏好。

例如，登录后浏览器可能保存的是一个会话标识，而不是你的密码本身。

Secure 是 Cookie 的一个重要属性：它要求浏览器只在 HTTPS 请求中发送该 Cookie。它能减少 Cookie 被明文 HTTP 链路暴露的风险，但Cookie 不是完整的登录安全方案：服务端仍需要处理会话过期、权限校验、防盗用等问题。

HTTPS 到底多了什么？

HTTP 只规定"请求和响应怎么表达"，它本身不保证这些内容在传输途中保密。

如果你在普通 HTTP 连接中发送：

text 复制代码

账号=alice&密码=example-password

网络路径上的攻击者或不可信中间设备，理论上可能看到、修改，甚至伪造相关内容。

HTTPS 的做法是：让 HTTP 运行在 **TLS（Transport Layer Security，传输层安全）**提供保护的连接上。

HTTPS 最关键的价值有三项：

1. 机密性：尽量不让旁观者读懂传输内容

TLS 会对传输中的 HTTP 内容进行加密。网络中的旁观者即使截获了数据，通常也不能直接读出页面内容、表单字段、Cookie 或接口返回的数据。

2. 完整性：尽量不让数据被悄悄改掉

TLS 会对数据进行完整性保护。若有人在中途修改内容，接收方应能发现验证不通过，而不是把被替换的内容当成正常内容使用。

3. 身份认证：帮助浏览器确认连的是谁

服务器会向浏览器提供数字证书。浏览器通常会检查：

证书是否适用于当前访问的域名；
证书链是否能追溯到浏览器或操作系统信任的证书颁发机构；
证书是否在有效期内，以及其他验证条件是否满足；
服务器是否能证明自己掌握与证书公钥对应的私钥。

如果这些验证明显失败，浏览器通常会显示证书风险警告。

TLS 握手：HTTPS 怎么建立安全连接？

很多人把 HTTPS 理解成："浏览器拿到服务器公钥，然后用公钥加密所有网页内容。"

这个说法不准确。

更接近真实情况的简化过程是：

浏览器发起连接：告诉服务器自己支持哪些 TLS 能力，并发送用于密钥协商的信息。
服务器回应并给出证书：浏览器可从证书中取得服务器公钥，并检查该证书是否可信、是否匹配当前域名。
服务器证明自己持有私钥：服务器会对握手内容进行签名等证明，避免"只拿到一张别人证书"的冒充者蒙混过关。
双方协商出会话密钥：浏览器与服务器通过密钥交换机制，各自计算出共享的会话密钥。
后续 HTTP 数据被保护：真正的大量网页数据、图片请求、接口响应等，通常使用高效的对称加密和认证加密机制保护。

可以这样记：

| 概念 | 主要作用 | |---|---| | 证书 | 把域名与公钥等信息关联起来，供浏览器验证 | | 公钥/私钥 | 用于身份认证、签名验证和密钥协商等关键环节 | | 会话密钥 | 用于保护后续大量传输的数据，效率更高 | | TLS 握手 | 在传输 HTTP 前，完成身份验证与密钥协商的过程 |

因此，HTTPS 不是"公钥直接加密整个网页"的简单模型，而是把身份验证、密钥协商、加密传输、完整性校验组合起来。

HTTP 和 HTTPS 的差异，一张表看懂

| 对比项 | HTTP | HTTPS | |---|---|---| | 关系 | 网页请求/响应协议 | HTTP 通过 TLS 安全传输的常用形式 | | 地址前缀 | http:// | https:// | | 常见默认端口 | 80 | 443 | | 传输内容 | 通常是明文 | HTTP 内容通常受到 TLS 加密和完整性保护 | | 服务器身份验证 | 没有 TLS 证书验证这一层 | 浏览器会进行证书相关验证 | | 被中途查看或修改的风险 | 更高 | 显著降低，但不是所有风险都消失 | | 浏览器表现 | 可能显示"不安全"提示 | 通常显示安全连接标识，异常时提示证书风险 |

现代网站广泛使用 HTTPS，不只是因为登录和支付。只要网页中存在账号、搜索内容、浏览记录、表单、Cookie、接口数据，甚至只是用户访问了什么页面，明文 HTTP 都可能带来不必要的隐私和篡改风险。

HTTPS 保护什么，又不保护什么？

理解 HTTPS 的边界，比只记住"HTTPS 是加密的"更重要。

HTTPS 主要保护的是：浏览器与已通过证书验证的服务器之间的传输链路

通常包括：

传输中的 HTTP 请求和响应内容；
表单提交的数据；
Cookie 等 HTTP 头中的敏感信息；
传输内容是否被中途篡改；
你是否连到了能够证明自己持有对应私钥的服务器。

HTTPS 不自动保证以下事情

1. 不保证网站本身是好网站

钓鱼网站也可以申请有效证书并使用 HTTPS。

https:// 只说明你与这个域名对应的服务器之间建立了受 TLS 保护的连接；它不等于该网站的经营者诚实，也不等于网页内容没有诈骗。

所以，仍然要看域名是否正确、网站是否可信，不要只看浏览器有没有锁形图标。

2. 不保证服务器没有漏洞或数据不会泄露

如果网站服务器被入侵、数据库配置错误，或者网站自身把用户数据卖掉、泄露掉，HTTPS 无法从根本上阻止这些问题。

HTTPS 保护的是"路上"，不负责保证"目的地内部"安全。

3. 不保证你的设备安全

如果电脑中了木马，恶意程序可能在数据加密前读取你的输入，或在浏览器解密后读取页面内容。HTTPS 不能修复被攻陷的终端。

4. 不保证所有连接信息都隐藏

HTTPS 重点保护 TLS 连接中的应用数据，并不等于把所有网络元数据全部隐身。在不同网络与部署条件下，网络观察者仍可能获知或推断一些信息，例如连接时间、流量大小、目标 IP 地址；域名解析信息是否暴露，还与 DNS 使用方式和网络配置有关。

5. 不保证你不会主动把信息交给错误的人

把验证码、密码或转账信息主动提交到冒充网站，HTTPS 也无法替你判断业务行为是否合理。

一个容易忽略的问题：混合内容

假设一个页面本身通过 HTTPS 打开：

text 复制代码

https://shop.example

但它又加载了一段 HTTP 脚本：

text 复制代码

http://cdn.example/script.js

这叫混合内容：安全页面里混入了不安全资源。

尤其是脚本这类"活动内容"，一旦在 HTTP 链路上被篡改，攻击者可能影响整个页面行为。因此现代浏览器通常会阻止或警告某些混合内容。

一个安全网站不能只让首页使用 HTTPS，而应尽量确保页面、接口、脚本、图片及跳转流程都正确使用 HTTPS。

另外，仅靠"先访问 HTTP，再跳转到 HTTPS"也并非完美：第一次 HTTP 访问可能仍有被干扰的空间。HSTS 是一种响应策略，它可以要求浏览器在后续访问中直接使用 HTTPS，从而降低被降级到 HTTP 的风险。

HTTP/1.1、HTTP/2、HTTP/3：和 HTTPS 是一回事吗？

不是。

HTTP/1.1、HTTP/2、HTTP/3 主要是在讨论：HTTP 消息如何组织、如何在连接上并发传输、如何提高效率；HTTPS/TLS 讨论的是：传输如何获得安全保护。

这是两个不同维度。

| 版本 | 可以怎样理解 | |---|---| | HTTP/1.1 | 经典且仍广泛存在的文本消息形式 | | HTTP/2 | 引入二进制分帧、多路复用等机制，让多个请求更高效地共享连接 | | HTTP/3 | 把 HTTP 语义映射到 QUIC 之上；QUIC 整合 TLS 1.3 的安全机制，并改善部分网络环境下的并发表现 |

核心结论是：

HTTP 版本升级，不等于"是否加密"。
HTTP/2 的核心是提高传输组织和并发效率；HTTP/2 在协议上可以不使用 TLS，但主流浏览器部署中通常只在 HTTPS 连接上启用它。
HTTP/3 使用 QUIC；QUIC 整合 TLS 1.3 的安全机制，因此 HTTP/3 的实际部署带有这层保护。
无论版本如何变化，HTTP 的基本语义仍然是：客户端请求，服务器响应。

常见误区，一次纠正

误区 1：HTTPS 就是"网站一定安全"

不对。HTTPS 主要保证连接安全，不保证网站内容可信、公司可靠或业务没有诈骗。

误区 2：HTTPS 会加密一切信息

不对。它重点保护 HTTP 应用数据；仍可能有部分网络元数据可被观察或推断。

误区 3：有锁形图标就可以随便输入密码

不对。先确认域名是否正确，警惕拼写相似的钓鱼域名和异常跳转。

误区 4：证书就是"网站官方认证书"

不完全对。证书的核心作用是帮助验证某个域名与公钥的绑定关系，以及建立 TLS 身份认证链路；它不是对网站商品、内容或经营行为的质量背书。

误区 5：HTTPS 用公钥加密全部内容

不准确。公钥/私钥主要参与身份认证、签名验证和密钥协商；后续大规模数据传输通常依赖协商出的会话密钥进行高效保护。

误区 6：HTTP 和 HTTPS 是两套完全无关的网页规则

不对。HTTPS 中仍然是 HTTP 的请求、响应、方法、状态码、头和内容；TLS 负责把这段 HTTP 通信保护起来。

最后，用一句话记住整套关系

当你打开一个 HTTPS 网站时：

URL 告诉浏览器要找什么，DNS 帮它找到地址，TCP 或 QUIC 负责传输，TLS 负责建立安全保护，HTTP 负责让浏览器和服务器完成请求与响应。

如果只记 HTTP 与 HTTPS 的关系，则记住这一句就够了：

HTTP 决定"说什么"；HTTPS 让 HTTP 能更安全地"说"。

一文讲清网络协议：从打开网页到理解 HTTP、HTTPS 与 TLS