性能 · XB 现场笔记

巨型页用灵活性换更少的 TLB 缺失

Tue, 21 Dec 2027 00:00:00 +0000

数据库及高吞吐服务往往因此受益，但要背负需要连续内存、池子要预先算好大小的成本——这是一笔架构账，不是免费的。

为什么 4 KB 会吃亏

默认页是 4 KiB,TLB 能容纳的条目又很有限。管理百万级工作集的大型应用,很容易在访问一个页面时就 miss 掉一个 TLB 表项,于是不得不到页表里去翻。这里的成本不是页本身,而是反复的页表遍历;一旦工作集的错杀超过 TLB 回填的速度,大应用就会明显吃到痛。更大的页让每条表项覆盖更多内存,同样大小的工作集约只需要很少的表项,这正是吃内存沉重的负载最需要的缓解。

hugetlb 与 THP 的区别

想要大页有两条路。hugetlb 让你从一块预留的内存里自己分配,页的大小是确定的(常见 2 MiB 或更大),行为可预期、由你掌控;transparent(THP)则在后台自动把映射整合成大页,省心,却可能在某些负载上带来延迟尖峰、碎片与写时复制的问题。对延迟敏感的业务,hugetlb 让你自己抱住那份池和那份 trade-off,而不是把决定权丢给一个你不知道用不用得着的通用策略。选哪条路,其实是在决定「可预测性由谁掌握」——你,还是内核。

池子要提前量

大页的真正收益,建立在它被真用满、并且真的常驻内存的前提上。一页 2 MiB 若只用了很小一部分,却仍占着一个整页表项,被锁住的那块内存就等同于浪费,而池子到底定多大,才是真正的功夫。给池子只留那份最诚实、最稳定使用的内存,而不是凭感觉很轻率地划一大块,并要为「稀疏大页」附带的多占 RAM 留出余量。当这些都成立——页被用满、工作集收得小、居住集成一两个表项——大页的收益才完整兑现;要是把它喂给几乎填不满的负载,那就只是一笔平白消耗。

坏掉的样子

池子给小了，失败多在启动瞬间。数据库要的共享缓冲超过预留大页能覆盖的范围，进程会直接退出，常见报错是无法分配内存；此时系统空闲内存可能还很充足，容易误判。关键是显式大页不能自动回退到小页，缺几页就是缺几页。做法是按应用文档的需求加少量余量定池子，重启后核对总页数与已预留数，而不是只看启动参数。

启动正常、运行中分配失败，多半是碎片。大页要求物理连续的整块区间，机器跑久之后，空闲总量充足，却拼不出完整区间，新映射会被拒绝。典型信号是空闲大页数停在大于零不再下降，同时内核日志出现大页分配失败；此时重试映射没有意义，应回到启动阶段预留或用启动参数固定池子。

更隐蔽的是位置放错与自动整理。池子落在远端节点上，每次命中都要跨互联访问，省下的表项优势会被延迟吃掉，绑定前要先看分节点分布。透明大页则是另一种风险：后台整理与写时复制拆分会把平稳的尾延迟打成尖峰，从合并等待与整理线程占用能看到痕迹。延迟敏感服务建议设为按需启用，只在实测有效的地方打开。

快速验证

下面脚本只读内存信息与系统页大小，不做任何分配，也不需要特权，因此在无特权容器里同样可直接运行。若环境没有内存信息文件或不支持大页，它会打印跳过提示并继续给出页表项换算，而不是抛异常退出。

把下面代码保存为大页检查脚本并运行，即可看到本机覆盖率与固定工作集的表项对比。脚本先解析总页数、空闲数、已预留数、溢出数与单页大小，算出预留覆盖总量；再用系统调用得到的基准页大小，对比同样工作集在基准页与大页下各需多少表项，估算省下的数量。

#!/usr/bin/env python3
"""Report hugepage coverage and estimated TLB entries saved (read-only)."""
import os
import re
from pathlib import Path

WORKING_SET_BYTES = 8 * 1024**3 # 8 GiB example working set

def parse_meminfo(text):
 vals = {}
 for key in ("HugePages_Total", "HugePages_Free", "HugePages_Rsvd",
 "HugePages_Surp", "Hugepagesize"):
 m = re.search(r"^" + key + r":\s+(\d+)", text, re.M)
 if m:
 vals[key] = int(m.group(1))
 return vals

def main():
 vals = {}
 try:
 text = Path("/proc/meminfo").read_text(encoding="utf-8")
 except OSError as exc:
 print(f"SKIP: /proc/meminfo unavailable ({exc}); showing page-table math only")
 text = ""
 if text:
 try:
 vals = parse_meminfo(text)
 if "HugePages_Total" not in vals or "Hugepagesize" not in vals:
 print("SKIP: no HugePages fields in /proc/meminfo (hugepages unsupported or disabled)")
 else:
 size_kb = vals["Hugepagesize"]
 total = vals["HugePages_Total"]
 free = vals.get("HugePages_Free", 0)
 rsvd = vals.get("HugePages_Rsvd", 0)
 surp = vals.get("HugePages_Surp", 0)
 cov_mb = total * size_kb / 1024
 print(f"Hugepagesize: {size_kb} kB")
 print(f"HugePages total/free/rsvd/surp: {total}/{free}/{rsvd}/{surp}")
 print(f"Reserved coverage: {cov_mb:.1f} MiB ({cov_mb/1024:.2f} GiB)")
 except Exception as exc:
 print(f"SKIP: failed to parse /proc/meminfo ({exc})")
 try:
 base = os.sysconf("SC_PAGE_SIZE")
 except (AttributeError, ValueError, OSError):
 base = 4096
 huge = vals.get("Hugepagesize", 2048) * 1024
 base_entries = WORKING_SET_BYTES // base
 huge_entries = WORKING_SET_BYTES // huge
 print(f"Base page size (sysconf): {base} bytes")
 print(f"8 GiB needs ~{base_entries} base-page entries vs ~{huge_entries} huge-page entries")
 print(f"Estimated TLB entries saved: ~{base_entries - huge_entries}")

if __name__ == "__main__":
 main()

在支持大页的系统上，预期能看到单页大小、各类计数与预留覆盖容量，以及两种粒度各自的表项数和节省量；在笔记本或极简容器里，则先看到一行跳过提示，再看到同样的表项换算，且本地基准页可能不是常见的四千字节。该脚本已在缺少内存信息文件的环境验证通过。它只衡量预留量与潜在节省，不能证明真实缺失下降、碎片或节点距离，调池子前还要用内核日志、分节点计数与延迟分位交叉确认。

来源

内核巨型页文档，定义 hugetlb 设置与行为，已核验 2026-06-01。
内核透明巨型页文档，定义 THP 模式与后台整理行为，已核验 2026-06-01。

Cache-Control 是缓存与源站之间的约定

Mon, 20 Dec 2027 00:00:00 +0000

缓存策略需要行为测试，而不只是检查头部是否存在。两个响应即使都带 max-age，也可能因为其中一个要求验证、另一个禁止存储而表现不同。请求本身同样影响结果：浏览器可以绕过已有副本，却不修改源站的响应策略，也不删除更早保存的缓存条目。要知道用户真正拿到什么，必须观察完整的重复请求过程。

双方都要读同一份约定

Cache-Control 指令具有方向性。请求指令不会自动复制到响应里，RFC 9111 还明确将请求指令描述为建议性的要求；响应指令则约束遵守协议的缓存。中间层即使自己不实现缓存，也必须在转发中保留相应缓存指令。部署配置可能另有覆盖规则，但“代理按自己的配置做了”不等于已经证明源站声明的策略得到执行。

应拆开三个问题：这条响应能否存储，当前年龄是否仍在适用的新鲜度寿命内，这次请求是否允许不经验证直接复用。no-store 禁止 HTTP 缓存存储；no-cache 允许存储，但复用前必须成功验证。max-age 设定新鲜度，must-revalidate 则禁止响应过期后未经验证就复用。响应仍然新鲜时，must-revalidate 本身并不要求每次回源，不能把它误解成 no-cache。

private 将存储限制到单用户缓存，public 在其他条件允许时明确授予缓存许可，并不是每一条可缓存响应都必须写 public。s-maxage 覆盖共享缓存的新鲜度，不适用于浏览器私有缓存。Vary 则提供请求匹配维度。这些机制都不会识别应用当前登录的是哪个账户，也不会因为有效期很短，就自动让个人数据变得适合共享。

坏掉的样子

测试时每次添加新的查询参数，会改变缓存键，可能完全掩盖原本的复用行为。在开发者工具中禁用缓存，也可能造成相同误判；某些自动化请求拦截机制同样会禁用 HTTP 缓存。有效测试应在一个隔离上下文中重复访问完全相同的网址，一边统计源站实际收到的请求，一边断言返回正文，而不是仅凭页面看起来没变化就判断命中。

Fetch 的 cache 选项属于浏览器接口，不是响应头。它的 no-store 模式跳过缓存查找，也不把新响应写回 HTTP 缓存；reload 跳过查找，但可以更新缓存。两者都不等于抹除全部旧副本。源站修改响应头，也不能迫使尚未过期的条目立刻回源。浏览器历史恢复、Service Worker 自行保存的内容又是其他机制，不属于下面实验的覆盖范围。

no-cache 也不保证获得 304。只有存在合适的验证器，并且所选表示仍然有效，才有机会节省正文传输。没有 ETag 或 Last-Modified 时，每次访问可能仍返回完整的 200 响应。因此要同时测量回源次数和传输正文，不能看到“每次都请求了源站”就认为重验证一定已经发挥性能收益。

快速验证

本次在 macOS 上使用 Node 26.0.0、Playwright 1.63.0 及其配套 Chromium 153.0.8010.12 无头浏览器验证。将依赖装入临时目录；Linux 还需具备 Playwright 文档要求的浏览器系统依赖。下载需要联网。使用 NODE_PATH="$cache_browser_lab/node_modules" PLAYWRIGHT_BROWSERS_PATH="$cache_browser_lab/browsers" node 执行 JavaScript，测试请求只访问自动分配的回环端口，不使用现有浏览器配置。

cache_browser_lab=$(mktemp -d)
npm install --prefix "$cache_browser_lab" --ignore-scripts --no-audit --no-fund --package-lock=false playwright@1.63.0
PLAYWRIGHT_BROWSERS_PATH="$cache_browser_lab/browsers" node "$cache_browser_lab/node_modules/playwright/cli.js" install chromium --only-shell --no-remove

const assert = require("node:assert/strict");
const http = require("node:http");
const { once } = require("node:events");
const { chromium } = require("playwright");

const policies = new Map([
 ["/fresh", "max-age=3600"],
 ["/must", "max-age=3600, must-revalidate"],
 ["/validate", "no-cache, max-age=3600"],
 ["/discard", "no-store, max-age=3600"],
]);
const hits = new Map();
const server = http.createServer((request, response) => {
 const route = new URL(request.url, "http://127.0.0.1").pathname;
 if (route === "/") {
 response.writeHead(200, { "Content-Type": "text/html", "Cache-Control": "no-store" });
 response.end("<!doctype html><title>Cache experiment</title>");
 } else if (policies.has(route)) {
 const count = (hits.get(route) || 0) + 1;
 hits.set(route, count);
 response.writeHead(200, {
 "Content-Type": "text/plain", "Cache-Control": policies.get(route),
 });
 response.end(`${route}:${count}`);
 } else {
 response.writeHead(404, { "Cache-Control": "no-store" });
 response.end();
 }
});

async function main() {
 server.listen(0, "127.0.0.1");
 await once(server, "listening");
 let browser;
 try {
 browser = await chromium.launch();
 console.log("Chromium", browser.version());
 const context = await browser.newContext({ serviceWorkers: "block" });
 try {
 const page = await context.newPage();
 await page.goto(`http://127.0.0.1:${server.address().port}/`);
 const read = (route, cache = "default") => page.evaluate(async ({ route, cache }) => {
 const response = await fetch(route, { cache });
 if (!response.ok) throw new Error(`HTTP ${response.status}`);
 return response.text();
 }, { route, cache });
 for (const [route, expectedHits] of [
 ["/fresh", 1], ["/must", 1], ["/validate", 2], ["/discard", 2],
 ]) {
 const first = await read(route);
 const second = await read(route);
 assert.equal(first, `${route}:1`);
 assert.equal(second, `${route}:${expectedHits}`);
 assert.equal(hits.get(route), expectedHits);
 console.log(route, "origin requests:", hits.get(route));
 }
 assert.equal(await read("/fresh", "no-store"), "/fresh:2");
 assert.equal(await read("/fresh"), "/fresh:1");
 assert.equal(hits.get("/fresh"), 2);
 assert.equal(await read("/fresh", "reload"), "/fresh:3");
 assert.equal(await read("/fresh"), "/fresh:3");
 assert.equal(hits.get("/fresh"), 3);
 console.log("no-store bypass retained version 1; reload stored version 3");
 } finally {
 await context.close();
 }
 } finally {
 if (browser) await browser.close();
 await new Promise((resolve, reject) => server.close(error => error ? reject(error) : resolve()));
 }
}

main().catch(error => { console.error(error); process.exitCode = 1; });

最初四条路由的回源次数依次为一、一、二、二。两个新鲜策略都复用第一次拿到的正文；no-cache 与 no-store 即使搭配很长的 max-age，也会再次访问源站。这里有意不提供验证器，所以回源返回的是完整正文。仅凭这些次数，不能区分 no-cache 和 no-store 的存储资格，实验也没有做出这种推断。

后续 no-store 模式取得版本二，但紧接着的普通请求仍返回先前缓存的版本一。reload 模式取得并保存版本三，下一次普通请求便复用版本三。源站计数器证明这些确实是缓存决策，不是两次响应字符串碰巧相同。最后关闭服务器和隔离浏览器上下文，不改变日常使用的浏览器状态。

这些观察只覆盖这个 Chromium HTTP 缓存和列出的请求，没有验证共享 CDN、重启后的持久化、陈旧响应或账户隔离。它们需要各自的验收。局部实验的价值在于明确客户端实际执行了什么，而不是把一次可复现的本地结果延伸成整条生产交付链都正确的结论。

来源

RFC 9111：Cache-Control，指令方向性及存储、复用要求，已核验 2026-09-07。
MDN：Request.cache，default、no-store 和 reload 行为，已核验 2026-09-07。
Playwright 浏览器上下文，隔离且非持久化的上下文，已核验 2026-09-07。
Playwright 浏览器安装，配套无头浏览器与系统依赖，已核验 2026-09-07。

EXPLAIN ANALYZE 把查询真的跑一遍

Thu, 16 Dec 2027 00:00:00 +0000

EXPLAIN 展示 PostgreSQL 的执行计划，EXPLAIN ANALYZE 还会真正执行语句并测量工作量。最有用的比较，是同一个节点的估计行数与实际行数。两者都不能单独当成结论：估计来自模型，实测则只描述特定数据、缓存、并发和插桩条件下的一次执行。不能把前者称为谎言，也不能把后者当成脱离环境的永恒事实。

先比较同一种量

计划中的 cost 是相对成本单位，不是毫秒。两个成本值分别描述启动成本与完成成本，带 LIMIT 的查询可能更重视尽早得到前几行，因此选择不同计划。actual time 才使用毫秒。即使成本和耗时恰好都打印成一百，也不能把它们直接相减或求比例；它们本来就不表示同一件事。

一个节点被重复执行时，actual rows 和节点耗时是每次循环的平均值，需要结合 loops 理解总工作量。但不能把所有节点耗时简单相加，因为父节点已经包含子节点的工作，重复相加会重复计算。并行执行时更不能用这种方式猜总延迟。先沿树看输入输出、循环次数、过滤条件和行数流向，再决定哪个位置值得调查。

BUFFERS 区分 shared、local 和临时块活动。shared hit 表示 PostgreSQL 在共享缓冲区里找到了块；shared read 只表示需要读入，操作系统仍可能从页缓存满足它，不能直接断言每次都访问了物理磁盘。临时表使用本地缓冲区，排序或哈希溢出则可能读写临时文件。父节点计数包含子节点，逐行把所有计数加起来同样会夸大 I/O。

找到有意义的估计偏差

某个选择性条件估计只返回十行，实际却返回一万行，通常值得先调查，再考虑重写其上方的连接。统计信息陈旧、分布倾斜、列间相关、参数值变化或选择性模型能力不足，都可能造成偏差。ANALYZE 可以刷新统计信息，却不能保证每个估计精确，也不会自动修好所有慢计划。先看真实数据和缺失的信息，再决定是否调整统计目标或增加扩展统计。

行数估计准确也不能证明查询高效。缺少访问路径、昂贵表达式、排序溢出、锁等待和并发争用仍可能存在。反过来，小表或需要返回大量行的查询采用顺序扫描可能正合适，不应把“没用索引”一律判为错误。分析时应保留应用实际使用的参数和查询形状，避免用一个稀有值的漂亮计划替代整个生产分布。

坏掉的样子

最危险的误解，是把 ANALYZE 当成只读预演。UPDATE 会改变行，触发器会执行，锁会被获取，SELECT 也可能调用带副作用的函数。事务末尾执行 ROLLBACK 可以恢复事务性表变化，却不能一般性撤销序列前进或外部系统副作用。对语句影响范围不确定时，应使用可丢弃的数据集，不能靠“最后会回滚”就放心在生产运行。

另一个误判来自测量本身。第一次执行会加热缓存，频繁读取时钟的成本也可能占据廉价节点的大部分时间。TIMING OFF 仍保留实际行数和整条语句的总耗时，同时避免逐节点计时。EXPLAIN 不会把普通结果集完整发送给应用，所以它不能测出传送整个响应的网络耗时。重复执行、代表性负载和应用延迟各自回答不同问题，应结合解释而不是只挑最小的毫秒值。

快速验证

用 psql 连接一个可丢弃的 PostgreSQL 18 数据库，把代码保存为 explain.sql，再运行 psql -X -v ON_ERROR_STOP=1 -f explain.sql；连接参数应明确指向实验库。这里创建的表和序列都是临时对象，最后回滚会清除它们，不需要借用已有 orders 表，也不会假定生产中存在某个字段。

\set ON_ERROR_STOP on
BEGIN;
SET LOCAL statement_timeout = '5s';
CREATE TEMP TABLE orders (id integer, status text);
INSERT INTO orders SELECT g, CASE WHEN g <= 100 THEN 'paid' ELSE 'new' END
FROM generate_series(1, 10000) AS g;
ANALYZE orders;
EXPLAIN (COSTS ON) SELECT * FROM orders WHERE status = 'paid';
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT * FROM orders WHERE status = 'paid';
CREATE TEMP SEQUENCE measured_calls;
SAVEPOINT before_measurement;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
UPDATE orders SET id = id + 10000 WHERE id <= 3;
EXPLAIN (ANALYZE, TIMING OFF) SELECT nextval('measured_calls');
ROLLBACK TO SAVEPOINT before_measurement;
SELECT count(*) AS updated_rows_after_rollback FROM orders WHERE id > 10000;
SELECT nextval('measured_calls') AS sequence_after_rollback;
DO $$ BEGIN
 IF (SELECT count(*) FROM orders WHERE status = 'paid') <> 100 THEN
 RAISE EXCEPTION 'unexpected selected row count';
 END IF;
 IF EXISTS (SELECT FROM orders WHERE id > 10000) THEN
 RAISE EXCEPTION 'UPDATE was not rolled back';
 END IF;
 IF (SELECT last_value FROM measured_calls) <> 2 THEN
 RAISE EXCEPTION 'sequence advance unexpectedly rolled back';
 END IF;
END $$;
ROLLBACK;

夹具恰好包含一百条 paid 订单。实际执行的 SELECT 应显示一百行通过过滤、九千九百行被过滤。UPDATE 下方的扫描节点处理三行，但没有 RETURNING 时顶层节点返回零行；这个零不代表没有更新。回滚到保存点后，更新后的行数回到零，但下一次序列值是二，因为被测 SELECT 已经消耗了第一个值。代码为这些结果提供断言，而不是仅打印一个看似合理的计划。

在 PostgreSQL 18.6 上这些断言通过。具体计划、缓冲区计数、耗时和打印格式可以变化，稳定预期是行数、回滚效果与序列前进。五秒 statement timeout 限制本实验中单条语句的执行时间，但不会把任意生产写操作变成安全检查。临时对象和受控数据是这个实验可复现的前提，不能移除后仍声称风险相同。

来源

PostgreSQL EXPLAIN，真实执行的副作用和测量选项，已核验 2026-09-10。
PostgreSQL 使用 EXPLAIN，成本、循环次数与缓冲区解释，已核验 2026-09-10。
PostgreSQL 规划器统计信息，估计与统计模型的边界，已核验 2026-09-10。
PostgreSQL 序列函数，不随回滚撤销的序列前进，已核验 2026-09-10。

