代码随想录 | 八股-HTTP版本
HTTP1.0和HTTP1.1的区别
- 🚗 连接方式：从“一次一清”到“多次复用”
- HTTP 1.0： 默认短连接。浏览器每请求一个资源（图片、CSS、JS等），都要和服务器建立一次新的TCP连接，用完后立即关闭。
- HTTP 1.1： 默认持久连接。浏览器和服务器建立一个TCP连接后，可以在这个连接上连续发送多个请求和接收多个响应通过Connection: keep-alive头来实现持久连接。
- 🏠 Host头：从“单间平房”到“共享公寓”
- HTTP 1.0：
请求中没有
Host请求头。服务器认为一个IP地址就对应一个网站（一个“主机”）。想象成：一个门牌号只住一户人家。 - HTTP 1.1：
请求中必须包含
Host请求头。指明请求要访问的是服务器上的哪个虚拟主机/域名。这使虚拟主机托管成为可能（一台服务器托管多个不同域名的网站）。想象成：一个门牌号（服务器IP）里住了好几户人家（不同网站），送快递必须写明收件人姓名（Host头）才知道送到哪户。
- HTTP 1.0：
请求中没有
- 🧊 缓存控制：从“简单指示”到“精细管理”
- HTTP 1.0：
主要用
If-Modified-Since/Expires（绝对过期时间）和Pragma: no-cache（简单不缓存）控制缓存。功能简单，不够灵活。 - HTTP 1.1：
引入了更强大、更精细的
Cache-Control头。可以指定max-age（相对过期时间）、no-cache（需重新验证）、no-store（禁止存储）、public/private等众多指令。（缓存控制能力大大增强！）也可使用If-None-Match/Etag
- HTTP 1.0：
主要用
- ⏳ 带宽优化：从“全有全无”到“按需取件”
- HTTP 1.0： 如果下载大文件中断，必须从头开始重新下载。
- HTTP 1.1：
支持断点续传。使用
Range请求头可以指定只请求资源的一部分（如从第1000个字节开始），服务器用206 Partial Content状态码和Content-Range响应头返回部分内容。想象成：下载电影断网了，续播时可以从上次断开的地方继续下载，不用重头看。
- 🚀 请求处理：从“排队等”到“连续发”（理论上）
- HTTP 1.0： 客户端必须等前一个请求的响应完全返回后，才能发送下一个请求。想象成：收费站，前一辆车完全通过栏杆落下再抬起，后一辆车才能进。
- HTTP 1.1： 支持管道化。客户端可以在一个连接上连续发送多个请求，而不用等待每个响应。服务器必须按照收到请求的顺序返回响应。想象成：收费站允许连续进多辆车，但出来的顺序必须和进去的顺序一致。（理论上提升速度，但实践中问题多，较少用）
- 📦 分块传输：从“等菜齐”到“边做边上”
- HTTP 1.0：
服务器必须在知道资源的完整长度（
Content-Length）后才能开始发送响应。对于动态生成的内容，需要等全部生成完才能发送。 - HTTP 1.1：
引入了分块传输编码。服务器可以将响应分成多个“块”发送，并在最后一个块发送完毕后标记结束。使用
Transfer-Encoding: chunked响应头。想象成：厨房边做菜边端上桌，不用等所有菜都做好。（提升动态内容响应速度，减少延迟）
- HTTP 1.0：
服务器必须在知道资源的完整长度（
- 📝 错误处理：从“模糊”到“更明确”
- HTTP 1.1： 新增了一些状态码，提供更精确的错误信息：
409 Conflict：请求与服务器当前状态冲突。410 Gone：资源被永久删除（比404 Not Found更明确）。100 Continue：客户端发送大请求体前，先询问服务器是否愿意接收，服务器同意（100 Continue）后再发完整请求。避免带宽浪费。
- 响应格式： HTTP 1.1
要求响应行中必须包含原因短语（如
HTTP/1.1 200 OK），而 1.0 只要求状态码是可选的（虽然实践中通常都有）。
- HTTP 1.1： 新增了一些状态码，提供更精确的错误信息：
HTTP2.0与HTTP1.1的区别？
一句话记忆：HTTP/2 = 更快、更智能、更省资源！
1️⃣ 传输方式：从“文本排队”到“二进制分帧”
- HTTP/1.1：
- 用纯文本格式发送请求和响应（比如
GET /index.html HTTP/1.1）。
- 多个请求必须排队串行处理（即使开了管道化也有队头阻塞问题）。
- 想象： 邮局用明信片寄信，一次只能寄一张，必须等回信才能寄下一张，效率低。✉️➡️✉️➡️✉️
- 用纯文本格式发送请求和响应（比如
- HTTP/2：
- 将数据拆分成更小的二进制帧（Frame）（头部帧 HEADERS
+ 数据帧 DATA）。
- 同一个连接上，多个请求/响应的帧可以混合发送、并行传输，互不阻塞！
- 想象： 快递公司把包裹拆成小件，打上标签，通过立体分拣通道同时运输，到目的地再组装。📦📦📦 → 🚚💨
- 将数据拆分成更小的二进制帧（Frame）（头部帧 HEADERS
+ 数据帧 DATA）。
👉 核心价值：彻底解决队头阻塞，大幅提升并发效率！
2️⃣ 连接方式：从“多路排队”到“真·多路复用”
- HTTP/1.1：
- 虽然支持持久连接（一个TCP连多个请求），但响应必须按顺序返回（队头阻塞）。
- 浏览器通常开 6~8个TCP连接 并行请求资源（但占用资源多）。
- 虽然支持持久连接（一个TCP连多个请求），但响应必须按顺序返回（队头阻塞）。
- HTTP/2：
- 一个TCP连接 上即可实现
成百上千个流的并行传输（每个流是一个请求/响应）。
- 帧自带流ID标识，接收方能按ID重组数据，无需排队等待！
- 想象： 从多条乡间小路 → 升级成一条双向十车道高速路，所有车辆（请求）畅通无阻。🛣️🚗🚙🚕
- 一个TCP连接 上即可实现
成百上千个流的并行传输（每个流是一个请求/响应）。
👉 核心价值：一个连接解决所有请求，省资源、低延迟！
3️⃣ 头部信息：从“重复臃肿”到“高效压缩”
- HTTP/1.1：
- 每次请求都携带大量重复的文本头部（如Cookie、User-Agent），不压缩。
- 浪费带宽（尤其小文件请求时，头部可能比数据还大）。
- 每次请求都携带大量重复的文本头部（如Cookie、User-Agent），不压缩。
- HTTP/2：
- 使用 HPACK 算法压缩头部：
- 客户端和服务端维护“头部字典”，相同头部只传索引；
- 用霍夫曼编码压缩文本。
- 客户端和服务端维护“头部字典”，相同头部只传索引；
- 头部大小减少 30%~90%！
- 想象： 从每次寄信都手写完整地址 → 改用电子二维码扫码寄件，地址库自动匹配。📮→📲
- 使用 HPACK 算法压缩头部：
👉 核心价值：大幅节省带宽，加快小资源加载！
4️⃣ 服务器主动推送：从“被动响应”到“主动送货”
- HTTP/1.1：
- 服务器只能被动响应客户端请求。
- 浏览器需解析HTML后，再请求CSS/JS/图片等依赖资源。
- 服务器只能被动响应客户端请求。
- HTTP/2：
- 服务器可主动推送客户端可能需要的资源（如CSS/JS）！
- 客户端可缓存推送内容，下次直接使用。
- 想象： 点外卖时，商家不仅送米饭，还主动附赠了筷子和纸巾（你知道你一定会需要）。🍚+🥢+🧻
- 服务器可主动推送客户端可能需要的资源（如CSS/JS）！
👉 核心价值：减少请求往返次数，加速页面渲染！
5️⃣ 优先级与流量控制：更智能的资源调度
- HTTP/2：
- 客户端可为请求标记优先级（如CSS >
图片），服务器优先处理高优先级流。
- 支持精细的流量控制（基于每个流控制传输速率）。
- 客户端可为请求标记优先级（如CSS >
图片），服务器优先处理高优先级流。
- HTTP/1.1： 无法真正实现优先级调度（依赖浏览器启发式策略）。
⚠️ 注意：
- HTTP/2 未加密，但所有主流浏览器只支持
HTTP/2 Over TLS（即 HTTPS）。
- HTTP/2 解决了应用层队头阻塞，但 TCP
层仍有队头阻塞（丢包会阻塞所有流）。
- 这是 HTTP/3（基于QUIC/UDP）要解决的下一代问题！
HTTP3.0有了解过吗？
🚀 核心一句话：HTTP/3 = 抛弃TCP！拥抱QUIC！ > 解决 HTTP/2 的终极痛点：TCP 的队头阻塞！
1️⃣ 底层协议革命：从 TCP 到 QUIC（基于UDP）
- HTTP/1.1 & HTTP/2： 都跑在 TCP
协议之上。
- TCP 问题：
如果传输中丢了一个包，后续所有包都要等待重传（即使它们属于不同请求），这就是
TCP 队头阻塞。
- 想象：
快递车队走一条单行道，前一辆车抛锚，后面所有车都得堵着等（无论是不是同一批货物）。🚚❌🚛🚗🚐
- TCP 问题：
如果传输中丢了一个包，后续所有包都要等待重传（即使它们属于不同请求），这就是
TCP 队头阻塞。
- HTTP/3： 彻底抛弃 TCP，改用全新协议
QUIC（Quick UDP Internet Connections），运行在
UDP 之上。
- QUIC 优势：
每个请求/响应流是独立传输的，丢包只影响当前流，其他流畅通无阻！
- 想象：
快递改用无人机配送，每件包裹独立飞行路线，一个包裹出问题，其他包裹照常送达。✈️📦➡️🏠
| ✈️📦➡️🏠 | 💥📦❌ | ✈️📦➡️🏠
👉 核心价值：彻底消灭传输层队头阻塞，网络波动时性能大幅提升！
- QUIC 优势：
每个请求/响应流是独立传输的，丢包只影响当前流，其他流畅通无阻！
2️⃣ 建连速度飞跃：0-RTT 与 1-RTT 握手
- HTTP/1.1 & HTTP/2（TCP+TLS）：
- 首次连接需 TCP 三次握手（1.5 RTT） + TLS 握手（1~2 RTT） =
总计 2~3.5 RTT 延迟才能发送数据。
- 首次连接需 TCP 三次握手（1.5 RTT） + TLS 握手（1~2 RTT） =
总计 2~3.5 RTT 延迟才能发送数据。
- HTTP/3（QUIC）：
- 首次连接：1-RTT 握手（QUIC
将传输和加密握手合并）。
- 重连用户：0-RTT
握手！客户端缓存了服务器密钥，首次请求可直接带上加密数据。
- 想象：
进地铁站——旧方式：先排队买票（TCP握手），再安检（TLS握手）；新方式：刷脸直接进（0-RTT）！🎫→🛂→🚇
→ 😃🔜🚇
👉 核心价值：首次访问更快，重复访问“闪电启动”！
- 首次连接：1-RTT 握手（QUIC
将传输和加密握手合并）。
3️⃣ 连接迁移：网络切换不断线
- HTTP/1.1 & HTTP/2：
- 连接绑定 IP + 端口 +
TCP协议。切换网络（如WiFi→4G）会导致IP变化，连接必须重建！
- 连接绑定 IP + 端口 +
TCP协议。切换网络（如WiFi→4G）会导致IP变化，连接必须重建！
- HTTP/3（QUIC）：
- 使用 连接ID（Connection ID） 唯一标识连接。
- 切换网络时，只要客户端能通信，连接ID不变，会话无缝延续！
- 想象：
旧手机卡换手机要重新插卡激活；eSIM卡换手机自动联网，号码不变。📱➡️📱 =
❌ vs 📱➡️📱 = ✅
👉 核心价值：移动端福音！地铁进隧道、WiFi切5G，视频会议不中断！
- 使用 连接ID（Connection ID） 唯一标识连接。
4️⃣ 内嵌加密：安全是强制要求
- QUIC 协议设计之初就强制加密（使用 TLS 1.3）。
- 没有明文的 QUIC！ 所有头部和载荷默认加密。
- 对比： HTTP/2
的加密（HTTPS）是可选但事实强制，HTTP/3 直接内嵌到协议层。
👉 核心价值：提升安全性，防止运营商劫持、降低中间设备干扰。
5️⃣ 改进的多路复用 & 头部压缩
- 多路复用： 继承 HTTP/2
的流多路复用（一个连接并发多个流），且由于基于
QUIC，无队头阻塞。
- 头部压缩： 升级为 QPACK 算法（类似
HTTP/2 的 HPACK，但适应 QUIC 乱序特性）。
👉 核心价值：在 HTTP/2 高效基础上，更稳定！