守株阁

一个 TCP 连接依次返回两份 HTTP 响应，客户端怎样确定第一份到哪里结束？等待 socket 关闭会阻止连接复用；把一次 recv() 当作一份响应，又会受实际读取分块影响。正确的边界来自 HTTP 消息规则，还依赖对应请求的方法与响应状态。 前置是第 02 篇字节流分帧和第 16 篇连接生命周期。本篇用标准库回环服务发送固定长度与分块响应，检查解析器实际消费的字节。缓存验证留到第 23 篇，TLS 身份验证留到第 24 篇。 方法说明操作，长度规则划分消息 请求行中的方法和目标指出请求的操作，后续字段提供 Host 等上下文。响应状态说明处理结果；这些语义不能由连接成功或收到了若干字节代替。例如收到完整错误响应，表示消息传输与解析可以成功，业务请求仍可能失败。 RFC 9110 §9.2分别定义安全方法与幂等方法。安全指方法的请求语义本质上只读，不承诺服务器完全不写日志。幂等比较重复相同请求对服务器的预期效果，不要求每次响应状态、时间或正文完全相同。因而“第一次响应丢了”并不自动授权重试任意操作。 HTTP/1.1 消息具有起始行、字段、空行，以及按规则存在的消息体。头部...

权威服务器上的地址已经改了，客户端为什么还会得到旧地址？一个刚创建的名字，为什么仍被回答为不存在？这两种现象都可能来自缓存，但需要不同的记录和返回码来证明，不能统一归结为“DNS 尚未传播完”。 前置是第 13 篇 UDP 与第 16 篇连接状态。本篇用独立 Unbound 进程查询自建权威服务，比较权威数据、递归缓存和客户端实际结果。实验不修改操作系统 DNS 配置，也不请求公共域名。 查询的是某个名字的某类数据 DNS 不是只保存“域名到一个 IP”的表。一次问题包含名字、类型和类；例如 www.lab.test. IN A 与同名的 AAAA 是两个问题。A 提供 IPv4 地址，RFC 3596 §2定义的 AAAA 提供 IPv6 地址，NS 描述名称服务器，SOA 携带一个区的管理信息。一个名字可以有多种记录，同一类型也可能有多条记录。 名字末尾的点表示从根开始的完整名称。www.lab.test. 的标签按层次组织，但每一级标签不必对应独立服务器或独立管理区。区（zone）是权威管理与数据提供的边界；委派把一部分名字空间交给下一级，父区保留通向下一级的指引。RFC ...

下载一直有进度，交互请求却迟迟没有响应，这两种现象可以同时发生。出口持续发送并不说明新到的短报文很快就能通过：如果前方积累了大量数据，吞吐接近瓶颈容量时仍可能有很长的等待。 本篇承接第 19 篇的发送窗口与共享瓶颈，在相同限速出口下比较 FIFO 和 FQ-CoDel。实验需要区分吸收短暂突发的缓冲与长期积压，并观察拥塞信号如何返回发送端。 缓冲容量不是转发容量 设理想出口每秒服务 5,000,000 bit，前方已有 625,000 B 等待，且不考虑其他调度、协议开销或突发许可。仅把这些字节送出就需要一秒。把存储空间扩大一倍不会把出口变成每秒一千万 bit，只会允许保留更多尚未服务的数据。 123from fractions import Fractionassert Fraction(625000 * 8, 5000000) == 1assert Fraction(62500 * 8, 5000000) == Fraction(1, 10) 这道题计算的是给定积压对应的理想服务时间，不能直接拿内核的某个缓冲参数代入，便当作真实 RTT。实际路径还有反向传输、端点调度、报文大...

