计算机网络二月 16, 2026网络分层 + 端到端路径# - 网络分层 + 端到端路径 - 分层模型 - 链路层 (LINK) - 负责：同一链路/局域网内把 IP 包送到下一跳 - 典型概念：以太网、WIFI、ARP、MAC、MTU - 网络层 (IP) - 负责：跨网络把包从源 IP 路由到目的 IP - 典型概念：IP 地址、路由表、NAT、ICMP、分片 - 传输层 (Transport) - 负责：端到端进程通信，提供端口与可靠性 - 应用层 (Application) - 负责：定义应用语义 - 端到端路径（一次 HTTPS URL 发生了什么） - URL 解析与策略决策（应用层前置） - 浏览器先拆 URL： - schema：https -> 需要 TLS - host：example.com -> 需要 DNS - port：默认 443 - path：/index.html - 是否可用缓存 - 是否复用已有连接 - DNS 解析：把域名变成 IP - 目标：得到服务器的 IP (A=IPv4/AAAA=IPv6) - 典型流程 - 浏览器/OS 先查本地缓存 - 没命中 -> 向递归解析器发起查询 - 递归解析器询问：根 -> TLD -> 权威 DNS - 返回 IP + TTL - TTL 决定缓存时长 - 同一域名可能返回多个 IP：简单的负载均衡，但是不可控 - TCP 连接（传输层） - 目标：建立一条到服务器IP:443的 TCP 连接 - 典型流程 - 客户端选一个临时端口作为源端口 - 形成 socket 四元组 - 三次握手完成后，连接进入 ESTABLISHED - 连接的唯一标识符是四元组 - NAT 环境下：srcIP 可能是私网 IP，但是公网会被 NAT 改写 - RTT 大时，建连成本高：三次握手至少消耗 1 个 RTT - NAT：内网 IP 也能访问公网（网络层/链路层交叉） - 大多数客户端在 NAT - 内网 192.168.x.x:ramdomPort - 出口 NAT 把它映射成：公网 IP:另一个 Port - NAT 设备维护一张映射表（内网四元组<->公网四元组） - 映射有超时：长时间无数据可能被回收 - 并发连接太多可能端口耗尽 - TLS 握手：在 TCP 上建立安全通道 - 目标 - 验证服务器身份 - 协商密钥 - 后续数据用对称加密 + 完整性保护 - TLS 发生在 TCP 建立之后、HTTP 之前 - 证书用于“证明对方是它声称的域名“ - 发送 HTTP 请求并接受响应 - HTTP 内容 - 请求行：GET /index.html - 头：Host、User-Agent、Accept、Cookie - 体：GET 通常无，POST 常见 - 服务器返回 - 状态码：200/301/404/500 - 头：Content-Type、Content-Length、Set-Cookie - 体：HTML/JSON/图片等 - 连接复用与关闭：不是每次都重新握手 - HTTP/1.1 默认倾向长连接（Keep-Alive） - 浏览器有连接池，会复用到同一个 host:port 的连接 - 关键概念锚点 - RTT：网络交互的时间单位 - RTT = 一个来回的延迟 - 建连/TLS/重传都依赖 RTT - 高 RTT 下，交互次数越多越慢 - 吞吐与 BDP(带宽-时延积) - MTU 月 MSS - MTU：链路层最大承载 - MSS：TCP 单段可承载的应用数据最大值 - 包太大可能被分片或者丢弃 - 合理 MSS 能减少分片风险，提升稳定性 TCP 精讲# - TCP 精讲 - TCP 本质：在不可靠 IP 上提供可靠字节流 - TCP 提供内容 - 面向连接：双方都维护连接状态（序号、窗口、定时器等） - 可靠、有序：丢包重传、乱序重排、去重 - 字节流：没有消息边界（粘包/拆包的根源） - 流量控制：避免把对方接收缓冲打爆（rwnd），端到端 - 拥塞控制：避免把网络打爆，端到网络 - 报文段关键字段 - Sequence Number：本段数据在字节流里的起点序号 - Acknowledgment Number：我期望收到的下一个收到的序号 - Flags：SYN/ACK/FIN/RST/PSH/URG - Window（rwnd）：接收端通告窗口 - Options：MSS，Window Scale - 连接建立：三次握手 - 标准流程 - C->S: SYN（seq=x） - S->C: SYN+ACK (seq=y,ack=x+1) - C->S: ACK (ack=y+1) -  - 为什么必须三次 - 双方都要确认两件事 - 对方能收：对方收到了我的东西 - 对方能发：对方能把东西发回来让我收到 - 两次握手只能证明客户端 -> 服务端这条路通了；但是服务端无法证明服务端->客户端也通、且客户端确实收到了服务端的回应，第三次 ACK 就是让服务端拿到这个确认（服务端无法确认客户端能收） - 如果只有两次握手 - 服务端回 SYN + ACK 丢失了 - 服务端仍为连接建立，开始分配连接资源，等待数据 - 客户端实际上没有收到任何回应，会重试或放弃 - 三次握手还能防止历史重复 SYN 造成的“幽灵连接“ - 历史重复 SYN 指的是：某次旧连接尝试时发出的 SYN，由于网络拥塞、路由绕行、链路重传、设备缓存/异常等原因，在很久之后才到达服务器 - 如果服务器把旧 SYN 当新建连： - 服务器会分配资源 - 如果后续又出现旧 ACK 包，让服务器误以为连接已建立，交付错误的数据 - 幽灵连接：就是服务端自嗨式建立，客户端不认可 - 半连接队列与 SYN Flood - 服务端收到 SYN 后进入 SYN_RECV，会占用半连接资源（backlog） - SYN Flood：大量 SYN 不完成握手 —> 半连接队列被占满 -> 正常连接进不来 - 典型缓解：SYN cookies、增大 backlog、限速、丢弃策略、前置抗 DDoS - 连接关闭：四次挥手、半关闭 - 主动关闭方 A->B：FIN（不再发了） - B -> A：ACK （知道了） - B -> A：FIN （我也不再发了） - A -> B：ACK （知道了） -  - 为什么常见是四次 - TCP 是全双工：A 不发 != B 不发 - B 可能还有数据要发完，所以 ACK 和 FIN 分开 - 半关闭 - A 发 FIN 表示 A 的发送方向关闭，但仍然可以接受 B 的数据 - 工程上常见于“请求发送完但继续接受响应流“的场景 - RST：不是正常关闭，是异常打断 - RST（Reset）是 TCP 里面非常硬的控制信号：立刻终止连接/拒绝连接 - 不是正常的四次挥手关闭，告诉对方：“这条连接不存在/状态不一致，马上停“ - RST 常见原因 - 端口没监听 - 应用崩溃/强制关闭 - 中间设备丢弃状态后注入 RST - TIME_WAIT、CLOSE_WAIT - 主动关闭方在发送最后一个 ACK 后进入 TIME_WAIT，并等待 2MSL。 - 必须 TIME_WAIT - 保证对方收到最后 ACK：最后 ACK 丢了，对方重发 FIN；TIME_WAIT 还能再次 ACK - 让旧连接的延迟报文过期：避免旧数据混入新连接 - 为什么是 2MSL - MSL = 报文在网络中可能存活的最大时间 - 等待 2MSL 是为了覆盖对方 FIN 重传 + 我 ACK 再次发送等往返的不确定性。 - TIME_WAIT 多了怎么办 - 常见场景：短连接高 QPS - 治理思路 - 优先做连接复用：HTTP Keep-Alive/连接池 - 调整应用行为：减少主动 close、合并请求、复用长连接 - 系统参数：允许端口更快复用等 - 通常是我方主动关 + 短连接 - CLOSE_WAIT 多是什么 - CLOSE_WAIT 表示：对方已经 FIN 了，但是我方应用还没有 close - 常见原因：应用层忘记关闭连接、连接泄露、线程阻塞导致没有走到 close - 通常是我方没关 - 可靠传输机制：序号、ACK、重传、SACK - 序号与累计 ACK - TCP 把数据看成连续字节流：每个字节都有序号 - ACK 是累计的：ack = N 表示 0..N-1 都收到了，下一步要 N - 好处：ACK 开销小 - 坏处：遇到乱序/丢包，单靠累计 ACK 不够精细 - 重传触发机制 - 超时重传（RTO）：等不到 ACK 就重发（RTO 动态估计，基于 RTT 抖动） - TCP 发送一个数据段后，会期待收到 ACK，如果在某个时间窗口没有等到 ACK，TCP 可能认为丢了，于是触发超时重传。 - 等多久的时间阈值就是 RTO（Retransmission Timeout）。 - 触发条件：发送后，计时器到期，仍未收到能确认该段的 ACK - 行为：重传未确认的数据段 - RTO 动态估计 - 网络 RTT 会变，而且会抖动，RTO 必须跟随着链路实际 RTT 变化 - SRTT + RTTVAR -> RTO - 名词解释 - RTT sample：一次测得的 RTT（从发出某段到收到它对应 ACK 的时间） - SRTT (Smoothed RTT)：平滑后的 RTT 均值。 - RTTVAR：RTT 的波动。 - RTO = SRTT + 4 * RTTVAR - SRTT 给出正常情况下 ACK 来回要多久 - RTTVAR 给出不确定性有多大 - 乘以 4 是给一个安全幅度：抖动越大，RTO 增长越明显，避免误重传 - 指数退避：超时一次，RTO 翻倍 - RTO 重传 vs 快速重传 - RTO 重传 - 触发：计时器到期，没等到 ACK - 特点：更“保底“，但通常更慢；而且代表网络更糟糕 - 常伴随：指数退避，cwnd 通常会大幅下降 - Fast Retransmit （快速重传） - 触发：重复 ACK - 特点：更快，更轻判拥塞 - 一半比 RTO 更温和 - 快速重传（Fast Retransmit）：收到多个重复 ACK （典型 3 个）推断某段丢失了，立即重传） - RTO 重传局限性 - 必须等待一段时间没收到 ACK 才重传 - 在 RTT 较大或 RTO 比较保守时，恢复会很慢 - 快速重传的思路 - 不等超时，利用接收端反馈的 ACK 形态更早推断丢包 - 重复 ACK - 如果接收端收到了更后面的段，但是缺了中间某段 - 不能把乱序段交付给应用 - 会继续发送同一个累计 ACK，告诉发送端还在等从 1000 开始的那段，后面来的我先缓存 - ACK 值没前进，但又反复出现的 ACK 就是重复 ACK - 3 个重复 ACK 会触发快速重传 - 收到 3 个重复 ACK 代表某段大概率丢了 - 立即重传缺口对应的最早未确认段 - 快恢复 - 原因 - 收到快重传代表完了给没有完全堵死（还能持续收到 ACK） - 不必像 RTO 那样极度保守把发送速率打到很低 - Reno 直觉 - 触发快速重传后，认为发生拥塞 -> 降低 cwnd - 但利用重复 ACK 的到来，允许发送端在恢复期间适度继续发，避免完全停摆 - 当收到新的 ACK 后，退出快恢复，回到拥塞避免阶段 - SACK（选择确认） - 痛点：累计 ACK 信息不够 - 当出现丢包 + 乱序到达时，累计 ACK 只能不断重复同一个 ACK=N，发送端只知道缺口在 N，不知道 - 后面哪些段已经到了 - 究竟丢失了几段，丢失了哪几段 - 重传时是否把已到达的也重传 - 目标是把接收端实际收到的乱序块显式告诉发送端 - SACK 是什么：在 ACK 里带已收到的区间块 - SACK 是 TCP 的一个 Option，启用后 - 接收端在 ACK 报文的 TCP Options 中携带若干个 SACK blocks - 每个 block 描述一个已经收到的连续字节区间 - SACK block 的语义 - SACK block = (Left Edge, Right Edge) - 表示接收端已经收到：[LeftEdge, RightEdge) 这个区间 - ACK 字段仍然存在，表示最左侧连续已收前缀的下一个期待序号 - 启用流程：SACK Permitted - SACK 需要在三次握手时协商 - 双方在 SYN/SYN+ACK 中携带 SACK Permitted 选项 - 只要双方都声明支持，后续才会在 ACK 中携带 SACK blocks - 乱序与重排 - 网络层可能乱序，TCP 负责在接收端按序交付给应用 - 接收端会缓存乱序段，等缺口补齐再交付 - 滑动窗口 - 痛点 - 如果每发一段就必须等 ACK 再发下一段，吞吐会被 RTT 严重限制：链路大部分时间在等回音。 - 滑动窗口允许发送端在未收到 ACK 前，先发出一批数据，让数据在路上飞，从而把链路利用起来。 - 窗口 = 允许在途未确认数据的上限；窗口越大，在高 RTT 链路上容易跑满带宽 - rwnd（receive window，接收窗口，流量控制） - 由接收端通告（在 TCP 头的 Window 字段里） - 表示接收端缓冲区还剩多少空间 - 目的：防止发送端把接收端内存撑爆 - cwnd（congestion window，拥塞窗口，拥塞控制） - 由发送端维护 - 表示发送端认为网络当前能够承受的在途数据量上限 - 目的：防止把网络打爆 - swnd（send window，实际发送窗口） - 发送端真正允许“在途未确认“的上限 - 近似于 min(rwnd,cwnd) - 发送端视角：窗口如何限制发送 - 发送端维护两个关键指针 - SND.UNA：最早未确认的序号(UnACKed) - SND.NXT：下一个准备发送的序号(Next to send) - 窗口约束可以理解为： - 允许发送的序号范围：[SND.UNA, SND.UNA + swnd) - 已发送未确认的范围：[SND.UNA, SND.NXT) - 还能继续发送的额度：swnd - (SND.NXT - SND.UNA) - ACK 到来时发生什么 - 收到 ACK，把 SND.UNA 往前推进 - 已确认数据从窗口左边滑出 - 窗口右边腾出了空间，允许继续发送新的数据 - 接收端视角：为什么会出现 dupACK/乱序缓存 - 接收端维护两个关键指针 - RCV.NXT：下一段按序期望的序号 - 接收缓冲：可以暂存乱序到达的段 - 出现乱序 - 接收端会缓存后到的段，但 ACK 仍然回 RCV.NXT（累计 ACK） - 发送端看到重复 ACK (dupACK)，可能触发快速重传 - 窗口、吞吐、RTT - 吞吐上限 = 窗口大小/RTT - RTT=100ms，窗口=64KB，吞吐=64KB/0.1s=640KB/s - BDP（带宽-时延积），窗口需要=BDP 才能跑满带宽 - 表示一条网络路径在任意时刻在路上飞着的数据量大概有多少，也叫管道容量 - BDP = 带宽 * 往返时延 (RTT) - 想要把链路跑满，发送端需要让“在途未确认数据“接近 BDP - 在途未确认数据主要受窗口限制：in_flight <= min(cwnd, rwnd) - 要跑满带宽，需要窗口大小 >= BDP - 零窗口与窗口探测 - 如果接收端缓冲满了，会通告 rwnd=0 - 发送端此时必须停止发送新数据，但是要避免死锁 - TCP 有 persist timer：周期性发送 Zero Window Probe 探测包 - 一旦接收窗口恢复，发送端继续发 - 粘包/拆包 - 粘包：在发送端 send() 了两条业务消息，接收端一次 recv() 读到了两条合在一起的字节。 - 拆包：在发送端 send() 了一条业务消息，接收端需要 recv() 多次才能读完 - TCP 不保证 send 一次就对应端 recv 一次 - 原因 - TCP 的抽象是流 - 像读文件一样读一串字节 - send()：把字节追加到发送缓冲区 - recv()：从接收缓冲区取走当前可读的字节 - 分段由 TCP 决定，不由应用决定 - 接收端读取粒度由应用决定 - 解法 - 在应用层定义消息边界 - 长度前缀（Length-Prefixed，最通用） - 格式 | 4-byte length (big-endian) | payload bytes... | - length 表示 payload 长度 - 接收端先读满 4 字节得到 length，再继续读满 length 字节 - 分隔符（Delimiter-Based，适合文本协议） - 行协议：以 \r\n 结尾 - 固定长度（Fixed-Size） - 每条消息固定 N 字节 - 拥塞控制 - 拥塞不是对端瘦不下，那是流量控制 rwnd，拥塞是网络路径上的队列/链路承载不住 - 路由器/交换机队列堆积 -> RTT - 队列溢出 -> 丢包 - 丢包/排队抖动 -> 吞吐下降、延迟暴涨 - 拥塞控制控制的是发送端允许在网络中飞着的未确认数量，cwnd - Reno 的两个核心状态变量 - cwnd：拥塞窗口（发送端认为网络现在能承受的在途数据量） - ssthresh：慢启动阈值，决定从指数增长到线性增长的分界点 - 四个阶段 - 慢启动 - 目的：刚开始不知道网络能承受多少，先快速试探 - 规则： - 初始 cwnd 为一个较小值，历史是 1MSS - 每收到一个 ACK，cwnd 增加 1MSS - 因为一个 RTT 内会收到大约 cwnd/MSS 个 ACK，所以每个 RTT cwnd 近似翻倍 - 每 RTT 把在路上的包数翻倍，迅速逼近瓶颈带宽 - 太快可能把队列灌满，引发丢包 - 拥塞避免 - 当 cwnd 到达或超过 ssthresh，从慢启动切换到拥塞避免 - 每 RTT 让 cwnd 大约增加 1 MSS，每个 ACK 增加 MSS*MSS/cwnd - 大多数时间连接处于的阶段 - 快重传：用 dupACK 提前判断丢包，不等 RTO - 触发条件 - 收到 3 个重复 ACK dupACK - ACK 号不前进，连续出现多次 - 快恢复：丢包后减速但不中断，比 RTO 温和 - 发生快重传后的关键动作 - 设定新的值 - ssthresh = cwnd/2 - cwnd 不回到很小，而是进入快恢复逻辑 - 当收到能够推进 ACK 的新 ACK，退出快恢复，进入拥塞避免 - RTO vs dupACK - RTO：最严重，认为网络可能很糟 - ssthresh = cwnd / 2 - cwnd 下降到很小，经典是 1MSS - 回到慢启动（重新探测） - RTO 通常会指数退避，导致恢复更慢 HTTP 与 Web 体系# - HTTP 与 Web 体系 - HTTP 基础语义 - HTTP 是无状态应用层协议：每个请求都自包含信息，状态由 Cookie/Token/Session 等机制在应用层实现 - HTTP 定义的语义，具体传输方式由 HTTP/1.1、HTTP/2、HTTP/3 决定 - 方法：语义 + 幂等 + 安全性 - GET：获取资源，应当安全+幂等 - HEAD：只要响应头，不要响应体，用作探测/缓存探测 - POST：提交数据，创建子资源或触发动作，通常非幂等 - PUT：整体替换/创建指定资源，通常幂等 - PATCH：部分更新，是否幂等取决于语义设计 - DELETE：删除资源，通常幂等 - OPTIONS：探测服务器能力（常用于 CORS 预检） - 状态码 - 1xx：信息（少见） - 2xx：成功 - 200 OK - 201 Created 创建成功 - 204 No Content 成功但无响应体 - 3xx：重定向 - 301 永久 - 302 临时(历史语义混乱) - 303 让客户端用 GET 拿 - 307/308 保持方法不变 - 4xx：客户端错误 - 400 参数/格式问题 - 401 需要认证 - 403 拒绝 - 404 不存在 - 409 冲突 - 429 限流 - 5xx：服务器错误 - 500、502 上游坏/网关问题 - 503 不可用 - 504 上游超时 - Header - 通用与内容相关 - Content-Type：实体类型（json/html...） - Content-Length：长度（HTTP/1.1 重要） - Content-Encoding：gzip/br 等压缩 - Accept/Accept-Encoding/Accept-Language：内容协商 - Host：HTTP/1.1 必须（虚拟主机） - Connect：连接管理（HTTP/2 中不再使用） - 会话与安全 - Cookie/Set-Cookie - Authorization (Bearer/Basic 等) - Origin/Refer：CORS/CSRF 相关 - Strict-Transport-Security：强制 HTTPS - Content-Security-Policy(CSP)：前端安全策略 - 缓存相关 - Cahce-Control - Expires - ETag/If-None-Match - Last-Modified/If-Modified-Since - Vary - Age （代理缓存的年龄） - Pragma：no-cache （历史兼容） - HTTP 缓存 - 两类缓存：强缓存vs协商缓存 - 强缓存 - 命中强缓存时浏览器直接用本地缓存，不走网络 - 典型控制 - Cache-Control: max-age= - Expires：老机制 - 协商缓存（发请求但可能不下载） - 浏览器发请求带校验文件，服务器判断资源是否变化 - ETag 流程 - 响应：ETag: "xxx" - 下次请求：If-None-Match: "xxx" - 若未变：返回 304 Not Modified - Last-Modified 流程 - 响应：Last-Modified: ... - 下次请求：If-Modified-Since：... - 未变：304 - Cache-Control 关键指令 - max-age=N：资源在 N 秒内视为新鲜（强缓存） - no-store：绝对不缓存 - no-cache：可以缓存，但每次使用前必须去服务器验证 - must-revalidate：过期后必须验证，不能用陈旧副本 - public：允许被共享缓存（CDN/代理）缓存 - private：只允许浏览器私有缓存，不允许共享缓存缓存 - s-maxage=N：给共享缓存的 max-age - Vary 存储维度的分桶键 - Vary 告诉缓存，同一个 URL 的响应会因为某些请求头不同而不同 - Vary：Accept-Encoding，gzip/br 不同版本要分开缓存 - Vary：Origin：CORS 常见 - Vary 过多会让缓存碎片化，命中率下降 - ETag 的强弱、代理与一致性 - 强 ETag：字节级一致才算命中 - 若 ETag (W/)：语义上等价即可 - HTTP/1.1：连接、报文、队头阻塞 - HTTP/1.1 报文与传输 - 文本协议：请求行 + 头 + 空行 + body - 连接默认与持久化：Keep-Alive （减少握手成本） - Chunked Transfer-Encoding：服务端可流式传输，不提前知道 Content-Length - HTTP/1.1 的性能问题：应用层 HOL - 同一连接上请求/响应按顺序进行 - 一个慢请求会阻塞后续的请求（队头阻塞） - HTTP/2：二进制分帧与多路复用 - HTTP/2 为什么快 - 二进制分帧：把大消息拆成帧 - 多路复用：多个 stream 在同一 TCP 连接上并发交错传输 - 头部压缩：HPACK（减少重复头部开销） - HTTP/2 性能问题：TCP 层 HOL(队头阻塞) - TCP 一旦丢包，需要重传并按序交付 - 丢的那段之前的洞补不上，后续数据即使到了也不能交给上层 - 结果：一个丢包会让同连接上所有 stream 都受影响 - HTTP/3/QUIC - 核心变化 - HTTP/3 跑在 QUIC 上，QUIC 基于 UDP - QUIC 自己实现可靠传输与拥塞控制 - 按 stream 提供独立的有序交付，一个 stream 丢包不影响其他 stream 的交付 - TLS 与 HTTPS - 位置与成本 - HTTPS = TCP 建连后再 TLS 握手，再 HTTP - 首次访问慢常见原因：DNS + TCP + TLS 多次 RTT - 解决的问题 - 身份认证：验证连接的是域名的真实服务器 - 机密性：传输内容加密 - 完整性：防篡改 - TLS 握手 - TLS 1.2 - ClientHello：客户端支持的版本/套件，随机数，SNI 等 - ServerHello：选定版本/套件、随机数，让双方对本次会话参数单程一致 - Certificate：服务器发送证书链，客户端据此验证：链是否可信、域名是否匹配、是否过期，用途是否正确 - ServerKeyExchange：服务器提供 ECDHE 参数与公钥，客户端通过验证签名，确保密钥协商参数的安全性 - ServerHelloDone：告诉客户端，材料已经发完 - ClientKeyExchange：客户端协商参数，客户端发送自己的 ECDHE 公钥，双方据此计算共享 secret - ChangeCipherSpec + Finished：双方切换到加密通信并校验握手完整性 - Web 会话：Cookie/Session/Token - Web 会话解决的问题 - 认证：你是谁 - 授权：你能做什么 - 会话保持：登录态怎么持续、怎么过期、怎么注销 - 安全边界：防窃取、防伪造、防重放、防跨站 - Cookie：浏览器自动携带的会话容器 - Cookie 是浏览器保存的一组 key=value，由服务器通过响应头 Set-Cookie 下发。 - 后续请求中，浏览器会按照规则自动带上 Cookie 头，无需 JS 参与 - Cookie 关键属性 - Domain/Path：决定发送范围 - Domain=example.con：子域也可能携带 - 不设置 Domain：仅当前 host - Path=/api：只对当前路径生效 - Expires/Max-age：决定生命周期 - Max-Age=0：立即删除 - Session Cookie：不设过期时间，随浏览器进程结束而清理 - Secure：只在 HTTPS 发送 - HttpOnly：禁止 JS 读取 - 有 HttpOnly 的 cookie，JS 读取不到 - 不能防止 CSRF - SameSite：控制跨站请求是否携带 - Strict：几乎不跨站携带 - Lax：默认常用 - None：允许跨站携带，必须同时设置 Secure - Session：服务端保存状态，客户端只存门票 - Session 的典型模式 - 服务端维护 session_id -> session_data - 客户端用 Cookie 存 session_id - 每次请求：浏览器自动带 cookie -> 服务端查 session store -> 识别用户 - Token（尤其是 JWT）：把身份证明带在请求里 - Token 的核心模式 - 服务端签发 token 给客户端 - 客户端后续请求带 token - 服务端验证 token 来识别用户 - JWT 结构 - JWT=header.payload.signature - header：算法等元信息 - payload：claims 声明 - signature：服务端用密钥签名 - Refresh Token 与 Access Token - Access Token：短有效期，每次用于请求 - Refresh Token：长有效期，用于换取新的 Access Token - 安全边界：XSS、CSRF、会话固定、重放 - XSS（跨站脚本） - 若 token/cookie 可以被 JS 读取，xss 可以直接窃取并盗用 - cookie 用 HttpOnly + Secure - CSP 减少脚本注入 - 输入输出编码 + 模板转义 - CSRF 跨站请求伪造 - CSRF 利用浏览器自动携带 cookie - 攻击者诱导用户在登录态下访问恶意页面，发起跨站请求到受害站点 - 防护手段 - SameSite Cookie （优先） - CSRF Token（表单/请求头携带，服务端校验） - 检查 Origin/Rerfer - 同源策略与 CORS - 痛点 - 浏览器安全模型默认假设：不同站点之间互不信任 - 浏览器用同源策略（Same-Origin Policy，SOP）限制一个网页脚本能读取另一个来源的资源内容 - 业务需要跨域调用 API，有了 CORS（CrossOrigin Resource Sharing）：在 SOP 的基础上提供一个受控的放行机制。 - Orgin 源是什么：同源的三元组 - Origin = scheme + host + port - https://example.com:443 - 同源策略具体限制 - 跨源读被禁止 - JS 用 fetch 请求 https://xxx.com，请求可能能发出去，但是浏览器会阻止 JS 读取响应，除非响应满足 CORS 规则 - 跨源写/发送很多情况下是允许的 - <form action="xxx.com" method="POST"> 可以提交，因此 CSRF 能成立，请求可以发出去，但是页面读取不到 bank.com 的响应内容 - 部分资源加载天然跨源允许 - <img> <scirpt> <link> 浏览器允许加载这些资源 - CORS 本质：服务器声明允许，浏览器执行拦截 - 浏览器在请求带上 Origin - 服务器在响应返回 Access-Control-* 头 - 浏览器据此决定：是否把响应暴露给 JS - CORS 两种请求路径：简单请求 vs 预检请求 - 简单请求 - 方法是 GET/HEAD/POST - Content-Type 只能是三种之一 - application/x-www-form-urlencoded - multipart/form-data - text/plain - 请求头只能是 CORS-safelistedhead，不能随意加自定义头 - 预检请求 - 不满足简单请求条件，浏览器会先发送一个 OPTIONS 请求，询问服务器是否允许 - 预检请求携带关键头 - Origin: https://a.com - Access-Control-Request-Method：PUT - Access-Control-Request-Headers：x-token（将要携带的自定义头列表） - 服务器如果允许，需要在 OPTIONS 响应返回 - Access-Control-Allow-Origin - Access-Control-Allow-Methods - Access-Control-Allow-Headers - Access-Control-Max-Age（预检缓存多久） - 通过后，浏览器才会发真实请求 - CORS 响应头：每个头怎么用 - Access-Control-Allow-Origin - 指定允许的 Origin - 可以是精确 Origin 或者 * （允许任意源），如果要带 Cookie/凭证，不能用 * - Access-Control-Allow-Methods - 允许的方法列表：GET/POST - 主要用于预检响应 - Access-Control-Allow-Headers - 允许的自定义请求头列表 - 必须覆盖预检中 Access-Control-Request-Headers 请求到的那些头 - Access-Control-Allow-Credentials - true 表示允许携带凭证，例如 Cookie - 配合前端请求 credentials: 'include' - Access-Control-Expose-Headers - 默认情况下，JS 能够读取的响应头很有限，如果希望暴露，必须显式添加 - Vary: Origin - 按 Origin 分桶缓存 - DNS 解析 - 基础对象 - 记录类型 - A(IPv4) - AAAA(IPv6) - CNAME(别名) - NS(权威) - 解析角色 - Stub resolver（客户端/OS） - Recursive resolver（递归解析器：运营商/公司 DNS/公共 DNS） - Authoritative server （权威 DNS） - 正向代理、反向代理、透明代理与隧道 - 代理：本质上是位于客户端与服务端之间的一种中间节点，代表一侧发起连接、转发数据、并可能施加策略 - 承担职责 - 路由/转发：把请求送到正确上游 - 安全控制：鉴权、WAF、访问控制 - 性能优化：连接复用、压缩、缓存、限流 - 可观测性：日志、指标、追踪、采样 - 协议转换：HTTP <-> grpc 等 - 正向代理 - 正向代理站在客户端一侧，客户端明确知道自己在用代理，由代理代表客户端访问外部资源 - 反向代理 - 反向代理站在服务端一侧，对外它像真正的服务器入口，对内把请求转发到后端服务 - 反向代理常用原因 - 隐藏后端拓扑：外部只有一个入口 - 统一 TLS 终止：证书集中管理 - 统一流量治理：限流、熔断、灰度、路由、鉴权 - 连接复用：对外维持大量连接、对内复用少量连接 - 观测与审计：同一日志/指标/链路追踪 - 透明代理 - 隧道：Connect 到底干了什么 - 隧道：代理不解析上层协议，只做字节透传。 - HTTP Connect 隧道流程 - 客户端先对代理发 CONNECT - 客户端 -> 代理 - CONNECT bank.com:443 HTTP/1.1 - Host: back.com:443 - 代理建立到目标的 TCP 连接 - 代理 -> bank.com:443：发起 TCP 连接 - 代理回客户端 - HTTP/1.1 200 Connect Established - 隧道建立，字节透传 - 客户端与 bank.com 的 TLS 握手数据会被原封不动地通过代理转发，代理看不懂也不需要看懂 - TLS 会话在客户端<->目标服务器之间建立 - 负载均衡：L4 vs L7、算法、会话保持、健康检查 - 目标 - 扩展性：把流量分散到多台实例，提高吞吐 - 高可用：实例故障自动摘除，流量不中断或快速恢复 - 性能：就近、减少重连、减少排队、提升尾延迟 - 治理：灰度、限流、熔断、路由、可观测 - 边界 - LB 解决的是把请求推送到谁，不解决业务正确性 - LB 层任何自动重试/超时，都可能改变业务语义 - L4 与 L7 的区别 - L4 LB（传输层）：基于 IP/端口/连接做转发 - 优点：性能高，对协议透明 - 缺点：无法基于 URL/Header 做路由 - 常见实现：内核转发、四层 VIP、DSR、NAT 模式等 - 适合长连接：WebSocket、MQ、数据库连接等 - L7 LB（应用层）：理解 HTTP，按照 Host/Path/Header/Cookie 路由 - 常见常见：API Gateway、Ingress、CDN 回源入口 - 负载均衡算法 - Round Robin（轮询） - 依次分发到每个后端 - 适合：请求耗时相近、后端同质、短连接 - 问题 - 后端性能差异大时不均衡 - 长连接场景下连接一旦分配就会粘住，RR 也会失衡 - Weighted Round Robin - 按权重分配（机器规格不同，冷热分层） - 适合：异构机器，逐步扩容 - 问题：权重需要维护；负载时间随时间变化时仍然不准 - Least Connections（最少连接） - 连接数最少的后端连接 - 适合：长连接、连接数与负载相关的业务 - 问题： - 连接数不等于负载 - 需要 LB 维护连接计数状态 - Least Request/Least Load（最少请求/最小负载） - 按当前活跃请求数或综合指标选择 - 适合：请求耗时差异大，尾延迟敏感 - 问题：实现复杂、依赖观测准确性；指标延迟可能导致震荡 - Random/Power of Two Choices（随机/二选一） - 随机挑两个后端，选最优者 - 优点：简单且实际效果接近最优，分布更稳定，大规模下能显著降低热点概率 - 适合：大规模集群、需要避免中心化状态 - Consistent Hash（一致性 hash） - 按 key 映射到固定节点 - 适合： - 需要缓存命中（本地 cache） - 会话保持（不想引入共享 session） - 分片存储（按 key 分片） - 关键性质：节点增减时迁移量小 - 问题： - 热点 key 会压垮单节点（热点拆分/虚拟节点） - 节点故障时 key 重映射会引发抖动。 - 会话保持 - 为什么需要 sticky - 后端有状态 - 本地缓存必须命中 - WebSocket/长连接绑定到某实例 - 常见 sticky 手段 - Source IP hash - 按客户端 IP 做 hash 选节点 - 优点：简单 - 缺点： - NAT/代理下大量用户共享同一出口 IP -> 严重倾斜 - 用户换网 IP 变化导致漂移 - Cookie 粘性 - LB 注入 cookie ，后续按照 cookie 路由 - 优点：比 IP 稳定 - 缺点：跨域，隐私策略，cookie 清理，灰度/回源复杂 - 一致性哈希（按 userId/会话键） - 工程风险 - 降低容错：节点挂了，该节点的用户都受影响 - 产生热点：某些用户/租户流量大->单节点热 - 扩缩容抖动：重新分配导致缓存冷启动、延迟尖刺 - 推荐的替代方案 - 应用无状态 + 共享 session (Redis) - 把状态外置(DB/Cache)，实例可以随时替换 - 长连接常见：连接层 sticky 不可避免，要做好限流与迁移策略 - 健康检查 - L4 健康检查 - 探测 TCP 能否 connect 成功 - 优点：便宜、通用 - 缺点：应用假活时仍然会通过（线程池满、依赖挂） - L7 健康检查 - 请求 /healthz 或 /readyz - 可检查 - 进程存活 - 是否可接新流量 - 关键依赖是否可用 - 设计要点 - liveness vs readliness 分离 - liveness：进程是否需要重启 - readliness：是否接流量 - 避免健康检查过重 - 如果每秒大量探测并且检查依赖，会把依赖也打挂 - 阈值与抖动控制 - 连续 N 次失败才摘除 - 连续 M 次成功才恢复 - 慢启动与预热 - 新实例启动后先不接流量，预热缓存/JIT，再标 ready - 网络排障 - L3/L4 基础联通与路径 - ping - 测试的是什么 - ping 用的是 ICMP Echo Request/Echo Reply - 发 Echo Request（带序号 seq、时间戳等） - 对端回 Echo Reply - 测量往返时延 RTT -  - 查看延迟 - 看 avg 和 min/max - 抖动 - RTT 的波动程度 - stddev（标准差） 大，说明网络队列/无线/拥塞波动明显 - 丢包 - packet loss > 0 说明有包没有收到回包 - tracerout/mtr 的原理 - traceroute：用 TTL 把路径探测出来 - IP 包里有 TTL，每过一跳路由器把 TTL - 1 - 当 TTL 变为 0，路由器丢包并回 ICMP Time Exceeded - traceroute 依次发 TTL=1,2,3 的探测包 - 可以看到每一跳的地址与该跳的 RTT - 每一跳显式的 RTT 是你->该跳->你的往返，不是单程，也不是该跳->下一跳的延迟 - mtr：traceroute + ping 的结合 - mtr 会对每一跳持续发探测包并统计 - 丢包率 - 最快/平均/最慢 RTT - 抖动 - mtr 更适合定位抖动/偶发丢包/拥塞点 - 用 traceroute 看路径与绕路 -