pg_stat_statements 找出最贵的查询

Sun, 12 Dec 2027 00:00:00 +0000

因为 pg_stat_statements 会把同一条查询形态的每一次执行都聚合起来，「这个页面慢」就变成了一张排好序的表。代价只是一行配置加一次重启；回报是你能知道上万种查询形态里，到底是哪一种在占用时钟。

真正重要的决定只有一个：按哪一列排序。按平均耗时排，只是把慢日志已经告诉过你的事再说一遍；按总耗时排，才能找出那个一直悄悄吃掉数据库四分之一时间的查询。

先归一化，再聚合

这个扩展并不原样保存你的 SQL。常量会被折叠成参数符号，于是 WHERE tenant_id = 42 和 WHERE tenant_id = 8712 合并成同一条记录，展示出来的文本是第一个产生该 queryid 的查询。编号规则是位置式的——符号从当前文本里最大 $n 的下一个数字开始，所以 PL/pgSQL 里的 SELECT i + 1 INTO j 会显示成 SELECT i + $2。列表的行为一样：只差 IN 元素个数的两条查询会被压成 IN ($1 /*, ... */)，调用次数记为 2。

效果很夸张。一份建模负载里 1420052 次执行、每次字面量都不同，最后塌缩成 6 行——平均每行统计代表 236675 条原始语句。随之而来的有两点注意：queryid 是对解析后语法树做的哈希，所以 search_path 不同时，文本完全相同的查询可能落进不同记录；不相干的查询也可能碰撞进同一条；而且它并不承诺跨大版本稳定。把 queryid 当成比文本更好的标识符，而不是一个永久主键。

文档还提醒一个反向情况：当归一化没能生效时——比如条目被频繁淘汰——你会在 pg_stat_statements 里看到带着具体常量值的查询，同一种形态散成很多行。把 pg_stat_statements.max 调大可以降低这种概率，而 pg_stat_statements_info 里的淘汰计数就是判断依据。

看总耗时，不看平均耗时

真正该看的列是 calls、total_exec_time、mean_exec_time、rows 和几个块计数器。min/max/stddev_exec_time 则告诉你这条查询是一直慢还是偶尔特别长，前者指向坏计划，后者指向锁竞争。

按平均排序和按总量排序回答的是两个不同问题，而两者的差距很大。同一份负载里，平均耗时最差的那条（9689 ms，12 次调用）占总测量时间的 22.4%；总耗时最高的那条占 25.9%，但平均每次只要 0.749 ms。总耗时第一的这条查询，在任何合理的 log_min_duration_statement 下都一次也不会被记进慢日志；而总耗时前三名加起来占了全部测量时间的 65.5%。一条 0.099 ms 的查询被调用 900000 次之后，平均排名第六，总量排名第三，合计 89217 ms。

计数器只增不减，所以要按窗口比较

计数器从统计建立起就一直累积，所以历史上慢过的查询不会自己从榜首淡出。解法有两种：要么做定向重置——pg_stat_statements_reset(userid, dbid, queryid, minmax_only) 四个参数都收，你可以只清一条查询、只清一个库，或者只清 min/max 字段；要么取两个快照做增量。

块计数器值得单独读一遍。shared_blks_hit 和 shared_blks_read 是一直在统计的；track_io_timing 打开的是 *_blk_read_time 与 *_blk_write_time 这两列时间，不是那两个计数。命中率是诊断指标，不是代价：负载里命中率最高的一条（98.89%）同时也是块消耗量最大的一条，81000000 个块；而命中率最低的一条（62.22%）只搬了它的三十七分之一。

坏掉的样子

第一种失败是这个扩展根本不在。它必须写进 shared_preload_libraries，因为它需要额外的共享内存，所以增删都要重启；compute_query_id 必须是 auto 或 on；视图也只在你执行过 CREATE EXTENSION pg_stat_statements 的那个库里存在。任缺一条，你写的每一条查询都会失败——也就是说你以为有的那套监控，已经空了好几个月。

第二种失败是重置毁掉了对比。在窗口中间把计数器清零，之后每个差值都是负的：夹具里 6 种查询形态全部报出负耗时。算术没错，错的是窗口。pg_stat_statements_info.stats_reset 就是为此存在的——做任何减法之前先看它；如果重置是故意的，就把窗口起点挪到重置之后，而不是硬去跨越它做对账。

顺带一个容易踩的坑：如果监控系统把 queryid 当作长期基线写进时序库，一次大版本升级就可能让所有基线错位——文档明确不承诺这个标识符跨大版本稳定。

快速验证

把两个排名都跑一遍，看看它们有多不一致：

psql -c "SELECT calls, round(total_exec_time) AS total_ms, round(mean_exec_time,3) AS mean_ms, rows FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;"
psql -c "SELECT calls, round(mean_exec_time,2) AS mean_ms, round(total_exec_time) AS total_ms FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;"
psql -c "SELECT stats_reset FROM pg_stat_statements_info;"
psql -c "SELECT sum(calls) AS calls, round(sum(total_exec_time)/1000) AS total_s, round(sum(shared_blks_read)*8.0/1024/1024,1) AS read_gib FROM pg_stat_statements;"
psql -c "SELECT pg_stat_statements_reset(0, 0, queryid) FROM pg_stat_statements WHERE query LIKE 'SELECT%';"

前两条列表应当对不上，而该据以动手的是第一条。stats_reset 决定一个增量窗口是否有效。第三条汇总用来核对量级——如果 total_s 大于统计信息存在的实际时长，说明你跨越了一次重启在读数。最后一条是定向重置，要刻意去跑，因为它恰好就是让下一次对比失真的那个动作。

来源

PostgreSQL：pg_stat_statements，归一化、统计列与 pg_stat_statements_reset，已核验 2026-09-16。
PostgreSQL：累积统计系统，stats_reset 与各计数器的所在，已核验 2026-09-16。
PostgreSQL：统计监控配置，track_io_timing 与它启用的块耗时列，已核验 2026-09-16。

TCP 窗口缩放分别扩展两个方向的接收窗口编码

Thu, 02 Dec 2027 00:00:00 +0000

TCP 头部的接收窗口字段只有十六位。窗口缩放让已建立连接依据握手期间确定的移位解释这个字段，从而允许接收端通告超过65535字节的空间。两个方向可以采用不同移位值。它扩展的是接收窗口信息的编码，不会直接扩大每个缓冲区，也不保证发送端始终让那么多数据处于未确认状态。

坏掉的样子

高带宽且 RTT 较长的路径，可能需要远多于未缩放窗口所能描述的在途数据。例如每秒一百兆比特、往返八十毫秒，对应大约一百万字节在途数据；65535字节窗口会形成明显更低的理想速率上限。带宽时延积用于容量估算，不是吞吐量实测，也不保证链路不存在其他约束，不能用一个乘法直接宣布应用应达到某个速度。

发送端还受到拥塞窗口限制，并且必须有应用数据可发。扩大接收窗口编码，无法修复过小的拥塞预算、停止读取的应用、丢包或被阻断的路由。零窗口经过缩放仍然是零。应判断究竟哪个资源限制进展，不能仅因握手里存在缩放选项，就断言连接理应跑满链路，也不能把所有低吞吐问题都归因于缓冲配置。

对协商的误解还会导致抓包解释错误。双方都必须提供选项，缩放才能生效；每个因子用于解释提供它的端点所通告的窗口。SYN 与 SYN-ACK 自身的窗口字段从不缩放。使用反方向的移位值，或把 SYN 窗口也乘上因子，即使数据包字节完全正确，也会算出错误容量。报文值需要结合方向和连接阶段解释。

快速验证

