浏览 21798 次
|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-13
引用 keep alive通俗地讲，就是所谓的常连接。常连接节省了TCP连接过程的开销，有一定的优势。现有操作系统越来越先进，建立连接的开销越来越小，比如 linux 2.6的epoll，freebsd的kqueue，可以让程序不fork进程或开线程就能同时服务N多连接。与此同时，客户端比如IE，Firefox 却可以同时开多个线程取内容，如果开了Keep alive，反而不好。因此一般情况下不需Keep Alive
有谁能详细的说一说在这种情况下keep-alive怎么不好了？ 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2008-11-14
这段话听不懂，我只知道tcp有个选项叫keep alive,就是心跳包。
|
| 返回顶楼 | |
|
发表时间：2008-11-14
tcp 的 keep-alive 包, 发包间隔可长了. 一般没必要设置. 一般的http请求哪有等这么长时间的
|
| 返回顶楼 | |
|
发表时间：2009-10-15
最后修改：2009-10-15
Keep-Alive 持续性连接，在HTTP 中，持续性连接的工作方式是服务器通过响应的Content-Length 首部告诉客户端响应体有多大。客户端能够在下载的过程中准确的显示进度条。
所以Keep-Alive 还是很有必要的。 |
| 返回顶楼 | |
|
发表时间：2009-10-16
觉得keepalive就是为长连接准备的，如果长连接设计是合理的，那么这个机制是有必要的，无论是传输层TCP的分节，还是应用层实现的消息。但是的确，TCP（SO_KEEPALIVE选项）提供的心跳跳的是慢点，大概2小时后才连续发几个探测分节。个人接触较多的还属于应用层keepalive一类。
|
| 返回顶楼 | |
|
发表时间：2009-11-11
keep-alive的主要目的是为了给服务器提供一个实时向客户端推送信息的手段（比如Gmail的新邮件到达），而不需要不停的通过客户端刷新实现，从这个角度而言，keep-alive对很多应用是必要的，尤其是交互类的。
|
| 返回顶楼 | |
|
发表时间：2009-11-13
http的keep-alive是看情况的
如果一个访问会对同一个服务器请求多次那是有用的。不然就是没用的。 比如在完全分离动态页面和静态文件的时候，跑动态页面的服务器就可以关闭keep-alive，以节省连接数。 |
| 返回顶楼 | |
