1. http1.1 浏览器访问一个网页的过程用户输入网址域名浏览器通过DNS服务器查询域名对应的IP地址浏览器会将查询结果“域名→IP”缓存在本地浏览器与Web服务器IP地址:80端口建立TCP连接浏览器在握手③中携带HTTP请求报文指明要访问哪个html网页服务器返回HTTP响应报文携带html文件如果html引用了其他n个元素还需要n组HTTP请求响应持续、非持续工作方式有所区别1.2 http的五种工作方式-------------------------------------------------------------------------------- 1. 非持续连接 (HTTP/1.0) 特点: 一请求一连接每次都要握手挥手 RTT : 2N (N资源数量) -------------------------------------------------------------------------------- 客户端 服务器 | | |--- [SYN] ----------------------- | (1. TCP握手) |-- [SYNACK] -------------------- | |--- [ACK] ----------------------- | | | |--- [REQ 1] --------------------- | (2. 传输对象1) |-- [RES 1] ---------------------- | | | |--- [FIN] ----------------------- | (3. TCP挥手 - 关闭) |-- [ACKFIN] - - - - - - - - - - -| | | |--- [SYN] ----------------------- | (4. 重新握手 - 传输对象2) |-- [SYNACK] -------------------- | |--- [ACK] ----------------------- | |--- [REQ 2] --------------------- | |-- [RES 2] ---------------------- | | | | (每个对象都重复上述过程效率极低) | | | -------------------------------------------------------------------------------- 2. 持续连接 - 非流水线 (HTTP/1.1 默认) 特点: 一连接多请求但必须等一个回一个 (串行) RTT : 2 N -------------------------------------------------------------------------------- 客户端 服务器 | | | TCP 三次握手 (仅1次) | | | |--- [REQ 1] --------------------- | |-- [RES 1] ---------------------- | (必须等RES1回来) | | |--- [REQ 2] --------------------- | (才能发REQ2) |-- [RES 2] ---------------------- | | | |--- [REQ 3] --------------------- | |-- [RES 3] ---------------------- | | | | TCP 四次挥手 (最后1次) | | | (存在队头阻塞前一个慢后面全等) -------------------------------------------------------------------------------- 3. 持续连接 - 流水线 (HTTP/1.1 可选) 特点: 请求可连续发但响应必须按序回 RTT : 2 (理论最优但有缺陷) -------------------------------------------------------------------------------- 客户端 服务器 | | | TCP 三次握手 (仅1次) | | | |--- [REQ 1] --------------------- | |--- [REQ 2] --------------------- | (不用等连续发) |--- [REQ 3] --------------------- | | | |-- [RES 1] ---------------------- | (必须按序返回) |-- [RES 2] ---------------------- | (若RES1慢RES2/3做好了也得等) |-- [RES 3] ---------------------- | | | | TCP 四次挥手 | | | (存在响应队头阻塞浏览器默认禁用) -------------------------------------------------------------------------------- 4. HTTP/2 多路复用 (基于 TCP) 特点: 二进制分帧多流交错应用层无阻塞 RTT : 2 (但受限于TCP底层丢包阻塞) -------------------------------------------------------------------------------- 客户端 服务器 | | | TCP 三次握手 TLS 握手 | | | |--- [STR 1: HEADERS] ------------ | \ |--- [STR 2: HEADERS] ------------ | } 请求乱序发送 |--- [STR 3: DATA ] ------------| / | | |-- [STR 2: DATA ] -------------| \ |-- [STR 1: DATA ] -------------| } 响应乱序返回 (靠流ID重组为一个完整消息) |-- [STR 3: DATA ] -------------| / | (帧交错传输互不等待) | | | | TCP 四次挥手 | | | (应用层无阻塞。但若TCP包丢失所有流都会因TCP重传而阻塞) -------------------------------------------------------------------------------- 5. HTTP/3 (基于 QUIC/UDP) 特点: UDP传输0-RTT握手彻底解决传输层阻塞 RTT : 0-1 (最快) -------------------------------------------------------------------------------- 客户端 服务器 | | |--- [ClientHello REQ 1] -------| (0-RTT: 握手带数据一起发) |-- [ServerHello RES 1] --------| | | |--- [STR 1: DATA ] --------------| |--- [STR 2: DATA ] --------------| 真正的独立并行 | | |-- [STR 2: DATA ] ---------------| |-- [STR 1: DATA ] ---------------| 某流丢包不影响其他流 | (QUIC协议层独立重传) | | | | (连接迁移: IP变了也不用重新握手) | | | (彻底解决应用层 传输层队头阻塞)属性1. 非持续连接(HTTP/1.0)2. 持续连接-非流水线(HTTP/1.1 默认)3. 持续连接-流水线(HTTP/1.1 可选)4. HTTP/2多路复用(基于 TCP)5. HTTP/3 (QUIC)(基于 UDP)核心机制一请求一连接用完即毁一连接多请求串行处理一连接多请求并行发串行回一连接多流帧级交错并发一连接多流独立流控制传输层协议TCPTCPTCPTCPQUIC (UDP)数据格式纯文本纯文本纯文本二进制分帧二进制分帧TCP连接数(N个资源)N 条(频繁创建销毁)1 条(复用)1 条(复用)1 条(复用)1 条(复用基于UDP)逻辑流数量1 流/连接1 流/连接1 流/连接多流/连接(Stream ID区分)多流/连接(Stream ID区分)队头阻塞无严重请求层阻塞前一个没回后一个不发中等响应层阻塞前一个没回完后一个不回部分解决应用层无阻塞,传输层阻塞TCP丢包卡死所有流彻底解决应用层 传输层均无阻塞丢包只影响当前流头部压缩无无无HPACK消除重复头部QPACK解决HPACK依赖顺序问题连接迁移不支持不支持不支持不支持支持加密要求可选 (通常明文)可选 (通常明文)可选 (通常明文)标准未强制但浏览器强制HTTPS强制加密强制HTTPS浏览器现状已淘汰广泛兼容因队头阻塞默认禁用主流标准快速普及1.3 http21.3.1 二进制分帧层HTTP/2 在应用层与传输层之间引入了一个二进制分帧层。文本转二进制HTTP/1.x 的 ASCII 文本报文被转换为二进制格式。帧通信的最小单位。每个帧包含帧头和负载帧头内包含流 ID。消息逻辑上的完整 HTTP 请求或响应由一个或多个帧组成。1.3.2 多路复用与流流应用协议自定义的每个流有唯一的流 ID奇数为客户端发起偶数为服务器发起。交错传输在同一个 TCP 连接上不同流的帧可以任意交错发送。客户端发送多个帧每个帧的流ID可以不同。解决应用层队头阻塞接收端根据流 ID将帧重组为完整的消息。流1 的大数据块传输不会阻塞 流2 的小数据块发送。1.3.3 头部压缩 (HPACK)问题HTTP/1.x 头部冗余大如 User-Agent,Cookie 重复传输且未压缩。机制静态表 动态表维护索引表将头部字段映射为整数索引。哈夫曼编码对头部值进行无损压缩。上下文更新发送端和接收端同步维护动态表状态仅发送增量变化。1.3.4 依赖与优先级客户端可在HEADERS帧中指定流的依赖树Parent Stream和权重1-256。服务器据此调度发送顺序优先传输关键资源如 HTML/CSS但这只是建议性的不保证绝对顺序。1.3.5 局限性传输层TCP 队头阻塞尽管应用层解决了阻塞但底层仍依赖TCP。TCP 特性面向字节流、可靠、严格有序。阻塞机制若 TCP 序列号 N 的包丢失接收端 TCP 栈会缓存 N1 及之后的所有数据包直到 N 重传成功。后果即使 HTTP/2 的 Stream 1 和 Stream 2 互不相关只要底层的 TCP 包丢失该连接上的所有 Stream 都会暂停交付给应用层。这就是传输层队头阻塞。1.4 http3HTTP/3 将传输层从TCP替换为基于UDP的QUIC协议。它将 TLS 1.3 和可靠传输逻辑直接集成在用户态库中。1.4.1 协议栈重构HTTP/2: HTTP/2 - TLS 1.3 - TCP - IPHTTP/3: HTTP/3 -QUIC (内置 TLS 1.3) - UDP- IP意义绕过内核态 TCP 栈的限制在应用层实现拥塞控制、重传和加密迭代更灵活。1.4.2 流级多路复用与独立可靠性QUIC用 UDP 在应用层实现了类似 TCP 的可靠传输但粒度不同多流架构QUIC 连接包含多个独立的Streams。独立序号空间每个 Stream 有自己独立的字节偏移量和确认机制。解决传输层队头阻塞若 Stream A 的某个 Packet 丢失QUIC 仅重传该 Packet。Stream B、C 的数据包即使物理上紧随其后到达也能立即交付给应用层无需等待 Stream A 的重传。结论丢包影响仅限于当前流不影响同一连接下的其他流。1.4.3 0-RTT 握手与连接迁移快速握手 (0-RTT)利用 TLS 1.3 的会话恢复机制。客户端在第一个数据包中直接携带加密的应用数据。若服务端接受可直接处理请求并返回响应实现0-RTT延迟。连接迁移问题TCP 使用 (SrcIP, SrcPort, DstIP, DstPort) 四元组标识连接。网络切换WiFi-4G导致 IP 变化TCP 连接断开。QUIC 方案使用Connection ID (CID)标识连接与 IP/Port 解耦。过程客户端 IP 变更后后续数据包携带相同的 CID服务端识别后继续传输无需重新握手。1.4.4 头部压缩 (QPACK)问题HTTP/2 的 HPACK 依赖严格的帧顺序动态表更新必须按序若前一个帧丢失后续帧无法解码导致应用层队头阻塞复现。QPACK 改进引入独立的控制流来同步动态表更新。允许头部块在不阻塞的情况下引用动态表条目。即使更新指令丢失仅影响依赖该指令的特定流不阻塞其他流。1.4.5 拥塞控制QUIC 在用户态实现了可插拔的拥塞控制算法默认通常为CUBIC或BBR。由于运行在用户态开发者可以快速部署新的拥塞控制算法无需等待操作系统内核升级。2. https对比维度HTTP (明文)HTTPS (加密)端口号80443防火墙通常只开放443给Web安全性低明文传输高加密传输加密机制无SSL/TLS 协议(对称加密非对称加密哈希)建立连接前先交换密钥后续数据全程加密身份认证无数字证书验证服务器身份握手过程TCP 3次握手TCP 3次握手TLS 握手多了密钥协商和证书验证HTTP/2支持浏览器不支持实际标准未强制但浏览器强制浏览器强制要求仅对HTTPS开启H2HTTP/3支持不支持支持HTTP/3 本身就是基于加密设计的服务器生成公钥和私钥向客户端分发公钥客户端生成密钥用公钥加密发给服务器服务器用私钥解密获得密钥使用密钥加密通信。