将脚本保存为 check-window-scaling.py，准备 Docker 后运行 python3 check-window-scaling.py。一次性环境使用 Python 3.11.16、iproute2 6.1.0 和 tcpdump 4.99.3，在 Linux 6.12.76 上验证。NET_ADMIN 与 SYS_ADMIN 支持嵌套命名空间及临时 proc 挂载。端点通过新建 veth 相连，所有设置仅作用于实验范围：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends iproute2=6.1.0-3 iputils-ping=3:20221126-1+deb12u1 nftables=1.0.6-2+deb12u2 tcpdump=4.99.3-1 traceroute=1:2.1.2-1 procps=2:4.0.2-3 && rm -rf /var/lib/apt/lists/*\nCMD ["python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,select,signal,subprocess,time

def run(*args,check=True,input=None,timeout=8):
 result=subprocess.run(args,input=input,capture_output=True,text=True,timeout=timeout)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def ns(name,*args,**kwargs):return run('ip','netns','exec',name,*args,**kwargs)
def ip(name,*args,**kwargs):return ns(name,'ip',*args,**kwargs)
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=2)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=2)
def line(process,timeout=3):
 assert select.select([process.stdout],[],[],timeout)[0],'child response deadline exceeded'
 value=process.stdout.readline();assert value,('child exited without a response',process.stderr.read())
 return value
def spawn(stack,command):
 process=subprocess.Popen(command,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process);return process
@contextmanager
def lab(names):
 with TemporaryDirectory(prefix='net-path-') as directory,ExitStack() as stack:
 root=Path(directory);proc=root/'proc';proc.mkdir();run('mount','-t','proc','proc',str(proc))
 stack.callback(run,'umount',str(proc))
 for name in names:
 run('ip','netns','add',name);stack.callback(run,'ip','netns','delete',name,check=False)
 ip(name,'link','set','lo','up')
 def setting(name,key,value):
 assert name in names
 path=proc/'sys'/key.replace('.','/')
 return ns(name,'python3','-c',f'from pathlib import Path; p=Path({str(path)!r}); p.write_text({str(value)!r}); print(p.read_text().strip())').stdout.strip()
 yield root,stack,setting
def wire(left,left_if,right,right_if,left_addresses,right_addresses):
 run('ip','link','add',left_if,'type','veth','peer','name',right_if)
 for name,interface,addresses in [(left,left_if,left_addresses),(right,right_if,right_addresses)]:
 run('ip','link','set',interface,'netns',name)
 for address in addresses:ip(name,'address','add',address,'dev',interface,*(['nodad'] if ':' in address else []))
 ip(name,'link','set',interface,'up')
def nft(name,script):return ns(name,'nft','-f','-',input=script)
def counters(name):
 data=json.loads(ns(name,'nft','-j','list','ruleset').stdout);found={}
 for entry in data['nftables']:
 rule=entry.get('rule',{})
 if 'comment' in rule:
 for expression in rule['expr']:
 if 'counter' in expression:found[rule['comment']]=expression['counter']['packets']
 return found


def capture(stack,root,name,interface,expression,label):
 path=root/(label+'.pcap')
 process=subprocess.Popen(['ip','netns','exec',name,'tcpdump','--immediate-mode','-Z','root','-U','-n','-i',interface,'-w',str(path),expression],
 stdout=subprocess.DEVNULL,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process)
 deadline=time.monotonic()+3
 while time.monotonic()<deadline:
 assert process.poll() is None,'tcpdump exited before listening'
 if select.select([process.stderr],[],[],.1)[0] and 'listening on' in process.stderr.readline():return process,path
 raise AssertionError('tcpdump did not become ready')
def packets(process,path):
 import struct,socket
 process.send_signal(signal.SIGINT);_,diagnostic=process.communicate(timeout=3)
 assert process.returncode==0,diagnostic
 raw=path.read_bytes();assert raw[:4]==bytes.fromhex('d4c3b2a1') and struct.unpack_from('<I',raw,20)[0]==1
 offset=24;result=[]
 while offset<len(raw):
 seconds,micros,size,original=struct.unpack_from('<IIII',raw,offset);offset+=16
 frame=raw[offset:offset+size];offset+=size
 if frame[12:14]!=b'\x08\x00' or frame[23]!=6:continue
 ihl=(frame[14]&15)*4;length=struct.unpack_from('!H',frame,16)[0];tcp=14+ihl
 sport,dport,seq,ack=struct.unpack_from('!HHII',frame,tcp);header=(frame[tcp+12]>>4)*4
 opts={};cursor=tcp+20
 while cursor<tcp+header:
 kind=frame[cursor]
 if kind==0:break
 if kind==1:cursor+=1;continue
 option_length=frame[cursor+1];data=frame[cursor+2:cursor+option_length];assert option_length>=2
 if kind==2:opts['mss']=struct.unpack('!H',data)[0]
 elif kind==3:opts['wscale']=data[0]
 elif kind==4:opts['sack_ok']=True
 elif kind==5:opts['sack']=[list(pair) for pair in struct.iter_unpack('!II',data)]
 cursor+=option_length
 body=frame[tcp+header:14+length]
 result.append({'t':seconds+micros/1e6,'src':socket.inet_ntoa(frame[26:30]),'dst':socket.inet_ntoa(frame[30:34]),
 'sport':sport,'dport':dport,'seq':seq,'ack':ack,'flags':frame[tcp+13],'window':struct.unpack_from('!H',frame,tcp+14)[0],
 'length':len(body),'options':opts,'preview':body[:24].hex()})
 return result
with lab(['client','target']) as (root,stack,setting):
 wire('client','c0','target','t0',['192.0.2.1/30'],['192.0.2.2/30'])
 server_code=r'''
import socket,json
def read_exact(stream,length):
 data=b''
 while len(data)<length:
 chunk=stream.recv(length-len(data));assert chunk,'premature EOF';data+=chunk
 return data
listener=socket.socket();listener.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
listener.setsockopt(socket.SOL_SOCKET,socket.SO_RCVBUF,262144)
listener.bind(('192.0.2.2',18080));listener.listen();print('listening',flush=True)
with listener.accept()[0] as connection:
 connection.settimeout(4);print(json.dumps({'rcvbuf':connection.getsockopt(socket.SOL_SOCKET,socket.SO_RCVBUF)}),flush=True)
 assert read_exact(connection,4)==b'ping';connection.sendall(b'pong')
 assert connection.recv(1)==b''
'''
 client_code=r'''
import socket,json,sys
def read_exact(stream,length):
 data=b''
 while len(data)<length:
 chunk=stream.recv(length-len(data));assert chunk,'premature EOF';data+=chunk
 return data
s=socket.socket();s.settimeout(4);s.setsockopt(socket.SOL_SOCKET,socket.SO_RCVBUF,65536)
s.bind(('192.0.2.1',40400+int(sys.argv[1])));s.connect(('192.0.2.2',18080));s.sendall(b'ping')
assert read_exact(s,4)==b'pong'
print(json.dumps({'rcvbuf':s.getsockopt(socket.SOL_SOCKET,socket.SO_RCVBUF),'reply':'pong'}),flush=True)
assert sys.stdin.readline().strip()=='close';s.close()
'''
 outcomes={}
 for enabled in [1,0]:
 setting('client','net.ipv4.tcp_window_scaling',enabled);setting('target','net.ipv4.tcp_window_scaling',enabled)
 service=spawn(stack,['ip','netns','exec','target','python3','-u','-c',server_code]);assert line(service).strip()=='listening'
 tap,path=capture(stack,root,'client','c0','tcp port 18080','window'+str(enabled))
 client=spawn(stack,['ip','netns','exec','client','python3','-u','-c',client_code,str(enabled)])
 client_result=json.loads(line(client));server_result=json.loads(line(service))
 diagnostics=ns('client','ss','-tin','state','established').stdout
 client.stdin.write('close\n');client.stdin.flush();client.wait(timeout=2);service.wait(timeout=2)
 assert client.returncode==service.returncode==0
 observed=packets(tap,path);syn=next(p for p in observed if p['flags']&0x12==0x02)
 synack=next(p for p in observed if p['flags']&0x12==0x12)
 advertised=next(p for p in observed if p['sport']==18080 and p['length']==4)
 if enabled:
 assert 'wscale' in syn['options'] and 'wscale' in synack['options']
 effective=advertised['window']<<synack['options']['wscale'];assert effective>65535
 else:
 assert 'wscale' not in syn['options'] and 'wscale' not in synack['options'];effective=advertised['window'];assert effective<=65535
 outcomes[enabled]={'client':client_result,'server':server_result,'syn':syn,'synack':synack,
 'server_post_handshake_window_field':advertised['window'],'effective_receive_window':effective,'ss':diagnostics}
 print(json.dumps(outcomes))
"""
name='xbcatm-tcpflow-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 build=docker('build','-t',name,str(root));assert build.returncode==0,build.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--cap-add','NET_ADMIN','--cap-add','SYS_ADMIN',
 '--memory','256m','--pids-limit','128',name,'python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

连接建立之前，客户端请求65536字节接收缓冲，服务器监听套接字请求262144字节。脚本读取最终套接字选项值，不假定请求值会原样使用。Linux 的缓冲记账和上限会影响结果，本次客户端报告131072，服务器接受后的套接字报告425984。二者均不能直接等同于线上通告窗口。

两端启用缩放时，捕获到客户端 SYN 提供移位一，服务器 SYN-ACK 提供移位二。初始窗口字段仍按未缩放值解释。建立连接后，服务器数据段的窗口字段为53213，应用服务器因子后乘以四，得到212852字节。客户端套接字诊断也独立报告对应发送窗口，使协商、报文与生效状态互相印证。

下一条全新连接在两端关闭缩放，保持缓冲请求和应用交互相同。两个 SYN 都没有缩放选项，服务器通告窗口为65535字节。两次都发送 ping 并收到 pong，既检查协商，也检查真实通信。对照展示编码限制，没有把四字节交换包装成最大吞吐量测试；应用成功与容量上限属于不同结论。

脚本捕获建立过程，因为缩放因子对该连接固定。之后改变系统默认值，不会重新协商已有字节流。如果接收缓冲行为影响握手选择，就应在 connect 或 listen 前适当配置。从握手之后才开始的抓包，需要补充此前协商状态，才能正确解释原始窗口字段。缺少这段背景时，单看一个较小字段容易误判接收能力。

区分缓冲分配、通告容量与实际性能

记录相关套接字设置、双方移位、当前通告窗口、拥塞窗口、RTT 和应用活动。这些描述不同限制。分配量很大时，通告窗口仍可能较小，因为协议栈要考虑缓冲记账与当前占用。本例有意同时给出分配值和报文值，把差异明确展示出来，避免将多个不同指标都笼统叫作“窗口大小”，导致调参对象错误。

传输未达预期时，检查接收应用是否持续消费，以及发送端是否有足够任务使用允许的在途量。修改缓冲预算之前，应审阅丢包和拥塞行为。大量并发套接字采用更大分配，也会增加资源需求，因此调优应依靠负载证据，而不是把所有上限设到最大。只改变编码能力，无法保证应用生产与消费速度随之提升。

协议将移位限制为十四，使可表示窗口小于一吉比字节。这个编码上限并不要求分配同样多内存。变更之后，应针对部署内核和代表性流量验证。本例检查协商、方向、计算及成功交换，持续容量和实际应用行为还需要适合真实路径的测量。明确区分这些结论，才能避免用一个选项的存在代替完整性能证据。

来源

RFC 7323 TCP Extensions，双向独立缩放因子、SYN 例外与接收窗口计算，已核验 2026-09-12。
Linux tcp(7)，接收缓冲、窗口缩放与建立连接前的套接字设置，已核验 2026-09-12。
RFC 5681 Congestion Control，拥塞窗口与接收窗口分别施加的限制，已核验 2026-09-12。

缓存雪崩姗姗于同一时刻过期

Mon, 22 Nov 2027 00:00:00 +0000

缓存雪崩或击穿所造成的一个关键风险，是并发未命中对同一依赖发起大量重复工作。同时到期只是触发条件之一：容量淘汰、刚部署的空缓存、缓存服务不可用，都可能造成类似突发。即使只有一把热门键，也足以压垮后端。判断风险时应数清楚：一份结果尚未计算完的这段时间内，到底有多少次重建真正抵达数据源。

在真实边界内合并工作

Go 的 singleflight Group 对同一键，在这个 Group 内最多保持一次在途函数执行；重复调用者共享结果，也共享错误。不同 Group 之间不会协调，即使它们位于同一个进程；不同服务实例通常也各有自己的 Group。因此它既不是分布式锁，也不是保存已完成结果的缓存。把 Group 放在每个请求内部重新创建，无法实现跨请求合并。

实际使用时，应让请求共享同一个 Group，并使键准确表示等价工作。不同租户、权限、币种或响应表示如果错误地使用同一个键，可能拿到不属于自己的结果。对于缓存回填，在共享函数内部应再次检查缓存，确实仍缺失才访问数据源，并在函数返回前完成成功结果的缓存写入。这些存储操作都不是 singleflight 自动提供的能力。

错开时间不能改变新鲜度承诺

随机抖动可以打散不同条目或独立副本的到期时间，却不能阻止访问同一过期热键的人一起未命中。如果最大 TTL 是业务规定的新鲜度上限，在有界范围内随机缩短寿命，不会偷偷越过这个上限；任意增加正向抖动则改变了原有承诺。不能脱离请求量、计算成本和允许陈旧程度，宣称几个百分点或几秒钟就普遍足够。

提前刷新和允许使用旧响应，有机会避免用户等待，但必须有明确业务语义。暂时展示上一版公开目录可能可接受，已经撤销的权限或当前余额则未必可以。并发合并只减少重复计算，不负责判断陈旧内容能否使用；如果缓存完全是空的，系统仍需要取得一份数据源结果，不能把后台刷新当作无条件的可用性保证。

坏掉的样子

共享加载函数一旦卡住，可能同时拖住很多等待者。要为数据源调用设置执行期限，也让每个调用者能限制自己的等待时间。DoChan 返回的是结果通道，不是取消机制：某个等待者离开，不会自动停止底层执行。Forget 允许同一键重新启动一次执行，但并不取消原有执行，用它解除等待可能重新制造两次并行加载。

错误只在本次执行仍处于在途状态时共享。执行结束后立刻重试，会向故障依赖发起一轮又一轮新请求。应根据依赖的实际约束设置重试与准入策略，对可以缓存的“不存在”和瞬时失败分别处理。另一个常见误判是把进程内的数字推广到全局：一百个各有 Group 的实例，仍可能同时产生一百次重建，本地只执行一次不等于源站只收到一次。

快速验证

需要 Go 1.25 或更新版本；本次使用 Go 1.27.0 和 x/sync v0.22.0。在下面创建的独立模块目录中，将 Go 代码放入 main.go，再运行 go run -race main.go。只有依赖安装需要外网。程序从“已经发生冷缓存未命中”的边界开始，用有计数器的加载函数观察行为，没有连接真实数据库、缓存服务，也没有实现 TTL 定时器。

stampede_lab=$(mktemp -d)
cd "$stampede_lab"
go mod init example.invalid/stampede-lab
go get golang.org/x/sync@v0.22.0

package main

import (
 "errors"
 "fmt"
 "sync"
 "sync/atomic"

 "golang.org/x/sync/singleflight"
)

const callers = 12

func require(ok bool) {
 if !ok {
 panic("unexpected result")
 }
}

func wave(groups []*singleflight.Group, failure error) int32 {
 var calls atomic.Int32
 gate := make(chan struct{})
 results := make([]<-chan singleflight.Result, callers)
 load := func() (any, error) {
 calls.Add(1)
 <-gate
 if failure != nil {
 return nil, failure
 }
 return "catalog-v1", nil
 }
 for i := range results {
 results[i] = groups[i%len(groups)].DoChan("catalog", load)
 }
 close(gate)
 for _, result := range results {
 r := <-result
 require(r.Shared && r.Err == failure)
 if failure == nil {
 require(r.Val == "catalog-v1")
 } else {
 require(r.Val == nil)
 }
 }
 return calls.Load()
}

func main() {
 var plain atomic.Int32
 var workers sync.WaitGroup
 gate := make(chan struct{})
 for range callers {
 workers.Add(1)
 go func() {
 defer workers.Done()
 plain.Add(1)
 <-gate
 }()
 }
 close(gate)
 workers.Wait()
 require(plain.Load() == callers)
 fmt.Println("without coalescing: 12 loader calls")

 group := new(singleflight.Group)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 fmt.Println("one Group: 1 call per wave; completed results are not cached")
 other := new(singleflight.Group)
 require(wave([]*singleflight.Group{group, other}, nil) == 2)
 fmt.Println("two independent Groups: 2 loader calls")

 failure := errors.New("origin unavailable")
 require(wave([]*singleflight.Group{group}, failure) == 1)
 require(wave([]*singleflight.Group{group}, nil) == 1)
 fmt.Println("one error reaches 12 callers; next wave starts a new load")
}

未合并的基线执行十二次加载。所有调用加入同一个 Group 时，每一轮只执行一次；在同一个 Group 上再运行第二轮，仍会新增一次执行，说明完成结果并未被保存。把十二名调用者分给两个独立 Group，就得到两次加载。故障轮次让十二名调用者收到同一个错误，随后成功的轮次仍会重新加载，而不是读取已缓存的错误结果。

实验用通道闸门让共享加载保持在途，直到所有 DoChan 调用完成注册才放行，因此无需靠睡眠长度或碰巧的调度顺序制造重叠。这里同一轮的所有结果都会标记 Shared 为真，包括最初发起者收到的结果。每个结果通道只接收一次即可；DoChan 不会关闭这些通道，如果对它执行 range 并等待结束，程序就会一直等待。

验收真实服务时，应在隔离环境安排冷缓存测试，同时记录加载次数、等待人数、请求延迟和失败数。验证范围需要包括多个实例和数据源超时，不能只看正常运行时漂亮的缓存命中率。这次 race 检查证明的是此程序在观察到的执行中没有报告数据竞争，并不覆盖生产缓存所有交错顺序，更不代表全局容量、超时及恢复策略已经验收。

来源

Go x/sync v0.22.0：singleflight，Group 范围、DoChan、错误共享与 Forget，已核验 2026-09-07。
AWS Builders’ Library：缓存挑战与策略，冷缓存、请求合并、失败行为与基于实测的过期策略，已核验 2026-09-07。

Nagle 与延迟 ACK 可能让小请求的第二部分等待

Sun, 31 Oct 2027 00:00:00 +0000

Nagle 算法减少 TCP 小报文：当前面数据尚未确认时，它会暂缓额外的小块数据，除非已经积累到足以构成完整段。延迟确认则是接收端的另一种行为，可以短暂推迟 ACK。当应用把一个请求拆成多个很小的写入，而对端必须取得后续字节才能生成响应时，两者的相互作用就会影响延迟。需要明确是哪一部分数据已经发出、哪一部分仍在等待。

坏掉的样子

单独一个小请求，不会自动被 Nagle 延迟。如果没有更早的未确认数据，第一个小段可以直接发送。问题场景是第一部分已在途中，第二个短小部分排在后面等待。如果接收端延迟确认，同时应用又在等完整请求，进展可能暂停，直到确认计时器到期。不能把所有“小请求慢”都归到这个机制，也不能省略前面存在未确认数据这一条件。

这属于有边界的延迟，不是协议无限死锁。ACK 可以释放排队数据，积累足够多数据也可能改变发送决策。观察到的等待既不统一等于额外一个 RTT，也不固定为四十毫秒。接收策略、已有确认状态、请求分帧和网络条件，共同决定真正的报文顺序与时间。把一次实验数值当成所有系统的常数，会误导后续故障判断。

TCP_NODELAY 关闭指定套接字上的 Nagle，却不会关闭所有缓冲、拥塞控制、接收窗口流控或调度延迟。Linux TCP_QUICKACK 请求改变确认模式，但这种模式不是永久设置。把任意一个选项当作万能延迟开关，可能掩盖应用缓冲或其他传输限制；这些问题本来就不在该选项职责内，需要通过对应层次的证据定位。

快速验证

将脚本保存为 check-nagle.py，准备 Docker 后运行 python3 check-nagle.py。一次性环境使用 Python 3.11.16、iproute2 6.1.0 和 tcpdump 4.99.3，在 Linux 6.12.76 上验证。NET_ADMIN 与 SYS_ADMIN 支持嵌套命名空间。客户端和目标通过新建 veth 通信，所有参数都留在实验范围内，不修改宿主正在使用的网络配置：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends iproute2=6.1.0-3 iputils-ping=3:20221126-1+deb12u1 nftables=1.0.6-2+deb12u2 tcpdump=4.99.3-1 traceroute=1:2.1.2-1 procps=2:4.0.2-3 && rm -rf /var/lib/apt/lists/*\nCMD ["python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,select,signal,subprocess,time

def run(*args,check=True,input=None,timeout=8):
 result=subprocess.run(args,input=input,capture_output=True,text=True,timeout=timeout)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def ns(name,*args,**kwargs):return run('ip','netns','exec',name,*args,**kwargs)
def ip(name,*args,**kwargs):return ns(name,'ip',*args,**kwargs)
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=2)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=2)
def line(process,timeout=3):
 assert select.select([process.stdout],[],[],timeout)[0],'child response deadline exceeded'
 value=process.stdout.readline();assert value,('child exited without a response',process.stderr.read())
 return value
def spawn(stack,command):
 process=subprocess.Popen(command,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process);return process
@contextmanager
def lab(names):
 with TemporaryDirectory(prefix='net-path-') as directory,ExitStack() as stack:
 root=Path(directory);proc=root/'proc';proc.mkdir();run('mount','-t','proc','proc',str(proc))
 stack.callback(run,'umount',str(proc))
 for name in names:
 run('ip','netns','add',name);stack.callback(run,'ip','netns','delete',name,check=False)
 ip(name,'link','set','lo','up')
 def setting(name,key,value):
 assert name in names
 path=proc/'sys'/key.replace('.','/')
 return ns(name,'python3','-c',f'from pathlib import Path; p=Path({str(path)!r}); p.write_text({str(value)!r}); print(p.read_text().strip())').stdout.strip()
 yield root,stack,setting
def wire(left,left_if,right,right_if,left_addresses,right_addresses):
 run('ip','link','add',left_if,'type','veth','peer','name',right_if)
 for name,interface,addresses in [(left,left_if,left_addresses),(right,right_if,right_addresses)]:
 run('ip','link','set',interface,'netns',name)
 for address in addresses:ip(name,'address','add',address,'dev',interface,*(['nodad'] if ':' in address else []))
 ip(name,'link','set',interface,'up')
def nft(name,script):return ns(name,'nft','-f','-',input=script)
def counters(name):
 data=json.loads(ns(name,'nft','-j','list','ruleset').stdout);found={}
 for entry in data['nftables']:
 rule=entry.get('rule',{})
 if 'comment' in rule:
 for expression in rule['expr']:
 if 'counter' in expression:found[rule['comment']]=expression['counter']['packets']
 return found


def capture(stack,root,name,interface,expression,label):
 path=root/(label+'.pcap')
 process=subprocess.Popen(['ip','netns','exec',name,'tcpdump','--immediate-mode','-Z','root','-U','-n','-i',interface,'-w',str(path),expression],
 stdout=subprocess.DEVNULL,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process)
 deadline=time.monotonic()+3
 while time.monotonic()<deadline:
 assert process.poll() is None,'tcpdump exited before listening'
 if select.select([process.stderr],[],[],.1)[0] and 'listening on' in process.stderr.readline():return process,path
 raise AssertionError('tcpdump did not become ready')
def packets(process,path):
 import struct,socket
 process.send_signal(signal.SIGINT);_,diagnostic=process.communicate(timeout=3)
 assert process.returncode==0,diagnostic
 raw=path.read_bytes();assert raw[:4]==bytes.fromhex('d4c3b2a1') and struct.unpack_from('<I',raw,20)[0]==1
 offset=24;result=[]
 while offset<len(raw):
 seconds,micros,size,original=struct.unpack_from('<IIII',raw,offset);offset+=16
 frame=raw[offset:offset+size];offset+=size
 if frame[12:14]!=b'\x08\x00' or frame[23]!=6:continue
 ihl=(frame[14]&15)*4;length=struct.unpack_from('!H',frame,16)[0];tcp=14+ihl
 sport,dport,seq,ack=struct.unpack_from('!HHII',frame,tcp);header=(frame[tcp+12]>>4)*4
 opts={};cursor=tcp+20
 while cursor<tcp+header:
 kind=frame[cursor]
 if kind==0:break
 if kind==1:cursor+=1;continue
 option_length=frame[cursor+1];data=frame[cursor+2:cursor+option_length];assert option_length>=2
 if kind==2:opts['mss']=struct.unpack('!H',data)[0]
 elif kind==3:opts['wscale']=data[0]
 elif kind==4:opts['sack_ok']=True
 elif kind==5:opts['sack']=[list(pair) for pair in struct.iter_unpack('!II',data)]
 cursor+=option_length
 body=frame[tcp+header:14+length]
 result.append({'t':seconds+micros/1e6,'src':socket.inet_ntoa(frame[26:30]),'dst':socket.inet_ntoa(frame[30:34]),
 'sport':sport,'dport':dport,'seq':seq,'ack':ack,'flags':frame[tcp+13],'window':struct.unpack_from('!H',frame,tcp+14)[0],
 'length':len(body),'options':opts,'preview':body[:24].hex()})
 return result
with lab(['client','target']) as (root,stack,setting):
 wire('client','c0','target','t0',['192.0.2.1/30'],['192.0.2.2/30'])
 setting('client','net.ipv4.tcp_autocorking',0)
 server_code=r'''
import socket,json
def read_exact(stream,length):
 data=b''
 while len(data)<length:
 chunk=stream.recv(length-len(data));assert chunk,'premature EOF';data+=chunk
 return data
listener=socket.socket();listener.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
listener.bind(('192.0.2.2',18080));listener.listen();print('listening',flush=True)
for trial in range(2):
 with listener.accept()[0] as connection:
 connection.settimeout(3);connection.setsockopt(socket.IPPROTO_TCP,socket.TCP_QUICKACK,0)
 print('configured',flush=True)
 request=read_exact(connection,2);assert request==b'ab',request
 connection.sendall(b'OK');print(json.dumps({'request':request.decode()}),flush=True)
'''
 service=spawn(stack,['ip','netns','exec','target','python3','-u','-c',server_code]);assert line(service).strip()=='listening'
 tap,path=capture(stack,root,'client','c0','tcp port 18080','nagle')
 client_code=r'''
import json,socket,sys,time
def read_exact(stream,length):
 data=b''
 while len(data)<length:
 chunk=stream.recv(length-len(data));assert chunk,'premature EOF';data+=chunk
 return data
nodelay=int(sys.argv[1]);s=socket.socket();s.settimeout(3)
s.setsockopt(socket.IPPROTO_TCP,socket.TCP_NODELAY,nodelay);s.bind(('192.0.2.1',40300+nodelay));s.connect(('192.0.2.2',18080))
print('connected',flush=True);assert sys.stdin.readline().strip()=='go'
start=time.monotonic();s.sendall(b'a');time.sleep(.002);s.sendall(b'b');reply=read_exact(s,2)
assert reply==b'OK';print(json.dumps({'nodelay':nodelay,'reply':reply.decode(),'elapsed_ms':(time.monotonic()-start)*1000}),flush=True);s.close()
'''
 outcomes=[]
 for nodelay in [0,1]:
 client=spawn(stack,['ip','netns','exec','client','python3','-u','-c',client_code,str(nodelay)])
 assert line(client).strip()=='connected' and line(service).strip()=='configured'
 client.stdin.write('go\n');client.stdin.flush();outcomes.append(json.loads(line(client)))
 assert json.loads(line(service))['request']=='ab';client.wait(timeout=2);assert client.returncode==0
 observed=packets(tap,path);timelines={}
 for nodelay in [0,1]:
 port=40300+nodelay;flow=[p for p in observed if port in (p['sport'],p['dport'])]
 first=next(p for p in flow if p['sport']==port and p['preview']=='61')
 second=next(p for p in flow if p['sport']==port and p['preview']=='62')
 assert (second['seq']-first['seq'])%2**32==1
 acks=[p for p in flow if p['dport']==port and p['flags']&0x10 and 0<(p['ack']-first['seq'])%2**32<=2]
 assert acks
 if not nodelay:
 intermediate=next(p for p in acks if (p['ack']-first['seq'])%2**32==1)
 assert first['t']<intermediate['t']<=second['t'] and second['t']-first['t']>.01
 else:assert second['t']<=acks[0]['t']
 timelines[nodelay]={'first_byte':first,'second_byte':second,'first_ack_covering_data':acks[0],
 'data_segment_gap_ms':(second['t']-first['t'])*1000}
 print(json.dumps({'trials':outcomes,'packet_timelines':timelines,'receiver_quickack_requested':0,'client_autocorking':0}))
"""
name='xbcatm-tcpflow-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 build=docker('build','-t',name,str(root));assert build.returncode==0,build.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--cap-add','NET_ADMIN','--cap-add','SYS_ADMIN',
 '--memory','256m','--pids-limit','128',name,'python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

服务器等待完整请求 ab 才回复 OK。每次试验之前，它在已接受连接上请求非快速确认模式。客户端关闭本命名空间自动 corking，以排除另一种合并机制对比较的影响。父子进程通过明确消息同步，确保接收端先完成套接字设置，再让客户端开始发送应用字节，避免把配置时序竞争误认为算法差异。

第一次试验把 TCP_NODELAY 设为零。客户端发送 a，等待两毫秒，再发送 b。这些写入是应用动作，并不保证立即产生分离报文。抓包显示第一个字节离开、覆盖它的 ACK 到达，随后第二个字节才离开。程序检查这个顺序，而不是只要响应变慢就宣称 Nagle 一定是原因。应用写入时间与实际传输时间必须分开观察。

本次记录中，两段数据相隔约四十一毫秒，完整交互也花费接近这个时间。第二次启用 TCP_NODELAY，保持相同分帧与刻意加入的等待。第二个字节在首个数据确认之前离开，两段间隔约两毫秒。服务器在两次试验中都取得完整请求，并返回相同有效回复。比较改变的是传输时机，不能将第一种情况写成请求永远无法完成。

这些时间描述受控运行，不是生产延迟保证。脚本要求在所述设置下看到延迟确认交互，并检查对应报文先后关系；其他内核或接收策略需要重新调查。流式读取明确累积所需字节数，因为 recv 即使给定长度，通常也不保证一次返回完整应用消息。这个边界与 Nagle 是否启用无关，应用必须始终正确处理分段读取。

一起决定请求分帧与套接字策略

对于已经完整存在内存中的小型逻辑请求，可以考虑把完整表示一起写出，避免接收端等后续片段，同时保留有价值的传输合并。必须及时交付独立小更新的交互流，则可能适合 TCP_NODELAY。选择应依据负载的消息边界与实测行为，不能对所有连接使用同一条经验规则，也不能通过改变分帧后忘记重新检查应用语义。

请求周期性停顿时，同时捕获数据和确认，判断第二部分仍停在应用缓冲、已排入发送端，还是已经到达对端。应用中的一个超时，无法区分这些阶段。将抓包与套接字配置、接收端认定请求完整的时刻关联，才能知道需要改变哪一处等待，而不是反复调整与问题没有关系的传输参数。

大量发送微小更新时，还要考虑包速率与带宽开销。减少不必要的合并等待，可以改善交互，却也可能增加每次操作产生的段数。应同时测量相关响应延迟和资源成本。这里有用的结果，是对特定交互建立有证据支持的策略：两次请求都成功，而实际观察到的发送顺序不同，足以解释本例等待差异，但不构成统一性能承诺。

来源

RFC 896 Congestion Control，前面数据未确认时合并小块写入，已核验 2026-09-12。
RFC 1122 Host Requirements，延迟确认行为及其等待边界，已核验 2026-09-12。
Linux tcp(7)，TCP_NODELAY 与 TCP_QUICKACK 的临时性，已核验 2026-09-12。

小表上全表扫描反而赢

Thu, 16 Sep 2027 00:00:00 +0000

索引是一场下注：你先付出写入与存储的代价，换来读取时能跳过表的大部分。可当一条查询真的需要表的大部分时，这场下注就输了——引擎会为每一行都下一次 B 树，而不是把那些页按顺序读一遍。

优化器给两条路线都算了账，所以真正有意思的问题不是"原则上谁更快"，而是交叉点落在哪里。表小并不等于工作量小，你在 1000 行时看到的计划，也不是 1000 万行时该期待的计划。

真正的货币是页，不是行

顺序扫描按物理顺序读表的页，一页能拿到很多行。PostgreSQL 用 seq_page_cost（默认 1.0）对 random_page_cost（默认 4.0）来给这件事定价：非顺序取到的页按顺序页的四倍计价，而把 random_page_cost 相对 seq_page_cost 调低，正是让优化器开始偏好索引扫描的那个开关。文档也指出，如果整个数据库都能装进缓存，把两者设成相等是合理的。

机械盘上一次随机寻道以毫秒计，而顺序读完一整条磁道几乎免费；NVMe 把这个差距压到微秒级，但页数本身并没有变，所以代价模型里「页数」这一项始终在。既然货币是页，行数就是一个很差的规模代理。同样是 1000 行的两张表：4 字节负载的那张是 12 页，4000 字节负载的那张是 1010 页。在 sqlite 3.53 上配 2 MB 页缓存，命中约 90% 行的宽谓词查询在窄表上 0.02 ms 跑完，在宽表上要 1.30 ms——行数完全一样，差了 65 倍。只有其中一张算"小"。

索引从哪里开始不划算

把两条访问路径分别钉死，交叉点就露出来了。表是 events(id, tenant, payload)，1000 个不同 tenant，tenant 上有索引，谓词命中约 90% 的行：

1000 行、21 页：扫描 0.04 ms，索引 0.05 ms，打平。这个规模上索引什么也没买到，而每次写入都还要维护它。
50000 行、767 页：扫描 1.79 ms，索引 6.61 ms，扫描赢 3.7 倍。
1000000 行、15474 页（63 MB）：扫描 44.37 ms，索引 531.18 ms，扫描赢 12 倍；采七次样本，比值最低也有 11.3 倍。

还有一层细节：如果查询只需要索引里已经有的列，引擎就完全不必碰表，这时候索引在宽谓词上也依然便宜。上面的测试刻意用 sum(length(payload)) 而不是 count(*)，就是为了把数据行拉进来，让两条路径真正可比。覆盖索引会把整个交叉点挪走，代价是索引本身变大、每次写入更贵。

同一个索引在同样这张百万行表上，遇到选择性谓词却是 29 倍的优势：tenant = 7 只覆盖约 0.1% 的行，走索引 0.61 ms，扫描 17.88 ms。索引本身不坏，它只是对这个谓词坏。决定权在选择性手上，而且表越大，它决定得越狠。

让优化器做主，但把它的输入喂诚实

三种规模上，sqlite 都为宽谓词选了扫描，为选择性谓词选了索引。这是正确的默认值；当计划看起来不对时，该动的杠杆是统计信息，不是 hint。把强制索引当成诊断证据而不是长期策略：先钉死两条路径各量一次，再回头去修数据或统计。

统计信息会过期，计划跟着一起过期。把百万行的表 ANALYZE 一遍，然后把所有行都改成 tenant = 5 而不再分析：sqlite_stat1 仍然写着每个键 1000 行，于是优化器继续为一个命中全表 100% 的谓词选 SEARCH ... USING INDEX。再跑一次 ANALYZE，统计变成每个键 1000000 行，计划当场翻成 SCAN。这里错误计划只贵了 1.2 倍，原因是 sqlite 的表 b 树按 rowid 排序，索引游走取页时仍接近物理顺序；在 PostgreSQL 里，每一次索引命中都是一次按 random_page_cost 计价的独立堆取页，同样的错误要贵得多。

坏掉的样子

最经典的是统计信息陈旧导致的计划翻转。夜间任务灌进来一个逐渐占满全表的 tenant，直方图还描述着上周；原本走索引查找的看板查询，现在变成透过索引读掉五分之一张表。没有任何报错。延迟就那么抬了一级，而且恰好抬在没人盯着的那些查询上。

第二种失败与形状无关，只与规模有关。21 页上花 0.03 ms 的那次扫描，在 767 页上是 1.88 ms，在 15474 页上是 41.34 ms，因为代价对页数是线性的。今天还行的表，长一年之后就变成付不起的全表扫描。解法不是 hint，而是让优化器真正会选的那个索引，或者一条返回更少行的查询。

快速验证

先确认这张表在页数上确实小，再看优化器是否和现实一致：

sqlite3 events.db "PRAGMA page_count; PRAGMA page_size;"
sqlite3 events.db "EXPLAIN QUERY PLAN SELECT sum(length(payload)) FROM events WHERE tenant < 900;"
sqlite3 events.db "EXPLAIN QUERY PLAN SELECT sum(length(payload)) FROM events NOT INDEXED WHERE tenant < 900;"
sqlite3 events.db "ANALYZE; SELECT stat FROM sqlite_stat1 WHERE idx='events_tenant';"
printf '.timer on\nSELECT sum(length(payload)) FROM events NOT INDEXED WHERE tenant < 900;\n' | sqlite3 events.db

第一条给出页数，那才是关键数字。中间两条对宽谓词应该报出同一条路径：如果优化器说 SEARCH ... USING INDEX，而被钉死的 SCAN 明显更快，嫌疑就在统计信息上。sqlite_stat1 给出每个键的平均行数——当它仍旧写着 1000、而实际已有一个键占满全表时，重跑 ANALYZE 再看一次计划。

来源

PostgreSQL：优化器代价常量，seq_page_cost 与 random_page_cost，已核验 2026-09-16。
PostgreSQL：使用 EXPLAIN，如何读计划与行数估计，已核验 2026-09-16。
SQLite：EXPLAIN QUERY PLAN，扫描与查找步骤如何呈现，已核验 2026-09-16。

SACK 报告缺口之后已收到的范围，帮助定位需要恢复的数据

Sat, 11 Sep 2027 00:00:00 +0000

TCP 累计确认标识按序接收时下一个期待的字节。如果某段缺失、后续字节却已到达，累计确认不能跨过这个空洞。选择确认 SACK 补充报告累计边界之后已经收到的字节范围，帮助发送端区分真正缺失的数据与接收端已经排队的数据。它改善恢复算法获得的信息，而不是替代全部丢包判断、拥塞控制或应用交付语义。

坏掉的样子

没有 SACK，并不意味着累计 ACK 强制发送端重传后面的每一个段。发送端仍可根据重复确认、计时器和恢复算法推断丢失，只是反馈不够明确，尤其在存在多个缺口时。把普通 TCP 描述为必须重发整个后缀，是把信息能力的限制误写成强制恢复策略，会夸大差异，也无法准确解释真实抓包中的局部重传。

SACK 块报告已经收到的范围，不是直接列出缺失范围。每块在序列空间中具有包含的左边界和不包含的右边界。缺口需要结合这些块、累计确认及尚未确认数据推导。SACK 不改变普通 ACK 字段含义，应用仍获得有序字节流，而不是乱序的选择确认块。传输层暂存后续字节，并不等于已经把它们交给应用。

该能力还需要对当前连接取得许可。SYN 中的 SACK-Permitted 表示发送该 SYN 的一端允许对端向自己发送 SACK 选项，不证明一次无丢失传输中实际出现过 SACK 块。反过来，缺少 SACK 也不自动证明防火墙剥离选项。判断原因之前应核对端点设置与真实握手，不能把某种中间设备问题当成唯一解释，忽略连接本身的协商条件。

快速验证

将脚本保存为 check-sack.py，准备 Docker 后运行 python3 check-sack.py。一次性环境使用 Python 3.11.16、iproute2 6.1.0、nftables 1.0.6 和 tcpdump 4.99.3，在 Linux 6.12.76 上验证。NET_ADMIN 与 SYS_ADMIN 支持嵌套网络命名空间及临时 proc 挂载。实验仅使用新建 veth 和命名空间内部设置，不改变宿主现有流量：

from pathlib import Path
from tempfile import TemporaryDirectory
import json,subprocess,uuid
recipe='FROM python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84\nRUN apt-get update && apt-get install -y --no-install-recommends iproute2=6.1.0-3 iputils-ping=3:20221126-1+deb12u1 nftables=1.0.6-2+deb12u2 tcpdump=4.99.3-1 traceroute=1:2.1.2-1 procps=2:4.0.2-3 && rm -rf /var/lib/apt/lists/*\nCMD ["python3"]\n'
program=r"""
from contextlib import ExitStack,contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import json,os,select,signal,subprocess,time

def run(*args,check=True,input=None,timeout=8):
 result=subprocess.run(args,input=input,capture_output=True,text=True,timeout=timeout)
 if check:assert result.returncode==0,(args,result.returncode,result.stdout,result.stderr)
 return result
def ns(name,*args,**kwargs):return run('ip','netns','exec',name,*args,**kwargs)
def ip(name,*args,**kwargs):return ns(name,'ip',*args,**kwargs)
def stop(process):
 if process.poll() is None:
 process.terminate()
 try:process.wait(timeout=2)
 except subprocess.TimeoutExpired:process.kill();process.wait(timeout=2)
def line(process,timeout=3):
 assert select.select([process.stdout],[],[],timeout)[0],'child response deadline exceeded'
 value=process.stdout.readline();assert value,'child exited without a response'
 return value
def spawn(stack,command):
 process=subprocess.Popen(command,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process);return process
@contextmanager
def lab(names):
 with TemporaryDirectory(prefix='net-path-') as directory,ExitStack() as stack:
 root=Path(directory);proc=root/'proc';proc.mkdir();run('mount','-t','proc','proc',str(proc))
 stack.callback(run,'umount',str(proc))
 for name in names:
 run('ip','netns','add',name);stack.callback(run,'ip','netns','delete',name,check=False)
 ip(name,'link','set','lo','up')
 def setting(name,key,value):
 assert name in names
 path=proc/'sys'/key.replace('.','/')
 return ns(name,'python3','-c',f'from pathlib import Path; p=Path({str(path)!r}); p.write_text({str(value)!r}); print(p.read_text().strip())').stdout.strip()
 yield root,stack,setting
def wire(left,left_if,right,right_if,left_addresses,right_addresses):
 run('ip','link','add',left_if,'type','veth','peer','name',right_if)
 for name,interface,addresses in [(left,left_if,left_addresses),(right,right_if,right_addresses)]:
 run('ip','link','set',interface,'netns',name)
 for address in addresses:ip(name,'address','add',address,'dev',interface,*(['nodad'] if ':' in address else []))
 ip(name,'link','set',interface,'up')
def nft(name,script):return ns(name,'nft','-f','-',input=script)
def counters(name):
 data=json.loads(ns(name,'nft','-j','list','ruleset').stdout);found={}
 for entry in data['nftables']:
 rule=entry.get('rule',{})
 if 'comment' in rule:
 for expression in rule['expr']:
 if 'counter' in expression:found[rule['comment']]=expression['counter']['packets']
 return found


def capture(stack,root,name,interface,expression,label):
 path=root/(label+'.pcap')
 process=subprocess.Popen(['ip','netns','exec',name,'tcpdump','--immediate-mode','-Z','root','-U','-n','-i',interface,'-w',str(path),expression],
 stdout=subprocess.DEVNULL,stderr=subprocess.PIPE,text=True)
 stack.callback(stop,process)
 deadline=time.monotonic()+3
 while time.monotonic()<deadline:
 assert process.poll() is None,'tcpdump exited before listening'
 if select.select([process.stderr],[],[],.1)[0] and 'listening on' in process.stderr.readline():return process,path
 raise AssertionError('tcpdump did not become ready')
def packets(process,path):
 import struct,socket
 process.send_signal(signal.SIGINT);_,diagnostic=process.communicate(timeout=3)
 assert process.returncode==0,diagnostic
 raw=path.read_bytes();assert raw[:4]==bytes.fromhex('d4c3b2a1') and struct.unpack_from('<I',raw,20)[0]==1
 offset=24;result=[]
 while offset<len(raw):
 seconds,micros,size,original=struct.unpack_from('<IIII',raw,offset);offset+=16
 frame=raw[offset:offset+size];offset+=size
 if frame[12:14]!=b'\x08\x00' or frame[23]!=6:continue
 ihl=(frame[14]&15)*4;length=struct.unpack_from('!H',frame,16)[0];tcp=14+ihl
 sport,dport,seq,ack=struct.unpack_from('!HHII',frame,tcp);header=(frame[tcp+12]>>4)*4
 opts={};cursor=tcp+20
 while cursor<tcp+header:
 kind=frame[cursor]
 if kind==0:break
 if kind==1:cursor+=1;continue
 option_length=frame[cursor+1];data=frame[cursor+2:cursor+option_length];assert option_length>=2
 if kind==2:opts['mss']=struct.unpack('!H',data)[0]
 elif kind==3:opts['wscale']=data[0]
 elif kind==4:opts['sack_ok']=True
 elif kind==5:opts['sack']=[list(pair) for pair in struct.iter_unpack('!II',data)]
 cursor+=option_length
 body=frame[tcp+header:14+length]
 result.append({'t':seconds+micros/1e6,'src':socket.inet_ntoa(frame[26:30]),'dst':socket.inet_ntoa(frame[30:34]),
 'sport':sport,'dport':dport,'seq':seq,'ack':ack,'flags':frame[tcp+13],'window':struct.unpack_from('!H',frame,tcp+14)[0],
 'length':len(body),'options':opts,'preview':body[:24].hex()})
 return result
with lab(['client','target']) as (root,stack,setting):
 wire('client','c0','target','t0',['192.0.2.1/30'],['192.0.2.2/30'])
 setting('client','net.ipv4.tcp_sack',1);setting('target','net.ipv4.tcp_sack',1)
 setting('client','net.ipv4.tcp_autocorking',0)
 server_code=r'''
import socket,json,hashlib
listener=socket.socket();listener.bind(('192.0.2.2',18080));listener.listen();print('listening',flush=True)
with listener.accept()[0] as connection:
 connection.settimeout(6);data=b''
 while len(data)<12*256:
 chunk=connection.recv(4096);assert chunk;data+=chunk
 expected=b''.join(bytes([i])*256 for i in range(12));assert data==expected
 result={'bytes':len(data),'sha256':hashlib.sha256(data).hexdigest()}
 connection.sendall(json.dumps(result).encode()+b'\n');print(json.dumps(result),flush=True)
'''
 service=spawn(stack,['ip','netns','exec','target','python3','-u','-c',server_code]);assert line(service).strip()=='listening'
 nft('target','''table ip one_gap {
 chain input { type filter hook input priority 0; policy accept;
 tcp dport 18080 ip length > 100 numgen inc mod 2147483647 == 1 counter drop comment "second_data_packet"
 }
}
''')
 tap,path=capture(stack,root,'client','c0','tcp port 18080','sack')
 client_code=r'''
import socket,json,time,hashlib
s=socket.socket();s.settimeout(6);s.setsockopt(socket.IPPROTO_TCP,socket.TCP_NODELAY,1)
s.bind(('192.0.2.1',40500));s.connect(('192.0.2.2',18080))
for i in range(12):s.sendall(bytes([i])*256);time.sleep(.003)
with s.makefile('rb') as stream:result=json.loads(stream.readline())
expected=b''.join(bytes([i])*256 for i in range(12))
assert result=={'bytes':len(expected),'sha256':hashlib.sha256(expected).hexdigest()}
print(json.dumps(result));s.close()
'''
 result=json.loads(ns('client','python3','-c',client_code).stdout);assert json.loads(line(service))==result
 dropped=counters('target');assert dropped['second_data_packet']==1,dropped
 observed=packets(tap,path);syn=next(p for p in observed if p['flags']&0x12==0x02);synack=next(p for p in observed if p['flags']&0x12==0x12)
 assert syn['options'].get('sack_ok') and synack['options'].get('sack_ok')
 reports=[p for p in observed if p['sport']==18080 and p['options'].get('sack')]
 assert reports,observed
 data_start=(syn['seq']+1)%2**32
 def relative(sequence):return (sequence-data_start)%2**32
 hole=(data_start+256)%2**32
 assert any(relative(p['ack'])==256 and any(256<relative(left)<relative(right)<=3072 for left,right in p['options']['sack']) for p in reports),reports
 retransmissions=[p for p in observed if p['sport']==40500 and p['length'] and p['seq']==hole]
 assert len(retransmissions)>=2,retransmissions
 print(json.dumps({'sack_negotiated_both_directions':True,'missing_byte_sequence':hole,'sack_reports':reports,
 'original_and_retransmitted_hole':retransmissions,'drop_counter':dropped,'verified_delivery':result}))
"""
name='xbcatm-tcpflow-'+uuid.uuid4().hex[:10]
def docker(*args,**kwargs):return subprocess.run(['docker',*args],capture_output=True,text=True,timeout=300,**kwargs)
try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'Dockerfile').write_text(recipe)
 build=docker('build','-t',name,str(root));assert build.returncode==0,build.stderr
 result=docker('run','--rm','-i','--name',name,'--network','none','--cap-add','NET_ADMIN','--cap-add','SYS_ADMIN',
 '--memory','256m','--pids-limit','128',name,'python3','-',input=program)
 assert result.returncode==0,result.stderr
 print(json.dumps(json.loads(result.stdout),sort_keys=True))
finally:
 docker('rm','-f',name);docker('image','rm',name)

两端启用 SACK。客户端启用 TCP_NODELAY，并关闭自己命名空间的自动 corking，然后间隔短暂时间发送十二块可区分数据，每块256字节。目标输入链使用递增表达式，仅丢弃第二个匹配数据包。很大的取模值使这段短传输只出现一次受控丢弃，计数器必须恰好报告一次，避免把不可控随机丢失冒充固定实验条件。

捕获确认两个 SYN 消息均包含 SACK-Permitted。第一块到达后，第二块缺失形成空洞。接收端累计确认停在缺口的首字节，而 SACK 块描述后来已经接收的范围。脚本使用本次实际初始序列号检查这些关系，不要求每次运行采用同一个序列值。数字大小本身没有固定意义，范围之间的对应关系才是需要验证的协议事实。

缺失范围在捕获中先以原始发送段出现，随后以相同序列号重传，本次长度为256字节。服务器最终按预期顺序收到全部3072字节，并检查内容，再返回 SHA-256 摘要。客户端独立将该摘要与计划发送的载荷比较。因此，结果不只是“连接没报错”，而是同时确认重传后真正交付了完整且正确的数据。

这些观察证明真实缺口、有效确认信息、重传与成功交付，却没有对比关闭 SACK 的性能，也不能建立统一重传次数改善比例。单独这份捕获，同样无法说明 Linux 丢失检测决策的每个细节。协商 SACK 与选择何时重传，是相关但不同的传输实现部分；不能把出现一个选择确认块，直接解释成某个特定恢复算法必定触发。

解释反馈时，不承诺重传判断绝对完美

RFC 2018 将 SACK 定义为建议性信息，接收端之后可能丢弃此前报告的数据。因此，发送端不能把 SACK 当作永久应用收据，也不能仅因某个范围出现在选项里，就放弃全部重传责任。累计确认仍是判断哪些字节已被 TCP 按序接受的核心依据，业务是否处理或持久保存数据，还属于更高一层的确认契约。

乱序也可能产生缺口和选择报告，即使报文没有永久丢失。应关联序列范围、重传时间、累计进展与捕获位置，再判断是否存在网络损坏。本例的明确输入过滤和精确丢弃计数，为刻意丢失提供直接证据；原因不明的生产抓包通常没有这种实验控制，不能照搬故障归因，需要补充对应观察。

事件排查应保留握手选项，以及足以重建相关范围的数据交换，分别比较应用交付和传输恢复。正确重组可能使短暂网络丢失不影响应用内容，却仍影响延迟或吞吐量。性能问题需要代表性负载测量，本例则验证协议信息与最终字节交付。这样既能说明 SACK 的作用，也不会用一个小型成功样本替代完整网络性能结论。

来源

RFC 2018 TCP Selective Acknowledgment，已接收字节范围、许可方向与 SACK 的建议性质，已核验 2026-09-12。
RFC 9293 TCP，累计确认、序列空间与可靠字节交付，已核验 2026-09-12。
Linux tcp(7)，Linux TCP SACK 配置与套接字诊断，已核验 2026-09-12。

TLS 会话恢复省一次往返

Sun, 08 Aug 2027 00:00:00 +0000

“省一次往返”需要结合协议版本和 early data 模式理解。TLS 1.3 的普通完整握手，以及不携带 early data 的恢复握手，通常都需要一次 TLS 往返。恢复仍然可以减少证书传输和身份认证开销，但不能把标题理解成“只要开启票据，每个 HTTPS 请求就一定提前一个 RTT 开始”。

新连接仍要派生新的流量密钥

TLS 会话恢复使用先前握手派生的 PSK，为一条新连接建立安全上下文。NewSessionTicket 提供的是与恢复状态关联的不透明标识，不是让后续连接直接沿用原来的流量密钥。新的握手仍会根据自身上下文派生密钥。服务器可以用密码学方法保护票据状态，也可以在不透明标识后保存服务端状态；应用不应把票据解析成一种通用登录凭据。

服务器接受 PSK 认证时，不再发送自己的 Certificate 和 CertificateVerify 消息。恢复可以结合一次新的临时 Diffie-Hellman 交换，获得相应的前向保密；协议也允许仅使用 PSK 的模式，后者没有这项保护。因此，“拿到了票据”既不能证明实际选用了哪种密钥交换，也不能独自证明节省了多少网络等待。

可选的零往返模式允许符合条件的应用数据跟随 ClientHello 一起发送，这与普通会话恢复是两件事。early data 不具有前向保密，并可能跨连接被重放；某条连接后来完成握手，也不能消除另一条连接上已经发生或可能发生的重放。HTTP 服务需要按资源的实际副作用决定能否接受重放风险，并正确处理拒绝，包括规范要求的 425 Too Early 响应。

坏掉的样子

客户端可能根本没有启用票据缓存，可能在处理握手后票据之前就关闭连接，也可能每次请求都重建并丢弃缓存。服务器重启、密钥轮换或票据过期后，也可能不再接受原来的恢复状态。一次恢复尝试最终走完整握手，不自动等于 TLS 服务不可用；恢复比例和建连成功率应该分别观察。

HTTP 连接复用还会让测试混淆。多个请求若沿用同一条已建立连接，根本不会重新握手。验证会话恢复时，必须有意创建新的 TCP 连接，再检查双方报告的协商状态，不能只根据第二次请求耗时较短就下结论。总耗时里还混有调度、传输建连、服务端业务处理和其他缓存效果。

票据及客户端缓存属于敏感状态，应限制适用范围和存续时间，协调服务器密钥轮换，并在认证策略变化时重新审视缓存状态。Go 的 VerifyPeerCertificate 不会在恢复连接上调用，而 VerifyConnection 会覆盖包括恢复在内的所有连接。必须每次检查的自定义策略应放在后者路径上；这并不是关闭标准证书验证的理由，更不能让缓存绕过刚刚收紧的授权规则。

快速验证

将代码保存为 resumption_probe.go，用 Go 1.23 或更新版本运行 go run resumption_probe.go。服务端和客户端都限定 TLS 1.3，测试证书仅在本地测试客户端中受信任。实验禁用 HTTP/1.1 的持久连接复用，但让前两个独立 transport 共享容量为四的 TLS 会话缓存；第三个 transport 刻意不配置缓存。

package main

import (
 "context"
 "crypto/tls"
 "fmt"
 "io"
 "net"
 "net/http"
 "net/http/httptest"
 "runtime"
 "strconv"
 "sync/atomic"
 "time"
)

type connectionKey struct{}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 var serial, verified atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 id := r.Context().Value(connectionKey{}).(int64)
 w.Header().Set("X-Connection-ID", strconv.FormatInt(id, 10))
 w.Header().Set("X-Resumed", strconv.FormatBool(r.TLS.DidResume))
 fmt.Fprintln(w, "ok")
 }))
 server.Config.ConnContext = func(ctx context.Context, connection net.Conn) context.Context {
 return context.WithValue(ctx, connectionKey{}, serial.Add(1))
 }
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()

 base := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 base.MinVersion, base.MaxVersion = tls.VersionTLS13, tls.VersionTLS13
 check(!base.InsecureSkipVerify, "certificate verification must stay enabled")
 base.VerifyConnection = func(state tls.ConnectionState) error {
 if len(state.VerifiedChains) == 0 {
 return fmt.Errorf("verified certificate chain required")
 }
 verified.Add(1)
 return nil
 }
 request := func(cache tls.ClientSessionCache) (int64, bool) {
 config := base.Clone()
 config.ClientSessionCache = cache
 transport := &http.Transport{
 TLSClientConfig: config,
 DisableKeepAlives: true,
 }
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 response, err := client.Get(server.URL)
 check(err == nil, fmt.Sprint(err))
 defer response.Body.Close()
 body, err := io.ReadAll(response.Body)
 check(err == nil, fmt.Sprint(err))
 check(response.StatusCode == 200 && string(body) == "ok\n", "unexpected HTTP reply")
 check(response.ProtoMajor == 1 && response.ProtoMinor == 1, "HTTP/1.1 required")
 check(response.TLS.HandshakeComplete && response.TLS.Version == tls.VersionTLS13, "TLS 1.3 required")
 id, err := strconv.ParseInt(response.Header.Get("X-Connection-ID"), 10, 64)
 check(err == nil, fmt.Sprint(err))
 resumed := response.TLS.DidResume
 check(response.Header.Get("X-Resumed") == strconv.FormatBool(resumed), "peers disagree")
 return id, resumed
 }

 cache := tls.NewLRUClientSessionCache(4)
 firstID, first := request(cache)
 secondID, second := request(cache)
 thirdID, third := request(nil)
 check(firstID == 1 && secondID == 2 && thirdID == 3, "three new TCP connections required")
 check(!first && second && !third, "expected full, resumed, full")
 check(verified.Load() == 3, "VerifyConnection must run for all three handshakes")
 fmt.Printf("new TCP connections: %d %d %d; DidResume: %t %t %t\n",
 firstID, secondID, thirdID, first, second, third)
 fmt.Println("both peers agree; VerifyConnection ran three times; no early data was sent")
 fmt.Println(runtime.Version())
}

每次完整读取响应，让这个测试服务器发出的握手后票据在下一次连接前得到处理。服务端为每条实际接受的 TCP 连接分配独立编号，预期顺序是一、二、三，而 DidResume 依次为 false、true、false。响应头还携带服务器自己看到的恢复状态，必须与客户端一致，不能只检查一端或凭耗时猜测。

VerifyConnection 的计数必须为三，说明恢复连接也经过这个回调，同时标准证书验证始终开启。恢复时保留的已验证证书链状态，关联的是先前认证的会话，并不意味着本次握手重新传输了一份证书消息。会话状态仅保留在内存缓存中；程序不打印票据、私钥和流量机密，也不将它们写入磁盘，不把测试证书安装到机器的全局信任库。

已核验的 macOS、Go 1.27.0 运行通过全部断言。实验直接证明：缓存会话可以在新的传输连接上被接受，没有缓存时则进行完整协商。它没有发送 early data、统计报文往返、基准测试握手 CPU，也没有验证负载均衡集群之间的票据共享与轮换。预估生产提速前，必须分别验证这些条件；本机第二次请求较快，不能代替其中任何一项证据。

来源

RFC 8446：TLS 1.3，第 2.2、2.3、4.6.1、8 节：PSK、票据、early data 与重放，已核验 2026-09-09。
RFC 8470：在 HTTP 中使用 Early Data，重放敏感操作与 425 响应，已核验 2026-09-09。
Go crypto/tls，ClientSessionCache、DidResume 与验证回调，已核验 2026-09-09。
Go net/http/httptest，隔离的回环 HTTPS 测试服务，已核验 2026-09-09。

TLS 握手会拉长延迟，但可以缩小

Mon, 28 Jun 2027 00:00:00 +0000

HTTPS 延迟由多个阶段组成，重复访问可以跳过其中一些阶段，却不一定是加密运算本身变快了。DNS、获取连接、TCP 建连、TLS 认证、服务端处理和响应传输，各自有不同的计时边界。分析前应先确认哪些阶段真的执行过；单看一次请求总耗时，无法区分复用既有连接与新连接上的 TLS 会话恢复。

消息会按批次传输

TLS 握手虽然包含多条消息，但并不是每条消息都需要单独一次往返，多条消息可以在同一批次中发送。通常的 TLS 1.3 完整握手在普通客户端应用数据之前需要一次 TLS 往返，HelloRetryRequest 会再增加一次。TCP 建连和之后的应用请求、响应，还属于另外的成本。

不使用 early data 的普通 TLS 1.3 会话恢复，通常也需要一次 TLS 往返。它能减少证书传输与认证工作，却仍可能执行新的临时密钥交换；恢复时派生的是新流量密钥，不是原封不动继续使用旧加密密钥。可选零往返数据有额外的重放安全限制，不能把一次快速重复请求直接叫作零往返。

HTTP 连接复用则跳过了建立另一条连接的步骤，因此该请求没有新的 TLS 握手。HTTP/2 多路复用也可以让多个流共享已建立连接。相反，关闭空闲连接再重新连接，即使缓存票据允许 TLS 恢复，仍然需要重新完成传输层建立，不能把两种节省混成同一个动作。

坏掉的样子

正常请求若每次创建新的 transport，就会丢掉连接池。响应正文没有读完或关闭，也可能妨碍复用。空闲超时、入口变化或并发需求都可能增加新连接数量，因此在把延迟变化归因于证书算法之前，应先按真实复用情况和握手事件分类，确认自己比较的是同一种路径。

尝试恢复后仍发生完整握手，并不必然意味着服务故障。票据可能过期或被拒绝，客户端也可能没有可用缓存。应保留普通证书验证，并观察最终选择的行为；为赢得性能数字而减少认证检查，改变的是安全约定，不是在同一个操作下获得了免费优化。

计时名称也要有定义。首字节时间包含的不只有 TLS，总时间还包括消费响应内容。跟踪回调可能来自不同协程，收集器必须正确同步。应比较有代表性的分布及连接类别，不能拿几次回环请求的微秒数去预测公网加速，也不能把偶然更快的一次执行写成稳定性能承诺。

快速验证

保存为 latency_probe.go，使用 Go 1.23 或更新版本运行 go run latency_probe.go。实验固定使用经过验证的 TLS 1.3 和 HTTP/1.1，服务端为接受的 TCP 连接编号。第一个 transport 同时保留 HTTP 连接池和 TLS 会话缓存，另一个独立 transport 刻意不配置会话缓存。

package main

import (
 "context"
 "crypto/tls"
 "fmt"
 "io"
 "net"
 "net/http"
 "net/http/httptest"
 "net/http/httptrace"
 "runtime"
 "strconv"
 "sync"
 "sync/atomic"
 "time"
)

type connectionKey struct{}

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 var connections atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 w.Header().Set("X-Connection-ID", fmt.Sprint(r.Context().Value(connectionKey{})))
 w.Header().Set("X-Resumed", strconv.FormatBool(r.TLS.DidResume))
 fmt.Fprint(w, "ok")
 }))
 server.Config.ConnContext = func(ctx context.Context, _ net.Conn) context.Context {
 return context.WithValue(ctx, connectionKey{}, connections.Add(1))
 }
 server.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 server.StartTLS()
 defer server.Close()
 base := server.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 base.MinVersion, base.MaxVersion = tls.VersionTLS13, tls.VersionTLS13
 check(!base.InsecureSkipVerify, "certificate verification must stay enabled")
 cached := base.Clone()
 cached.ClientSessionCache = tls.NewLRUClientSessionCache(4)
 transport := &http.Transport{TLSClientConfig: cached}
 defer transport.CloseIdleConnections()
 fresh := &http.Transport{TLSClientConfig: base.Clone()}
 defer fresh.CloseIdleConnections()
 probe := func(label string, transport *http.Transport, wantID int64, wantReuse, wantResume bool) {
 started := time.Now()
 var mu sync.Mutex
 var handshakeStarted time.Time
 var handshakeError error
 var observation struct {
 got, starts, done, first int
 reused bool
 tlsTime, ttfb time.Duration
 }
 trace := &httptrace.ClientTrace{
 GotConn: func(info httptrace.GotConnInfo) {
 mu.Lock()
 defer mu.Unlock()
 observation.got++
 observation.reused = info.Reused
 },
 TLSHandshakeStart: func() {
 mu.Lock()
 defer mu.Unlock()
 handshakeStarted = time.Now()
 observation.starts++
 },
 TLSHandshakeDone: func(_ tls.ConnectionState, err error) {
 mu.Lock()
 defer mu.Unlock()
 observation.done++
 observation.tlsTime = time.Since(handshakeStarted)
 handshakeError = err
 },
 GotFirstResponseByte: func() {
 mu.Lock()
 defer mu.Unlock()
 observation.first++
 observation.ttfb = time.Since(started)
 },
 }
 request, err := http.NewRequest(http.MethodGet, server.URL, nil)
 must(err)
 request = request.WithContext(httptrace.WithClientTrace(request.Context(), trace))
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 response, err := client.Do(request)
 must(err)
 body, err := io.ReadAll(response.Body)
 closeError := response.Body.Close()
 must(err)
 must(closeError)
 total := time.Since(started)
 check(response.StatusCode == 200 && string(body) == "ok", "wrong response")
 check(response.Proto == "HTTP/1.1", "fixture requires HTTP/1.1")
 check(response.TLS.Version == tls.VersionTLS13 && len(response.TLS.VerifiedChains) > 0, "verified TLS 1.3 required")
 id, err := strconv.ParseInt(response.Header.Get("X-Connection-ID"), 10, 64)
 must(err)
 check(id == wantID && response.TLS.DidResume == wantResume, "wrong connection or resumption")
 check(response.Header.Get("X-Resumed") == strconv.FormatBool(wantResume), "peers disagree on resumption")
 mu.Lock()
 observed, tlsError := observation, handshakeError
 mu.Unlock()
 must(tlsError)
 wantHandshakes := 1
 if wantReuse {
 wantHandshakes = 0
 }
 check(observed.got == 1 && observed.first == 1 && observed.reused == wantReuse, "wrong request trace")
 check(observed.starts == wantHandshakes && observed.done == wantHandshakes, "wrong handshake count")
 check(total >= observed.ttfb && observed.ttfb > 0, "invalid response timing")
 fmt.Printf("%s: conn=%d reused=%t handshakes=%d connection_resumed=%t tls_us=%d ttfb_us=%d total_us=%d\n",
 label, id, observed.reused, observed.done, response.TLS.DidResume,
 observed.tlsTime.Microseconds(), observed.ttfb.Microseconds(), total.Microseconds())
 }
 probe("cold", transport, 1, false, false)
 probe("reuse", transport, 1, true, false)
 transport.CloseIdleConnections()
 probe("resume", transport, 2, false, true)
 probe("no cache", fresh, 3, false, false)
 check(connections.Load() == 3, "four requests must use three TCP connections")
 fmt.Println("timings are observations, not a speedup or wire-RTT assertion")
 fmt.Println(runtime.Version())
}

不随运行耗时变化的结果如下：

请求	TCP 编号	复用连接	新握手次数	DidResume
cold	1	false	1	false
reuse	1	true	0	false
resume	2	false	1	true
no cache	3	false	1	false

第二次请求仍使用连接一。第三次请求前关闭空闲连接，会强制建立另一条 TCP 连接，但不丢弃 TLS 缓存，因此可以恢复会话。第四个请求使用没有缓存的 transport，重新执行完整握手。双方报告的恢复标志必须一致，四个 HTTP 请求总共只使用三条已接受的 TCP 连接。

DidResume 描述的是这条连接最初如何建立，不代表当前 HTTP 请求又触发了一次恢复。如果复用的连接最初通过会话恢复建立，后续响应仍可能报告 true，却没有新握手。因此要把这个连接级标志与当前请求的复用和握手事件一起读，不能把每个 true 响应都计为一次新的恢复连接。

TLS 耗时从 TLSHandshakeStart 计到 TLSHandshakeDone；TTFB 从发起请求前开始，计到响应头首字节可用；总耗时则计到正文读完并关闭。复用那一行的 TLS 耗时为零，是因为没有观察到新握手事件，不代表握手异常快，更不是已经发送 TLS 零往返数据。

已核验的 macOS、Go 1.27.0 运行通过全部断言。程序消费并关闭响应正文，以互斥锁保护跟踪状态，每次请求限时两秒。会话状态只留在内存，不打印票据、私钥或流量机密。恢复连接中的已验证证书链状态属于已认证会话，不能据此推断网络上刚刚又传输了一份新证书。

程序故意不对“加速多少”作断言，计时数字也会随运行变化。它没有数包或测量线上的 RTT、DNS、HTTP/2 或 HTTP/3、early data、集群票据轮换、单独握手 CPU，或者生产延迟分布。跟踪类别可以帮助组织后续测量，但不能把这个本地实验当成那些测量已经完成的结果。

来源

RFC 8446：TLS 1.3，握手批次、会话恢复与 early data 边界，已核验 2026-09-09。
Go net/http/httptrace，请求钩子、握手事件、计时边界和并发，已核验 2026-09-09。
Go net/http，transport 复用与响应正文生命周期，已核验 2026-09-09。
Go crypto/tls，会话缓存与协商后的恢复状态，已核验 2026-09-09。
Go net/http/httptest，隔离 TLS 服务和可信测试客户端，已核验 2026-09-09。

HTTP keep-alive：复用同一条连接

Fri, 28 May 2027 00:00:00 +0000

HTTP 持久连接允许多次请求与响应复用同一条连接，减少重复的 TCP 建连；使用 HTTPS 时，也可能省去新的 TLS 协商。收益取决于网络延迟、响应大小、服务端处理时间以及池中是否已经有可用连接。连接复用不会消除业务计算，也没有承诺某个套接字永远保持打开。讨论优化之前，先明确观察的是哪一段连接、哪个协议版本。

完整报文才允许复用

HTTP/1.1 默认允许持久连接，除非某一方发送 Connection: close，或实际关闭传输连接。通常不必额外添加 Connection: keep-alive。客户端连接池可以保留空闲连接，供符合源、代理、证书和池策略的后续请求使用。连续执行两次独立的命令行程序，通常不会共享内存中的连接池，因而不能凭两次响应成功就断言已经复用。

复用的前提是双方都能识别每条消息的结束位置。响应可以通过准确的 Content-Length、分块传输编码，或无正文响应的协议规则界定边界。如果只能依赖关闭连接表示正文结束，这条连接自然无法留给下一次请求。客户端需要读完响应正文；服务器需要读完请求正文，或者关闭连接。残留字节一旦被当成下一条消息解析，问题就从性能退化变成报文错位。

HTTP 持久连接与 TCP keepalive 也是两回事。后者在传输连接空闲足够久后发送探测，帮助识别失联的对端，不负责 HTTP 消息分界，也不能覆盖代理或应用自己的空闲超时。仅仅打开操作系统的探活选项，并不会让一个已经被代理回收的连接重新可用。排查时应分别记录应用层关闭、传输层错误和连接池回收动作。

顺序复用还不同于流水线请求。客户端可以等前一个响应完成后再发送下一条请求，同时一直使用相同连接。HTTP/1.1 流水线允许提前发送请求，但响应仍须按序返回。因此，仅有持久连接并不具备 HTTP/2 多路复用提供的独立响应流，不能把两者的并发收益混为一谈。

每一跳管理自己的超时

空闲超时按照具体实现的规则衡量无活动时间，请求截止时间则限制一次操作能等待多久，两者需要独立配置。反向代理同时拥有客户端连接和上游连接，两侧可能使用不同协议、连接池和超时。因此，浏览器到边缘复用了连接，并不能证明边缘到源站也复用；看到一侧握手减少，也不能直接解释另一侧的延迟变化。

连接池应结合已知的服务端限制提前淘汰空闲连接，但始终可能发生竞态：客户端刚发送下一条请求，服务器恰好开始关闭。监控应同时包含新建连接数、成功复用次数、连接重置、池占用和请求延迟。保留更久可以减少握手，也会占用文件描述符与内存。应依据实际请求间隔和资源预算确定保留策略，不能仅凭“站点很忙”推导一个固定超时。

坏掉的样子

正文长度错误可能让读取方一直等待，或让下一条响应的开头混进上一条正文。遇到请求挂起时先检查消息分界，再考虑调大超时。另一个常见故障是调用方放弃流式响应，却既不读完也不关闭，导致池中的连接长期占用。此时服务器还有处理能力，新的请求却全在客户端等空位，扩大服务端容量无法解决这个问题。

陈旧连接报错不代表服务器没有执行请求。如果支付已经提交而响应在回程丢失，自动重连并原样重发可能重复扣款。是否重试必须依照方法语义和业务幂等契约判断，不能把传输异常当成回滚证明。HTTP/2 虽然可以在连接上复用多个流，却禁止 Connection、Keep-Alive 等 HTTP/1.x 专属字段；把这些头搬进 HTTP/2 配置没有优化意义。

快速验证

下面是可直接运行的 Python 3 实验：服务器绑定系统分配的回环端口，客户端连续请求四次，结束后关闭测试服务器。它不需要外部服务；内置 HTTP 服务器只用于本地验证，不是部署配置。

from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from threading import Thread

class Handler(BaseHTTPRequestHandler):
 protocol_version = "HTTP/1.1"

 def do_GET(self):
 self.server.connections.append(self.connection)
 self.send_response(200)
 self.send_header("Content-Length", "2")
 if self.path == "/close":
 self.send_header("Connection", "close")
 self.end_headers()
 self.wfile.write(b"ok")

 def log_message(self, *args):
 pass

with ThreadingHTTPServer(("127.0.0.1", 0), Handler) as server:
 server.connections = []
 worker = Thread(target=server.serve_forever, daemon=True)
 worker.start()
 client = HTTPConnection(*server.server_address, timeout=3)
 try:
 for path in ("/one", "/two", "/close", "/four"):
 client.request("GET", path)
 response = client.getresponse()
 assert response.status == 200
 assert response.read() == b"ok"
 sockets = server.connections
 print("reused:", sockets[0] is sockets[1] is sockets[2])
 print("new after close:", sockets[2] is not sockets[3])
 finally:
 client.close()
 server.shutdown()
 worker.join()

预期输出是 reused: True 和 new after close: True。前两次完整读取正文后，第三次仍使用同一个套接字；第三次收到显式关闭指示后，第四次重新建连。这里比较的是服务器持有的连接对象，不是容易误读的响应耗时。实验只证明本地 HTTP/1.1 的复用与关闭行为，没有覆盖 TLS、浏览器连接池或生产代理；部署验证仍应逐跳检查连接标识与新建连接计数。

来源

RFC 9112：HTTP/1.1 连接管理，消息分界、持久连接、重试和关闭，已核验 2026-09-06。
MDN：HTTP/1.x 连接管理，持久连接及其资源成本，已核验 2026-09-06。
RFC 9113：HTTP/2 连接专属字段，HTTP/2 消息禁止使用的字段，已核验 2026-09-06。

EXPLAIN 计划揭示查询路径

Fri, 21 May 2027 00:00:00 +0000

慢查询首先是一个路线问题。EXPLAIN 逐节点画出规划器选择的路径，让你针对真正耗时的步骤去修，而不是凭猜测。

把计划当作路线来读

EXPLAIN 输出是一棵树:根节点是最终答案,真正的活是子节点干的。每个节点有操作名、行数估算和成本,真正值得盯的是离群点——行数估算远大于实际返回数的大扫描,或者与实际执行差距巨大的估算。读树的顺序很关键:要顺着成本最大的节点找,而不是盯着模式里第一个出现的那层。把 EXPLAIN 和 EXPLAIN ANALYZE 并排看,能直接看到规划器「猜的」和真实「跑出来」的差距,慢查询多半就藏在那里。

统计信息决定路线

有索引只是「有了选项」,不等于「会走到那里」。规划器是根据观测到的统计量——行数、可空性、列值分布——来选路线,所以一次 autovacuum、一次大量导入、一次缓存命中率变化,都可能让同一条 SQL 改道。卡在热点路径上的查询,应该在数据画像变化时重新分析,而不是只在建的时候看一次。统计信息过期时,一个 ANALYZE 有时比一顿索引微调改写更能改变计划。把计划当成需要拿真实 EXPLAIN 数据反复复核的证据,而不是背下来就完事的快照。

确认路线真的变了

把计划塞进改动循环:先留下基线 EXPLAIN ANALYZE,加索引或用改写后的 SQL,确认路线真的移动了再宣布成功。如果目标节点还是那个大的扫描、成本结构没变,那这改动无论听起来多顺,都只是表面功夫。经验再丰富,也不如前后两份计划来得实在;真实的执行耗时、取行数也要一并记录。新计划生效后,把前后对比放进合入请求里,让这次收益可追溯、可复现。

坏掉的样子

统计信息过期会让规划器走错路。一次大批量导入之后，如果很久没有跑过 ANALYZE，规划器可能还以为表里只有几千行，而实际已经有几百万行，于是继续选择只在小数据量下才划算的索引或嵌套循环。EXPLAIN ANALYZE 会露出马脚：估算行数与实际行数差出数量级。先跑 ANALYZE 再对比这两个数字，确认路线是基于新鲜画像选出来的，而不是急着加索引。数据分布变化之后不复核计划，再合理的索引也可能建在错误的假设上。

预编译语句会把某一次参数的计划复用到所有参数上。围绕高区分度的首个参数缓存下来的计划，对它很快，对匹配半张表的值却很慢；而你用 EXPLAIN 拿字面量测出的计划，往往并不是线上真正绑定的那个值。排查时要把区分度最高和最低的两个极端值都测一遍，并确认到底命中了定制计划还是通用计划，再下结论。只测一个最顺的值，就等于只看了一半的路线图。

隐式转换会悄悄让索引退休。拿 varchar 列直接和数字比较、排序规则不一致，或者在列上套 LOWER、日期截断，规划器只能全表扫描再过滤，索引明明存在却用不上。症状很固定：Seq Scan 上被过滤掉的行数远大于最终返回行数。修法是把调用处的类型改对，或者补一个匹配表达式的函数索引，让写法和索引站在同一边。类型不对时加再多索引，也只是给用不上的路线添摆设。

只看 cost 是最后一个陷阱。cost 是无量纲的规划估算，不是执行耗时；估算最便宜的计划，实际可能打出天文数字的共享缓冲命中，或者把排序溢出到临时文件。务必用 EXPLAIN (ANALYZE, BUFFERS) 确认，把实际耗时、buffers、被过滤掉的行数和 cost 并排读，几个数字一致向好，才能说这条路线真的健康。脱离 buffers 谈 cost，和脱离实际行数谈估算一样，都是在看路线的广告而不是路况。

快速验证

把下面程序保存到临时工作目录的 plan_route_check.py，运行 python3 plan_route_check.py。它只用标准库模拟两条候选路径——顺序扫描与索引扫描：先按过期的行数估算各自成本，让规划器选出路线，再用实际行数重新打分。程序会打印估算成本与真实成本、估算偏差和统计信息过期告警，并断言告警一定触发：

#!/usr/bin/env python3
"""教学用规划器模型：按估算成本选路线，按实际行数验路线。

仅用标准库。它模拟统计信息过期：规划器以为只有 500 行命中，
实际有 600,000 行，并检查估算偏差告警是否触发。
"""

from __future__ import annotations


def seq_scan_cost(pages: float, rows: float) -> float:
 return pages * 1.0 + rows * 0.01


def index_scan_cost(selectivity_est: float, pages: float, rows: float) -> float:
 heap_pages = selectivity_est * pages
 return 4.0 + heap_pages * 4.0 + selectivity_est * rows * 0.01


def main() -> None:
 pages, rows = 8_000.0, 1_000_000.0
 stale_selectivity = 0.0005 # 规划器的信念：500 行
 true_selectivity = 0.60 # 现实：600,000 行
 est_rows = stale_selectivity * rows
 actual_rows = true_selectivity * rows

 seq = seq_scan_cost(pages, rows)
 idx_est = index_scan_cost(stale_selectivity, pages, rows)
 idx_true = index_scan_cost(true_selectivity, pages, rows)
 chosen = "索引扫描" if idx_est < seq else "顺序扫描"
 print(f"估算行数：{est_rows:.0f}；实际行数：{actual_rows:.0f}")
 print(f"估算成本：顺序扫描={seq:.1f} 索引扫描={idx_est:.1f} -> 规划器选择{chosen}")
 print(f"实际区分度下的真实成本：顺序扫描={seq:.1f} 索引扫描={idx_true:.1f}")

 error = abs(actual_rows - est_rows) / actual_rows
 print(f"估算偏差：{error:.1%}")
 warned = False
 if error > 0.50:
 warned = True
 print("告警：行数估算偏差超过 50%——统计信息已过期，请重新 ANALYZE。")
 if chosen == "索引扫描" and idx_true > seq:
 warned = True
 print("告警：在真实区分度下所选路线更贵——请对照 EXPLAIN ANALYZE。")
 assert warned, "该用例应当触发统计信息过期告警"
 assert est_rows < actual_rows / 10, "用例需保持估算比实际低一个数量级"
 print("PASS：规划器选中了过期路线，估算偏差告警已触发")


if __name__ == "__main__":
 main()

预期看到规划器按过期估算选中索引扫描、接近百分之百的估算偏差，以及最后的 PASS。这组数字是教学用的玩具模型，不是真实优化器：页面成本都是常量，且只有两条路径竞争。它训练的是关键习惯——先记录估算，再拿实际行数对质——带着这个习惯去读生产环境的计划，就不容易被漂亮的 cost 骗过。该实验不连接任何数据库，也无需安装依赖；发布前仍需在真实链路上用 EXPLAIN (ANALYZE, BUFFERS) 复核热点查询，确认路线真的搬动了。

来源

PostgreSQL：EXPLAIN，生成计划，已核验 2027-05-19。
PostgreSQL：使用 EXPLAIN，解读输出，已核验 2027-05-19。
PostgreSQL：规划器与优化器，路线如何被选定，已核验 2027-05-19。
MySQL：EXPLAIN 语句，计划格式与输出列，已核验 2027-05-19。

负载削减保护系统

Sun, 16 May 2027 00:00:00 +0000

负载削减是在全部接收工作会威胁服务时，主动拒绝其中一部分。目标是保留容量，让仍有机会完成的工作继续进行，而不是保证每个获准请求都足够快、都足够重要。拒绝本身也会消耗资源，因此在哪个阶段做准入判断，以及拒绝路径有多贵，与阈值大小同样重要。

保护还能产生价值的容量

过载队列既占内存，也增加等待时间。客户端可能在任务被工作线程取走之前就已经放弃，服务器却继续为无人等待的答案花费资源。更长的队列可以吸收某些突发，但在需求长期超过处理能力时，它不会创造额外容量，只会推迟暴露问题。

Google SRE 讨论了队列限制、资源压力信号、选择性拒绝和降低响应质量。削减与降级相关，但并不相同：拒绝一个请求，不等于完成一个较便宜的版本。后者必须有清楚的产品契约，说明剩下的结果仍有什么价值，不能只是悄悄少做一部分工作。

不同保护机制也可能针对不同组件。Envoy 过载管理器保护代理自身资源，而它的熔断机制主要保护上游服务。依赖熔断器不会自动解决本地内存、连接或文件描述符耗尽，所以不能只看到请求被快速拒绝，就认定整个入口已经免于过载。

选择有依据的政策

按优先级拒绝，可以保护关键业务路径，但 HTTP 方法或是否容易重试，本身并不能决定重要性。一次读取可能非常关键，一次写入也可能只是允许丢弃的遥测。应使用可信的应用分类，而不是任由调用方把自己的所有请求都声明成最高优先级。

统一准入上限或按比例拒绝，也可以是合理政策，不能因为没有业务优先级就一概认为它们错误。需要明确公平性与容量之间的取舍，包括低优先级工作是否可能长期得不到执行，以及不同租户是否共用同一个限制。拒绝顺序应该服务于真实契约，而不是凭方法名称猜测。

请求数量、字节、执行时间和 CPU 成本是不同预算。只限制三个任务，如果每个任务都可以保留任意大的正文，仍然不能约束内存。应选择与受保护资源对应的信号，并通过真实请求组合验证行为，不能把单一计数上限解释成对所有资源的统一保证。

限制准入，而不只是线程数量

线程池的工作线程上限约束同时执行的任务数，不一定限制已经接受、正在排队的工作。只在工作线程内部获取信号量，会让它前面的队列继续增长。应在昂贵工作提交之前做有界准入，并在任务生命周期真正结束时归还容量，而不是等到执行阶段才开始计数。

名称类似的代理限制，也需要精确理解。NGINX limit_conn 按文档规定的连接规则计数；在 HTTP/2、HTTP/3 中，每个并发请求都被单独计入。不能默认某个“连接数上限”始终只是在统计 TCP socket，否则复用连接下的真实请求并发可能与预想完全不同。

下面的实验同时约束排队和运行中的任务。被拒提交不会创建 future；完成回调会在成功、失败或执行前取消后归还名额，而向已经关闭的执行器提交失败，也会归还尚未使用的名额。这样准入预算对应完整生命周期，而不是只覆盖正常结束的路径。

坏掉的样子

如果已经解析巨大正文、打开数据库连接或执行了业务写入，才开始拒绝，可能已经来不及保护目标资源。昂贵的日志和错误响应生成，也可能让拒绝路径本身过载。应一起观察拒绝成本、获准吞吐量、排队时长、活动工作量与资源压力，而不是仅统计拒绝了多少次。

HTTP 503 可以表达服务暂时不可用，429 则表示调用方在某种政策下请求过多。Retry-After 只是等待信号，不证明重放写操作安全，也不保证之后一定存在容量。立即重试可能把刚削减的负载原样加回来，因此拒绝与客户端行为必须放在同一条链路中理解。

不要仅因为调用方停止等待，就提前回收仍在运行任务的名额。等待 future 结果超时，不会终止工作线程。提前归还会让新任务与实际上尚未结束的旧任务重叠，破坏原先承诺的容量上限；资源记账应以工作真实结束为依据。

快速验证

保存为 shedding_check.py，用 Python 3.10 以上版本执行 python3 shedding_check.py。实验已在 Python 3.14.4 上运行，只使用标准库。真实线程等待测试协调事件，不访问外部服务，也不制造生产负载。前后两种配置接收的是同样十二个任务的突发，用来比较获准与等待数量。

from concurrent.futures import ThreadPoolExecutor
from threading import Barrier, BoundedSemaphore, Event, Lock


def exercise(gated):
 slots = BoundedSemaphore(3) # Bounds queued plus running work, not just threads.
 started, release, lock = Barrier(3), Event(), Lock()
 running, began = set(), []

 def held(job):
 with lock:
 running.add(job)
 began.append(job)
 try:
 if job < 2:
 started.wait(timeout=5)
 assert release.wait(timeout=5), "test coordinator did not release workers"
 return job
 finally:
 with lock:
 running.remove(job)

 with ThreadPoolExecutor(max_workers=2) as pool:
 def submit(function, *args):
 if not gated:
 return pool.submit(function, *args)
 if not slots.acquire(blocking=False):
 return None # Explicit local admission refusal; no future was enqueued.
 try:
 future = pool.submit(function, *args)
 except RuntimeError:
 slots.release()
 raise
 # Completion, failure, and cancellation before execution all return the slot.
 future.add_done_callback(lambda _: slots.release())
 return future

 futures = [submit(held, job) for job in range(12)]
 accepted = [future for future in futures if future is not None]
 replacement = None
 try:
 started.wait(timeout=5)
 with lock:
 assert running == {0, 1} and set(began) == {0, 1}
 assert all(not future.done() for future in accepted)
 if gated:
 assert len(accepted) == 3 and futures[3:] == [None] * 9
 assert futures[2].cancel() # Both workers are held, so job 2 has not started.
 replacement = submit(held, 12)
 assert replacement is not None
 assert submit(held, 13) is None
 print("gated burst: 2 running + 1 queued, 9 initial refusals; cancellation returns a slot")
 else:
 assert len(accepted) == 12
 print("ungated burst: 2 workers accept 12 unfinished tasks; the other 10 still wait")
 finally:
 release.set()
 completed = [future.result(timeout=5) for future in accepted if not future.cancelled()]
 if replacement is not None:
 completed.append(replacement.result(timeout=5))
 assert sorted(completed) == ([0, 1, 12] if gated else list(range(12)))

 if gated:
 def fail():
 raise ValueError("injected task failure")

 failed = submit(fail)
 assert failed is not None
 try:
 failed.result(timeout=5)
 except ValueError as error:
 assert str(error) == "injected task failure"
 else:
 raise AssertionError("the failed task must preserve its failure")

 if gated:
 # The executor is now closed; a failed submission must not consume a slot.
 try:
 submit(lambda: None)
 except RuntimeError:
 pass
 else:
 raise AssertionError("submission to a closed executor must fail")
 acquired = [slots.acquire(blocking=False) for _ in range(3)]
 try:
 assert acquired == [True, True, True]
 assert not slots.acquire(blocking=False)
 finally:
 for success in acquired:
 if success:
 slots.release()
 print("completion, task failure, cancellation, and closed-executor submission leave all 3 slots reusable")


exercise(False)
exercise(True)

只有两个工作线程、没有准入门槛时，十二个任务都仍未完成：两个正在运行，十个在等待。增加三个名额后，只接收三个任务，其他九个在提交之前被拒绝。这里获准的是两个运行任务加一个排队任务，不是同时运行三个线程，断言明确区分了两种数量。

取消还在排队的任务，会归还一个名额供替代任务使用，紧接着再提交一个则仍会被拒。协调事件释放线程后，预期任务完成。注入的任务异常和执行器关闭后的提交失败，都保留各自错误；最后通过公开信号量操作确认，三个名额全部可以再次使用。

实验验证的是准入记账与任务生命周期，不是 HTTP 响应、字节限制、优先级调度、生产延迟或自动资源压力控制器。NGINX、Envoy 只作为语义来源被引用，没有在本例中部署或执行。把该机制用于真实服务之前，仍需针对自己的保护对象验证容量与失败路径。

来源

Google SRE：处理过载，关键性、资源信号、拒绝成本与客户端行为，已核验 2026-09-08。
Google SRE：处理级联故障，队列上限、负载削减、截止期限与降级，已核验 2026-09-08。
Envoy 过载管理器，本地资源保护与上游熔断的区别，已核验 2026-09-08。
NGINX 连接限制，请求计数、HTTP/2–HTTP/3 语义与拒绝状态，已核验 2026-09-08。
Python futures，任务提交、结果等待超时、取消与完成回调，已核验 2026-09-08。
Python 线程工具，非阻塞有界信号量准入与协调原语，已核验 2026-09-08。
RFC 9110，服务不可用、Retry-After 与重试安全语义，已核验 2026-09-08。
RFC 6585，第四节单独定义 429 与服务器决定的计数政策，已核验 2026-09-08。

物化视图把查询结果存起来复用

Mon, 26 Apr 2027 00:00:00 +0000

物化视图保存定义查询的结果，让后续读取直接访问这些已存储的行。它把每次读取时的计算转移到刷新阶段，适合重复执行的报表查询。相应代价是明确的新鲜度边界，以及另一份需要维护的关系数据；它既不保证读取瞬间完成，也不会自动与源表保持同步。选择时应比较完整的读写成本。

已存储结果有自己的生命周期

普通视图保存查询定义，物化视图还保存查询结果。PostgreSQL 可以给物化结果建立索引，并直接针对它规划读取，而不必每次重跑原来的关联与聚合。源表发生普通插入或更新时，这份结果不会自动变化。应用也需要明确查询物化视图；创建它并不会让所有等价的源表查询自动改走这份缓存。

REFRESH MATERIALIZED VIEW 重新执行定义查询，再替换存储内容。标准 PostgreSQL 的刷新不是自动增量维护；即使源表只变了几行，定义查询仍然需要生成新的结果。比较物化与反复直接查询时，要把刷新计算、临时工作、存储和索引维护都计入，而不能只测读缓存的那条快速查询。

存储结果本身仍可能很大，或者缺少适合的索引，因此物化不代表任意读取都便宜。应根据报表过滤条件和返回字段，确定聚合粒度和索引。需要稳定顺序时，还应在读取查询中使用 ORDER BY；刷新不承诺保留定义查询所产生的物理排列，不能把上次看到的顺序当成输出契约。

并发刷新改变的是读者访问方式

普通刷新在替换物化内容时可能阻塞读取。CONCURRENTLY 允许 SELECT 在刷新期间继续访问已有结果，新内容何时可见仍遵循事务与快照规则。它依然需要锁、消耗资源，并可能等待其他操作；同一个物化视图在同一时刻也只能运行一个刷新任务，并不是允许任意多次刷新相互并行。

并发刷新要求视图已经有数据，并至少存在一个适用的唯一索引：索引只能使用列名，而且必须覆盖全部行。部分唯一索引或表达式索引都不满足这个条件。该索引用于刷新时识别结果行，并不意味着源表因此变得不可变，也不意味着源表在相同聚合粒度上具备同样的唯一性。

WITH NO DATA 会把视图变为未填充、不可扫描的状态。它不等于一个可以正常 SELECT 的空结果，也不会保留旧缓存答案。需要先通过普通刷新填充，再请求并发刷新。CONCURRENTLY 与 WITH NO DATA 不能组合成绕过这些前置条件的捷径，部署时应区分“零行有效结果”和“尚未生成结果”。

坏掉的样子

仅有刷新计划，并不能保证陈旧程度有上限。任务可能晚启动、运行很久、失败，或者排队等待另一个刷新；生成结果所用的源快照，也早于刷新工作完成的时刻。应记录成功刷新及报表所需的源数据覆盖范围，不能把配置了某个时间间隔当成数据已经及时更新的证据。失败任务不能像成功发布新结果一样推进页面的新鲜度标记。

部署预期使用并发读取路径时，缺少唯一索引或索引形态不符，会导致 CONCURRENTLY 直接失败。正式依赖前，应实际测试这条路径。PostgreSQL 十八的刷新还要求适用的 MAINTAIN 权限，所以定时任务所用角色必须确实能够刷新该关系。以所有者身份手工执行成功，不能证明任务角色也拥有所需权限。

快速验证

把下面内容保存为 materialized.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f materialized.sql。角色需要创建测试 schema 的权限。脚本在事务内创建 matview_demo，末尾整体回滚；如果这个名字已经存在，应选择未使用的名字，而不是删除已有 schema。

\set ON_ERROR_STOP on
BEGIN;
CREATE SCHEMA matview_demo;
SET LOCAL search_path=matview_demo,pg_catalog;
CREATE TABLE sales (region text NOT NULL,amount integer NOT NULL);
INSERT INTO sales VALUES ('east',10),('west',5);
CREATE MATERIALIZED VIEW totals AS SELECT region,sum(amount) AS total FROM sales GROUP BY region;
UPDATE sales SET amount=17 WHERE region='east';
SELECT * FROM totals ORDER BY region;
DO $$ BEGIN
 REFRESH MATERIALIZED VIEW CONCURRENTLY totals;
 RAISE EXCEPTION 'concurrent refresh accepted without unique index';
EXCEPTION WHEN object_not_in_prerequisite_state THEN
 RAISE NOTICE 'concurrent refresh requires an eligible unique index';
END $$;
CREATE UNIQUE INDEX totals_region ON totals (region);
REFRESH MATERIALIZED VIEW CONCURRENTLY totals;
SELECT * FROM totals ORDER BY region;
REFRESH MATERIALIZED VIEW totals WITH NO DATA;
DO $$ BEGIN
 PERFORM * FROM totals;
 RAISE EXCEPTION 'unpopulated view was readable';
EXCEPTION WHEN object_not_in_prerequisite_state THEN RAISE NOTICE 'unpopulated view cannot be read';
END $$;
DO $$ BEGIN
 REFRESH MATERIALIZED VIEW CONCURRENTLY totals;
 RAISE EXCEPTION 'concurrent refresh populated an unreadable view';
EXCEPTION WHEN feature_not_supported THEN RAISE NOTICE 'first population needs a normal refresh';
END $$;
REFRESH MATERIALIZED VIEW totals;
DO $$ BEGIN
 IF (SELECT total FROM totals WHERE region='east') IS DISTINCT FROM 17::bigint OR
 (SELECT count(*) FROM totals) <> 2 THEN RAISE EXCEPTION 'refresh result wrong'; END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 中，源表 east 已经从十变成十七，物化视图仍显示十。没有适用唯一索引时，并发刷新按预期因前置条件不足而失败；创建索引后，刷新把存储的 east 总额改成十七，west 仍然是五。这说明基表变化与物化结果更新之间有明确的刷新边界。

随后，WITH NO DATA 让读取失败，并发刷新也不能直接填充这个不可扫描的视图。普通刷新恢复可读结果，并通过最终断言。这个实验验证状态转换与前置条件，没有测量刷新吞吐量。实际容量评估还应使用真实报表查询，并在有代表性的刷新期间检查读者行为，同时考虑事务边界和任务失败的影响。

来源

PostgreSQL 物化视图，结果存储、索引和刷新用途，已核验 2026-09-10。
PostgreSQL REFRESH MATERIALIZED VIEW，锁、并发刷新前提、权限和未填充状态，已核验 2026-09-10。

请求体限制划定边界

Sun, 18 Apr 2027 00:00:00 +0000

请求体限制约束的是实际接受的输入，而不只是 Content-Length 里写出的数字。应在消费正文时执行限制，并在验证完成之前避免业务提交。压缩输入还需要分别限制编码后的字节和解码后的字节。如果昂贵的内存分配或不可逆写入已经发生，最后再返回 413，并没有守住原本要保护的边界。

明确预算到底计算哪些字节

采用长度分帧时，Content-Length 描述消息正文的长度；HTTP/1.1 分块传输则可能没有预先确定的长度。已声明长度过大，可以提前拒绝，但缺少长度不等于允许无限读取。消息分帧交给 HTTP 实现处理，应用再针对它提供的正文读取器施加自己的预算，不能自行混淆报文边界。

正文读取器不包含 HTTP 头和分块编码的分帧开销，因此这里的限制不是整个网络请求的总字节配额。Content-Encoding: gzip 下，这些正文是压缩后的数据，解码表示可能大得多。应在解压之前约束编码输入，在解压之后再次约束输出；一个很小的压缩包，也可能超过合法的解码大小上限。

限制应来自具体端点的契约，包括单位和支持的内容编码。整个请求体的总量限制，与某个 multipart 文件或字段的限制也不同。流式处理避免一次缓存全部内容，却不会自动限制最终存储量、解析工作或慢速发送方占据请求的时间，不能把“使用流”直接等同于“资源已经受控”。

验证完成之后再暴露副作用

Go 的 MaxBytesReader 在读取超过限制时返回 MaxBytesError。普通 LimitReader 则会在边界处返回 EOF；如果没有额外判断，应用可能把被截断的前缀当成完整输入。最多读取“解码上限加一”个字节，才能区分恰好达到上限的合法正文与确实超过上限的正文。

对 gzip 而言，成功读到一个前缀并不代表校验和有效。在接受未超限的表示之前，需要读到结尾；只关闭解码器不会完成校验。文件发布、数据库修改等动作应放在完整验证成功之后，或者采用带明确中止路径的暂存方案。不能忽略读取错误，仅因为读取器同时返回了一些数据就执行提交。

坏掉的样子

只看 Content-Length 会遗漏未知长度输入；只在解压前使用一个大小上限，会遗漏解压膨胀；先解析、后拒绝，则可能已经花掉需要保护的资源。损坏 gzip 流可以在报错时同时返回正文前缀，错误处理若只检查正文非空，就可能把受损数据变成被接受的业务输入。

字节限制不能修复冲突的 HTTP 分帧，不能验证调用方或文件类型，也不能限制所有并发请求的内存总和。它还无法阻止发送方把很小的正文无限拖慢。因此，时间和并发量需要独立预算；不能把字节上限叫作空闲超时，也不能从一次拒绝成功推导出已经具备高负载防护能力。

快速验证

保存为 body_probe.go，使用 Go 1.23 或更新版本运行 go run body_probe.go。环回测试服务允许最多 64 个编码输入字节和八个解码字节，支持无内容编码或单层 gzip。这里刻意使用很小的常量，是为了验证边界，不是推荐生产参数。计数器代表应用提交点，不会真的写入数据库或上传文件。

package main

import (
 "bytes"
 "compress/gzip"
 "errors"
 "fmt"
 "io"
 "net/http"
 "net/http/httptest"
 "runtime"
 "strings"
 "sync/atomic"
 "time"
)

const encodedLimit int64 = 64
const decodedLimit int64 = 8

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 var committed, handled atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 defer r.Body.Close()
 w.Header().Set("X-Received-Length", fmt.Sprint(r.ContentLength))
 fail := func(err error) {
 var tooLarge *http.MaxBytesError
 if errors.As(err, &tooLarge) {
 http.Error(w, "encoded limit", http.StatusRequestEntityTooLarge)
 } else {
 http.Error(w, "invalid body", http.StatusBadRequest)
 }
 }
 if r.ContentLength > encodedLimit {
 http.Error(w, "encoded limit", http.StatusRequestEntityTooLarge)
 return
 }
 limited := http.MaxBytesReader(w, r.Body, encodedLimit)
 var reader io.Reader = limited
 coding := strings.TrimSpace(strings.ToLower(strings.Join(r.Header.Values("Content-Encoding"), ",")))
 switch coding {
 case "":
 case "gzip":
 decoded, err := gzip.NewReader(limited)
 if err != nil {
 fail(err)
 return
 }
 defer decoded.Close()
 reader = decoded
 default:
 http.Error(w, "unsupported coding", http.StatusUnsupportedMediaType)
 return
 }
 body, err := io.ReadAll(io.LimitReader(reader, decodedLimit+1))
 if err != nil {
 fail(err)
 return
 }
 if int64(len(body)) > decodedLimit {
 http.Error(w, "decoded limit", http.StatusRequestEntityTooLarge)
 return
 }
 committed.Add(1) // No side effect before the complete body passes validation.
 fmt.Fprint(w, "accepted")
 }))
 server.Config.ReadTimeout = 2 * time.Second
 server.Config.ReadHeaderTimeout = time.Second
 server.Start()
 defer server.Close()
 transport := &http.Transport{}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 3 * time.Second}
 probe := func(label string, payload []byte, coding string, chunked bool, want int) {
 request, err := http.NewRequest(http.MethodPost, server.URL, bytes.NewReader(payload))
 must(err)
 if chunked {
 request.ContentLength = -1
 request.TransferEncoding = []string{"chunked"}
 }
 if coding != "" {
 request.Header.Set("Content-Encoding", coding)
 }
 before := committed.Load()
 response, err := client.Do(request)
 must(err)
 body, readError := io.ReadAll(response.Body)
 closeError := response.Body.Close()
 must(readError)
 must(closeError)
 check(response.Proto == "HTTP/1.1" && response.StatusCode == want, label+": wrong status/protocol")
 wantLength := len(payload)
 if chunked {
 wantLength = -1
 }
 check(response.Header.Get("X-Received-Length") == fmt.Sprint(wantLength), "wrong wire framing")
 delta := int64(0)
 if want == 200 {
 delta = 1
 check(string(body) == "accepted", "wrong successful body")
 }
 check(committed.Load() == before+delta, label+": rejected input caused a side effect")
 fmt.Printf("%s: status=%d committed=%d\n", label, response.StatusCode, committed.Load())
 }
 compress := func(value, name string) []byte {
 var buffer bytes.Buffer
 writer := gzip.NewWriter(&buffer)
 writer.Name = name
 _, err := writer.Write([]byte(value))
 must(err)
 must(writer.Close())
 return buffer.Bytes()
 }
 smallGzip := compress("12345678", "")
 expansion := compress(strings.Repeat("a", 1024), "")
 largeHeader := compress("12345678", strings.Repeat("h", 80))
 check(int64(len(expansion)) <= encodedLimit && int64(len(largeHeader)) > encodedLimit, "gzip fixtures must cross different limits")
 corrupt := append([]byte(nil), smallGzip...)
 corrupt[len(corrupt)-8] ^= 0xff

 probe("exact decoded limit", []byte("12345678"), "", false, 200)
 probe("known oversized", []byte("123456789"), "", false, 413)
 probe("chunked oversized", []byte("123456789"), "", true, 413)
 probe("known encoded limit", bytes.Repeat([]byte("x"), 65), "", false, 413)
 probe("compressed expansion", expansion, "gzip", false, 413)
 probe("exact gzip body", smallGzip, "GZip", false, 200)
 probe("chunked gzip header", largeHeader, "gzip", true, 413)
 probe("bad gzip checksum", corrupt, "gzip", false, 400)
 probe("unsupported coding", []byte("12345678"), "br", false, 415)
 probe("stacked coding", smallGzip, "gzip, gzip", false, 415)
 probe("recovery", []byte("small"), "", false, 200)
 check(handled.Load() == 11 && committed.Load() == 3, "eleven requests must yield three commits")
 fmt.Println(runtime.Version())
}

十一次请求依次检查：恰好达标的普通正文、已知长度超限、分块正文超限、声明的编码长度超限、gzip 膨胀、恰好达标的 gzip、大头部且未知长度的 gzip、损坏校验和、不支持的编码、叠加编码以及恢复请求。只有合法普通正文、合法 gzip 和最后的小正文增加提交计数，总计三次。

超限返回 413，损坏校验和返回 400，不支持或叠加的编码返回 415。混合大小写的 GZip 可以接受，因为内容编码名称不区分大小写。服务端还回显实际收到的 ContentLength，未知长度场景必须显示 -1；这样确认的是实际请求分帧，而不是客户端对象里某个配置字段已经被设置。

大 gzip 头部的输入超过编码限制，但解码正文仍然很小；膨胀样本则符合编码限制，却超过解码限制。两者分别验证不同预算，不能把每次 413 都算成同一条分支已经受检。失败场景逐次核对提交计数不变，最后的正常请求则证明拒绝之后服务仍然能够继续接受合法输入。

已核验的 macOS、Go 1.27.0 运行通过全部断言。读取与请求均有限时，响应正文均被关闭。实验没有测量内存分配，没有注入慢速客户端，没有解析 multipart 或 JSON 结构，没有验证反向代理，也没有证明数据库事务持久性。这些内容必须通过各自的测试补充，不能从计数器的正确变化直接外推。

来源

RFC 9110：HTTP 语义，Content-Length、内容编码和 413、415 语义，已核验 2026-09-09。
Go net/http，MaxBytesReader、请求正文生命周期、分帧和超时，已核验 2026-09-09。
Go compress/gzip，解码流与读取到 EOF 时的校验和验证，已核验 2026-09-09。
OWASP：文件上传安全清单，上传预算、解压后限制和其他验证边界，已核验 2026-09-09。

请求缓冲决定后端何时收到上传正文

Tue, 13 Apr 2027 00:00:00 +0000

一次上传经过两条连接：客户端到 nginx，以及 nginx 到应用。proxy_request_buffering on 会先读完客户端请求正文，再把该请求发送给上游。关闭它后，nginx 可以随着正文到达逐步转发。这个选择改变应用何时开始占用资源，却不会创造无限容量，也不会使慢发送方消失。应先明确应用是否需要边收边处理，再决定正文在哪一层等待。

坏掉的样子

常见错误是关错指令。proxy_buffering 控制响应，proxy_request_buffering 控制上传请求。仅关闭响应缓冲，流式上传仍可能停在代理处。反过来，如果应用原本应接收完整的小型提交，却在全站关闭请求缓冲，又没有考虑后端并发能力，慢客户端就可能长时间占住应用处理资源。两个方向的策略不能因为名称相似就混为一谈。

缓冲把资源压力转移到 nginx。请求正文超过配置的内存缓冲后，可以使用客户端正文临时存储。因此，大量并发上传会占用代理连接，并可能消耗磁盘空间或磁盘读写能力。增大某个缓冲值不能代替正文大小、上传超时、并发限制和临时文件系统容量规划。缓冲区也不需要一律扩大到能在内存中容纳完整上传。

流式转发还改变失败处理。nginx 一旦已经开始向上游发送请求正文，就不能简单把这个流式请求交给下一台服务器。应用可能已经处理前缀数据，甚至产生副作用。缓冲可以为某些重试路径保留正文，但不能让原本不安全的业务操作突然变得可安全重放。是否允许重试，还取决于实际方法、应用语义以及已经完成的工作。

快速验证

将脚本保存为 check-upload.py，先取得其中固定摘要的镜像，再用宿主 Python 和 Docker 执行。记录环境为 Linux arm64 上的 nginx 1.28.0、Python 3.11.16 容器。脚本建立专用后端网络，只把 nginx 发布到宿主回环地址，最后清理自己的容器、镜像标签和网络；已有服务不参与实验：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True)
 target.write_bytes(content if isinstance(content,bytes) else content.encode())
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 docker('run','-d','--name',containers[0],'--network',name,'-p','127.0.0.1::8080',tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 request.port=port
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'
import hashlib
backend=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
import hashlib,json,threading
state={};lock=threading.Lock()
class Handler(BaseHTTPRequestHandler):
 protocol_version='HTTP/1.1'
 def log_message(self,*args):pass
 def reply(self,data):
 data=json.dumps(data).encode();self.send_response(200)
 self.send_header('Content-Length',str(len(data)));self.end_headers();self.wfile.write(data)
 def do_GET(self):
 with lock:self.reply(dict(state))
 def do_POST(self):
 length=int(self.headers['Content-Length'])
 with lock:state[self.path]={'entered':True,'bytes':0}
 first=self.rfile.read(1)
 with lock:state[self.path]['bytes']=len(first)
 body=first+self.rfile.read(length-1)
 with lock:state[self.path]['bytes']=len(body)
 self.reply({'length':len(body),'sha256':hashlib.sha256(body).hexdigest()})
ThreadingHTTPServer(('0.0.0.0',8081),Handler).serve_forever()
'''
locations='''
location /on { proxy_request_buffering on; proxy_pass http://backend:8081; }
location /off { proxy_request_buffering off; proxy_pass http://backend:8081; }
location /state { proxy_pass http://backend:8081; }
'''
with lab(config(locations,'client_max_body_size 1m; proxy_http_version 1.1;'),backend=backend) as (_,request):
 payload=b'x'*65536;results={}
 def state():return json.loads(request('/state')[2])
 for mode in ('on','off'):
 connection=http.client.HTTPConnection('127.0.0.1',request.port,timeout=10)
 connection.putrequest('POST','/'+mode);connection.putheader('Content-Length',str(len(payload)))
 connection.endheaders();connection.send(payload[:1024])
 if mode=='off':wait(lambda:state().get('/off',{}).get('bytes')==1)
 else:
 until=time.monotonic()+1
 while time.monotonic()<until:
 assert '/on' not in state();time.sleep(.05)
 before=state().get('/'+mode)
 connection.send(payload[1024:]);response=connection.getresponse();data=json.loads(response.read());connection.close()
 assert response.status==200 and data=={'length':65536,'sha256':hashlib.sha256(payload).hexdigest()}
 results[mode]={'before_completion':before,'result':data}
 connection=http.client.HTTPConnection('127.0.0.1',request.port,timeout=5)
 connection.putrequest('POST','/off-too-large');connection.putheader('Content-Length',str(2*1024*1024))
 connection.endheaders();response=connection.getresponse();response.read();connection.close()
 assert response.status==413 and '/off-too-large' not in state()
 results['oversize_status']=response.status
 print(json.dumps(results,sort_keys=True))

客户端声明正文共 65,536 字节，起初只发送 1,024 字节。开启请求缓冲时，在受控暂停期间反复读取后端状态，都看不到上传处理器被进入。客户端已经开始发送，但应用还没有被要求消费不完整正文。直接观察后端状态，比只比较整个请求耗时更能说明等待发生在哪一层，也避免把一次快速响应误当成流式处理证据。

关闭请求缓冲时，后端在客户端补齐正文之前就进入处理器，并记录已经读到第一个字节，随后等待声明长度中的剩余部分。这验证的是真实上传过程中的转发，而不仅是 nginx 能接受某行配置。后端故意采用简单读取顺序，使“已经开始处理、尚未收完正文”这个中间状态可以明确观察和断言。

发送剩余数据后，两种模式都返回长度 65,536，并得到同一个预期 SHA-256 摘要。因此，虽然处理时机不同，本次缓冲与流式路径都保留了原正文。断言核对实际收到的字节，不只检查成功状态码。它也不代表所有应用解析器、数据保存操作或断线恢复策略已经验证；这些需要根据真实端点的行为另行覆盖。

另一个请求在一兆字节限制下声明两兆字节正文。客户端尚未发送正文，nginx 就返回 413，后端也没有对应处理记录。这是代理执行正文大小策略，关闭请求缓冲并不会关闭这项限制。实验刻意使用已知 Content-Length 的定长消息，让拒绝时机可以直接观察，不把未知长度流的接收过程混进这一结论。

先确定上传契约，再调整缓冲

如果应用工作资源稀缺，希望让慢发送方先在代理等待，且代理存储成本可接受，可以选择缓冲上传。如果应用必须逐步处理传入数据，就选择流式路径，同时承担后端资源占用和不完整提交的处理责任。两种模式都不保证写入方永远不会被下游容量限制；缓冲只能吸收一定程度的速度差。

请求和响应策略应分别决定。某个端点可以先接收缓冲上传，再流式返回进度；也可以流式接收上传，最后返回很小的缓冲结果。上游响应中的 X-Accel-Buffering 控制响应缓冲，不能取代这里验证的请求正文策略。检查配置时应明确每条指令影响哪条数据流。

扩展实验时，还要检查消息分帧和上游协议。在 nginx 1.28.0 中，客户端采用 HTTP/1.1 chunked 上传时，需要启用 HTTP/1.1 代理，才能避免该路径强制缓冲。这里显式选择了上游 HTTP/1.1，但实际测试的是定长正文。如果真实端点还接受分块正文或需要处理中途断开，就应针对这些契约补充验证，不能从本次定长上传结果直接推断。

来源

nginx proxy module，请求缓冲、流式请求重放限制与上游 HTTP 版本，已核验 2026-09-12。
nginx HTTP core module，请求正文大小限制、内存缓冲与临时存储，已核验 2026-09-12。
RFC 9110 HTTP Semantics，Content-Length 与 413 响应的语义，已核验 2026-09-12。

HTTP/3 与 QUIC 按流恢复

Sun, 21 Mar 2027 00:00:00 +0000

下一代 HTTP 从 TCP 转向 QUIC——一种在 UDP 之上、自带可靠性机制的传输。收益是:一条流上的丢包,不再像 TCP 上的 HTTP/2 那样卡住整条连接。

为什么 TCP 是上限

HTTP/2 在一条 TCP 连接上多路复用许多流,但 TCP 本身只认得一条字节流。一旦丢包,TCP 必须重传,并按字节序补好,这条连接上的所有流都要等它恢复完毕才能继续。这正是 HTTP/2 从它的传输层继承下来的那块队头阻塞。要让某个流不拖累邻居,办法不是修 TCP,而是换一种传输:给每条流各自的可靠交付,对方的序号不再和整条连接绑在一起。HTTP/3 要拆的,正是这层天花板。

QUIC 换了传输,没换语义

HTTP/3 继承了 HTTP/2 的大多数设计——多路复用、头压缩、流优先级——但把它们跑在 QUIC 上,而 QUIC 是坐在 UDP 之上、自带安全设计的传输。它实现了逐流的流控与丢包恢复、自带加密,还能在网络路径变化时迁移连接——这些都是 TCP 做不到的。对应用来说语义几乎不变:同样是方法、URL、状态码。真正移动的是字节被保护的方式、连接是哪一层维护的,而这正是让「一条流丢包不再拖垮整页」的机制所在。

何时它最要紧

逐流恢复的回报在丢包严重的路径上最明显:移动网络信号不稳、高延迟的末段链路、以及链路质量差的跨区网络——正是当年一条停滞的流就能把整页拖住的地方。这又是一种协商式升级,客户端与服务器都同意才启用;不支持 QUIC 的地方自动回落 HTTP/2,网站方不需要任何操作。所以往前滚是渐进而兼容的:部署风险低,收益又恰好集中用户最敏感的那一路——不稳定的连接上。

坏掉的样子

QUIC 依然跑在 UDP 之上,而不少网络把 UDP 当成可疑流量。企业防火墙和老旧中间设备可能限速乃至直接丢弃 UDP,或者只放行 DNS 那样的小包,却丢掉更大的 QUIC 数据包。故障现象很少是一句干净的报错:Alt-Svc 广播了 HTTP/3,客户端尝试 QUIC,握手超时后才回落到 TCP 上的 HTTP/2。如果回退计时器设得太宽松,用户感受到的反而是升级带来的退化,页面打开更慢而非更快。因此要按网络类型统计握手成功率,保留可用的 TCP 通路,并给回退设置明确的超时上限。

0-RTT 恢复是第二个陷阱。重放 ClientHello 省下一轮往返,但服务端作为早期数据接受的任何内容,都可能被旁观者再次重放。RFC 9001 因此把早期数据限定在可重放的安全操作内,通常只适合安全的 GET,只有幂等请求才可考虑。如果在 0-RTT 里发送非幂等的 POST,就可能把同一笔订单或扣款重复执行两次。服务端必须拒绝高风险的早期数据,或补上显式的抗重放、去重与幂等键处理,不能默认接受。

连接迁移也有自己的边界。QUIC 用连接标识而非四元组识别连接,手机从无线切换到蜂窝网时无需重新握手即可继续,这是它相对 TCP 的显著优势。但 NAT 重绑定看起来很相似,陈旧的 NAT 绑定或按地址哈希的负载均衡器,可能把回包送到无处可去的地方。端点必须按 RFC 9000 先验证新路径再信任它,否则迁移就会变成静默黑洞,连接看似存活却不再进包。

最后,不要承诺 QUIC 消灭了所有排队。它消除的是流之间的传输层队头阻塞,连接级的拥塞控制与流控依然存在。瓶颈链路饱和时,所有流会一起变慢;用尽自身流控窗口的流也会暂停,只是邻居不受牵连。逐流恢复隔离的是丢包,而不是过载。把拥塞当丢包优化,只会误判收益。

快速验证

把下面程序保存为临时目录中的 quic_streams.py,运行 python3 quic_streams.py。它模拟四条流、每条十个包,其中零号流第三个包丢失,再对比理想化的 QUIC 调度与 TCP 调度。全程不打开套接字,只是调度时刻的数值计算,而非真实网络抓包,适合快速理解语义差异。

STREAMS = 4
PACKETS = 10
LOST_STREAM = 0
RETRANSMIT_PENALTY = 3


def quic_completion():
 """Each stream recovers on its own: only the lossy stream pays."""
 completions = []
 for stream in range(STREAMS):
 if stream == LOST_STREAM:
 completions.append(PACKETS + RETRANSMIT_PENALTY)
 else:
 completions.append(PACKETS)
 return completions


def tcp_completion():
 """One ordered byte stream: a single loss blocks every stream."""
 blocked_at = PACKETS + RETRANSMIT_PENALTY
 return [blocked_at] * STREAMS


def main():
 quic = quic_completion()
 tcp = tcp_completion()
 # Only the stream that lost a packet waits for retransmission.
 assert quic[LOST_STREAM] == PACKETS + RETRANSMIT_PENALTY, quic
 assert all(t == PACKETS for i, t in enumerate(quic) if i != LOST_STREAM), quic
 # TCP cannot release later bytes until the loss is repaired.
 assert all(t == PACKETS + RETRANSMIT_PENALTY for t in tcp), tcp
 quic_blocked = sum(1 for t in quic if t > PACKETS)
 tcp_blocked = sum(1 for t in tcp if t > PACKETS)
 assert quic_blocked == 1, quic
 assert tcp_blocked == STREAMS, tcp
 print(f"QUIC completion: {quic} (blocked streams: {quic_blocked})")
 print(f"TCP completion: {tcp} (blocked streams: {tcp_blocked})")
 print("PASS: loss stalls one QUIC stream but all TCP streams")


if __name__ == "__main__":
 main()

QUIC 调度下三条健康流在时刻十完成,只有丢包的流等到时刻十三。TCP 调度下所有流都在时刻十三完成,因为单一有序字节流在丢包修复前无法释放后续字节。脚本断言这种隔离性,再打印两组完成向量与阻塞流数量。模型故意忽略拥塞控制、流控窗口与乱序,只隔离丢包恢复,让队头阻塞的差异一次运行即见分晓,也便于对照正文的结论复核。

来源

Cloudflare：HTTP/3 与 QUIC，协议原理，已核验 2027-03-19。
RFC 9000：QUIC，传输协议，已核验 2027-03-19。
RFC 9114：HTTP/3，HTTP on QUIC，已核验 2027-03-19。

读 EXPLAIN 估算时要带上执行上下文

Fri, 19 Mar 2027 00:00:00 +0000

EXPLAIN 描述 PostgreSQL 打算执行的计划，EXPLAIN ANALYZE 则真正执行它并补充测量结果。比较这两组数字之前，必须先理解每个数字究竟在数什么。表面上的估计偏差，既可能来自统计过时，也可能来自节点重复执行，或者父节点提前停止取行。行数吻合只能增强我们对模型某一部分的信任，不能证明这个计划已经是所有可能方案里最快的一个。

把节点放回执行上下文

估计的 rows 是节点输出行数，不一定是它实际检查的全部元组数。一个扫描可以检查几千条记录，过滤后只交出十条。启动成本与总成本使用规划器自己的单位，不是毫秒。父节点的成本已经包含子节点工作，因此把整棵树所有成本相加会重复计算。实际时间也通常包含子节点耗时，不能把它当成彼此独立的一组费用来求和。

对于重复执行的节点，实际行数和耗时按每次执行的平均值报告，执行次数由 loops 表示。一个实际输出两行、循环三次的节点，总共提供六行。过滤掉的行数同样按每轮平均值展示，四舍五入可能影响小数字。应当从底部扫描向上追踪，找到实际数据规模第一次明显偏离估计的位置，同时遵守这些执行边界，而不是挑出整棵树中最显眼的一对数字就下结论。

LIMIT、EXISTS 等上层操作还可能提前停止请求子节点。此时子节点的估计描述完整执行时可能产生的输出，实际值却只记录父节点真正取走的部分。这不自动意味着统计错误。排序也可能已经读完整个输入，却只向上交出所需的前几行；“输出少了”与“底层工作少了”不是一回事。

坏掉的样子

给写语句加上 EXPLAIN ANALYZE 会真的执行写入。外层事务回滚可以保护事务性的表变更，但不能撤销所有副作用，例如序列已经发出去的号码，或函数调用触发的外部行为。在执行测量前，应使用可丢弃的夹具，或者明确语句及其函数、触发器的完整副作用。不能因为输出长得像报告，就把它视为只读操作。

另一个常见误判是仅凭 BUFFERS 诊断磁盘。共享缓冲区命中表示没有发生 PostgreSQL 缓冲区未命中；报告中的读取仍可能由操作系统缓存满足，不能直接等同于设备读取次数，访问计数也不是不同数据块的数量。即使估计行数完全准确，仍可能存在锁等待、内存不足引发的临时文件、配置问题，或没有被选中的更合适访问路径。

快速验证

在 PostgreSQL 18 的 psql 中执行下面事务。它建立三个父记录、三十个子记录，分别观察重复的横向子查询和单独的前三名查询。数据全部放在临时表中，最后回滚清理，避免把演示对象留在业务表里。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE parents (id integer PRIMARY KEY);
CREATE TEMP TABLE children (parent_id integer,value integer);
INSERT INTO parents VALUES (1),(2),(3);
INSERT INTO children SELECT 1+(g-1)%3,g FROM generate_series(1,30) AS g;
ANALYZE parents;
ANALYZE children;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT p.id,c.value FROM parents p CROSS JOIN LATERAL (
 SELECT value FROM children WHERE parent_id=p.id ORDER BY value DESC LIMIT 2
) c;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT value FROM children ORDER BY value DESC LIMIT 3;
SELECT p.id,c.value FROM parents p CROSS JOIN LATERAL (
 SELECT value FROM children WHERE parent_id=p.id ORDER BY value DESC LIMIT 2
) c ORDER BY p.id,c.value DESC;
DO $$ BEGIN
 IF (SELECT array_agg(value ORDER BY parent_id,value DESC) FROM (
 SELECT p.id AS parent_id,c.value FROM parents p CROSS JOIN LATERAL (
 SELECT value FROM children WHERE parent_id=p.id ORDER BY value DESC LIMIT 2
 ) c
 ) s) IS DISTINCT FROM ARRAY[28,25,29,26,30,27] THEN RAISE EXCEPTION 'wrong lateral result'; END IF;
END $$;
ROLLBACK;

PostgreSQL 18.6 实测的横向查询采用嵌套循环。内层 Limit 显示实际行数为二、loops=3，因此整个连接输出六行。其下的扫描每轮返回十个符合条件的孩子，并过滤掉二十个，所以它在三轮里每轮都检查了三十条子记录。把这些数字放在一起读，才不会误以为整个查询只看过十行。

最终按父编号和数值倒序输出的结果是：父记录一得到二十八、二十五，父记录二得到二十九、二十六，父记录三得到三十、二十七。断言核对这些具体成员，不依赖执行计划长什么样。即使别的版本选择了不同扫描方式，返回集合与排序要求仍须保持正确，不能用计划变化掩盖结果变化。

单独查询前三名时，排序节点估计可以输出三十行，但实际上只交出三行，因为上层已经停止取数。底下扫描仍然读取三十行。实验刚刚分析过数据，这里的差异展示的是节点消费语义，而不是需要再跑一次分析的证据。如果忽视提前停止，就会把健康计划误诊成统计失真。

针对真正的问题选择测量

TIMING OFF 保留实际行数和总体执行时间，同时避免每个节点反复读取时钟的开销；BUFFERS 补充页面访问情况，结构化的 JSON 输出则便于系统比较。这些选项都不能让测量值自动等于应用请求延迟：客户端传输、页面渲染、连接建立和并发负载仍需要另外观察。比较计划时应保留相同参数及相关会话设置，把变化解释为处理行数、循环次数、内存溢写或等待的变化，而不是只凭节点名称换了就认定发生回归。

来源

PostgreSQL 18：EXPLAIN，执行副作用与测量选项，已核验 2026-09-10。
PostgreSQL 18：使用 EXPLAIN，行数、循环次数与计划解读，已核验 2026-09-10。

上游 keepalive 缓存空闲连接，不限制活动容量

Mon, 15 Mar 2027 00:00:00 +0000

nginx 上游 keepalive 缓存会保留符合条件的空闲后端连接，供后续请求复用。在本次配置中，keepalive 2 允许每个 worker 为该上游缓存保留两条空闲连接，并不把 worker 的活动后端连接限制为两条。复用可以减少重复建立连接的开销，却不会自动施加应用并发预算，也不能保证每个请求的延迟都下降。空闲保留与活动容量需要分别理解。

坏掉的样子

把空闲缓存大小误当成连接上限，会让后端同时承受的工作量超过预期。忙碌 worker 可以继续新建活动连接，而保留的空闲缓存仍很小。存在多个 worker 时，各自的空闲缓存也需要计入资源。将 nginx 配置与后端真实连接容量比较时，应分别统计活动与空闲资源，不能只拿一个 keepalive 数字作为全部连接预算。

复用要求协议交换本身可以继续使用。在这个 nginx 1.28.0 HTTP 示例中，上游 HTTP/1.1 和清除默认 Connection: close 都是显式配置。仅设置 Host 并不能建立持久连接。后端仍可能主动关闭连接，不完整或分帧错误的消息，也不能仅因为配置了缓存，就被当成干净可复用的交换。连接是否适合归还空闲缓存，需要实际通信满足条件。

客户端持久连接属于另一组连接关系。新的客户端连接可以使用之前缓存的上游连接；长时间存在的客户端也可能触发多条后端连接。假设两者生命周期总是一致，会产生误导性测量。建立连接的节省也取决于后端使用明文 HTTP 还是 TLS；本次 nginx 后面采用明文 HTTP，因此没有把 TLS 握手节省写成已测结果。

快速验证

将脚本保存为 check-upstream-keepalive.py，准备 Python、Docker 和固定镜像后执行。实验使用单个 nginx 1.28.0 worker，以及专用网络里的 Python HTTP/1.1 后端。后端为每条接收连接分配身份，每个响应都提供明确长度。客户端通过宿主回环进入 nginx，实验结束后清理自己的资源，不接入已有业务连接池：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True)
 target.write_bytes(content if isinstance(content,bytes) else content.encode())
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 docker('run','-d','--name',containers[0],'--network',name,'-p','127.0.0.1::8080',tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 request.port=port
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'
from concurrent.futures import ThreadPoolExecutor
backend=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
import itertools,json,threading
ids=itertools.count(1);lock=threading.Lock();opened=set();active=set();release=threading.Event()
class Handler(BaseHTTPRequestHandler):
 protocol_version='HTTP/1.1'
 def setup(self):
 super().setup();self.ident=next(ids)
 with lock:opened.add(self.ident)
 def finish(self):
 try:super().finish()
 finally:
 with lock:opened.discard(self.ident)
 def log_message(self,*args):pass
 def do_GET(self):
 if self.path=='/hold':
 with lock:active.add(self.ident)
 assert release.wait(15)
 with lock:active.remove(self.ident)
 elif self.path=='/release':release.set()
 with lock:data=json.dumps({'connection':self.ident,'active':sorted(active),'other_open':sorted(opened-{self.ident}),
 'host':self.headers.get('Host'),'connection_header':self.headers.get('Connection')}).encode()
 self.send_response(200);self.send_header('Content-Length',str(len(data)));self.end_headers();self.wfile.write(data)
ThreadingHTTPServer(('0.0.0.0',8081),Handler).serve_forever()
'''
locations='''
location /reuse/ { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass http://pool/; }
location /close/ { proxy_http_version 1.1; proxy_set_header Connection close; proxy_pass http://pool/; }
location /host-only/ { proxy_http_version 1.1; proxy_set_header Host service.example; proxy_pass http://pool/; }
location /control/ { proxy_set_header Connection close; proxy_pass http://backend:8081/; }
'''
extra='upstream pool { server backend:8081; keepalive 2; keepalive_timeout 30s; }'
with lab(config(locations,extra),backend=backend) as (_,request):
 def get(path):
 status,_,body=request(path);assert status==200;return json.loads(body)
 results={}
 for mode in ['reuse','close','host-only']:
 first=get('/'+mode+'/id');second=get('/'+mode+'/id')
 assert (first['connection']==second['connection'])==(mode=='reuse')
 if mode=='host-only':assert first['host']=='service.example' and first['connection_header']=='close'
 results[mode]={'connections':[first['connection'],second['connection']],'host':first['host'],'connection_header':first['connection_header']}
 with ThreadPoolExecutor(max_workers=4) as pool:
 futures=[pool.submit(get,'/reuse/hold') for _ in range(4)]
 wait(lambda:len(get('/control/state')['active'])==4)
 active=get('/control/state')['active'];assert len(set(active))==4
 get('/control/release');replies=[f.result(timeout=10) for f in futures]
 assert len({r['connection'] for r in replies})==4
 wait(lambda:len(get('/control/state')['other_open'])==2)
 results['concurrent_active']=active;results['idle_after_burst']=get('/control/state')['other_open']
 print(json.dumps(results,sort_keys=True))

连续两次 /reuse/id 返回相同后端连接身份。客户端辅助函数每次请求都新建并关闭自己的 HTTP 连接，因此观察到的是跨不同下游连接的上游复用。该 location 显式使用上游 HTTP/1.1，并且不发送 Connection 头。每个响应完整读完后，后端交换才具备进入空闲状态的条件，不能在正文尚未消费完时仅凭状态成功判断连接可复用。

/close/id 对照发送 Connection: close，连续请求得到不同后端连接身份。/host-only/id 对照修改 Host，却保留关闭行为，响应同样使用不同连接。这些比较说明：即使所有路径连接同一个应用，用于路由的头也不能替代正确的持久连接设置。观察请求头和连接身份，比只看两次请求都成功更有解释力。

接着，四个客户端请求由后端故意保持未完成的响应。控制端等到后端报告四个活动连接身份后，才放行任何响应。这直接展示 keepalive 2 下仍有四条并发上游连接，不是根据耗时猜测并发，也不是数四个可能顺序完成的请求。受控等待使活动连接数量成为可以直接检查的中间状态。

放行后，四个响应全部完成。实验随后观察到恰好两条剩余空闲后端连接，计数排除了用于查询状态的短期控制连接。最终保留哪些身份会随完成顺序变化，断言关心的是数量。这样就能区分配置规定的空闲保留上限，与突发期间实际使用的更大活动连接集合，避免把两种阶段混成一个总上限。

让复用设置匹配后端行为

应结合连接建立成本、预期再次使用概率、后端限制和 nginx worker 数量确定空闲保留规模。连接即使没有承载请求，保留期间也会占用资源。过大的缓存可能挤占新请求可用连接，过小的缓存则可能反复丢弃马上就会复用的连接。选择规模需要真实访问分布和后端预算，而不是一律把值调大。

请求次数、空闲时间和连接总寿命控制，会因为不同原因回收持久连接。不要看到重连就同时提高所有限制。应先观察后端主动关闭、有效配置、响应分帧完成情况，以及真实连接身份。本次空闲超时设为三十秒，短暂突发没有测量长期连接老化，也没有测量 TLS 会话行为，因此不能据此推断那些不同机制的效果。

如果目标是限制后端工作量，应采用真实并发或准入策略；keepalive 负责复用策略。示例明确选择协议和缓存设置，因为滚动文档还包含较新 nginx 的默认值与功能。应用时要遵循实际部署版本的语义，同时验证连续复用和并发突发，不能认为一次重复请求成功复用，就已经证明容量边界受到控制。

来源

nginx upstream module，空闲连接缓存、worker 范围与 keepalive 限制，已核验 2026-09-12。
nginx 1.28.0 upstream keepalive source，被测版本的空闲缓存与连接复用实现，已核验 2026-09-12。
RFC 9112 HTTP/1.1，持久连接、消息分帧与 Connection close，已核验 2026-09-12。

性能 · XB 现场笔记

巨型页用灵活性换更少的 TLB 缺失

为什么 4 KB 会吃亏

hugetlb 与 THP 的区别

池子要提前量

坏掉的样子

快速验证

延伸阅读

来源

Cache-Control 是缓存与源站之间的约定

双方都要读同一份约定

坏掉的样子

快速验证

延伸阅读

来源

EXPLAIN ANALYZE 把查询真的跑一遍

先比较同一种量

找到有意义的估计偏差

坏掉的样子

快速验证

来源

pg_stat_statements 找出最贵的查询

先归一化，再聚合

看总耗时，不看平均耗时

计数器只增不减，所以要按窗口比较

坏掉的样子

快速验证

来源

TCP 窗口缩放分别扩展两个方向的接收窗口编码

坏掉的样子

快速验证

区分缓冲分配、通告容量与实际性能

来源

缓存雪崩姗姗于同一时刻过期

在真实边界内合并工作

错开时间不能改变新鲜度承诺

坏掉的样子

快速验证

延伸阅读

来源

Nagle 与延迟 ACK 可能让小请求的第二部分等待

坏掉的样子

快速验证

一起决定请求分帧与套接字策略

来源

小表上全表扫描反而赢

真正的货币是页，不是行

索引从哪里开始不划算

让优化器做主，但把它的输入喂诚实

坏掉的样子

快速验证

来源

SACK 报告缺口之后已收到的范围，帮助定位需要恢复的数据

坏掉的样子

快速验证

解释反馈时，不承诺重传判断绝对完美

来源

TLS 会话恢复省一次往返

新连接仍要派生新的流量密钥

坏掉的样子

快速验证

延伸阅读

来源

TLS 握手会拉长延迟，但可以缩小

消息会按批次传输

坏掉的样子

快速验证

延伸阅读

来源

HTTP keep-alive：复用同一条连接

完整报文才允许复用

每一跳管理自己的超时

坏掉的样子

快速验证

延伸阅读

来源

EXPLAIN 计划揭示查询路径

把计划当作路线来读

统计信息决定路线

确认路线真的变了