为什么 TUX Web 服务器死了？用 Nginx/Lighttpd/Epoll/Kqueue 代替吗？答案

【问题标题】：Why is the TUX Web Server Dead? Does Nginx/Lighttpd/Epoll/Kqueue Replace it?为什么 TUX Web 服务器死了？用 Nginx/Lighttpd/Epoll/Kqueue 代替吗？
【发布时间】：2013-11-28 06:20:55
【问题描述】：

我想起了一个非常快速的 Linux 内核模块，称为“TUX”，用于静态文件，以回答 IIS 优于 Linux 静态文件 Web 服务的性能并解决“C10K 问题”。现在我不断看到：

Nginx
Lighttpd
CDN

... 用于“快速静态文件服务”。如果您的操作系统具有正确的功能，那么快速提供静态文件并不困难。自从发明了 IO Completion 端口、重叠 I/O 等以来，Windows 就有了。

Tux 是否因为安全隐患而死亡？将 Kqueue/Epoll 与 Sendfile 等功能相结合而过时的实验是否已经过时？提供 100% 静态内容的最佳解决方案是什么——比如用 50 张左右的图片打包来模拟“翻书”电影。

我理解这是“与服务器相关”的问题，但这也是理论上的。如果它是纯静态的，CDN 真的会更好吗？

【问题讨论】：

我不是这里的专家，但你的最后一个问题对我来说似乎很奇怪.. CDN 不是简单的多个具有负载平衡的静态文件服务器吗？您只需告诉客户端要连接到哪个服务器（通过最低延迟/最不忙的服务器/最近等），就是这样。单个服务器迟早会无法满足需求，但如果您有几个像 CDN 中的服务器，您只需在它们之间分配负载。
我认为这个问题没有问题，尽管我确实将这个问题混为一谈。您不需要用户空间线程来发送文件。内核可以做到。问题是您确实需要一个用于应用程序逻辑的线程，因此许多站点只创建一个名为 images.example.com 的第二个域，并在其前面添加一个 CDN。它缓存它，所以服务器暂时看不到请求。据推测，CDN 必须使用像 Tux 这样的超级优化的东西（我怀疑他们使用 Nginx 以及其他原因，但因为 Nginx 并不早于 CDN 的扩散）来提供静态文件，因为这就是他们所做的一切。

标签： nginx linux-kernel cdn lighttpd epoll

【解决方案1】：

主要是因为 Ingo Molnár 停止了这项工作。为什么？我相信这是因为内核版本2.2 实现了sendfile(2) 调用，它与Tux 之前获得的巨大性能优势相匹配（大约）。请注意Tux 2.0 Reference Manual 的日期为 2001 年。

【讨论】：

我提到了 sendfile()。问题是您仍然必须有一个线程来invoke sendfile()，所以它不可能是全部。我假设您的意思是 sendfile()+epoll/kqueue。即使那样，如果您所做的只是提供没有任何应用程序逻辑的静态内容，那么它会更重。这正是 Facebook 和 Myspace 对隐私权倡导者的愤怒的做法。如果您知道文件名，则可以查看任何人的照片。从他们的角度来看，文件名 IS 是密码，但您可以看到为什么 CDN 可能不想在任何地方引入应用程序逻辑。 Sendfile() 不是全部。
epoll 直到 2.5.44 才被引入，那时 Tux 不再被开发。 kqueue 在 4.1 中被添加到 FreeBSD - 无论如何都不会影响 linux 内核服务器。我们谈论的是一个从未被主线内核接受的 linux 内核服务器。
我提到kqueue是因为它看起来和epoll很像。你说得对，它只是 FreeBSD。我应该把它排除在外。 sendfile() 永远无法达到 Tux 的速度，因为每个文件需要 1:1 线程，或者 select/poll()，不是吗？我不明白这怎么可能远程接近 Tux。
没有。这不是 1:1 内核：用户线程；您是否注意到在 sendfile() 手册页中 - sendfile() copies data between one file descriptor and another. Because this copying is done within the kernel... - 无论如何它都在内核空间中。
它是否复制内存与它是否阻塞以及如何通知您完成完成无关。我不知道它是否可以或将在完成之前返回静态文件，但它肯定可以用于某些设备或在负载下。不明白你的答案。