接收程序一直读取，发送程序也一直有数据，为什么一条 TCP 连接仍不能任意提高发送速度？另一条连接加入后，第一条连接的吞吐为什么会变化？第 18 篇的接收窗口只能解释接收端限制，不能单独解释网络中的共享瓶颈。 本篇先把窗口与速率分开，再用固定限速出口比较一条和两条连接。前置是第 01 篇的 RTT 与带宽时延积、第 17 篇的重传依据，以及第 18 篇的流控。队列管理与 ECN 的对照实验留到第 20 篇。 两个窗口约束同一发送方向 接收端通告 rwnd，发送端维护 cwnd。前者表达接收限制，后者用于约束向网络注入的数据。RFC 5681 §2–3.1区分这两个量；在讨论普通新数据发送、暂不展开恢复期间额外规则时，需要同时考虑二者。 设当前 cwnd=12000 B、rwnd=8000 B，已经发出但尚未确认的数据为 6000 B。忽略回绕、SACK 恢复、分段和发送节奏等细节，可用于新增数据的余量为 max(0, min(12000, 8000)-6000)=2000 B。这是一道窗口记账题，不是完整内核发送算法。 窗口为八千字节，不意味着每秒八千字节。同样的窗口经过不同 R...

服务端暂停读取 socket，客户端为什么还能发送一段时间，随后才停下来？恢复读取后，传输又为什么能够继续？应用调用、两端内存缓冲与 TCP 通告窗口之间存在多个不同的进度，不能用“对端不读，所以本次写立即阻塞”概括。 第 15 篇解释了字节序号和确认号。本篇把窗口放回同一序号空间，沿着“停读、缓冲积累、零窗口、恢复读取”的路径观察背压。窗口是接收限制，不是链路带宽；拥塞窗口与网络瓶颈的关系留给第 19 篇。 ACK 推进与应用读取是两回事 TCP 可以先把接收字节放入内核缓冲并确认，应用稍后才读取。ACK 前进说明传输层连续接收进度，并不代表应用已经处理这些字节。应用暂停 recv() 后，只要接收端仍有可以接纳数据的空间，传输不必立刻停止。 RFC 9293 §3.8.6把通告窗口定义为接收端准备接收的序号范围。接收端在报文中给出的窗口值，应与同一报文的确认号一起解释；只比较两次窗口字段大小，容易把窗口宽度变化误认为右边界后退。 设一个无回绕算例中，接收端原先通告 ACK=1001、窗口=4096，右边界为 5097。随后接收 2048 字节，应用仍未消费，通告 ACK=30...

一个已发送的数据段迟迟没有得到确认，应该再等多久？立刻重发会把正常延迟当成丢失；一直等待又无法从真正丢包中恢复。发送端看到的是确认进度和时间，不是网络内部每个队列的完整情况。 第 15 篇定义了序号与累计确认，第 16 篇区分了连接状态和应用结果。本篇讨论发送端根据什么证据决定重传。超时、重复 ACK 和现代丢失检测各有条件，不能把抓包工具显示的“重传”直接当成某个内核分支已经被证明。 没有确认不等于数据一定丢了 同一段数据迟迟没有确认，可能是数据在去程丢失，也可能是确认在回程丢失，或者任一方向发生了排队延迟。接收端还可能采用延迟确认。只在发送端观察不到 ACK，无法在这些解释之间作唯一选择。 设发送时间为零，原始段于 80 ms 到达接收端，但确认丢失；发送端在 200 ms 重发，随后收到覆盖该数据的 ACK。接收应用可能早已取得数据，而发送端直到重发后才确认完成。这是一个假设时序，用来说明观察不充分，不是本篇实测延迟。 重传也不能代替应用层幂等设计。TCP 在同一连接的字节流中处理重复数据，上层在连接失败后重新发起一次业务请求，仍可能造成重复操作。跨连接请求标识、执行结果和...

程序调用 close() 后，为什么连接条目还可能留在系统里？服务端读到 b''，为什么仍然能够返回应答？这两种现象并不矛盾：应用对象、文件描述符、TCP 端点状态与两个传输方向，不是同一个生命周期。 第 15 篇核对了字节序号、累计确认和 FIN 的序号占用。本篇把观察点扩展到 socket 调用、报文以及内核状态，分别复现正常关闭、半关闭和复位。握手成功只证明相应连接阶段完成，不能替代业务请求验收。 连接状态保存在端点 TCP 连接不是链路上一个持续存在的报文。通信两端需要保存本地与远端地址和端口、序号、窗口、计时器以及连接状态；网络中的报文推动这些状态变化。两端可能处于不同状态，某一时刻的单端列表不能代表远端已经同步到同一阶段。 RFC 9293 §3.3.1–3.3.2定义了相关状态变量与状态机。一个监听 socket 可以接受多条连接，监听状态不等于每条已接受连接的状态。排障时至少要区分监听端口、某个已连接四元组和应用持有的对象。 Python socket 对象是应用访问接口。应用关闭对象后，内核仍可能为协议收尾保存状态；反过来，对象还存在也不证明对端可达或下一次收发...

