HttpWebRequest中的KeepAlive

一直不是非常理解.NET中HttpWebRequest的KeepAlive属性有何用处，看了这篇文章就清楚了！

http://www.cnblogs.com/lwzz/archive/2011/08/15/2139937.html

摘录如下：

有人也许会问，Http不是基于TCP/IP的吗？而这个是可以保持状态的。怎么Http就是无状态了的呢？搞清楚这个问题，对以后我们WCF中选择协议也有帮助。

Http是属于最高层的应用协议，基于TCP/IP，也就是说它在TCP/IP的基础上引入了新的概念和规定。因此，无状态是Http规定的，是为了适应Web的要求而规定的。Web应用经常面对大量的访问，如果都保持TCP的连接状态那么将会消耗大量的资源。就会演变成了类似“客户端/服务端”一对一模型。因此，Http规定了它是无状态的，也就是说，处理完一个请求并返回以后，服务器端就要直接关闭掉TCP连接，不管相同的客户端是否再次发送请求。以这样的形式来实现单向的Request/response模式的。

上面我说的是Http 1.0 的规定。用图来表示就是:

注意，服务端关闭连接这个动作不可少。这样才是无状态。也就是说HTTP 1.0的协议的无状态是由这4个步骤组成，缺一不可。一个连接请求就在一次处理后关闭。

看到这里如果对浏览器有些了解的人就会知道，其实这个模型并不高效。在当初网页主要是HTML文本的时候还可以，但是现在一个的网页里都包含了非常多的诸如img,javascript,css等元素，这使得浏览器在解析由服务器发回的HTML网页以后，如果解析HTML时发现了上面这些元素的标签，那么还要多次的发起连接请求。而每次建立连接请求都需要三次握手，比较耗资源。因此，HTTP 1.0对于现在的网页来说并不很适合。
浏览器生成一个完整的页面，一共发送了N+1条请求。1就是指返回的HTML网页字符串，N是其中包含的资源，由浏览器解析HTML标签后发出。

如图:

这个问题应该怎么解决呢？要是能够在一条已建立的连接上，多处理几次资源请求就好了。也就是连接能够复用，更直接了当的说就是当服务器处理完一条资源请求时，不要像1.0那样马上关闭连接，而是等一段时间。

持久连接

在1.0+(1.0的各种修正版本)以及1.1中，允许HTTP设备在事务处理结束以后仍然将TCP保持在打开的状态，以便为未来的HTTP请求重用现存的连接。在事务处理结束以后仍然保持打开的连接我们就叫做“持久连接”，持久连接在1.0+和1.1中是通过不同方式确定的：

• HTTP 1.0中通过首部插入keep-alive信息表明是持久连接
• HTTP 1.1中默认是持久连接

下面来介绍一下这两种方式

1.keep-alive

客户端 ：实现HTTP/1.0 keep-alive连接的客户端可以通过包含connection:Keep-Alive首部请求将一条连接保持在打开状态。

服务器端：如果服务器端愿意将一条连接保持在打开状态，那么就在响应头部中同样插入connection:Keep-Alive ，否则表达的意思就是我响应你这条信息后我就要把TCP连接给关闭掉。

HTTP 1.0 中keep-alive不是默认采用的，也就是说如果你不主动的往头部加入这个信息，那么就意味着是一次HTTP请求就会打开关闭一次TCP连接。客户端通过检查服务器端的响应有没有connection:Keep-Alive，就可以知道服务器发出响应以后是否会关闭连接了。

2.和keep-alive正好相反，在HTTP1.1中持久连接默认是激活的，除非你发送了Connection:close表明可以关闭连接。HTTP1.1客户端假定在收到响应之后，除非响应中包含了Conncetion:close,否则HTTP/1.1的连接就仍然维持在打开的状态。
因此，这时服务器对于关闭TCP连接就会采用两种方式，一种是当收到浏览器发送的关闭连接请求后关闭该TCP请求（意味着浏览器已经把该网页所需的请求资源已经拿完了，无需再从这条连接里获取其他资源），另一种就是当经过一段时间后，就算浏览器没有发送关闭连接的请求，服务端也会因为超时而自动关闭该条TCP连接。

因此我们知道为什么我们的HTTP请求中还包含了HTTP的版本信息，因为这会影响到双发对于关闭请求的理解。

当然HTTP 1.1除了这条改进之外，还增加了诸如PUT,DELETE等动作。在接下来讲REST的文章的时候会讲到。