1 TCP 深入要解决什么
在 Linux 主机上执行 curl http://127.0.0.1:8000/，表面上只是取回文件，实际涉及客户端进程、文件描述符、网络栈、监听套接字和服务端进程。TCP 位于这条链路的传输部分：它让应用通过连接收发有序字节流，并在网络丢包、重复、乱序时尽力恢复。它不理解文件名，也不理解应用消息。理解 TCP 的目的，是在“连接慢”“下载卡住”“请求偶尔超时”出现时，知道该看哪组证据，以及哪些结论还不能成立。
先区分几个经常混用的时间。连接建立时间主要涉及握手；首字节时间还可能包含服务端排队、读取文件和处理请求；整个下载时间又受到数据量、接收速度和路径条件影响。假设连接只花 2 ms，首字节却等了 800 ms，直接增大 TCP 缓冲区缺少依据。进程没有及时生成数据、文件读取变慢、应用线程繁忙，都可能让网络保持空闲。反过来，应用已经持续写入，连接上却出现重传和长时间停顿，才值得进一步检查传输条件。
TCP 连接通常由源 IP、源端口、目的 IP、目的端口组成的 4 元组标识，同时还要区分传输协议。客户端临时端口与服务端监听端口承担不同角色。同一台服务端可以在 8000 端口上接收许多连接，因为每条连接的完整地址组合不同。只记录“8000 慢了”不足以定位故障；应记录连接两端、发生时段、数据方向和受影响的操作。进程标识也很有用，因为相同端口上的服务可能已重启。
TCP 的可靠性有明确边界。发送进程调用 write() 成功，通常表示字节已交给本机相关缓冲，并不表示对端应用已经读到，更不表示文件已经写入持久存储。对端 TCP 发回 ACK，证明的是传输层已确认相应字节；业务是否完成，仍要靠应用自己的响应。发送端进程崩溃、连接被重置或超时，都可能使应用面对不确定结果。运维记录必须区分“写入成功”“传输确认”和“业务完成”。
本课围绕 3 个问题展开：数据如何被编号和确认，发送速度为什么会变化，以及如何从命令和抓包中建立可复查的解释。我们只建立状态、窗口、重传与排队的入门直觉。具体内核实现、拥塞算法的完整推导和网卡处理细节留待后续。学完后，你应能把“网络有问题”改写为“哪个方向、哪个时间段、哪些观测支持了哪种判断”，并明确下一项验证动作。
2 连接、状态与可靠性机制
建立连接时，客户端先发送带 SYN 标志的报文，服务端以 SYN 和 ACK 响应，客户端再确认。通常称为 3 次握手。双方借此交换各自的初始序列号，确认收发路径，并协商部分 TCP 选项。不要把握手理解成测得了固定带宽：连接建立只说明当时的小报文能够往返，后续大流量仍可能遇到排队或丢包。握手报文丢失也会重传，因此“出现 SYN”与“连接已经建立”是不同事实。
用相对序列号表示时，抓包工具常把首个 SYN 显示为 Seq=0。SYN 本身占用 1 个序列号，所以后续首个数据字节通常从 Seq=1 开始。假设发送 Seq=1, Len=1000 的数据，接收方完整收到后可以返回 Ack=1001，表示下一步期待从 1001 开始的字节。ACK 确认的是连续字节位置，而非“第几个包”。分段大小改变时，这个规则仍然适用。
TCP 的双向数据流各有自己的序列空间。客户端发出的 ACK 字段确认服务端的数据，客户端自己的 Seq 字段则属于另一条方向。阅读抓包时应先画出方向，再跟踪同一方向的序列范围。假如收到 1001 后面的数据，却缺少前面的某段，累计 ACK 不能直接越过缺口。协商成功的选择性确认可以额外报告已经收到的范围，但不会取消向应用按序交付的约束。这里掌握“累计位置与已收范围可能不同”即可。
TCP 保留已发送但尚未确认的数据，以便需要时重传；接收端依据序列号整理顺序，并避免向应用重复交付同一范围。它提供字节流，而不是消息队列。发送端连续执行 2 次 write()，接收端可能通过 1 次或多次 read() 读出这些内容。应用必须约定长度、分隔符或其他消息边界。把某次读取长度当作完整消息长度，是程序设计错误，扩大窗口不能修好它。
状态名称可以帮助解释连接处于哪段生命周期。服务端的 LISTEN 表示等待连接；SYN-SENT 常见于主动发起方等待握手回应；ESTABLISHED 表示连接已建立，但不保证应用正在前进。正常结束某个方向通常通过 FIN 表示该方向不再发送字节，另一方向仍可继续发送。RST 则表示连接被重置，需要结合端口是否监听、进程退出和中间设备行为分析原因。看到 RST 不能直接认定是服务端程序主动报错。
主动关闭方正常经历的 TIME-WAIT，有助于处理延迟到达的旧报文和关闭阶段的确认。大量短连接可能留下许多这类记录，但记录数本身不是故障证明。CLOSE-WAIT 则提示本端已收到对方关闭发送方向的通知，应用尚未完成本端关闭；若长期积累，应检查应用是否正确释放连接。先把状态与进程、持续时间联系起来，再考虑资源限制。随意缩短等待时间可能掩盖连接管理问题。
3 拥塞控制与窗口直觉
发送端不能只按本机网卡速度持续灌入数据。它至少受到接收方能力和路径承载情况的约束。接收窗口常记为 rwnd，反映接收端当前允许继续接收的字节范围，目的是避免接收缓冲被压满。拥塞窗口常记为 cwnd，是发送端根据反馈管理的发送额度，目的是适应网络路径。两者都可以用字节理解，但来源和意义不同。抓包中的 Window 字段不能直接当作 cwnd。
粗略理解，未确认的在途数据量受到 min(rwnd, cwnd) 约束，实际还会受到应用供数速度、发送缓冲和具体实现影响。假设 rwnd 为 256 KiB、cwnd 为 64 KiB，接收端愿意接收更多，发送端也仍可能按较小额度推进。如果接收进程不及时读取，rwnd 可能逐步缩小，甚至变为 0。这种现象首先指向接收端消费问题，而不是自动说明路径带宽不足。接收方恢复读取后，窗口可以重新开放。
往返时延 RTT 决定反馈多快回来。将“每个 RTT 内允许飞行多少数据”除以 RTT，可以得到简化吞吐估计。例如有效窗口为 64 KiB、RTT 为 100 ms，估计约为 655360 B/s，即约 5.24 Mbit/s。这里采用 1 KiB 等于 1024 B、1 Mbit/s 等于每秒 1000000 bit。这个估计不是承诺值，丢包、协议开销、应用停顿和路径竞争都会改变实际结果。
带宽时延积 BDP 表示为了持续利用路径，通常需要多少在途数据。假设瓶颈速率为 100 Mbit/s、RTT 为 40 ms，乘积约为 4000000 bit，也就是 500000 B。这个数描述路径中持续飞行的数据规模，不等于应该在每个设备上堆积同样多的队列。窗口明显不足可能限制吞吐，队列过长却可能推高时延。理解这两者的区别，才能避免把“更多缓冲”当成所有性能问题的答案。
拥塞控制让发送端依据确认、丢失和其他可用反馈调整发送。连接初期通常需要逐渐探测可用能力，因此短文件可能在充分利用链路之前就传完。长连接获得的稳定吞吐，不能直接预测每次新建连接的小请求延迟。不同拥塞算法的行为也不完全相同，本课不推导它们的增长曲线。实际排查时先记录所用算法和 RTT、重传、吞吐之间的关系，再讨论算法是否适合场景。
窗口缩放允许连接使用比报文头原始字段更大的接收窗口。缩放能力在握手时协商，之后要结合对应方向的缩放因子解释 Window 字段。如果抓包从连接中途开始，工具可能缺少协商信息，不能盲信它给出的有效窗口解读。窗口扩大也不会让应用自动生成更多数据；如果服务每隔 1 s 才写出少量内容，连接长时间空闲可能完全符合设计。先确认是否存在足够待发送数据，再讨论窗口上限。
4 动手：读一次抓包中的握手与窗口
准备 1 台可运行 Python 3、curl、ss 和 tcpdump 的 Linux 实验机，在独立目录中提供测试文件。不要在含有私密文件的目录启动文件服务。下面用 127.0.0.1 限制服务范围，并以随机目录名避免与已有文件混用。命令需要在相应终端中分别执行，抓包通常需要管理员权限。没有权限时应申请合规的实验环境，不要修改主机安全策略来绕过限制。
# 终端 A：创建隔离的实验目录并启动服务
tcp_lab_dir=$(mktemp -d /tmp/s31-tcp.XXXXXX)
dd if=/dev/zero of="$tcp_lab_dir/payload.bin" bs=1M count=8
python3 -m http.server 8000 --bind 127.0.0.1 --directory "$tcp_lab_dir"# 终端 B：先开始抓包，用 Ctrl+C 结束
sudo tcpdump -i lo -nn -s 128 -w /tmp/s31-loopback.pcap 'tcp port 8000'# 终端 C：观察监听并发起请求
ss -ltnp 'sport = :8000'
curl --noproxy '*' --http1.1 -o /dev/null -sS \
-w 'connect=%{time_connect}s first=%{time_starttransfer}s total=%{time_total}s\n' \
http://127.0.0.1:8000/payload.bin
ss -tin '( sport = :8000 or dport = :8000 )'先确认监听地址确实是 127.0.0.1:8000。如果启动时报地址已占用，应换用可用端口，并同步修改抓包过滤器和请求地址。不要为了完成实验终止未知进程。curl 的 time_connect 从操作开始计时，到 TCP 连接建立；time_starttransfer 到收到首字节；time_total 到操作完成。本实验使用 IP 地址、禁用代理且不启用 TLS，减少了额外阶段，但首字节时间仍包含服务进程处理请求的耗时。
结束抓包后，可以在终端查看摘要，也可以用具备权限的图形抓包工具打开文件。抓包文件应留在实验环境中，分享前确认内容和地址是否允许披露。这里截取长度为 128 B，主要用于观察头部；它不能保证包含所有选项与封装，也不足以分析完整应用正文。命令中的 -S 要求显示绝对序列号，便于明确 tcpdump 摘要的表示方式。
tcpdump -nn -tttt -S -r /tmp/s31-loopback.pcap 'tcp port 8000'先找客户端临时端口到 8000 的 SYN，再找反向 SYN、ACK 和后续确认。图形工具可能显示相对序列号，终端命令这里显示绝对值；比较的是变化量，不要直接混抄数值。挑选同一方向的连续数据段，用起始序列号加数据长度，计算下一个期望字节。随后观察反向 ACK 是否覆盖这个位置。ACK 不一定每段返回 1 个，数据段也可能在本机抓包中呈现比预期更大的长度，因此要围绕字节范围阅读。
回环传输可能结束得太快，导致 ss -tin 执行时已经没有连接。这不是命令失效，而是采样时刻错过了活动阶段。可以重新请求，并在另一终端传输期间观察；若使用 curl 限速拉长时间，应把它记录为客户端施加的实验条件，不能据此测量链路容量。ss 的 RTT、cwnd 等字段随内核和工具版本而异，而且只反映本端视角。将输出与采样时间放在一起保存。
本实验只能建立读包方法。回环接口没有真实交换机、无线竞争或远端磁盘延迟，不能代表跨主机网络性能。本机抓包中出现校验和异常或报文较大时，还应考虑抓包位置与卸载处理的影响，不能立即认定线路损坏。若握手包缺失，先检查抓包启动时机、接口、过滤器和连接方向。完成后在服务终端按 Ctrl+C，保留需要的记录，再按明确路径清理自己创建的实验文件。
5 重传、超时与队头阻塞
假设发送端已经发出 3 段数据，中间 1 段在路径上丢失。接收端可能先收到后面的字节，但累计确认停在缺口之前。发送端依据重复确认、选择性确认等反馈，可能在计时器到期前发现丢失；如果可用反馈不足，也可能等待重传超时。这里不把“收到固定数量重复 ACK 就一定重传”当成普遍定律，因为具体检测机制会随实现和条件变化。初学者应先识别缺口、后续反馈和再次发送的时间关系。
重传超时不是每条连接共用的固定等待秒数。发送端会依据 RTT 及其变化估计等待范围，并遵循实现采用的计时规则。连续失败时，重传间隔可能增大，所以连接表现为越来越长的停顿。RTT 很短却出现明显长暂停，也不一定证明服务器处理很慢：少量数据丢失、尾部丢失或反馈不足，都可能让恢复等待占据主要时间。要把应用日志时间与抓包时间对齐后再归因。
TCP 队头阻塞指同一连接内，较早的字节缺失会挡住后续字节向应用的按序交付。即使后面的数据已经到达接收端，应用通常也不能越过缺口读取它们。若应用把多个逻辑任务复用在这条字节流中，传输层的缺口可能同时影响这些任务。增加应用并发量不能消除这条连接上的顺序约束。是否拆分连接，应结合协议设计、连接成本和公平性考虑，而不是临时无限增加连接数。
要区分传输等待与应用读取方式造成的等待。接收进程若要求读满某个长度才处理，即使 TCP 已交付部分字节，应用也可能继续等待；接收进程停止读取时，还可能使接收窗口收缩。抓包看到数据已获确认、应用却迟迟无响应，应该同时检查进程状态、读取逻辑和服务日志。ACK 证明传输层的进展，不证明处理逻辑的进展。可以用明确的应用时间戳记录“开始读”“读到字节”“处理完成”来缩小范围。
重传也不总能证明某段原始数据真的丢了。ACK 丢失、严重乱序或观测点漏抓，都可能让分析复杂化。工具标注的“重传”“乱序”是根据所见报文作出的判断，应回到序列范围与时间检查。只有发送端抓包时，可以知道本机发出了什么，却不知道远端究竟何时收到；只有接收端抓包时，也无法完整重建发送端决策。必要时经授权在两端同时采集，并核对时钟偏差。
应用超时是另一条边界。某个客户端可能在 2 s 后放弃请求，但底层连接的恢复计时尚未结束；另一个客户端可能一直等待，看起来像“没有报错”。连接超时、单次读取超时和整个操作的截止时间，语义不同。运维手册应写明具体配置对应哪个阶段。依靠不断加大超时可以减少部分表面错误，却也可能让故障占用更多连接和进程资源。先定位等待发生在哪里，再设定符合业务容忍度的截止时间。
6 常见坑：把带宽当吞吐上限
链路标称带宽只是分析起点。文件实际传输吞吐还取决于路径中最窄的环节、可用份额、RTT、窗口、丢失恢复、协议开销，以及两端进程和存储的速度。1 Gbit/s 的接口无法保证每次文件下载都达到相应数值。尤其要统一单位：工具可能显示 MB/s，也可能显示 Mbit/s；字节与 bit 相差 8 倍，十进制与二进制前缀又有差别。先写单位，再比较数值，避免把正常差异当故障。
例如，某条路径标称 100 Mbit/s，但可持续供给数据的进程每秒只生成 4 MB，那么网络再快也无法凭空提高文件吞吐。若进程供数充足，而有效在途额度只有 64 KiB、RTT 为 100 ms，前面估算的窗口约束也远低于标称值。若多个进程共享出口，每条连接的份额还会变化。只看接口速率无法在这些解释之间作出选择，必须补充应用供数、连接状态和路径负载的证据。
常见误区是把任何低吞吐都归咎于接收窗口，并立刻调大系统缓冲上限。若真正瓶颈是应用每次读取很少、磁盘持续繁忙或出口长期排队，这种调整可能没有收益，还可能增加内存占用和等待。用 ss -tin 观察连接，用应用日志记录处理阶段，再结合系统可用的进程和存储观测工具。不同信息的采样周期应尽量一致，不能拿高峰时的吞吐与空闲时的 RTT 拼出结论。
另一个误区是用 ping 正常证明 TCP 正常。ICMP 探测与实际 TCP 连接的报文类型、大小和处理方式可能不同，探测时刻也可能避开拥塞。ping 可以提供辅助时延与可达性线索，却不能替代 TCP 握手、重传、窗口和应用完成时间。反过来，ping 没有响应也不能单独证明目标服务不可用。应在允许的环境中发起实际协议请求，并保留完整错误信息与耗时阶段。
测速还需要区分短时峰值和持续能力。操作系统缓存可能让第 2 次读文件比第 1 次快；连接复用省去了建立连接的部分成本；并发连接能改变资源分配，却可能恶化其他用户的延迟。记录文件大小、并发数、是否复用连接、运行持续时间以及两端资源情况，结果才有可比性。不要为了追求漂亮数字修改多个条件后只展示最好的一次。重复实验应报告范围和异常，而不是隐藏不稳定性。
遇到“局域网小请求成功，大文件持续卡住”，还应保留路径 MTU 或过滤配置异常的可能性，但本课不展开其探测机制。先检查是否只有某个方向、某种大小或某条路径受影响，再交给后续网络排查步骤。连接成功并不保证所有大小的数据都能正常传输。类似地，TLS 协商错误、应用权限错误和 HTTP 错误码也不应被统称为 TCP 丢包，它们需要对应层面的证据。
7 案例：缓冲膨胀导致的延迟尖刺
某台 Linux 主机白天交互正常，夜间开始备份后，远程 shell 输入和监控请求都出现延迟尖刺。备份吞吐仍接近出口能力，连接没有大量断开。初步记录显示，空闲时 RTT 约为 20 ms，备份持续上传时升至 300 ms，暂停上传后逐渐恢复。这个现象提示瓶颈附近存在持续排队，但还不能仅凭相关性认定设备缓冲过大；远端服务繁忙和其他竞争流量也需要检查。
假设出口处理能力为 20 Mbit/s，而某处长期积压了 1 MB 数据，粗略排空时间就是 1000000 × 8 ÷ 20000000，约为 400 ms。小型交互报文自身很短，也可能排在这些数据之后。吞吐看起来良好，排队延迟却很差，这正是缓冲膨胀值得关注的原因。缓冲本来用于吸收短暂突发，长期塞满则让“暂存”变成持续等待。包没有立即丢弃，不代表用户体验一定良好。
排查先建立可比较的时间线：在获准的维护窗口，记录空闲基线、备份开始、负载持续、备份暂停和恢复后的 RTT、业务耗时、出口速率。使用相同目标和相同采样方式，同时观察备份进程是否持续供数。若有网关管理权限，可以读取队列相关统计；若只有主机权限，就应把“瓶颈具体位置待确认”写入结论。端点看到时延上升，并不能直接指出是哪台设备在排队。
接着进行受控干预：通过备份工具自身的速率设置，逐步降低上传速率，同时观察业务延迟和备份完成时间。如果出口速率略低于可持续能力后，RTT 显著下降，而服务端处理时间稳定，这支持排队是主要因素。数值应依据现场测量选择，不能机械套用某个固定百分比。还要记录干预是否影响其他任务，并用恢复后的对照结果排除偶然波动。每次只改变 1 项条件，因果解释才清楚。
可以先把备份放到业务低峰，限制其速率或并发，并给交互流量留下可用余量。如果组织具备网关配置权限，可进一步评估合适的队列管理和流量调度策略；具体算法与配置不在本课展开。不要在不清楚出口位置和设备能力时直接复制队列命令。主机侧限速只能控制本机发出的负载，无法消除同一出口上其他主机造成的拥塞，也不能修复远端接收进程不读取的问题。
验收需要同时保留吞吐和延迟指标。例如约定备份必须在维护窗口内完成，同时交互请求的高分位耗时不能持续超过预算。只降低平均 RTT，仍可能漏掉用户真正感受到的尖刺；只关注备份完成时间，又可能把其他业务的等待当作无关成本。案例的结论应写成带条件的判断：在已测负载与路径下，限制备份发送降低了排队延迟；更换路径、增加竞争主机或改变备份规模后需要重新评估。
8 把 TCP 调参边界写进运维手册
运维手册首先写现象与适用范围，再写参数。适用范围至少包括主机角色、网络路径、操作系统版本、应用版本、连接寿命和流量方向。同一个参数可能对长距离大文件传输有帮助，对本机小请求几乎没有收益。跨主机复制配置前，必须确认问题机制相同。参数名称只是操作入口，真正需要解释的是它改变了哪种限制，以及预期会在哪项指标上看到改善。
基线记录应包含应用成功率、连接耗时、首字节时间、总耗时、吞吐、RTT 和重传变化，同时保留进程资源与错误日志。Linux 上可以用 ss -tin 观察指定连接，用 nstat -az 查看协议计数器。后者通常是主机相关网络命名空间范围内的累计统计，不能直接当成某个服务的重传次数；比较前后增量时，还要注意期间混入的其他连接。不要仅根据 1 个总计数器定位单条连接故障。
参数修改前，应通过本机文档和只读查询确认当前值、单位、作用范围以及是否影响已有连接。某些配置是系统范围，某些可以在应用套接字上设置，还有些依赖连接建立时的协商。手册不能只写“立即生效”，而应说明验证对象是否需要新建连接。若问题仅存在于某个程序，优先判断是否可在应用范围内解决，避免不必要地改变整台主机上所有服务的行为。
可执行变更单应写出：待验证假设、允许修改的 1 项配置、变更窗口、观察时长、通过标准、停止条件、原值与回滚方法。例如怀疑长 RTT 路径上的接收额度不足，就先证明应用供数充足且相关窗口确实限制传输，再在隔离测试中改变额度，观察吞吐与内存是否符合预期。如果重传增加、延迟恶化或其他服务受影响，就按预先条件结束实验。不要用“感觉更快了”作为上线依据。
连接保活与应用健康检查也应分开记录。TCP 保活可以在配置条件下探测长期空闲连接的存活情况，但不能证明服务能够及时处理业务。对端进程可能仍持有连接，却已经卡在文件读取或工作队列上。业务层健康检查应覆盖真正重要的处理路径，并具有清晰截止时间。无限延长连接寿命或盲目启用保活，都不能替代应用错误处理、资源释放和请求结果确认。
最后，明确哪些现象不允许直接触发全局调参：单次超时、孤立的抓包分析标记、短暂的 TIME-WAIT 增长，以及没有单位的“带宽不足”报告。它们都可以触发调查，但不足以证明某个系统参数应改变。值班人员应有权收集只读证据和执行已批准的回滚；涉及共享出口、系统范围缓冲和连接生命周期的变更，应按既有变更流程执行。这样的边界让故障处理可以复查，也减少不同班次重复试错。
9 从传输层走向路由原理（S32）
到这里，我们把 TCP 看作端点之间根据反馈推进字节流的机制。它能观察确认、RTT、接收窗口和丢失迹象，却不会在报文头中告诉你“第几个路由设备正在排队”。同一对端点之间的路径可能随网络条件变化；同一连接在不同时段的吞吐和时延，也可能受到路径共享者影响。因此，端点证据能够说明传输遇到了什么现象，却不一定能独立说明中间哪里出了问题。
进入 S32 前，先区分目的端口与下一跳。目的端口帮助接收主机把传输交给相应套接字；路由选择则决定 IP 数据往哪个方向发送。服务监听正确，但主机缺少合适路由，连接仍可能失败。路由存在也不保证对端监听、返回路径可用或过滤规则允许通过。这些条件需要分别检查，不能把“能查到路由”写成“端到端服务正常”。
在 Linux 上，ip route get 目标IP 可以提供本机对该目标的路由查询结果，包括可能的出口接口、源地址与下一跳。它不会真的完成 TCP 握手，也不能证明后续每段路径都畅通。多网卡主机尤其要关注选出的源地址，因为返回流量要能到达这个地址。把路由查询与抓包接口对应起来，可以避免一直监听错误接口却误以为主机没有发包。具体选路规则将在 S32 继续学习。
交接给网络排查时，建议整理为可直接复现的描述：哪台进程主机向哪个 IP 与端口发起连接，何时开始失败，是 SYN 没有得到回应、建立后停止前进，还是只有负载增大时 RTT 上升。附上过滤后的抓包、命令结果和应用时间线，并说明当前只观察到了哪端。这样的材料既保留 TCP 层判断，也给路由与路径排查留下明确入口，避免从模糊的“请求慢”重新开始。
本课可以停在这条边界：先确认字节是否在推进，再判断是接收方消费、发送方额度、丢失恢复还是持续排队的线索；当证据指向路径时，再沿接口、源地址、下一跳和返回方向继续追踪。暂时无需记忆动态路由协议细节，也不必背诵完整分层名称。能把观测事实、推测原因与待做验证分开写清楚，就已经具备进入路由原理所需的排查基础。
放进方案里
在文件备份与远程运维共用出口的方案中，应明确 TCP 提供有序可靠字节流，应用负责消息边界、结果确认和超时后的处理。发送调用成功与收到传输确认均不能替代业务成功记录。方案应列出客户端、服务端、监听地址、端口、主要流量方向和预计连接寿命，使值班人员能够关联进程、套接字、抓包和应用日志。测试文件、抓包存放位置与保留期限也要写明，避免实验数据进入正式业务目录。
容量评估同时给出出口可持续速率、典型 RTT、文件规模和完成窗口，以带宽时延积检查在途额度是否明显不足，但不把该数值直接当成设备队列配置。验收分别记录吞吐、连接时间、首字节时间、总耗时和高分位交互延迟，并在空闲、正常备份和竞争负载下进行比较。单位统一到明确的字节或 bit，注明是否使用新连接、缓存和限速条件，让结果能够复现。
对于缓冲膨胀，预案先通过备份速率或调度调整降低持续排队，再在有权限的网络范围内评估队列策略。每次干预保留前后时间线，记录 RTT、出口负载、重传和应用处理时间；若只有端点证据，就明确瓶颈位置尚未确认。保留备份完成时限与交互延迟预算，避免仅以更低平均延迟或更高下载速度判断成功。
TCP 参数变更必须对应可验证的机制假设，写明当前值、作用范围、是否需要新连接、观察时间与回滚条件。先在隔离环境改变 1 项配置，再根据吞吐、延迟、内存和错误率决定是否推广。手册另列连接拒绝、握手无回应、零窗口、持续重传与关闭状态积累的证据入口；超出端点可解释范围时，附上源地址、接口和路由查询结果转入 S32 的路径排查。这样方案既能执行，也能在失败后说明判断依据。
10 小结：下一步路由原理（S32）
TCP 用序列号与确认推进字节流，通过接收窗口照顾接收方能力，通过拥塞控制适应路径反馈。可靠性恢复可能增加等待，同一连接上的字节缺口也会挡住后续交付。带宽、窗口、RTT、队列和应用供数共同影响体验，任何单个指标都不能替代完整解释。
自测时尝试回答：ACK 已前进而应用仍卡住，应补查哪些进程证据？吞吐接近出口能力而 RTT 激增，为什么还需要调查队列？抓包没有握手时，为什么不能直接认定窗口缩放未启用？下一课 S32 将从本机路由查询出发，继续解释数据如何选择出口与下一跳，以及返回方向为什么同样重要。