一个 TCP 段携带四字节数据，接收端为什么可能仍返回与之前相同的 ACK？如果把确认号机械地写成“本段 seq 加长度再加一”，就无法解释数据前面存在缺口的情况。确认号描述连续接收进度，并不只是对当前报文长度做算术。 第 14 篇用按块编号的教学协议组合了确认、重传、窗口和去重。本篇转向真实 TCP：编号单位变成字节，确认语义也不能直接照搬逐块 ACK。连接状态迁移留给第 16 篇，这里只分析建立、传输和关闭过程中相关的序号占用。 编号属于一个方向的字节序列 TCP 是双向通信。一条连接中，两个方向分别维护发送序号与接收进度，不共享一个全局计数器。客户端发出的 ACK 确认服务端方向的数据。计算客户端还有多少已发字节未被确认，则需要服务端返回的 ACK 和客户端发送状态。 RFC 9293 §3.4定义了序号空间。数据按字节计数，SYN 与 FIN 各占一个序号，纯 ACK 不占。对一个段，序号空间中的占用长度可以写成： 12占用长度 = 数据字节数 + (SYN ? 1 : 0) + (FIN ? 1 : 0)段后边界 = (SEQ + 占用长度) mod 2^32 “段后边...

接收端已经得到某块数据，但返回的确认丢了，发送端应该怎么办？不再发送，可能遗漏真正丢失的数据；再次发送，又可能让接收端重复处理。仅靠发送一次或固定重发几次，都无法同时说明完整性与重复交付问题。 第 13 篇展示了 UDP 数据报边界不提供可靠交付。本篇把数据块、确认、计时器、窗口和接收缓存组合成一个有界教学协议。实验采用确定性事件信道，不发送实际网络报文；它不是 TCP，也不声称实现 TFTP。 先定义成功和允许失败的条件 输入是有限字节串，按固定方式划成有限块，每块有唯一编号。接收成功要求按照原顺序输出相同字节，不能少块、重复交付或靠最终排序掩盖已经发生的错误处理。发送成功则要求全部块都收到有效确认。 这两个状态需要分别记录。接收端拿齐内容时，最后一个 ACK 仍可能丢失；发送端因而不能立即知道接收成功。协议应允许接收端继续回应重复数据，同时让发送方在有界尝试后明确失败。永久故障下，不能承诺总能完成传输。 本篇只处理同一传输内的固定编号，不考虑进程重启、旧会话报文、序号回绕和恶意输入。实际协议需要传输身份、生命周期和资源限制，不能把本例的整数编号直接用于无限运行的服务。 确认必...

应用连续发送编号 0 到 4 的五条消息，接收端为什么可能得到 0,3,2,4,4？这既包含缺失，也包含乱序和重复。若每次接收仍得到一条完整消息，是否就说明传输可靠？数据报边界与交付保证是两个不同的问题。 第 02 篇解释了 TCP 字节流需要应用划分消息，第 09 篇说明大小还受路径 MTU 约束。本篇使用本机 UDP socket 和一个专用应用代理，主动改变转发序列。实验发送真实 UDP 数据报，但故障来自代理代码，不代表内核自然丢包或公网故障概率。 一次发送留下什么边界 RFC 768定义 UDP 数据报服务。UDP 首部含源端口、目的端口、长度和校验和，每项为十六位；长度包含八字节首部与数据。端口必须放在目的 IP 地址等上下文中解释，不能把一个端口号视为全球唯一的服务身份。 12IP 头部 | 源端口 目的端口 UDP长度 校验和 | 应用数据 <---------- UDP 首部8字节 ----------> 发送两个数据报，并不等于向接收端提供一段可以任意切分的连续字节流。接收接口一次取一个数据报的内容，不把后一个数据报拼到前一...