现代的http keep-alive

Question

所以根据haproxy作者的说法，谁知道关于http的一两件事:

Keep-alive was invented to reduce CPU usage on servers when CPUs were 100 times slower. But what is not said is that persistent connections consume a lot of memory while not being usable by anybody except the client who openned them. Today in 2009, CPUs are very cheap and memory is still limited to a few gigabytes by the architecture or the price. If a site needs keep-alive, there is a real problem. Highly loaded sites often disable keep-alive to support the maximum number of simultaneous clients. The real downside of not having keep-alive is a slightly increased latency to fetch objects. Browsers double the number of concurrent connections on non-keepalive sites to compensate for this.

(来自 http://haproxy.1wt.eu/)

这是否符合其他人的经验？即没有保持事件 - 结果现在几乎不明显吗？ (可能值得注意的是，对于 websockets 等 - 无论保持事件状态如何，连接都保持“打开”状态 - 对于响应性很强的应用程序)。
对于远离服务器的人来说，效果是否更大 - 或者在加载页面时从同一主机加载许多工件？ (我认为像 CSS、图像和 JS 之类的东西越来越多地来自缓存友好的 CDN)。

想法？

(不确定这是否是 serverfault.com 的事情，但在有人告诉我将其移到那里之前，我不会交叉发布)。

Answer 1

嘿，因为我是这个引文的作者，我会回复:-)

大型站点有两个大问题:并发连接和延迟。并发连接是由于慢速客户端下载内容需要很长时间以及空闲连接状态引起的。这些空闲连接状态是由连接重用以获取多个对象引起的，称为保持事件，延迟会进一步增加。当客户端非常靠近服务器时，它可以密集使用连接并确保它几乎从不空闲。然而，当序列结束时，没有人关心快速关闭 channel ，并且连接保持打开且长时间未使用。这就是为什么许多人建议使用非常低的保持事件超时的原因。在某些服务器(如 Apache)上，您可以设置的最低超时时间为 1 秒，并且通常无法承受高负载:如果您面前有 20000 个客户端并且它们平均每秒获取一个对象，您将永久建立那 20000 个连接。像 Apache 这样的通用服务器上的 20000 个并发连接是巨大的，需要 32 到 64 GB 的 RAM，具体取决于加载的模块，即使添加 RAM，您也可能不希望更高。实际上，对于 20000 个客户端，您甚至可能会在服务器上看到 40000 到 60000 个并发连接，因为如果浏览器有很多对象要获取，它们会尝试建立 2 到 3 个连接。

如果在每个对象之后关闭连接，并发连接数将急剧下降。事实上，它会下降一个与对象之间的时间下载对象的平均时间相对应的因子。如果您需要 50 毫秒来下载一个对象(一张微型照片、一个按钮等...)，并且您平均每秒下载 1 个对象，那么每个客户端只有 0.05 个连接，也就是 1000 个20000 个客户端的并发连接。

现在是时候建立新的连接了。远程客户端会遇到令人不快的延迟。过去，浏览器在禁用 keep-alive 时会使用大量并发连接。我记得 MSIE 上的数字是 4，Netscape 上的数字是 8。这真的会将每个对象的平均延迟除以那么多。现在，keep-alive 无处不在，我们再也看不到这么高的数字了，因为这样做进一步增加了远程服务器的负载，而浏览器负责保护 Internet 的基础设施。

这意味着使用当今的浏览器，要使非保持事件的服务与保持事件的服务一样具有响应性变得更加困难。此外，一些浏览器(例如:Opera)使用启发式方法来尝试使用流水线。流水线是使用 keep-alive 的一种有效方式，因为它通过发送多个请求而不等待响应几乎消除了延迟。我在一个有 100 张小照片的页面上尝试过，第一次访问的速度大约是没有 keep-alive 的速度的两倍，但是下次访问的速度大约是 8 倍，因为响应非常小，只计算延迟(仅“304”响应)。

我会说，理想情况下，我们应该在浏览器中设置一些可调参数，使它们保持获取的对象之间的连接处于事件状态，并在页面完成时立即删除它。但不幸的是，我们并没有看到这一点。

为此，一些需要在前端安装通用服务器(例如Apache)并且必须支持大量客户端的站点通常必须禁用keep-alive。并且为了强制浏览器增加连接数，它们使用多个域名以便可以并行下载。这在大量使用 SSL 的站点上尤其成问题，因为连接设置甚至更高，因为还有一次额外的往返。

现在更常见的是，此类站点更喜欢安装 haproxy 或 nginx 等轻量级前端，它们在处理数万到数十万个并发连接时没有问题，它们在客户端启用 keep-alive，并在客户端禁用它。 Apache 方面。在这一方面，建立连接的成本在 CPU 上几乎为零，在时间上根本不明显。这样，这提供了两全其美的优点:由于保持事件状态，客户端的超时时间非常短，以及服务器端的连接数少，因此延迟低。每个人都很开心:-)

一些商业产品通过重用前端负载平衡器和服务器之间的连接并通过它们多路复用所有客户端连接来进一步改进这一点。当服务器靠近 LB 时，增益并不比以前的方案高多少，但通常需要对应用程序进行调整，以确保不存在由于多个用户之间意外共享连接而导致用户之间 session 交叉的风险.从理论上讲，这永远不应该发生。现实大不相同:-)