linux – 很长(1分钟)KeepAlives适合JSONAjax WebService吗？

概述我知道,当我们从客户端浏览器获得大量快速连续请求时,Keepalive非常适合消除TCP连接惩罚,但是像 JSONP Web服务这样的情况呢？这与网页加载的特征不同： >客户端(浏览器)通常一次发出1个请求.几乎没有像HTML中那样的引用文件的辅助快速激活请求. >请求有时会连续出现,但通常会间隔几秒甚至几分钟.像许多建议一样设置keepalive并不总是合理的设置. Apache目前的默认值是5 我知道,当我们从客户端浏览器获得大量快速连续请求时,Keepalive非常适合消除TCP连接惩罚,但是像 JSONP Web服务这样的情况呢？这与网页加载的特征不同：

>客户端(浏览器)通常一次发出1个请求.几乎没有像HTML中那样的引用文件的辅助快速激活请求.
>请求有时会连续出现,但通常会间隔几秒甚至几分钟.像许多建议一样设置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.假设动态内容在另一个任务池中完成,一旦完成,keepalive’d套接字将只是一个打开的文件描述符.

它真的“只是”文件描述符吗？例如,在一个或多或少的空闲状态下跟踪更多的linux内核需要多少钱.这是否会导致网络服务器耗尽FD或以任何方式使其饿死？应该将此成本与从头开始为后续请求构建另一个TCP连接的成本进行权衡.

http://gabenell.blogspot.com/2010/11/connection-keep-alive-timeouts-for.html& http://blog.fastmail.fm/2011/06/28/http-keep-alive-connection-timeouts/文件表示Safari之外的所有内容都将保持> = 1分钟. http://www.semicomplete.com/blog/geekery/ssl-latency.html记录了http和httpS的TCP延迟.

解决方法 在这种情况下,我认为应该权衡其他事情.保持活动不会给你的服务器带来负担;它应至少部分专注于任务.更严重的瓶颈是客户和中间元素.客户端有时对总连接有限制(浏览器倾向于每页,每服务器和全局).沿途最脆弱的跳跃是NAT路由器.一些客户端可能在NAT后面,无法跟踪有时数百个用户的几千个连接.在这种情况下,您可能会浪费可用资源的百分比来保持连接打开(并且必须针对断开连接的高可能性进行编码).权衡所需的时间：建立连接(甚至通过httpS和客户端证书)不应该花费很长时间(与空闲时间相比)并且只需要3次额外的往返(最坏的情况应该是移动设备上的半秒)设备).还要考虑保持活动的常见缺点：防止客户端漫游(例如,在移动数据和wifi之间切换);资源被标记为“在使用中”而实际上没有(例如,设备或其组件被阻止注意由所有者建立的电源策略).因此,除非满足下列条件之一,否则我会反对保持活着：a)保持活动的实现在某种程度上比重新连接更容易[如果这不是相反的情况,我会感到惊讶],或者b )你处于一个实时环境中[当RTT变得相关时,你会希望将它们全部放在一起,而不仅仅是4个中的3个]. 总结

以上是内存溢出为你收集整理的linux – 很长(1分钟)KeepAlives适合JSON / Ajax WebService吗？全部内容，希望文章能够帮你解决linux – 很长(1分钟)KeepAlives适合JSON / Ajax WebService吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。