第二章 第2节-第3节

第二章第二节续

http响应报文：

接下来我们说说cookie，Web服务站点和客户端浏览器使用 cookies在它们之间的事务上维持状态

四个组成部分: 1)包含在响应报文的头部行中Cookie

2) 包含在请求报文头部行中的Cookie

3) Cookie文件被保存在用户的端系统中，被用户的浏览器管理

4)在Web服务站点的后台数据库中

也就是说什么意思呢，我们的这个cookie文件保存在我们本地和后台数据库那里，也就是说比如我们建立一个用MySQL数据库的应用，ai对话，然后把前后端部署好之后发网上，别人和ai聊天的消息会自动保存在你的数据库里面，你可以看到别人发的消息。

http协议本身是无状态的，每次请求都是独立的，cookies通过客户端和服务器端维护一小段信息来记住用户，cookies应用层的数据，它类似于一种随机生成的会话ID和一个token，一种零时身份证，里面虽然没有密码，但是服务器认识这个cookie，他就会直接跳过账号密码，直接进入你的账户，如果让别人拿到了你的cookie塞入他的浏览器，他就可以直接进入你的账户不需要输入密码，叫做会话劫持。

类似于我们之前明日方舟终末地的网吧小事故~，我们登陆游戏也会有这种cookie/token也就是这些所谓的登陆的cache和crc文件缓存，但是笨蛋老鹰把文件的校验机制放在了客户端本地，也就是登录凭证明文保存在本地文件里，服务器只检查token是否有效，所以一旦让别人拿到就可以直接访问你在数据库的账号。

核心工作流程：访问网站发送http请求之后，受到响应之后会包含类似于set-cookie：1678 然后把cookie ID保存在cookie文件中，后续访问会自动发送，服务器受到请求就会查到你的id自动保存登陆状态。

核心：Cookies实现了用于认证购物车用户会话关了等问题的解决。解决了谁再访问的问题，用于维护用户状态和身份识别，数据存储在客户端文件+服务器数据库。

接下来看web缓存：

Web缓存解决访问速度和减少带宽消耗的问题，用于存储内容副本，数据存储在中间代理服务器，web缓存能极低成本大幅提升体验，比单纯买带宽更有效，是CDN内容分发网络的核心思想

未命中时：需经过接入链路互联网到原始服务器，传输延迟100kbits/1.54Mbps约等于0.065s加上RTT2s，也就是简化为2.01s

命中时本地缓存忽略不计，端到端延迟就是0.6乘以2.01约等于1.206s，反而升级链路是每秒请求都走，效果不好，而安装缓存，存在大量重复访问命中率客观，当用户请求有重复性，也就是公司内部多人用同样的网站软件包等，使用web缓存会方便很多。

条件式get解决web缓存方案的问题

Web缓存保存一个对象但无法确定它是否还是最新的，如果不加验证，每次都用网络去拿，要么使用过期的内容可能错误。

工作原理：首次请求：服务器返回对象时，响应头部会包含last-modified：<date> 再次请求时客户端发送get请求，在头部加上上次缓存对象最后修改的时间，如果对象自date以来没有修改过，返回304not modified，可以继续使用缓存副本，已被修改则返回200 ok，并在响应体中增加新的对象内容

第二章第三节：HTTP/2：减少多个对象请求的延迟

HTTP/1.1 存在的问题：HOL 阻塞（Head-Of-Line Blocking）

HTTP/1.1 虽然支持在同一个 TCP 连接上发送多个请求（流水线），但服务器必须按照请求的到达顺序依次响应（FCFS，先到先服务）。

举例：客户端请求一个大对象 O1（比如一个视频文件），接着请求三个小对象 O2、O3、O4。

服务器必须先把 O1 整个发送完毕，才能开始发送 O2、O3、O4。

这样小对象就被“堵”在大对象后面，用户明明可以快速看到小图片，却不得不等大视频传完。这就是 HOL 阻塞。

此外，如果 TCP 段丢失触发重传，整个连接上的所有对象传输都会暂停，进一步加剧延迟。这个也就是所谓TCP的回退N步所谓的GBN（gobackN）在第三章说，具体就是他需要为了保持滑动窗口同步，他必须要等base的这个ACK（返回）这样才能往后滑动一个，要不之后的文件发来之后我们全部扔掉依旧发ACK要求重传，

HTTP/2 的改进（RFC 7540, 2015）HTTP/2 通过多路复用和帧来解决 HOL 阻塞：

1. 将每个请求/响应拆分为“帧”， 每个对象（如 O1、O2）被分成多个小的二进制帧，每个帧带有流编号，标识它属于哪个对象。

2. 交错传输

服务器可以在同一个 TCP 连接上，交叉发送不同对象的数据帧。比如发送 O1 的帧1，然后发送 O2 的帧1，再发 O1 的帧2，再发 O3 的帧1…… 这样小对象可以“插队”到大对象中间传输，用户能更快看到小内容。

3. 优先级

客户端可以告诉服务器哪些对象更重要（比如网页中的 CSS 和 JS 优先于图片）。服务器会根据优先级调度帧的发送顺序，而不是死板的 FCFS。

