1、什么是Keep-Alive模式？
我们知道HTTP协议采用“请求-应答”模式，
当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成 之后立即断开连接（HTTP协议为无连接的协议）；
当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服 务器端的连接持续有效，
当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。
http 1.0中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；
http 1.1中默认启用Keep-Alive，如果加入"Connection: close "，才关闭。
目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep- Alive连接就看服务器设置情况。
2、启用Keep-Alive的优点
从上面的分析来看，启用Keep-Alive模式肯定更高效，性能更高。因为避免了建立/释放连接的开销；
注意：单用户客户端与任何服务器或代理之间的连接数不应该超过2个。
一个代理与其它服务器或代码之间应该使用不超过2 * N的活跃并发连接。
这是为了提高HTTP响应时间，避免拥塞（冗余的连接并不能代码执行性能的提升）。
3、回到我们的问题（即如何判断消息内容/长度的大小？）
Keep-Alive模式，客户端如何判断请求所得到的响应数据已经接收完成（或者说如何知道服务器已经发生完了数据）？
我们已经知道 了，Keep-Alive模式发送完数据HTTP服务器不会自动断开连接，所有不能再使用返回EOF（-1）来判断；
（当然你一定要这样使用也没有办法，可 以想象那效率是何等的低）！下面我介绍两种来判断方法。
3.1、使用消息首部字段Conent-Length
故名思意，Conent-Length表示实体内容长度，客户端（服务器）可以根据这个值来判断数据是否接收完成。
但是如果消息中没有Conent-Length，那该如何来判断呢？又在什么情况下会没有Conent-Length呢？请继续往下看……
3.2、使用消息首部字段Transfer-Encoding
当客户端向服务器请求一个静态页面或者一张图片时，服务器可以很清楚的知道内容大小，
然后通过Content-length消息首部字段告诉客户端 需要接收多少数据。
但是如果是动态页面等时，服务器是不可能预先知道内容大小，这时就可以使用Transfer-Encoding：chunk模式来传输 数据了。
即如果要一边产生数据，一边发给客户端，服务器就需要使用"Transfer-Encoding: chunked"这样的方式来代替Content-Length。
chunk编码将数据分成一块一块的发生。
Chunked编码将使用若干个Chunk串连而成，由一个标明长度为0 的chunk标示结束。
每个Chunk分为头部和正文两部分，头部内容指定正文的字符总数（十六进制的数字 ）和数量单位（一般不写），
正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF) 隔开。
在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。
Chunk编码的格式如下：
复制代码代码如下:
Chunked-Body = *&strong&chunk &/strong&"0" CRLFfooterCRLFchunk = chunk-size [ chunk-ext ] CRLFchunk-data CRLF&/p&&p&hex-no-zero = &HEX excluding "0"&&/p&&p&chunk-size = hex-no-zero *HEXchunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )chunk-ext-name = tokenchunk-ext-val = token | quoted-stringchunk-data = chunk-size(OCTET)&/p&&p&footer = *entity-header
即Chunk编码由四部分组成： 1、&strong&0至多个chunk块&/strong& ，2、&strong&"0" CRLF &/strong&，3、&strong&footer &/strong&，4、&strong&CRLF&/strong& &strong&.&/strong& 而每个chunk块由：chunk-size、chunk-ext（可选）、CRLF、chunk-data、CRLF组成。4、消息长度的总结
其实，上面2中方法都可以归纳为是如何判断http消息的大小、消息的数量。
RFC 2616 对 消息的长度总结如下：一个消息的transfer-length（传输长度）是指消息中的message-body（消息体）的长度。
当应用了 transfer-coding（传输编码），每个消息中的message-body（消息体）的长度（transfer-length）由以下几种情况 决定（优先级由高到低）：
任何不含有消息体的消息（如1XXX、204、304等响应消息和任何头(HEAD，首部)请求的响应消息），总是由一个空行（CLRF）结束。如果出现了Transfer-Encoding头字段 并且值为非“identity”，那么transfer-length由“chunked” 传输编码定义，除非消息由于关闭连接而终止。如果出现了Content-Length头字段，它的值表示entity-length（实体长度）和transfer-length（传输长 度）。如果这两个长度的大小不一样（i.e.设置了Transfer-Encoding头字段），那么将不能发送Content-Length头字段。并 且如果同时收到了Transfer-Encoding字段和Content-Length头字段，那么必须忽略Content-Length字段。如果消息使用媒体类型“multipart/byteranges”，并且transfer-length 没有另外指定，那么这种自定界（self-delimiting）媒体类型定义transfer-length 。除非发送者知道接收者能够解析该类型，否则不能使用该类型。由服务器关闭连接确定消息长度。（注意：关闭连接不能用于确定请求消息的结束，因为服务器不能再发响应消息给客户端了。）为了兼容HTTP/1.0应用程序，HTTP/1.1的请求消息体中必须包含一个合法的Content-Length头字段，除非知道服务器兼容 HTTP/1.1。一个请求包含消息体，并且Content-Length字段没有给定，如果不能判断消息的长度，服务器应该用用400 (bad request) 来响应；或者服务器坚持希望收到一个合法的Content-Length字段，用 411 (length required)来响应。
所有HTTP/1.1的接收者应用程序必须接受“chunked” transfer-coding (传输编码)，因此当不能事先知道消息的长度，允许使用这种机制来传输消息。消息不应该够同时包含 Content-Length头字段和non-identity transfer-coding。如果一个消息同时包含non-identity transfer-coding和Content-Length ，必须忽略Content-Length 。
阅读(...) 评论()怎样设置keep-alive_百度知道
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。
怎样设置keep-alive
请问在tomcat和weblogic中都是如何设置http的keep-alive为off的？
我已经知道了
我有更好的答案
可以在服务器配置文件中配置，浏览器现在大部分是http1.1的，所以默认是keep-Alive = on
为您推荐：
其他类似问题
alive的相关知识
等待您来回答HTTP Keep-Alive是什么？如何工作？ -- 简明现代魔法HTTP Keep Alive分析与优化总结
一、什么是HTTP Keep Alive
HTTP Keep-Alive 很大程序上被误解了，下面介绍一下它在HTTP/1.0和HTTP/1.1版本下是如何工作的，以及其在JAVA中的运行原理及优化建议。
HTTP是一个请求&-&响应模式的典型范例，即客户端向服务器发送一个请求信息，服务器来响应这个信息。在老的HTTP版本中，每个请求都将被创建一个新的客户端-&服务器的连接，在这个连接上发送请求，然后接收请求。这样的模式有一个很大的优点就是，它很简单，很容易理解和实现；它也有一个很大的缺点就是，它效率很低，因此Keep-Alive被提出用来解决效率低的问题。
具体说，HTTP构建在TCP之上。在HTTP早期实现中，每个HTTP请求都要打开一个socket连接。这种做效率很低，因为一个Web 页面中的很多HTTP请求都指向同一个服务器。例如，很多为Web页面中的图片发起的请求都指向一个通用的图片服务器。持久连接的引入解决了多对已请求服务器导致的socket连接低效性的问题。它使可以再一个单独的连接上进行多个请求。浏览器和服务器使用Connection头ilai指出对Keep-Alive的支持。
在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接
在HTTP/1.1版本中，官方规定的Keep-Alive使用标准和在HTTP/1.0版本中有些不同，默认情况下所在HTTP1.1中所有连接都被保持，除非在请求头或响应头中指明要关闭：Connection: Close &，这也就是为什么Connection: Keep-Alive字段再没有意义的原因。另外，还添加了一个新的字段Keep-Alive:，因为这个字段并没有详细描述用来做什么，可忽略它
二、HTTP Keep Alive的注意点
Not reliable（不可靠）
HTTP是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果
Keep-Alive和POST
在HTTP1.1细则中规定了在一个POST消息体后面不能有任何字符，还指出了对于某一个特定的浏览器可能并不遵循这个标准（比如在POST消息体的后面放置一个CRLF符）。而据我所知，大部分浏览器在POST消息体后都会自动跟一个CRLF符再发送，如何解决这个问题呢？根据上面的说明在POST请求头中禁止使用Keep-Alive，或者由服务器自动忽略这个CRLF，大部分服务器都会自动忽略，但是在未经测试之前是不可能知道一个服务器是否会这样做。&
三、闲聊实现
Java实现--客户端
在客户端，Java抽象了Keep-Alive，和程序员分享离开来，HttpURLConnection类自动实现了Keep-Alive，如果程序员没有介入去操作Keep-Alive，Keep-Alive会通过客户端内部的一个HttpURLConnection类的实例对象来自动实现。也就是说，在java中keep-alive是由一个Java类库来实现的，但在其他类库中不一定可用。
Java实现--服务器端
在服务器端，Java依然是将Keep-Alive抽象出来，HttpServlet、HttpServletRequest、和HttpServletResponse类自动实现 了Keep-Alive。这种情况下一些由第三方控制的操作是可能的，如在KeepAliveServlet中提到的JavaWebServer，Keep-Alive是否启用由两个因素决定，内容长度和输出大小，如果内容长度是响应的一部分（即这段内容长度输出后还有内容需要输出），则Keep-Alive被启用（当然需要客户端支持的情况下）；如果内容长度未设定，则Servlet会试着计算响应缓冲区长度以确定内容长度，在Javasoft实现中，使用一个4KB的缓冲区（相当于上面说的响应）。也就是说如果内容长度未设定，并且返回数据超过4KB，此时相当于内容长度大于响应长度，而不是响应长度一部分，Keep-Alive就不会被启用 。&
四、HTTP Keep Alive 优化例子与总结
4.1 例子分析
问题现象： 一个JSP页面，居然要耗时40多秒。网页中有大量的图片的
问题解决： 原因也找了半天，原来Apache配置里面，把Keep-Alive的开关关闭了。这个是个大问题，工程师为什么要关闭它，原来他考虑的太简单了，我们知道Apache适合处于短连接的请求，处理时间越短，并发数才能上去，原来他是这么考虑，但是没有办法，只能这样了，还是打开Keep-Alive开关吧。
当然，不是所有的情况都设置KeepAlive为On，下面的文字总结比较好：
【在使用apache的过程中，KeepAlive属性我一直保持为默认值On，其实，该属性设置为On还是Off还是要具体问题具体分析的，在生产环境中的影响还是蛮大的。
KeepAlive选项到底有什么用处？如果你用过Mysql ，应该知道Mysql的连接属性中有一个与KeepAlive 类似的Persistent Connection，即：长连接(PConnect)。该属性打开的话，可以使一次TCP连接为同一用户的多次请求服务，提高了响应速度。
比如很多网页中图片、CSS、JS、Html都在一台Server上，当用户访问其中的Html网页时，网页中的图片、Css、Js都构成了访问请求，打开KeepAlive 属性可以有效地降低TCP握手的次数(当然浏览器对同一域下同时请求的图片数有限制，一般是2 见下文章节 减少域名解释的开销)，减少httpd进程数，从而降低内存的使用(假定prefork模式)。MaxKeepAliveRequests 和KeepAliveTimeOut 两个属性在KeepAlive =On时起作用，可以控制持久连接的生存时间和最大服务请求数。
不过，上面说的只是一种情形，那就是静态网页居多的情况下，并且网页中的其他请求与网页在同一台Server上。当你的应用动态程序(比如：php )居多，用户访问时由动态程序即时生成html内容，html内容中图片素材和Css、Js等比较少或者散列在其他Server上时，KeepAlive =On反而会降低Apache 的性能。为什么呢？
前面提到过，KeepAlive =On时，每次用户访问，打开一个TCP连接，Apache 都会保持该连接一段时间，以便该连接能连续为同一client服务，在KeepAliveTimeOut还没到期并且MaxKeepAliveRequests还没到阈值之前，Apache 必然要有一个httpd进程来维持该连接，httpd进程不是廉价的，他要消耗内存和CPU时间片的。假如当前Apache 每秒响应100个用户访问，KeepAliveTimeOut=5，此时httpd进程数就是100*5=500个(prefork 模式)，一个httpd进程消耗5M内存的话，就是500*5M=G，夸张吧？当然，Apache 与Client只进行了100次TCP连接。如果你的内存够大，负载不会太高，如果你的内存小于2.5G，就会用到Swap，频繁的Swap切换会加重CPU的Load。
现在我们关掉KeepAlive ，Apache 仍然每秒响应100个用户访问，因为我们将图片、js、css等分离出去了，每次访问只有1个request，此时httpd的进程数是100*1=100个，使用内存100*5M=500M，此时Apache 与Client也是进行了100次TCP连接。性能却提升了太多。
1、当你的Server内存充足时，KeepAlive =On还是Off对系统性能影响不大。
2、当你的Server上静态网页(Html、图片、Css、Js)居多时，建议打开KeepAlive 。
3、当你的Server多为动态请求(因为连接，对文件系统访问较多)，KeepAlive 关掉，会节省一定的内存，节省的内存正好可以作为文件系统的Cache(vmstat命令中cache一列)，降低I/O压力。
PS：当KeepAlive =On时，KeepAliveTimeOut的设置其实也是一个问题，设置的过短，会导致Apache 频繁建立连接，给Cpu造成压力，设置的过长，系统中就会堆积无用的Http连接，消耗掉大量内存，具体设置多少，可以进行不断的调节，因你的网站浏览和服务器配置 而异。
4.3 减少域名解释的开销
对于HTTP/1.0来说可以充分利用浏览器默认最大并发连接数比HTTP/1.1多的好 处，实现不增加新域名的开销而更高的并行下载，减少域名解释的开销（注：IE 6,7在HTTP/1.0中默认最大并发连接数为4，在HTTP/1.1中默认最大并发连接数为2，IE8都为6，Firefox2在HTTP/1.0中 默认最大并发连接数为2 在HTTP/1.1中默认最大并发连接数为8，firefox 3默认都是6），根据10年7月Google索引的42亿个网页的统计报告，每张网页里包含29.39个图片，7.09个外部脚本，3.22个外部CSS 样式表，如果设置了Keep-Alive并且合理控制Keep-Alive TimeOut这个参数可以大量的节约连接的开销，提高相应速度。如果设置不好，在大并发的情况小，因维持大量连接而使服务器资源耗尽，而对于目前国内大 部分的用户使用的还是IE6，7的情况HTTP keep-alive
要利用HTTP的keep-alive机制，需要服务器端和客户端同时支持，以下使用tomcat服务器(支持keep-alive)，使用wireshark抓包测试几种客户端是否支持keep-alive
使用chrome浏览器作为客户端
往浏览器地址栏敲入http://localhost:8080/user/object?name=ds&id=2&，并刷新一次
抓包结果如下：
可以看到，浏览器和服务器先进行了三次握手，然后传数据，完成之后没有断开连接。接着刷新了页面之后，浏览器和服务器没重现进行三次握手连接，而是利用原来的连接传输数据。从下面的数据解析可以看到，浏览器传给服务器带"Connection:keep-alive"
使用curl命令作为客户端
连续执行两次命令：curl "http://localhost:8080/user/object?name=ds&id=2&"
抓包结果如下：
可以看到，curl客户端访问了两次服务器，但每次都是三次握手之后立即四次挥手。
加上keep-alive请求头，连续执行两次：curl -H "Connection:keep-alive" "http://localhost:8080/user/object?name=ds&id=2&"
抓包结果一样：
加上浏览器一模一样的请求头，又执行两次：curl
"Host: localhost:8080" -H "Connection: keep-alive" -H "Upgrade-Insecure-Requests: 1" -H "User-Agent: Mozilla/5.0 (M Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" -H "Accept: text/html,application/xhtml+xml,application/q=0.9,image/webp,*/*;q=0.8" -H "Accept-Encoding: gzip, deflate, sdch, br" -H "Accept-Language: zh-CN,q=0.8,q=0.6" -H "AlexaToolbar-ALX_NS_PH: AlexaToolbar/alx-4.0" "http://localhost:8080/user/object?name=ds&id=2&"，结果还是一样
总结：客户端利用keep-alive机制，不仅是加请求头keep-alive的问题，最重要的是客户端要支持。从抓包结果可以看到，每次请求完，curl客户端都是主动发送FIN包关闭连接。客户端想要支持keep-alive，客户端需要在完成请求之后，保持住连接的socket以便接下来的复用，而不是主动断开。
使用Java客户端HTTP client
Java代码如下:
package edu.kxw
import java.io.IOException
import org.apache.http.HttpEntity
import org.apache.http.HttpResponse
import org.apache.http.client.methods.HttpGet
import org.apache.http.impl.client.CloseableHttpClient
import org.apache.http.impl.client.HttpClientBuilder
import org.apache.http.util.EntityUtils
import org.junit.Test
public class TestHttpKeepAliveClient {
public void testHeader() throws InterruptedException {
String url = "http://localhost:8080/user/object?name=ds&id=2&"
//创建HttpClientBuilder
HttpClientBuilder httpClientBuilder = HttpClientBuilder.create()
//HttpClient
CloseableHttpClient closeableHttpClient = httpClientBuilder.build()
HttpGet httpGet = new HttpGet(url)
httpGet.addHeader("Connection", "keep-alive")
//执行get请求
HttpResponse httpResponse = closeableHttpClient.execute(httpGet)
//获取响应消息实体
HttpEntity entity = httpResponse.getEntity()
//响应状态
System.out.println("status:" + httpResponse.getStatusLine())
//判断响应实体是否为空
if (entity != null) {
System.out.println("contentEncoding:" + entity.getContentEncoding())
String content = EntityUtils.toString(entity)
System.out.println("response content:" + content)
Thread.sleep(5000)
closeableHttpClient.execute(httpGet)
} catch (IOException e) {
e.printStackTrace()
} finally {
//关闭流并释放资源
closeableHttpClient.close()
} catch (IOException e) {
e.printStackTrace()
抓包结果如下：
程序发请求时带上请求头keep-alive（不加也行）， 并休眠5秒后重新发送请求，从抓包结果中看，复用了连接。
reference：
wireshark使用：
本文已收录于以下专栏：
相关文章推荐
Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。市场上 的大部分Web服务器，包括iPlanet、IIS和Ap...
前文：在PC上运行着许多应用，有时一打开wireshark进行抓包，什么操作都没有进行，就发现wireshark已经抓取了许多内容，想要查看某个应用的网络数据，该怎么做？下面是操作步骤：
Wireshark抓包分析TCP的建立与断开过程
一、TCP建立连接
说明：在此图中HostA充当客户端角色，HostB充当服务器角色。
TCP是因特网中的传输层协议，使用三次握手协议建...
我们知道，TCP建立连接时会进行三次握手，而握手是以一方发送一个SYN为开始的。下载抓包工具Wireshark之后，进行抓包调试。在Java里实现了一段模拟请求的代码：
名词解释：
HTTP无状态：无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。从另一方面讲，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系
如果你要实现一...
1、什么是Keep-Alive模式？
我们知道HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（...
1、HTTP Keep-Alive
在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接。
使用keep-alive可以改善这种状态，即在一次T...
Chapter: 关于HTTP Keep-Alive
1. HTTP
Keep-Alive是什么？如何工作？
2. 了解HTTP
Keep-Alive的基本情况
3. Apach...
在CSDN上的这一段日子，接触到了很多同行业的人，尤其是使用FFMPEG进行视音频编解码的人，有的已经是有多年经验的“大神”，有的是刚开始学习的初学者。在和大家探讨的过程中，我忽然发现了一个问题：在“...
FFMPEG工程浩大，可以参考的书籍又不是很多，因此很多刚学习FFMPEG的人常常感觉到无从下手。我刚接触FFMPEG的时候也感觉不知从何学起。
因此我把自己做项目过程中实现的一个非常简单的视频播放器...
他的最新文章
讲师：汪剑
讲师：刘道宽
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)