我记得一个非常快的Linux内核模块，称为“TUX”，用于静态文件，以回答IIS优于Linux的静态文件Web服务性能并解决“C10K问题”。 现在我继续看到：
…为“快速静态文件服务”。 如果您的操作系统具有正确的function，快速提供静态文件并不困难。 自从IO完成端口，重叠I / O等发明以来
Tux是否因为安全隐患而死亡？ Kqueue / Epoll与Sendfile之类的function结合在一起是否过时了？ 什么是最好的解决scheme来服务100％的静态内容 – 比如50个左右的图像模拟一个“animation书”电影packshots。
我明白这个“服务器相关”的问题，但这也是理论上的。 如果它纯粹是静态的，CDN真的会更好吗？
主要是因为IngoMolnár停止了工作。 为什么？ 我相信这是因为内核版本2.2实现了sendfile(2)调用，它大致匹配了Tux先前获得的巨大性能优势。 请注意Tux 2.0参考手册的日期为2001年。
提供静态文件有三个步骤：决定发送哪个文件，决定是否发送文件，发送文件。 现在Tux做了一个很好的发送文件的工作，所以决定发送哪个文件，以及决定是否发送一个文件是一个糟糕的工作。 决策是政策的问题，应该在用户空间中完成。 添加sendfile，我可以在短时间内编写一个几乎和tux一样好的服务器，并且不用重新编译我的内核就可以添加东西。 也许SQL日志记录。 只是考虑从内核创建的用户空间sql调用使我的眼睛抽搐。
由于sendfile（），Tux不再需要了。 Nginx充分利用了这一点，IMO是静态或非静态内容的最佳Web服务器之一。 我发现了lighttpd，ymmv的内存问题。
CDN的全部目的是将“网络服务器”移到最终用户浏览器附近。 这意味着更少的网络跳数和更少的往返延迟，而无需在全球托管多台Web服务器并使用地理位置服务器将用户发送到最近的服务器。 请注意，由于这些Web服务器不在您的控制范围内，因此可能会超载，而且如果网络负载过重，可能会减少跳数减少的好处。 CDN通常是DDOS攻击的目标，您可能会陷入与您的内容无关的事情中。