4. 服务器推送

服务器可以主动向客户端推送可能需要的对象（例如客户端请求了 index.html，服务器主动推送 style.css 和 script.js），减少额外的往返请求。

5. 头部压缩

使用 HPACK 算法压缩 HTTP 头部（尤其是重复的 Cookie、User-Agent 等），减少开销。

6. 二进制编码

相比 HTTP/1.1 的文本协议，二进制解析更高效，也更不容易出错。

· HTTP/1.1：小对象被大对象阻塞，用户感知延迟高。

· HTTP/2：小对象可以“跳过”大对象提前到达，页面加载明显变快。

http2可以说运用了我们第三章所学的多路选择复用，回退N步的解决方法以及选择重传的插帧缓存

接下来简要说下HTTP3（第三章传输层还会细说）

HTTP/2 在 TCP 上的“老毛病”依然存在

HTTP/2 虽然通过帧和流解决了应用层的 HOL 阻塞，但它底层依然是 TCP 连接。TCP 有几个固有缺陷：

1. 队头阻塞（HOL blocking）仍然存在，只是转移到了 TCP 层

在 HTTP/2 中，多个流（不同对象的帧）交织在同一个 TCP 连接上传输。

如果 TCP 段（segment）在传输中丢失，TCP 的可靠机制会要求重传丢失的段，并且后续所有数据（包括属于其他流的帧）都必须等待这个丢失段重传完成才能继续交付给应用层。

结果：一个流的丢包会阻塞所有其他流的处理，这就是 TCP 层的 HOL 阻塞。

2. 浏览器会开多个 TCP 连接来缓解，但有限制

· 为了减少上述停顿，浏览器通常对同一个域名同时打开多个 TCP 连接（比如 4~6 个）。 但这样会消耗更多资源，且服务器和客户端都有连接数限制，并不能彻底解决问题。

3. TCP 连接建立开销大（尤其加上 TLS）

· 传统的 HTTPS 需要 TCP 三次握手 + TLS 握手（至少 2-RTT 才能开始发送数据）。即使 TLS 1.3 将握手缩减到 1-RTT，仍然比 UDP 的 0-RTT 慢。

4. 协议栈层次多，效率低

· HTTP/2 通常运行在 TLS 之上，TLS 再运行在 TCP 之上，每一层都有封装和解析开销。

HTTP/3：放弃 TCP，改用 UDP + QUIC

HTTP/3 的核心思想是：将传输层的可靠性、拥塞控制、多路复用、安全性全部在 UDP 之上重新实现，这个实现就叫 QUIC（Quick UDP Internet Connections）。

传输层 HOL 阻塞 一个流丢包，阻塞整个连接 每个流独立，一个流丢包只影响它自己，其他流可以继续

连接建立延迟 TCP + TLS 至少 1-2 RTT 0-RTT 或 1-RTT（QUIC 集成了 TLS 1.3，复用连接时可立即发数据）

移动设备网络切换 TCP 连接依赖 IP 和端口，切换网络（如 WiFi 切 4G）会断连 QUIC 使用 连接 ID（CID），网络切换后仍可识别连接，无需重新握手

头部压缩 HPACK（依赖 TCP 的可靠顺序） QPACK（适配 QUIC 的流独立特性）

安全性 依赖 TLS 层 QUIC 原生加密（TLS 1.3 集成），默认安全

效果就是更快：尤其是在高丢包率的网络（如移动网络、卫星链路）下，HTTP/3 的页面加载速度明显优于 HTTP/2。

总结一下效果：

· 更安全：QUIC 强制加密（不像 TCP 可以选择不加密）。

· 更灵活：连接 ID 机制让连接在网络切换时不中断，对移动设备非常友好。

· 可演化：QUIC 和 HTTP/3 都在用户空间实现，升级协议不需要修改操作系统内核。

· HTTP/2 解决了应用层的 HOL 阻塞，但 TCP 层的 HOL 阻塞依然存在。

· HTTP/3 彻底抛弃 TCP，在 UDP 上实现 QUIC，将每个流独立，丢包不再互相影响，同时集成加密、0-RTT 连接、连接迁移等特性。

· 目前主流浏览器（Chrome、Edge、Firefox、Safari）和服务器（Cloudflare、Nginx、Apache 等）都已支持 HTTP/3。

……小赖下周期中，该复习一下了，微机控制和计组……会更新的….还有leetcode也会…….下节可能会补用vibe用aiagent用Figma或者mastergo来写一个前后端的网页，落地页用HeroUI，产品主界面用shadcn/ui 管理后台用Ant Design / Ant Design Pro，UI/UX Pro Max美化界面，所以会用ai的MCP和skills来服务，会写的很详细，当然说部署网页就是另外一回事了，这个会在我的springboot设计ai智能体的项目里更新，项目做的基本完了，但是笔记还没写完，后面会用docker部署，阿里云函数的计算方式……当然这是后话，后面还会拿rust和vibe实现一个OS内核，目前也在跟着夏令营学习还是小白……，怎么又在画饼，这……不过会更新的会更新的……应该吧，嗯，应该吧…那我们下次再见啦