上一篇我们搞懂了域名、DNS、URL 的核心逻辑，解决了 “如何找到服务器上的具体资源” 的问题。但找到资源后，浏览器和服务器之间如何传递数据？比如搜索关键词后，服务器如何将结果返回至浏览器？这就需要依靠应用层的核心通信协议 ——HTTP 和 HTTPS。今天就全面拆解这两个协议，搞懂它们的工作原理、核心特点、区别及安全逻辑。
一、HTTP：浏览器与服务器的 “基础通信语言”
HTTP 全称超文本传输协议，是基于 TCP/IP 模型应用层的无状态协议，也是浏览器与 web 服务器之间最基础的通信规则。其核心作用是：浏览器向服务器发送资源请求，服务器将 HTML、图片、视频等超文本资源传输至浏览器，实现网页内容的展示。
HTTP 的四大核心特点
- 无状态服务器不会记录客户端的历史访问状态，每一次请求都是完全独立的。比如第一次访问某网站和第二次访问，服务器不会记住你的任何操作，需通过Cookie、Session补充状态管理，让服务器实现 “记住用户” 的功能（如登录状态保持）。
- 基于 TCP 连接HTTP 依赖 TCP 的可靠传输特性，通信前必须通过 TCP 三次握手建立连接，数据传输完成后，通过四次挥手释放连接，确保数据无丢失、按序传输。
- 明文传输这是 HTTP 最大的缺点：请求和响应的所有数据均为明文形式，没有任何加密处理。在公共 WiFi、局域网等环境中，数据极易被窃取、篡改，存在严重的安全风险。
- 简单高效HTTP 协议的头部格式简洁，请求 / 响应的流程简单，易于实现和解析，能快速完成资源传输，适合普通的网页浏览、资源获取场景。
HTTP 的报文结构：请求与响应的 “数据载体”
HTTP 通信的核心是请求 - 响应模式，所有数据都以 “报文” 的形式传输，分为请求报文（客户端→服务器）和响应报文（服务器→客户端），两者结构相似，均由「起始行 + 头部 + 空行 + 实体主体」四部分组成，空行是分隔头部和实体主体的固定格式，必须存在。
1. HTTP 请求报文：客户端的 “指令单”
请求报文是浏览器向服务器发送的 “资源请求指令”，包含客户端的请求信息、浏览器信息等，GET 请求无实体主体，POST 请求的实体主体存放表单、JSON 等数据。简化示例：
http
GET /s?wd=网络知识 HTTP/1.1 # 起始行
Host: www.baidu.com # 头部字段：目标服务器域名
User-Agent: Chrome/114.0.0.0 # 头部字段：客户端浏览器信息
Accept: text/html # 头部字段：可接收的资源格式
# 空行（固定格式）
# 实体主体（GET请求无，POST请求存放数据）
各部分说明：
- 起始行：核心部分，包含「请求方法 + 请求路径 + HTTP 版本」；
- 头部字段：键值对形式，传递客户端信息、请求条件（如 Host、User-Agent、Cookie）；
- 实体主体：可选，仅 POST 请求使用，用于存放提交的数据。
两大核心请求方法：
- GET：用于获取资源（如浏览网页、搜索内容），参数直接拼在 URL 后，长度有限制，明文传输，相对不安全；
- POST：用于提交资源（如登录、注册、提交表单），参数存放在实体主体中，长度无限制，相对安全。
2. HTTP 响应报文：服务器的 “回复单”
响应报文是服务器对客户端请求的 “回复”，包含请求处理结果、服务器信息、返回的资源数据等，实体主体是服务器返回的具体资源（如 HTML 内容、图片二进制数据）。简化示例：
http
HTTP/1.1 200 OK # 起始行
Content-Type: text/html# 头部字段：响应数据格式为HTML
Content-Length: 1024 # 头部字段：响应数据的字节长度
Server: Apache # 头部字段：服务器的类型
# 空行（固定格式）
<!DOCTYPE html><html><body>网页内容</body></html> # 实体主体：网页HTML内容
各部分说明：
- 起始行：包含「HTTP 版本 + 状态码 + 状态描述」，状态码是核心，用于表示请求的处理结果；
- 头部字段：键值对形式，传递服务器信息、响应数据属性（如 Content-Type、Server）；
- 实体主体：服务器返回的具体资源，是浏览器最终展示的内容。
必记的 HTTP 状态码
状态码由 3 位数字组成，代表请求的不同处理结果，日常上网最常见的有：
200 OK：请求成功，服务器正常返回资源（网页能正常打开）；403 Forbidden：请求被拒绝，客户端无访问该资源的权限；404 Not Found：请求的资源不存在（如 URL 错误、网页被删除）；500 Internal Server Error：服务器内部故障，与客户端无关。
二、HTTPS：HTTP 的 “安全升级版”
由于 HTTP 明文传输的致命缺陷，在涉及账号、密码、支付等敏感信息传输时，数据极易被窃取和篡改，为了解决这一问题，HTTPS 协议应运而生。
HTTPS 全称超文本安全协议，并非全新的协议，而是在 HTTP 和 TCP 之间添加了一层 TLS 加密层（早期为 SSL），通过加密实现请求 / 响应数据的安全传输，是目前互联网中主流的安全通信协议。
HTTPS 的加密核心：对称加密 + 非对称加密结合
HTTPS 的加密并非单一方式，而是结合了对称加密和非对称加密的优点，兼顾加密效率和传输安全性，两者各司其职，缺一不可。
1. 对称加密：高效的 “数据传输密码”
加密和解密使用同一把密钥，通信双方共享这把密钥：发送方用密钥加密数据，接收方用同一把密钥解密数据。
- 优点：加密、解密速度快，效率高，适合大量数据的传输；
- 缺点：密钥需要在网络中传输给对方，极易被窃取，一旦密钥泄露，数据会被直接破解。
2. 非对称加密：安全的 “密钥传递密码”
非对称加密有两把配对的密钥：公钥和私钥，公钥可全网公开，私钥由服务器独自保存，绝不泄露。
- 加密规则：公钥加密的数据，只有对应的私钥能解密；私钥加密的数据，只有对应的公钥能解密；
- 应用逻辑：服务器生成公钥和私钥，将公钥发送给客户端；客户端用公钥加密数据后发送给服务器，服务器用私钥解密，即使公钥被窃取，也无法破解数据；
- 缺点：加密、解密速度慢，效率低，不适合大量数据的传输。
3. HTTPS 的加密组合逻辑
HTTPS 结合两种加密方式的核心逻辑：用非对称加密传递对称加密的密钥，用对称加密传输实际的业务数据。
- 浏览器与服务器建立连接后，通过非对称加密完成 “对称加密密钥” 的安全传递；
- 密钥传递完成后，双方使用对称加密进行后续的所有数据传输；
- 既保证了密钥的传输安全，又保证了数据的传输效率。
HTTPS 的身份认证核心：CA（证书颁发机构）
光有加密还不够，如何确认 “通信的对方是真正的目标服务器”，而非伪装的钓鱼网站？这就需要CA（数字证书颁发机构） 来实现身份认证，CA 是公认的、权威的 “网络身份证颁发机构”。
CA 的核心作用
- 验证服务器的真实身份（如域名归属、企业信息）；
- 为合法服务器颁发数字证书（包含服务器公钥、身份信息、数字签名）；
- 自身拥有根证书（浏览器、电脑自带），用于验证下级证书的合法性。
CA 的认证与验签过程（简化版）
步骤 1：服务器申请数字证书
- 服务器向 CA 提交自身的身份信息（域名、企业资质）和公钥；
- CA 审核通过后，将这些信息整理成信息文件；
- CA 对信息文件进行哈希运算（不可逆，生成唯一的固定字符串）；
- CA 用自己的私钥对该字符串加密，生成数字签名；
- CA 将「信息文件 + 哈希字符串 + 数字签名」打包，生成数字证书，发送给服务器。
步骤 2：客户端验证服务器身份
- 浏览器访问服务器时，服务器将数字证书发送给浏览器；
- 浏览器用预装的CA 公钥解密数字签名，得到原始的哈希字符串；
- 浏览器对证书中的信息文件进行一次哈希运算，得到新的哈希字符串；
- 对比两个哈希字符串：一致则服务器身份合法，可安全通信；不一致则为钓鱼网站，浏览器提示 “访问不安全”。
三、HTTP 与 HTTPS 核心区别总结
| 对比维度 | HTTP | HTTPS |
|---|---|---|
| 安全性 | 明文传输，无加密，安全风险高 | 基于 TLS 加密，数据密文传输，安全性高 |
| 加密层 | 无额外加密层 | HTTP 与 TCP 之间添加 TLS 加密层 |
| 端口号 | 默认 80 端口 | 默认 443 端口 |
| 证书 | 无需证书 | 必须向 CA 申请数字证书 |
| 速度 | 无加密 / 解密开销，速度更快 | 有加密 / 解密开销，速度略慢于 HTTP |
| 适用场景 | 普通网页浏览、非敏感资源获取 | 登录、支付、金融、电商等敏感信息传输 |
四、总结：HTTP/HTTPS 核心知识点快速记忆
- HTTP 是基础通信协议，无状态、明文传输、基于 TCP，是浏览器与服务器的基础通信语言；
- HTTP 报文分为请求和响应，均由「起始行 + 头部 + 空行 + 实体主体」组成，状态码表示请求结果；
- HTTPS 是 HTTP 的安全升级版，核心是添加 TLS 加密层，结合对称 / 非对称加密实现安全传输；
- CA 是 HTTPS 的身份认证核心，通过数字证书验证服务器身份，防止钓鱼网站；
- 日常开发和使用中，涉及敏感信息的场景必须使用 HTTPS，普通场景可使用 HTTP。
至此，网络通讯的核心基础知识点（模型 / 协议→寻址→通信）已全部拆解，从数据的分层传输，到域名的解析寻址，再到浏览器与服务器的加密通信，一套完整的上网逻辑已清晰呈现，搞懂这些，就能真正理解互联网通信的底层原理。
