摘要

  • RFC 2398 按测试类别、工作方式、自动化程度、可获取性和运行环境记录十二种 TCP 工具，没有把“测试”视为一种可互换活动。
  • 主动注入故障、测量真实协议栈、抓包、离线分析和绘图产生的是不同证据；曲线或吞吐量数字本身不能证明正确性、安全性或应用结果。

1998 年的 TCP 测试没有一台万能仪器。有的工具协调多条传输并输出日志；有的把队列、带宽和延迟限制插入正在运行的协议栈；有的把 Linux 主机变成“选择性变坏”的路由器；还有的构造报文、注入故障、阅读抓包或绘制时间—序列图。RFC 2398 把十二种路径放进同一目录。

目录格式本身就是约束。每个条目必须说明名称、类别、构造方法、自动化与人工介入、获取位置、所需环境以及参考资料。这样一来，工具名称不能代替方法。若没有记录流量如何生成、哪一个协议栈接受了测试、分析器使用了什么假设，再漂亮的图也可能失去意义。

规范把目标分为功能正确性、性能与压力。三者互相关联，却不是同一件事。实现可以很快，却没有遵守所有要求；可以在简单交换中合规，却在高负载下失败；压力结果也可能只显示脆弱，而不能自动区分问题来自被测实现、测量路径还是测试夹具。

Dummynet、NIST Net 和 Orchestra 位于证据链前端。它们能够改变真实流量所处的条件：限制带宽、制造队列、延迟、丢弃、复制、重排，甚至修改或新增报文。Orchestra 虽能按脚本注入故障，最后仍需用户查看报文轨迹，判断行为正确与否。制造条件与解释结果从来不是同一个动作。

Tcpanaly 则从抓包开始。它把轨迹与多种 TCP 实现的知识模型比较，尝试解释每个报文为何在那个时刻出现，并区分可能的测量错误与实现偏差。RFC 2398 坦言它很难分类，因为它更像给行为画像，而不是执行一个固定测试。Tcptrace 计算重传、往返时间、窗口和吞吐量；Tracelook 与 Xplot 把变量变成图。它们帮助人看见，但没有制造被画出的事件。

Netperf、TReno 与 Ttcp 又揭示另一层边界。吞吐或延迟数字取决于谁生成流量、包含了哪一端的 TCP 行为。TReno 用 UDP 或 ICMP 模拟遵守拥塞控制和 SACK 的 TCP 时序，希望把路径测量与端系统 TCP 实现分开。这让它回答不同问题，而不是天然给出更高等级的答案。

RFC 对自身权威保持克制。目录来自 TCP Implementer’s 工作组向作者报告的工具，不声称穷尽。作者核验的是出版时可以获得，并没有承诺永久维护、当前兼容或普遍适用。一个可下载地址只能证明当时可取，不能把 1998 年的可用性延长到今天。

安全章节划出更硬的边界。有些工具能产生恶意报文或拒绝服务条件，有些需要外来内核代码与 root 权限，抓包还可能看到他人的邮件和文件。但规范明确说，列表里没有任何工具以任何方式评估安全。能够扰动网络，不等于能够裁决网络是否安全。

所以，图表从来不是测试本身。它只是较长保管链末端的一种表示：工具、环境、注入或观察条件、实现版本、流量、抓包、计算、可视化、人工判断。缺少一环，平滑曲线可能只剩漂亮故事；保留全部环节，结果才能准确说明发生了什么，同时不冒充实验无力回答的问题。

资料来源