嗨，由于我是这篇引用的作者，所以我来回答：-）
在大型网站上有两个主要问题：并发连接和延迟。慢速客户端导致并发连接，需要花费很长时间才能下载内容，并且由于闲置连接状态而导致。这些闲置连接状态是通过重复使用连接以获取多个对象（称为keep-alive）导致的，这进一步增加了延迟。当客户端非常靠近服务器时，它可以密集地使用连接并确保连接几乎从不闲置。但是当序列结束时，没有人关心快速关闭通道，连接会保持打开和未使用很长一段时间。这就是为什么许多人建议使用非常低的keep-alive超时的原因。在像Apache这样的某些服务器上，您可以设置的最低超时时间为1秒，这通常太长以维持高负载：如果您面前有20000个客户端，并且他们平均每秒获取一个对象，则将永久建立这些20000个连接。像Apache这样的通用服务器上的20000个并发连接量巨大，将需要32到64 GB的RAM，具体取决于加载了哪些模块，并且即使添加RAM也可能无法希望更高。实际上，对于20000个客户端，您甚至可能会看到服务器上的40000到60000个并发连接，因为浏览器将尝试设置2到3个连接（如果他们有许多对象要获取）。
如果在每个对象后关闭连接，则并发连接数量将急剧下降。事实上，它将按照平均下载一个对象所需时间与对象间时间之比的因素下降。如果您需要50毫秒来下载一个对象（缩略图、按钮等），并且如上所述平均每秒下载1个对象，则每个客户端只有0.05个连接，即20000个客户端只有1000个并发连接。
现在建立新连接的时间很重要。远程客户端会遇到不愉快的延迟。过去，浏览器在禁用keep-alive时使用大量并发连接。我记得MSIE上有4个连接，而Netscape上有8个连接。这样会将每个对象的平均延迟减少很多。现在，由于keep-alive无处不在，我们不再看到那么高的数字了，因为这样做会进一步增加远程服务器的负载，而浏览器负责保护互联网基础设施。
这意味着在当今的浏览器中，非keep-alive服务越来越难以获得像keep-alive服务一样的响应能力。此外，一些浏览器（例如：Opera）使用启发式算法来尝试使用管线化。管线化是一种有效地使用keep-alive的方式，因为它通过发送多个请求而无需等待响应来几乎消除了延迟。我曾经在一个包含100张小照片的页面上尝试过，第一次访问比没有keep-alive时快两倍左右，但下一次访问则快了大约8倍，因为响应很小，只有延迟才起作用（只有“304”响应）。
我认为，理想情况下，我们应该在浏览器中设置一些可调节参数，使它们在获取对象之间保持连接，并在页面完成后立即关闭。但不幸的是，我们没有看到这一点。
因此，一些需要在前端安装通用服务器（例如Apache）并且必须支持大量客户端的网站通常需要禁用keep-alive。为了强制浏览器增加连接数，他们使用多个域名来实现下载的并行处理。这在使用SSL的站点上尤其有问题，因为连接设置更高，因为需要额外的往返。
现在更常见的是，这些网站倾向于安装轻量级前端，如haproxy或nginx，它们没有问题处理数万到数十万个并发连接，在客户端启用keep-alive，并在Apache端禁用它。在服务器端，建立连接的成本几乎为零，而且在时间上几乎不可感知。这样可以提供最佳效果：由于客户端的keep-alive具有非常低的超时时间，因此低延迟，同时在服务器端保持较少的连接数。每个人都满意 :-)
一些商业产品通过重复使用前置负载平衡器和服务器之间的连接，并将所有客户端连接多路复用到它们上面来进一步改善这种情况。当服务器靠近LB时，收益不会比以前的解决方案高得多，但通常需要适应应用程序，以确保没有用户会话交叉风险，因为多个用户共享一个连接可能会导致此类问题。理论上不应该发生这种情况。现实情况则大相径庭 :-)
