【发布时间】：2012-10-31 05:41:51
【问题描述】：
我正在设置一个面向服务的 Web 应用程序。 UI 部分（一个 Web 应用程序）正在使用我正在编码的 REST Web 服务。所以我在服务器端和客户端都有手。
我只是想知道在这种情况下设置 HTTP keep-alive 是否有意义。如果是，我很好奇为什么。
提前致谢。
【问题讨论】：
标签： web-services rest keep-alive
【发布时间】：2012-10-31 05:41:51
【问题描述】：
是的，确实如此！根据我在服务器上的测试，我可以在不使用 keepalive 的情况下每秒对我的 REST Web 服务进行 300 次调用，在启用 keepalive 的情况下超过 2000 次。
您必须对使用模式进行一些分析 - 用户驱动的使用通常是突发性的，因此将 keepalive 超时保持在相当短的时间是有意义的，只是为了处理单个突发。
【讨论】：
-
感谢您的回复。这是 REST 上下文中 keepalive 的唯一优势吗？
-
基本上是的 - 每次协商一个新的 TCP 连接都非常耗时 - 它很容易花费几百毫秒，足以让最终用户在某些情况下产生“站点很慢”的想法。因为，如果你使用keep-alive，连接丢失时会透明地重新协商，使用它并没有什么坏处，它不会使你的代码更复杂，只是增加了一点速度。
-
@thedayofcondor 如果有更多请求来自同一个客户端，则具有保持活动的好处，不是吗？保持连接活动的缺点是我们可能会阻止新客户端创建连接，如果我错了，请纠正我。
-
@Bruce_Wayne 是的——如果你想继续交换数据，keep-alive 可以避免代价高昂的 TCP 协商。当然，没有免费啤酒之类的东西，您需要为服务器端使用的额外资源付费。但是，服务器可以保持打开的连接数量没有技术限制（但操作系统有限制），并且保持活动更多的是服务器和客户端之间的礼貌协商 - 服务器可以随时改变主意如果资源不足，那么总的来说我认为这不是问题。
-
@thedayofcondor 感谢您的回复，在某种程度上它验证了我的理解。出于好奇，我现在有另一个问题，正如你所说的限制。连接数主要是由于操作系统限制（我同意），假设服务器为部署在其上的其余服务侦听 5 个不同的端点，并且服务器可以随时允许最多 1000 个连接，这是否意味着所有端点将共享这 1000 个连接以任何比率取决于来自哪个端点的请求？