1. http

1.1 浏览器访问一个网页的过程

1. 用户输入网址（域名）

2. 浏览器通过DNS服务器查询域名对应的IP地址（浏览器会将查询结果“域名→IP”缓存在本地）

3. 浏览器与<Web服务器IP地址:80端口>建立TCP连接

4. 浏览器在握手③中携带HTTP请求报文（指明要访问哪个html网页）

5. 服务器返回HTTP响应报文（携带html文件）

6. 如果html引用了其他n个元素，还需要n组HTTP请求&响应（持续、非持续工作方式有所区别）

1.2 http的五种工作方式

--------------------------------------------------------------------------------
1. 非持续连接 (HTTP/1.0)
   特点: 一请求一连接，每次都要握手挥手
   RTT : 2N (N=资源数量)
--------------------------------------------------------------------------------
客户端                              服务器
  |                                   |
  |--- [SYN] -----------------------> |  (1. TCP握手)
  |<-- [SYN+ACK] -------------------- |
  |--- [ACK] -----------------------> |
  |                                   |
  |--- [REQ 1] --------------------- >|  (2. 传输对象1)
  |<-- [RES 1] ---------------------- |
  |                                   |
  |--- [FIN] -----------------------> |  (3. TCP挥手 - 关闭)
  |<-- [ACK+FIN] - - - - - - - - - - -|
  |                                   |
  |--- [SYN] -----------------------> |  (4. 重新握手 - 传输对象2)
  |<-- [SYN+ACK] -------------------- |
  |--- [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)
核心机制	一请求一连接，用完即毁	一连接多请求 串行处理	一连接多请求 并行发，串行回	一连接多流 帧级交错并发	一连接多流 独立流控制
传输层协议	TCP	TCP	TCP	TCP	QUIC (UDP)
数据格式	纯文本	纯文本	纯文本	二进制分帧	二进制分帧
TCP连接数 (N个资源)	N 条 (频繁创建销毁)	1 条 (复用)	1 条 (复用)	1 条 (复用)	1 条 (复用，基于UDP)
逻辑流数量	1 流/连接	1 流/连接	1 流/连接	多流/连接 (Stream ID区分)	多流/连接 (Stream ID区分)
队头阻塞	无	严重：请求层阻塞，前一个没回，后一个不发	中等：响应层阻塞，前一个没回完，后一个不回	部分解决： 应用层无阻塞, 传输层阻塞 ，TCP丢包卡死所有流	彻底解决：应用层 + 传输层均无阻塞，丢包只影响当前流
头部压缩	无	无	无	HPACK 消除重复头部	QPACK 解决HPACK依赖顺序问题
连接迁移	不支持	不支持	不支持	不支持	支持
加密要求	可选 (通常明文)	可选 (通常明文)	可选 (通常明文)	标准未强制 但浏览器强制HTTPS	强制加密，强制HTTPS
浏览器现状	已淘汰	广泛兼容	因队头阻塞默认禁用	主流标准	快速普及

1.3 http2

1.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 栈会缓存 N+1 及之后的所有数据包，直到 N 重传成功。
• 后果：即使 HTTP/2 的 Stream 1 和 Stream 2 互不相关，只要底层的 TCP 包丢失，该连接上的所有 Stream 都会暂停交付给应用层。这就是传输层队头阻塞。

1.4 http3

HTTP/3 将传输层从 TCP 替换为基于 UDP 的 QUIC 协议。它将 TLS 1.3 和可靠传输逻辑直接集成在用户态库中。

1.4.1 协议栈重构

• HTTP/2: HTTP/2 -> TLS 1.3 -> TCP -> IP
• HTTP/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 (加密)
端口号	80	443，防火墙通常只开放443给Web
安全性	低，明文传输	高，加密传输
加密机制	无	SSL/TLS 协议(对称加密+非对称加密+哈希)，建立连接前先交换密钥，后续数据全程加密
身份认证	无	数字证书 ，验证服务器身份
握手过程	TCP 3次握手	TCP 3次握手 + TLS 握手 多了密钥协商和证书验证
HTTP/2支持	浏览器不支持，实际标准未强制但浏览器强制	浏览器强制要求，仅对HTTPS开启H2
HTTP/3支持	不支持	支持，HTTP/3 本身就是基于加密设计的

• 服务器生成公钥和私钥，向客户端分发公钥；
• 客户端生成密钥，用公钥加密发给服务器；
• 服务器用私钥解密，获得密钥；
• 使用密钥加密通信。

3. DNS

3.1 简介

