原始网络

相关性和可重复性

George Neville-Neil

尊敬的 KV，

我工作的公司已决定使用无线网络链路来减少延迟，至少在站点之间的天气良好时是这样。在我看来，对于通过有损无线链路的传输，我们需要我们自己的传输协议，该协议直接位于无线电提供的任何东西之上，而不是在 IP 和 TCP 或 UDP 标头上浪费比特，对于点对点网络来说，这些标头并不是真正有用的。

原始网络

尊敬的 Raw，

我完全同意，推出新的网络服务的最佳方法是忽略该领域 30 年的研究成果。祝你好运。

仅次于操作系统开发人员——所有这些人都想重写调度程序（参见“错误和吹牛的权利”，第二封信 https://queue.org.cn/detail.cfm?id=2542663）——是网络工程师和开发人员，他们想编写自己的协议。“如果我们能从一张白纸开始，我们就能比 ARPANET 做得更好，因为 ARPANET 是为旧的、糟糕的硬件设计的，而我们的是闪亮的新硬件。” 这种说法既对又错，在编写任何一行新代码之前，你最好非常确定你的想法属于布尔逻辑的哪一边。

互联网协议不是网络的全部和最终，但它们的应用研究和测试时间比目前存在的任何其他网络协议都多。你说你正在构建一个无线网络，我确信，使用的是你能买到的最高质量的设备。无线网络是出了名的有损，至少与有线网络相比是这样。事实证明，在有损环境中使用 TCP 已经进行了大量研究。因此，尽管你可能需要为每个数据包支付额外的 40 个字节才能通过 TCP 传输数据，但你可能会从已完成的工作中获得一些好处——调整带宽和往返时间估计器——这些工作将存在于发送和接收数据的节点中。

你的网络是点对点的，这意味着你认为你不在乎路由。但是，除非所有工作始终都在此链路的一端或另一端进行，否则你最终将不得不担心寻址和路由。事实证明，有人考虑过这些问题，并且他们将他们的想法实现到了，是的，互联网协议中。

TCP/IP 协议不仅仅是一组标准标头，它们还是一个完整的寻址、路由、拥塞控制和错误检测系统，该系统已经建立并改进了 30 年，以便用户可以从网络最贫困和最偏远的角落访问网络，在这些角落，带宽仍然以千比特为单位衡量，延迟超过半秒。除非你正在构建一个永远不会增长并且永远不会连接到任何其他东西的系统，否则你最好考虑是否需要 TCP/IP 的功能。

我完全赞成对网络协议进行全新研究。有很多东西尚未尝试，有些东西已经尝试过，但当时没有奏效。你的信暗示的不是研究，而是推出，除非你做了功课，否则这种类型的推出会让你和你的项目垮掉。

尊敬的 KV，

你写了测试的重要性，但我没有在你的专栏中看到任何关于如何测试的内容。告诉大家测试是好的固然很好，但一些具体细节会有所帮助。

如何做，而不是为什么

尊敬的 How，

对此回应的推诿之词是，软件测试的方法太多了，无法在一个专栏中给出答案。毕竟，已经有很多关于软件测试的书籍。这些书中的大多数都很糟糕，而且在很大程度上也是理论性的。任何不同意的人都可以给我发送电子邮件，其中包含他们最喜欢的软件测试书籍，我将考虑发布该列表或驳回该建议。我在这里将描述我是如何为我的特定类型的测试设置各种测试实验室的，也许这会有些用处。

任何测试方案都有两个要求：相关性 和 可重复性。测试驱动开发是一个好主意，但是为了编写测试而编写测试就像以 KLOC 来衡量软件工程师的生产力一样。为了编写重要的测试，测试开发人员必须足够熟悉软件领域，才能提出能够确认软件工作正常并且还试图破坏软件的测试。关于这个主题已经有很多文章，所以我将转换方向来谈论可重复性。

当在同一系统上执行的两个不同测试不相互干扰时，测试被认为是可重复的。来自我自身工作的一个具体例子是各种软件缓存（例如路由表和 ARP 表）的填充，这可能会加速数据包转发系列测试中的第二个测试。为了实现可重复性，运行测试的系统或人员必须完全控制测试运行的环境。如果被测系统完全由一个没有副作用的程序封装，那么在相同输入上重复运行该程序就足够控制了。但是大多数系统都不是那么简单。