【解决方案2】：

服务一个静态文件有三个步骤：决定发送哪个文件，决定是否发送文件，发送文件。现在 Tux 在发送文件方面做得非常好，所以决定发送哪个文件，以及决定是否发送文件的糟糕工作。这些决定是政策问题，应该在用户空间中完成。添加 sendfile，我可以在短时间内编写几乎与 tux 一样好的服务器，并且无需重新编译内核即可添加内容。也许是 sql 日志记录。只是想到从内核进行的用户空间 sql 调用让我的眼睛抽搐。

【讨论】：

但是除了 sendfile() 之外你还会使用什么？显然，它需要是非阻塞的，但也需要知道它什么时候“完成”。 Windows 中的 I/O 完成端口执行此操作。在 *nix 中似乎不太明确。我喜欢 I/O 完成端口的想法，因为它是一个“以防万一”它阻塞的线程池，以及采用零拷贝技术和 TransmitFile()。我看到的另一个问题是 SSL 呢？您需要在内核中安装 SSL，以便在没有副本和用户空间线程的情况下高效传输。
Tux 也没有 ssl，但内核级加密可以更轻松地进行硬件加速（自从我关注 pgp 电话以来一直梦想着这一点）。至于阻塞，这取决于您的流程模型。
好吧，既然我们在这里试图用类似 Nginx 的东西来模拟 Tux，假设进程模型意味着所需的线程数，这可能是 1 左右——因为大部分工作可以由操作系统完成。但它可能更多地保持它的最佳状态，因为在你将它交给内核之前会有一点点开销。 Sendfile 并没有在这里做所有事情。天真地使用 sendfile() 只会为每个连接生成 1 个线程并调用 sendfile() 并阻塞。这将节省内存（零拷贝），但仍会为 C10k 实验创建大量线程。
这里有一个非常有趣的对位，说明为什么 1:1 可能没问题。为了记录，他有一个观点。如果线程库变得更好并且所有 O(N) 的东西都消失了，谁在乎呢？ usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/…
sendfile 和 splice 被记录为在实现之间存在差异，在我的简短阅读中可能没有 linux 上的非阻塞模式。

【解决方案3】：

由于 sendfile()，不再需要 Tux。 Nginx 充分利用了这一点，而 IMO 是静态或非静态内容的最佳 Web 服务器之一。我发现 lighttpd、ymmv 存在内存问题。

CDN 的全部目的是将“网络服务器”移动到更靠近最终用户浏览器的位置。这意味着更少的网络跃点和更少的往返延迟，您不必在世界各地托管多个 Web 服务器并使用地理 dns 将用户发送到最近的位置，而无需付出高昂的成本。请注意，由于这些 Web 服务器不在您的控制范围内，它们可能会超载，并且如果它们的网络超载，则可能会减少跳数减少的好处。 CDN 通常是 DDOS 攻击的目标，您可能会陷入与您的内容无关的事情中。

【讨论】：

Sendfile() 并不是全部。这不是 CDN 的（唯一）要点——恭敬地不同意。 CDN 还为提供大量静态内容而优化，不一定完全是网络事物。至少这是我的经验。
while open()+loop(sendfile())+close() 与 open()+ 相比，减少了大约 50% 的系统调用开销（在大文件上，在小文件上大约 25%） loop(read()+write())+close(), tux 减少了 100% 的系统调用开销（在小文件和大文件上）......所以 Tux 仍然比 nginx 有优势。（这两种方法都将用户空间内核 memcpy 减少了大约 100%）