是长期(1分钟+)KeepAlives良好的JSON / Ajax WebService?

我知道,当我们有很多来自客户端浏览器的快速连续请求时,keepalive对于消除TCP连接的惩罚是很好的,但是像JSONP web服务那样的情况呢? 这与网页加载有不同的特征:

  1. 客户端(浏览器)通常会一次发出1个请求。 几乎没有辅助的快速请求参考文件,如在HTML中。

  2. 这些要求有时会相继发生,但更常见的是几秒钟甚至几分钟。 如许多build议设置keepalive非常低并不总是一个合理的设置。 Apache的当前默认值是5s( http://httpd.apache.org/docs/2.4/mod/core.html#keepalivetimeout ),它低于1.3的15s( http://httpd.apache.org/docs/ 1.3 / mod / core.html#keepalivetimeout )。 两者都低于一分钟。 这可能是因为15太高,或者宽带缓解了延迟 – 或者两者兼而有之。 目前的5s可能对这种情况没有任何好处。

我们可以假设每个连接(一个线程或一个进程)不会占用一个Linux任务,而套接字在空闲/等待/阻塞保持活动状态下保持打开状态,但是将这样的套接字悬空打开是个好主意几分钟? 使用这种方法的选项是Nginx,Apache Event MPM等,它们在* nix中使用基础的基于事件的特性,如kqueue或epoll。 假设dynamic内容在另一个任务池中完成,一旦完成,keepalive的套接字将只是一个打开的文件描述符。

它真的只是一个文件描述符吗? linux内核花费多less,例如在一个或多或less空闲的状态下跟踪更多的内核。 这是否会导致Web服务器耗尽FD或以任何方式挨饿? 这个成本应该与从头开始为后续请求build立另一个TCP连接的成本权衡。

http://gabenell.blogspot.com/2010/11/connection-keep-alive-timeouts-for.html&http://blog.fastmail.fm/2011/06/28/http-keep-alive-connection- 超时/文件,除了Safari将保持> = 1分钟。 http://www.semicomplete.com/blog/geekery/ssl-latency.html文档HTTP和HTTPS的TCP延迟。

我认为在这种情况下应该权衡其他事情。 保持活力不太可能给你的服务器造成负担; 它应该至少部分地专注于这项任务。 更严重的瓶颈是客户和中间要素。 客户端有时对总连接数有限制(浏览器往往每页,每台服务器和全局都有)。 一路上最脆弱的一跳是NAT路由器。 某些客户端可能在NAT后面,有时候无法跟踪数百个用户的数千个连接。 在这种情况下,您可能会浪费可用资源的百分比来保持连接打开(并且必须针对断开连接的高可能性进行编码)。 称重到所需的时间:建立一个连接(甚至通过HTTPS和客户端证书)不应该花很长时间(与空闲时间相比),只需要3个额外的往返(最坏的情况应该是半秒钟设备)。 还要考虑保持活力的常见缺点:防止客户端漫游(例如,在移动数据和WiFi之间切换); 资源被标记为“正在使用”,而实际上不是(例如,设备或其组件被阻止接受所有者设置的电源策略)。 所以我建议反对保持活力,除非下列情况之一是真实的:a)保持活力的实施比重新连接要容易得多[如果这不是相反的情况,我会感到惊讶],或者b )你处于一个实时的环境中(当RTT变得相关的时候,你会想把它放在一起,而不是4个中的3个)。

Facebook使用长轮询,并且无论是否有响应,每55秒重置一次连接。 他们克服了在后端使用彗星服务器而导致Apache过载的问题。

在前端打开连接的问题是大多数浏览器限制同时连接到同一个域的总数。 这可能会减慢你的页面加载速度,甚至冻结它。 例如,如果firefox让我有2个连接打开到一个域,并进行60秒的民意调查,这让我有一个连接的一切。 如果我想下载一个大文件和一些图片,我会被困在剩下的一个流中。 这是使用短轮询而不是长轮询技术更好的地方。 Websockets虽然会帮助解决这个问题。

对不起,我还不能添加评论。

https://www.facebook.com/note.php?note_id=14218138919