12. 我们的观点

12.1. NNTP 的效率问题

要理解为什么 NNTP 通常不适合作为新闻源选择，我们需要理解 TCP 的滑动窗口协议和 NNTP 的本质。由于以下简单的原因，对于大多数批量文章传输情况，NNTP 惊人地浪费带宽

• 无压缩：文章以纯文本形式传输。

• 无文章传输重启：如果连接在文章传输一半时中断，则下一轮必须从文章开头重新开始。

• 乒乓协议：NNTP 不适用于批量流数据传输，因为 TCP 滑动窗口功能在 NNTP 中无法使用。

什么是乒乓协议？TCP 使用滑动窗口机制来非常快速地单向泵出数据，并且在大多数情况下可以接近线路速度。然而，这只有在应用层协议可以聚合大量数据并将其泵出，而无需频繁停止，等待来自另一端应用层的确认或响应时才有效。这正是通过 FTP 发送一个 100 MB 的文件比发送 10,000 个 10 KB 的文件花费的时钟时间少得多的原因，所有其他参数保持不变。诀窍是保持滑动窗口在传出数据上平稳滑动，尽可能快地发送数据包，而永远不允许窗口在等待确认时变空。需要来自两端不断发送短 bursts 数据的协议，例如在远程过程调用的情况下，被称为“乒乓协议”，因为它们让您想起乒乓球。

对于 NNTP 来说，问题恰恰在于此。Usenet 新闻消息的平均大小，包括标头和正文，是 3 KB。当数千篇文章通过 NNTP 发送出去时，发送服务器必须发送第一篇文章的消息 ID，然后等待接收服务器回复“是”或“否”。一旦发送服务器收到“是”，它就会发送该文章，并等待接收服务器的“确定”回复。然后它发送第二篇文章的消息 ID，并等待另一个“是”或“否”。等等。TCP 滑动窗口永远无法发挥作用。

这种对 TCP 数据泵送能力的次优使用，加上缺乏压缩，使得该协议非常适合同步连接，例如用于新闻阅读或实时更新，但对于可以延迟和泵出的批量数据传输来说非常糟糕。所有这些在基于 TCP 的 UUCP 的情况下都恰恰相反。

要决定哪种协议，基于 TCP 的 UUCP 或 NNTP，适合您的服务器，您必须解决两个问题

1. 从您的上游服务器收到一篇文章到将其传递给您，您的服务器可以承受多少等待时间？

2. 您是否从多个邻近服务器接收同一组层级结构，即您的新闻源流量模式是网状结构而不是树状结构？

如果您对以上两个问题的回答是“消息不能等待”和“我们以网状结构运行”，那么 NNTP 是您的服务器接收其主要源（们）的正确协议。

在大多数情况下，主要服务提供商运营的运营商级服务器不希望接受从收到文章到重新传输文章的哪怕一分钟的延迟。它们也在网状结构中与其他由其自身组织（例如为了冗余）或其他组织运营的服务器一起运行。它们通常非常靠近互联网骨干网，即与 Tier 1 ISP，并且拥有极快的互联网链路，通常超过 10 Mbits/秒。从这些服务器流出的传出源的数据量大于传入的数据量，因为每篇传入的文章都会被保留，不是为了本地消费，而是为了重新传输给流量下游的其他服务器。这些服务器以小于 30 秒的重新传输延迟而自豪，即我会在收到一篇文章后 30 秒内将其重新传输给您。

但是，如果您的服务器被公司用于为其员工提供 Usenet 新闻，或者被机构用于为其学生和教师提供服务，那么您不是以网状模式运营您的服务器，也不介意消息是否需要几个小时才能从您的上游邻居处到达您。

在这种情况下，您可以通过迁移到 UUCP 来节省大量带宽。即使在这个互联网主导的时代，没有人使用拨号点对点链路为您提供新闻源，您也可以通过互联网使用基于 TCP 的 UUCP 来获取压缩的批量新闻源。

在此背景下，我们想提及 Taylor UUCP，这是一个在 GNU GPL 下提供的优秀的 UUCP 实现。即使对于拨号连接，我们也优先使用此 UUCP 实现，而不是商业 Unix 供应商提供的捆绑 UUCP 系统，因为它更加稳定、高性能，并且始终支持文件传输重启。在 TCP/IP 上，Taylor 是我们唯一尝试过的，我们不希望尝试任何其他的。

除了其稳健性之外，Taylor UUCP 还具有对于大型 Usenet 批量传输至关重要的一个宝贵功能：文件传输重启。如果它正在传输一个 10 MB 的批次，并且连接在 8 MB 后中断，它将从上次中断的位置精确地重新开始。因此，不会浪费任何字节的带宽，并且队列永远不会卡住。

在 NNTP 上，由于没有批处理，传输一次发生一篇文章。考虑到一篇文章（相对）较小的尺寸与多兆字节的 UUCP 批次相比，人们会期望一篇文章在传输过程中永远不会构成重大问题；如果它无法一次性推送过去，它肯定会在下次被复制。然而，我们经历过整个 NNTP 源因一篇文章而卡住数天的情况，日志显示同一篇文章在传输过程中一次又一次地中断连接 [1]。一些罕见的文章大小可能超过兆字节，尤其是在comp.binaries中。在每次此类事件中，我们都不得不手动编辑传输服务器上的队列文件，并将有问题的文章从队列的头部移除。另一方面，Taylor UUCP 从未在阻塞队列方面给我们带来任何问题。