从测试防火墙的具体示例开始：要测试任何将数据包从一个网络传递到另一个网络的网络设备，你至少需要三个系统：源、宿和被测设备（DUT，测试术语）。正如我之前指出的，测试的可重复性需要对被测系统进行一定程度的控制。在我们的网络测试场景中，这意味着每个系统至少需要两个接口，而 DUT 需要三个接口。源和宿都需要一个控制接口以及一个数据包将被发送到 DUT 或从 DUT 接收的接口。“为什么我们不能只使用控制接口来发送和接收数据包？” 我听到你喊道。“接线所有这些东西很复杂，我们有三台计算机在同一个交换机上，我们现在就可以测试了。” 工作方式是，控制接口和测试接口在所有系统上都必须是不同的，以防止测试期间的干扰。无论你测试什么，你都必须确保减少外部干扰量，除非那是你想要测试的内容。如果你想知道系统如何对干扰做出反应，那么设置测试以引入干扰，但不要让干扰无缘无故地出现。在我们特定的网络案例中，我们希望保持对所有三个节点的控制，无论当我们跨防火墙发送大量数据包时会发生什么。保持对压力下系统的控制并非易事。

维护系统控制的另一种方法是访问串行或视频控制台。这需要比仅仅一堆网络端口更专业的布线，但这是非常值得的。通常，会发生糟糕的事情，而重新获得系统控制权的唯一方法是通过控制台登录。

控制的最终后备能力是远程重启被测系统的能力。现代服务器具有带外管理系统，例如 IPMI，它允许具有用户名和密码的人远程重启机器，以及执行其他低级系统管理任务，包括连接到控制台。每当有人希望我以我描述的方式测试联网系统时，我都要求他们通过网络连接的电源控制器或 IPMI 在相关系统上拥有带外电源管理。在测试期间，没有什么比系统卡死并且不得不走到数据中心重置它，或者更糟糕的是，让你的远程助手为你做这件事更令人沮丧的了。我浪费在测试上的时间，因为有人太小气而没有在他们的服务器上安装 IPMI 或安装合适的电源控制器，本可以更好地花在杀死那些吸收了同一家公司编写糟糕代码的脑细胞上。似乎对细节的疏忽是普遍存在的，当我看到糟糕的测试设置时，我应该准备好看到糟糕的代码。

此时，我们知道我们必须保持对系统的控制——并且我们有几种方法通过单独的控制接口来实现这一点——并且最终，我们必须控制系统的电源。大多数测试实验室接下来会失败的地方是访问必要的文件。

曾几何时，一家工作站公司发现，如果他们可以将文件存储集中在一台更大、而且不得不承认更昂贵的服务器上，他们就可以销售大量廉价工作站。因此，网络文件系统诞生了，这是一种备受诟病但仍然相关的在多组系统之间共享文件的方式。如果你的测试在任何方面都会破坏系统，或者如果使用新软件升级系统会删除旧文件，那么你需要使用某种形式的网络文件系统。最近，我看到人们尝试使用分布式版本控制系统（例如 git）来处理这个问题，其中测试代码和配置被检出到测试组中的系统上。如果每个人都勤奋地从测试系统检入和推送更改，这可能会奏效。但在我的经验中，人们永远没有那么勤奋，并且不可避免地有人升级了一个系统，该系统上有关键的测试结果或配置更改。使用网络文件系统将节省你头上剩下的任何头发。（我应该早点吸取这个教训。）确保网络文件系统流量通过控制接口而不是测试接口。这应该是理所当然的，但在测试实验室建设中，我认为很多理所当然的事情都需要说出来。

此时，我们已经满足了网络测试系统的最基本要求：我们控制所有系统，并且我们有一种方法来确保所有系统都可以看到相同的配置数据，而不会有不必要的数据丢失风险。从这里开始，是时候编写控制这些系统的自动化程序了。对于大多数测试场景，我倾向于在每次测试运行时重新启动所有系统，这会清除所有缓存。这并非适用于所有测试的正确答案，但它肯定会减少先前运行的干扰。

喜欢它，讨厌它？请告诉我们

[email protected]

Kode Vicious，凡人称之为 George V. Neville-Neil，为了乐趣和利润而从事网络和操作系统代码的工作。他还教授各种与编程相关的科目。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他在马萨诸塞州波士顿的东北大学获得了计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

最初发表于 Queue 第 13 卷，第 2 期—
在数字图书馆中评论本文

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。存在许多由各种安全要求驱动的加密哈希标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但在面对具有特定模式的数据集时，它可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在快速前进的过程中，它容易受到时尚的支配，并且可能会忘记或忽略针对它面临的一些永恒问题的经过验证的解决方案。用例于 1986 年首次引入，并在后来普及，是这些经过验证的解决方案之一。