• 默认端口：53
• 作用：是将域名转换为 IP 地址的分布式数据库系统。基于UDP。
• 命名规则与层级：
  • 分隔符：使用句点 (.) 来分隔不同部分（例如 www.server.com）。
  • 层级方向：
    • 越靠右的位置，表示其层级越高。对应关系：.com (根/顶级) -> server (二级) -> www (主机)。
    • 实际上域名最后还有一个点（例如 www.server.com.），最后的点代表根域名。
• 树状层级结构：
  • 根 DNS 服务器 (.)：位于最顶层。
  • 顶级域 DNS 服务器：如 .com, .cn 等。
  • 权威 DNS 服务器：如 server.com，负责管理具体的域名记录。
• 查询与访问机制
  • 根域信息的普及性：根域 DNS 服务器的信息保存在互联网中所有的 DNS 服务器中。
  • 查询路径（顺藤摸瓜）：
    1. 客户端只要能找到任意一台 DNS 服务器，通过它找到根域 DNS 服务器。
    2. 再一路顺藤摸瓜，找到位于下层的某台目标 DNS 服务器。

3.2 工作流程

• 第一阶段：发起与缓存
  1. 客户端请求：客户端向本地 DNS 服务器（配置在 TCP/IP 中）发起查询请求（如 www.server.com 的 IP 是多少？）。
  2. 缓存检查：本地 DNS 先查自己的缓存。
     • 有记录：直接返回 IP，结束。
     • 无记录：进入下一阶段。
• 第二阶段：迭代查询（根—顶级—权威）
  1. 问根域：本地 DNS 问根 DNS 服务器。根服务器不直接给 IP，而是指引：“去找 .com 顶级域服务器”。
  2. 问顶级域：本地 DNS 拿着地址去问 .com 顶级域服务器。顶级域服务器指引：“去找 server.com 权威 DNS服务器”。
  3. 问权威域：本地 DNS 去问 server.com 的权威 DNS 服务器（这是域名的“原产地”）。
• 第三阶段：结果返回
  1. 获取 IP：权威 DNS 查询后，将对应的 IP 地址 告诉本地 DNS。
  2. 返回客户端：本地 DNS 将 IP 地址返回给客户端，并保存缓存。
  3. 建立连接：客户端拿到 IP，与目标服务器建立连接。

4. DHCP

4.1 简介

• 默认端口：服务器：67，客户端：68
• 传输协议：UDP
• 作用：自动为网络设备分配 IP 地址及相关网络参数，实现"即插即用"

4.2 工作流程

步骤	报文	方向	作用
1. Discover	DHCP Discover	C→S	客户端广播寻找可用服务器，携带 MAC 地址
2. Offer	DHCP Offer	S→C	服务器预分配 IP + 子网掩码 + 网关 + 租期
3. Request	DHCP Request	C→S	客户端确认选择某服务器（广播通知其他服务器释放预留）
4. ACK	DHCP ACK	S→C	服务器正式确认，客户端应用配置

1. 客户端首先发起 DHCP 发现报文（DHCP DISCOVER）的 IP 数据报，由于客户端没有 IP 地址，也不知道 DHCP 服务器的地址，所以使用的是 UDP 广播通信，其使用的广播目的地址是 255.255.255.255（端口 67）并且使用 0.0.0.0（端口 68）作为源 IP 地址。客户端将该 IP 数据报传递给链路层，链路层然后将帧广播到所有的网络设备。
2. DHCP 服务器收到 DHCP 发现报文时，用 DHCP 提供报文（DHCP OFFER）向客户端做出响应。该报文仍然使用 IP 广播地址 255.255.255.255，该报文信息携带服务器提供可租约的 IP 地址、子网掩码、默认网关、DNS 服务器以及 IP 地址租用期。
3. 客户端收到一个或多个服务器的 DHCP 提供报文后，从中选择一个服务器，并向选中的服务器发送 DHCP 请求报文（DHCP REQUEST进行响应，回显配置的参数。
4. 最后，服务端用 DHCP ACK 报文对 DHCP 请求报文进行响应，应答所要求的参数。一旦客户端收到 DHCP ACK 后，交互便完成了，并且客户端能够在用期内使用 DHCP 服务器分配的 IP 地址。

如果租约的 DHCP IP 地址过期后，客户端会向服务器发送 DHCP 请求报文：

• 服务器如果同意继续租用，则用 DHCP ACK 报文进行应答，客户端就会延长租期。
• 服务器如果不同意继续租用，则用 DHCP NACK 报文，客户端就要停止使用租约的 IP 地址。