我们认为，绝大多数提供 Usenet 新闻服务的服务器都位于 Usenet 新闻流的叶节点，而不是核心。这些服务器通常以树状结构连接，每个服务器都有一个上游“父节点”和多个下游“子节点”。这些服务器从其上游服务器接收其批量传入源，并且他们的用户可以容忍文章进出延迟几个小时。如果您的服务器属于此类，我们认为您应该考虑使用基于 TCP 的 UUCP 并传输压缩批次。这将最大限度地减少带宽使用，如果您使用拨号互联网连接运营，它将直接减少您的费用。

关于网状模式新闻源流量与使用 NNTP 的需求之间的联系。如果您的服务器正在从多个邻近服务器接收主要源 --- 而不是涓滴源 ---，那么您必须使用 NNTP 来接收这些源。原因在于 UUCP 批次被接受的方式。UUCP 批次完整地接收到您的服务器中，然后它们被解压缩和处理。当发送服务器给您批次时，它没有机会逐篇文章地检查批次，并询问您的服务器是否拥有每篇文章。这样，如果多个服务器为您提供相同层级结构的大型源，那么如果您选择 UUCP 方式，您将不可避免地收到每篇文章的多个副本。压缩批次的所有优势都将被抵消。NNTP 的IHAVE和SENDME对话实际上允许精确地对每篇文章进行这种双重检查，因此您甚至不会收到一篇文章两次。

对于定期使用拨号连接到互联网以获取新闻的 Usenet 服务器，UUCP 选项尤其重要。由于上述段落中描述的原因，它们的主要传入新闻源无法使用排队的 NNTP 源推送给它们。这些不幸的服务器通常被迫使用拉取 NNTP 源来拉取文章，这通常非常慢。这可能导致连接时间长、每次线路中断后重复尝试以及高昂的互联网连接费用。

另一方面，我们已经使用基于 TCP 的 UUCP 和gzip压缩的批次超过五年了，在各种站点中。即使在今天，所有八个标准层级的完整源，加上完整的microsoft, gnu和netscape层级，减去alt和comp.binaries，也可以在每晚几个小时的连接时间内轻松处理，以 33.6 或 56 Kbits/秒的速度拨号连接到互联网。我们相信，只要您忘记 NNTP 源，即使是包含alt的谚语般的“完整源”，也可以在 56 Kbits/秒的 24 小时链路中轻松处理。顺便说一句，我们通常在使用gzip -9压缩我们的新闻批次时，获得 4:1 的压缩比。

12.2. C-News+NNTPd 还是 INN？

INN 和 CNews 是 Usenet 新闻最流行的两种自由软件实现。在这两者中，我们更喜欢 CNews，主要是因为我们已经在一个非常广泛的 Unix 版本范围内使用它超过十年了，从其最早的版本 --- 所谓的“Shellscript 版本” --- 开始，并且我们还没有看到需要更改。[2]

我们见过 INN，并且我们对在一个可执行文件中放入如此多功能的软件实现感到不舒服。这让我们想起了 Windows NT、Netscape Communicator 和其他复杂而庞大的系统，这些系统的不透明性让我们感到不舒服。我们认为 CNews 的架构，它包含许多小程序，直观地符合构建大型复杂系统的 Unix 方法，在 Unix 方法中，每个部分都可以被理解、调试，并在需要时单独替换。

其次，我们似乎看到向 INN 转移伴随着向 NNTP 作为主要新闻源机制的转移。这不是 INN 的错；我们怀疑这是 INN 用户和 CNews 用户之间的一种文化差异。我们发现 UUCP 与 NNTP 用于批量新闻源的问题比 CNews 与 INN 的选择更严重。我们根本不同意 NNTP 对于大多数站点的批量 Usenet 源来说是合适的协议这种观点。不幸的是，我们似乎发现大多数更习惯使用 INN 的站点似乎也更喜欢 NNTP 而不是 UUCP，原因我们尚不清楚。

我们的评论不应被视为对 INN 的质量或稳健性有任何保留。它的受欢迎程度证明了它的质量；它肯定“完成了工作”，和其他任何东西一样好。此外，有大量商业 Usenet 新闻服务器实现是从 INN 代码开始的；我们不知道有任何是从 CNews 代码开始的。我们怀疑 Netwinsite DNews 系统和 Cyclone Typhoon 都是受 INN 启发的。

我们将推荐 CNews 和 NNTPd 而不是 INN，因为对于上述原因，我们对 CNews 架构更满意，并且我们不运行运营商级站点。我们将继续支持、维护和扩展这个软件基础，至少对于 Linux 而言是这样。我们看不出绝大多数 Usenet 站点有任何理由被迫使用其他任何东西。欢迎您发表观点。

如果我们正在设置和管理具有近乎实时的吞吐量要求的运营商级站点，我们可能不会选择 CNews。对于这些情况，我们在第 12.1 节中讨论了我们对 NNTP 与压缩 UUCP 的看法。

Suck 和 Leafnode 在选项范围内有其位置，它们对于那些被 CNews+NNTPd 或 INN 的“功能齐全”的外观吓倒的新手来说似乎很有吸引力。然而，即使在 Linux 笔记本电脑上，我们也运行 CNews + NNTPd。我们怀疑 INN 也可以这样使用。我们不认为这些“功能齐全”的实现比它们更简单的同类产品更耗费资源。因此，除了管理和配置的熟悉程度之外，我们看不到即使是单独的最终用户也会选择 Leafnode 或 Suck 而不是 CNews+NNTPd 的任何其他原因。一如既往，欢迎提出相反的意见。