前言做开发、运维、测试或者从事网络相关工作的朋友每天都在和HTTP/HTTPS打交道。打开网页、调用接口、刷短视频、手机 APP 联网背后全是这套协议在支撑可以说它就是整个互联网通信的基石。但很多人只停留在 “会用” 的层面知道 HTTP 是明文、HTTPS 带小锁图标、端口分别是 80 和 443再往深问就一头雾水。比如HTTP 为什么会出现无状态问题Cookie 和 JWT 到底该怎么选HTTP 从 1.0 到 3.0 一路迭代到底解决了哪些历史痛点HTTPS 明明多了一层加密具体是怎么实现安全传输的对称加密、非对称加密、数字证书又分别扮演什么角色面试高频的 HTTPS 握手流程六个阶段究竟发生了什么尤其是现在 HTTP/3 逐步落地基于 QUIC 协议彻底重构传输逻辑不少同学更是摸不着头脑。今天这篇文章我就用聊天对话的口吻从零开始由浅入深把整套知识讲透。先梳理 HTTP 基础、报文、版本演进再拆解 HTTPS 底层密码学原理、完整握手流程最后对比各版本优劣全文干货十足零基础也能看懂不管是日常工作查漏补缺还是应对面试笔试都可以收藏反复阅读。一、HTTP 基础详解1.1 什么是 HTTP首先咱们先把基础概念捋清楚。HTTP全称是超文本传输协议HyperText Transfer Protocol它工作在 OSI 七层模型的应用层是浏览器、客户端与服务器之间约定好的通信规则专门用来传输网页、图片、接口数据、文件等各类超文本内容。HTTP 有三个最核心的特性也是入门必记的知识点同时也是它天生的短板无状态服务器不会主动记录客户端的任何信息。每一次请求对于服务器来说都是独立的上一次的操作、登录状态、浏览记录服务器全都 “记不住”。无连接在早期版本中客户端和服务器完成一次请求与响应后就会直接断开 TCP 连接不会持续保持连通。明文传输所有交互的数据都是纯文本形式裸奔传输没有任何加密处理一旦被抓包账号、密码、隐私信息会直接泄露。HTTP 默认使用80 端口这是行业通用标准也是我们日常访问网页默认不走端口的原因。简单举个例子理解你把服务器想象成一家商店你是顾客。无连接就是你进店买完东西立刻关门走人下次再来还要重新开门无状态就是老板见过你无数次但每次都认不出你是谁明文传输就是你和老板的对话全程被路人听得一清二楚毫无隐私可言。1.2 HTTP 核心工作流程我们平时在浏览器输入网址按下回车一次完整的 HTTP 请求会走完固定的六个步骤环环相扣咱们一步步拆解客户端浏览器先和服务器建立TCP 连接也就是大家常说的 TCP 三次握手搭建起通信通道连接建立完成后客户端主动向服务器发送HTTP 请求报文告诉服务器自己想要什么资源服务器接收到请求解析报文、执行业务逻辑、查询数据库处理客户端的需求处理完成后服务器组装HTTP 响应报文把结果返回给客户端客户端解析响应内容渲染网页页面、展示数据或者执行对应逻辑通信结束按照协议规则断开 TCP 连接HTTP/1.0 默认行为。整个流程就像寄快递先打通运输通道然后寄出请求对方处理后回寄结果最后关闭通道逻辑非常清晰。1.3 HTTP 报文结构HTTP 所有交互都是依靠请求报文和响应报文完成这两种报文格式是学习接口调试、抓包分析的基础下面分开说明。请求报文客户端 → 服务器由三部分组成请求行、请求头、请求体。请求行位于报文第一行包含请求方法GET/POST 等、请求资源地址、协议版本用来告诉服务器请求方式和目标地址请求头紧随请求行之后是一组键值对携带客户端附加信息比如浏览器类型、Cookie、域名、可接收的数据格式等请求体也叫请求正文主要存放表单数据、接口入参等内容。这里有一个关键点GET 请求没有请求体参数一般拼接在 URL 后面POST 请求才会使用请求体传递数据。给大家看一段标准的请求报文示例GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 Accept: text/html Cookie: session_idabc123这段内容很好理解使用 GET 方式请求网站根目录下的 index.html 页面协议版本为 HTTP/1.1同时附带了主机地址、浏览器信息、可接收格式和会话 Cookie。响应报文服务器 → 客户端和请求报文对应同样分为三部分响应行、响应头、响应体。响应行第一行包含协议版本、状态码200、404、500 等、状态描述用来告知客户端本次请求的处理结果响应头键值对格式携带服务器附加信息比如数据格式、编码、缓存规则、下发的 Cookie 等响应体报文的核心部分存放真正要传输的数据比如网页 HTML 代码、JSON 接口返回数据、图片二进制流等。标准响应报文示例HTTP/1.1 200 OK Content-Type: text/html; charsetUTF-8 Content-Length: 1024 Set-Cookie: session_idabc123; Path/ html bodyHello World/body /html解读服务器使用 HTTP/1.1 协议响应状态码 200 代表请求成功随后定义了数据格式、长度并向客户端下发 Cookie最后在响应体中返回网页内容。日常抓包、接口联调时看懂这两类报文就能快速定位参数错误、跨域、状态码异常等问题。1.4 HTTP 无状态的问题与解决方案前面提到 HTTP 是无状态协议这个特性在实际使用中会带来很直观的麻烦。举个生活例子你在网站完成账号登录刷新页面、跳转新页面后网站又要求你重新登录电商网站把商品加入购物车刷新页面后购物车空空如也。本质原因就是服务器 “记不住” 客户端身份。为了解决无状态带来的身份识别、会话留存问题行业衍生出了三套主流方案各自适配不同业务场景方案核心原理主要特点Cookie Session服务端存储 Session 会话数据客户端保存 Session ID 并放在 Cookie 中每次请求携带 ID 完成身份校验传统经典方案服务端需要存储会话数据集群分布式场景下存在同步问题JWTToken客户端持有加密后的 Token 令牌服务端不存储会话信息仅通过算法校验令牌合法性服务端无状态天然适配分布式、微服务架构扩展性强OAuth / SSO基于授权协议实现统一身份认证支持第三方登录、跨系统单点登录多用于多平台、多系统互通场景比如微信 / QQ 快捷登录简单总结单体传统项目优先使用 CookieSession分布式、前后端分离、移动端 APP 优先选择 JWT多系统联动、第三方登录场景就用 OAuth/SSO。二、HTTP 版本演进对比从最初的 HTTP/1.0到如今主流的 HTTP/1.1、HTTP/2.0再到新兴的 HTTP/3.0二十多年间协议一直在迭代优化。每一个新版本都是为了解决旧版本的性能缺陷、传输瓶颈。下面我们逐个版本对比理清演进逻辑。2.1 HTTP/1.0 vs HTTP/1.1HTTP/1.0 是最早普及的版本也是问题最多的版本HTTP/1.1 做了大量针对性优化二者核心差异如下特性HTTP/1.0HTTP/1.1连接方式短连接一次请求响应后立即断开 TCP 连接支持长连接Keep-Alive复用同一条 TCP 连接缓存控制无标准化缓存机制资源重复请求浪费带宽新增 Cache-Control、ETag 等缓存字段优化资源缓存断点续传不支持文件中断后必须从头重新下载支持 Range 请求头实现断点续传Host 请求头非必填不支持虚拟主机强制必填一台服务器可部署多个网站HTTP/1.0 最大的痛点就是短连接。我们打开一个网页往往需要加载 HTML、多张图片、JS、CSS 等十几个甚至几十个资源。按照 1.0 规则每加载一个资源就要完成一次 TCP 三次握手 四次挥手。大量的建连、断连操作会产生极高的延迟页面加载速度很慢。HTTP/1.1 推出长连接后一条 TCP 连接可以连续处理多次请求不用反复创建销毁连接大幅降低开销。但它依旧存在一个致命缺陷队头阻塞。在同一条 TCP 连接中所有请求必须串行排队执行如果前面一个请求因为网络问题卡住后面所有请求都会被阻塞只能原地等待。这也是 1.1 版本始终无法彻底解决的性能瓶颈。2.2 HTTP/1.1 vs HTTP/2.0为了解决队头阻塞、请求冗余等问题HTTP/2.0 应运而生它没有改变底层 TCP 传输协议但从数据格式、传输模式、头部优化等方面做了全面升级性能提升非常明显。特性HTTP/1.1HTTP/2.0多路复用不支持请求串行执行存在严重队头阻塞支持多路复用单条 TCP 连接并行传输多个请求互不干扰数据格式纯文本报文体积大、解析效率低二进制帧格式结构紧凑解析更快、占用资源更少头部压缩仅支持响应体压缩请求头明文重复传输基于 HPACK 算法专门压缩请求头大幅减少冗余数据服务器推送不支持客户端必须主动请求资源支持服务器主动推送关联资源提前加载页面依赖文件浏览器连接限制浏览器单域名限制 6-8 个 TCP 连接单条连接即可完成所有请求无需多连接这里重点讲两个核心亮点 第一是多路复用。HTTP/1.1 的逻辑是排队执行先请求资源 A完成后再请求 B、C。而 HTTP/2.0 把所有数据拆分成独立的二进制帧在同一条 TCP 连接里并行传输就像多条车道同时通车彻底解决了应用层的串行阻塞问题。第二是HPACK 头部压缩。我们每次请求的请求头里User-Agent、Cookie、Host 等字段基本都是重复的明文反复传输会浪费带宽。HPACK 算法会对头部字段建立索引重复内容只传递索引号不再传输完整文本能让请求头体积缩减 80% 以上传输效率大幅提升。不过 HTTP/2.0 依旧基于 TCP 协议这也留下了隐患TCP 本身是有序可靠传输一旦连接中出现丢包TCP 会暂停所有数据传输等待丢包重传TCP 层的队头阻塞依旧存在。2.3 HTTP/2.0 vs HTTP/3.0HTTP/3.0 是目前最新的版本它彻底放弃了沿用多年的 TCP转而使用基于 UDP 的QUIC 协议从底层架构上解决了历史遗留问题也是未来的主流方向。特性HTTP/2.0HTTP/3.0底层传输协议TCPQUIC基于 UDP握手耗时TCP 三次握手 TLS 加密握手整体 2-RTT新连接 1-RTT重连可实现 0-RTT建连速度极快头部压缩HPACKQPACK适配 QUIC 协议压缩效率更高队头阻塞TCP 丢包会阻塞整条连接所有请求各数据流完全独立单个流丢包不影响其他流连接迁移依赖 IP 端口四元组网络切换直接断连基于 64 位唯一连接 ID切换 WiFi / 流量连接不中断我们重点拆解两个核心优势彻底根治队头阻塞HTTP/2.0 的多路复用只是在应用层优化底层 TCP 是串行有序传输。只要一个数据包丢失整条连接都会停滞等待重传。而 QUIC 协议将每一路请求作为独立的数据流流 A 丢包只重试流 A流 B、流 C 可以正常传输从根源上消灭了队头阻塞。无缝连接迁移TCP 依靠源 IP、源端口、目标 IP、目标端口四元组标识连接。当我们手机从 WiFi 切换到移动流量IP 地址发生变化TCP 连接会直接断开页面、视频、通话都会中断。而 QUIC 使用独立的 64 位连接 ID 标识连接和 IP、端口无关网络切换后连接依然保持这也是刷短视频、语音通话切网络不卡顿的核心原理。当然 HTTP/3.0 也有短板目前各大服务器、CDN、网关的适配部署成本较高所以现阶段还处于逐步普及的阶段。三、QUIC 底层核心解析上面反复提到 QUIC这里单独拿出来讲清楚。QUIC 全称是 Quick UDP Internet Connections是 HTTP/3 的专属底层传输协议。它站在 UDP 的基础上复刻了 TCP 的可靠传输能力同时弥补了 TCP 的所有缺陷。我们用表格对比 TCP 和 QUIC 的核心区别特性TCPQUIC基于 UDP运行层级操作系统内核态升级、修改难度极大应用层协议开发者可自由迭代、定制握手流程标准三次握手耗时较长支持 0-RTT/1-RTT 握手建连速度飞快丢包影响单个包丢失整条连接阻塞仅影响对应数据流其他流正常运行连接迁移依赖四元组网络变化即断连依靠连接 ID支持无缝网络切换加密能力本身不具备加密需要额外依赖 TLS协议内部集成 TLS数据天然加密拥塞控制内核固化策略自定义困难应用层实现可灵活调整拥塞算法用一句话概括 QUIC以无连接的 UDP 为载体在应用层手动实现了 TCP 的重传、流量控制、拥塞控制等可靠机制同时内置加密、独立数据流、连接迁移等新特性集百家之长。四、HTTPS 密码学基础核心底层聊完 HTTP 的演进接下来进入大家最关心的HTTPS部分。HTTPS 之所以安全核心依靠四大密码学基石对称加密、非对称加密、哈希算法、数字证书。如果看不懂这四块内容后续的握手流程就只能死记硬背无法理解本质。4.1 对称加密对称加密是数据加密传输的主力也是效率最高的加密方式。定义加密和解密使用同一把密钥通信双方都持有这把密钥。特点计算逻辑简单加密解密速度极快适合大批量数据传输。缺点最大的风险在于密钥分发。如果在网络中直接传递密钥很容易被中间人截获整个加密体系就会失效。主流算法AES目前 HTTPS 标配、DES、3DES。这里大家会有疑问既然对称加密又快又好用为什么不直接用它加密所有通信答案很简单密钥没法安全地传给对方这也是非对称加密存在的意义。4.2 非对称加密非对称加密使用一对配套的密钥公钥和私钥二者成对出现不可拆分。定义公钥对外公开私钥由持有者严格保密。遵循规则公钥加密只能用对应的私钥解密私钥加密只能用公钥解密。特点安全等级极高数学算法保证无法反向破解但计算复杂加解密速度很慢不适合加密大体积数据。用途只用来加密小段数据、传递密钥、生成数字签名。主流算法RSA传统主流、ECC椭圆曲线算法现在逐步普及。核心原则一定要记牢公钥可以公开分发任何人都能获取私钥绝对不能外泄一旦泄露整个安全体系彻底崩塌。4.3 哈希算法哈希算法不属于加密算法它的核心作用是数据完整性校验也就是给数据生成 “指纹”。定义无论原始数据长度多少经过哈希计算后都会生成一段固定长度的摘要字符串。核心特性第一不可逆无法通过哈希摘要反向推导出原始数据第二雪崩效应原始数据哪怕只修改一个字符最终的摘要结果会完全不同。用途校验数据在传输过程中是否被篡改也常用于数字签名。主流算法SHA-256安全可靠广泛使用、MD5已被破解彻底淘汰禁止使用。举个例子一段文字生成哈希值后只要传输后的哈希值和原始值不一致就说明数据被篡改过客户端可以直接丢弃数据。4.4 数字证书现在又出现一个新问题客户端从网络上拿到服务器的公钥怎么确定这个公钥就是目标服务器的而不是黑客伪造的中间人完全可以拦截通信替换成自己的公钥实施攻击。解决这个问题的方案就是数字证书我们可以把它理解为服务器在互联网上的 “官方身份证”。颁发机构CA证书授权中心相当于现实中的公安局是全球公认的权威机构。证书内容绑定服务器域名、服务器真实公钥、CA 机构的数字签名、证书有效期等信息。核心作用证明当前公钥归属合法服务器抵御中间人伪造攻击。验证逻辑浏览器、操作系统出厂时会预装各大权威 CA 的根证书公钥。客户端拿到证书后用根证书公钥校验 CA 签名同时检查证书是否过期、域名是否匹配全部通过才会信任这份证书。简单比喻CA 是公安局数字证书是身份证根证书公钥就是大家公认的公章有公章背书才能证明身份真实有效。五、HTTPS 本质解读搞懂密码学基础后HTTPS 的本质就一目了然了。HTTPS HTTP TLSSSL 是早期版本现已被 TLS 全面替代HTTP纯明文传输数据易被窃听、篡改、劫持端口 80HTTPS在 HTTP 外层包裹一层 TLS 加密通道所有数据加密传输端口 443。结合前面两种加密方式的优缺点HTTPS 采用了经典的组合方案完美兼顾安全与性能用非对称加密完成会话密钥的安全交换解决密钥传输不安全的问题交换完成后通信全程使用对称加密传输业务数据利用其速度快的优势避免性能损耗。这也是 HTTPS 设计的核心智慧取长补短把两种加密算法的优势结合起来。六、HTTPS 完整加密握手流程6 阶段详解HTTPS 的 TLS 握手流程是面试必考题也是理解加密通信的重中之重。整个流程分为六个阶段我们结合交互逻辑和图解一步步拆解全程梳理客户端与服务器的交互行为。阶段 1客户端发起 TLS 握手请求客户端主动向服务器发起握手携带两份关键信息客户端随机数Client Random、客户端当前支持的所有加密套件对称加密 非对称加密的组合。客户端 → 服务器Client Random 支持的加密套件阶段 2服务器响应握手请求服务器收到请求后做出回应返回自身生成的服务器随机数Server Random、从客户端列表中选中一套双方都支持的加密套件同时下发服务器的数字证书内含服务器公钥。服务器 → 客户端Server Random 选中加密套件 数字证书阶段 3客户端验证数字证书这是安全校验的关键一步客户端会逐一检查证书合法性三个核心校验点缺一不可检查证书是否超出有效期检查证书绑定的域名是否和当前访问的网站域名一致使用系统预装的 CA 根证书公钥校验 CA 签名是否合法判断证书是否被篡改、伪造。验证全部通过客户端信任服务器公钥继续后续流程验证失败立即断开连接浏览器弹出 “此连接不安全” 的警告。阶段 4非对称加密交换预主密钥客户端本地生成一串随机字符串称之为预主密钥Pre-Master Key。随后使用服务器的公钥对预主密钥进行非对称加密再将加密后的内容发送给服务器。服务器收到数据后使用自己独有的私钥进行解密成功拿到原始的预主密钥。这个环节是安全核心预主密钥全程被公钥加密传输即使被黑客截获没有服务器私钥也无法解密。阶段 5双方独立计算会话密钥现在客户端和服务器都拥有三份相同的数据Client Random、Server Random、Pre-Master Key。双方使用约定好的加密算法各自独立计算最终生成完全一致的会话密钥。会话密钥 加密算法 (Client Random Server Random Pre-Master Key)重点最终用来通信的会话密钥全程没有在网络中传输过第三方根本无法获取。阶段 6对称加密正式通信握手流程全部结束接下来客户端和服务器使用协商好的会话密钥 AES 对称加密算法传输正常的 HTTP 业务数据。所有内容都是密文抓包也无法读取原文。客户端 ↔ 服务器加密后的 HTTP 数据完整流程交互图解客户端 服务器 │ │ │ ① Client Random 加密套件 │ │ ──────────────────────────────► │ │ │ │ ② Server Random 证书 加密套件│ │ ◄────────────────────────────── │ │ │ │ ③ 验证证书域名/有效期/CA签名 │ │ │ │ ④ 生成预主密钥, 用公钥加密 │ │ ──────────────────────────────► │ │ │ │ ⑤ 各自计算会话密钥 │ │ 3 个输入 │ │ Client Random │ │ Server Random │ │ Pre-Master Key │ │ │ │ ⑥ 会话密钥 AES 加密通信 │ │ ◄════════════════════════════► │ │ HTTP 数据加密传输 │简单总结TLS 握手只执行一次完成密钥交换和协商后后续所有数据都靠高效的对称加密传输既保证了安全又控制了性能开销。七、全文总结最后我们用两张汇总表格把整篇文章的核心知识点浓缩方便大家记忆复盘。HTTP 各版本核心总结版本核心特点最大缺陷HTTP/1.0短连接请求完成立即断连反复建立 TCP 连接延迟高、开销大HTTP/1.1长连接 Keep-Alive、缓存优化、支持虚拟主机串行请求存在严重队头阻塞HTTP/2.0二进制帧、多路复用、HPACK 头部压缩、服务端推送底层基于 TCP丢包依然会阻塞整条连接HTTP/3.0基于 QUIC (UDP)、0-RTT 握手、连接迁移、彻底解决队头阻塞目前全网部署、生态适配成本较高HTTPS 密码学与原理总结表格技术一句话核心概括对称加密加解密速度快但密钥直接传输存在泄露风险非对称加密安全性极高但运算缓慢不适合大数据传输哈希算法不可逆专门用于校验数据是否被篡改数字证书服务器的官方 “身份证”抵御中间人伪造公钥攻击HTTPS非对称加密安全传递会话密钥对称加密传输业务数据安全与性能兼顾从最初明文裸奔的 HTTP到加密安全的 HTTPS再到不断迭代优化的 HTTP/2、HTTP/3整个协议体系的演进本质就是在安全性和传输性能之间不断寻找最优解。对于开发者而言理解这套知识不仅能看懂网络请求背后的逻辑排查抓包、接口、网络故障时也会更加得心应手同时这也是后端、前端、运维岗位面试的高频考点。建议大家结合抓包工具实际演练理论搭配实操才能真正吃透这套互联网核心协议。