HttpClient
个人分类： httpcomponent/httpclient
连接池技术作为创建和管理连接的缓冲池技术，目前已广泛用于诸如数据库连接等长连接的维护和管理中，能够有效减少系统的响应时间，节省服务器资源开销。其优势主要有两个：其一是减少创建连接的资源开销，其二是资源的访问控制。连接池管理的对象是长连接，对于HTTP连接是否适用，我们需要首先回顾一下长连接和短连接。
所谓长连接是指客户端与服务器端一旦建立连接以后，可以进行多次数据传输而不需重新建立连接，而短连接则每次数据传输都需要客户端和服务器端建立一次连接。长连接的优势在于省去了每次数据传输连接建立的时间开销，能够大幅度提高数据传输的速度，对于P2P应用十分适合，但是对于诸如Web网站之类的B2C应用，并发请求量大，每一个用户又不需频繁的操作的场景下，维护大量的长连接对服务器无疑是一个巨大的考验。而此时，短连接可能更加适用。但是短连接每次数据传输都需要建立连接，我们知道HTTP协议的传输层协议是TCP协议，TCP连接的建立和释放分别需要进行3次握手和4次握手，频繁的建立连接即增加了时间开销，同时频繁的创建和销毁Socket同样是对服务器端资源的浪费。所以对于需要频繁发送HTTP请求的应用，需要在客户端使用HTTP长连接。
HTTP连接是无状态的，这样很容易给我们造成HTTP连接是短连接的错觉，实际上HTTP1.1默认即是持久连接，HTTP1.0也可以通过在请求头中设置Connection:keep-alive使得连接为长连接。既然HTTP协议支持长连接，我们就有理由相信HTTP连接同样需要连接池技术来管理和维护连接建立和销毁。HTTP Client4.0的ThreadSafeClientConnManager实现了HTTP连接的池化管理，其管理连接的基本单位是Route（路由），每个路由上都会维护一定数量的HTTP连接。这里的Route的概念可以理解为客户端机器到目标机器的一条线路，例如使用HttpClient的实现来分别请求 www.163.com 的资源和 www.sina.com 的资源就会产生两个route。缺省条件下对于每个Route，HttpClient仅维护2个连接，总数不超过20个连接，显然对于大多数应用来讲，都是不够用的，可以通过设置HTTP参数进行调整。 <!-- more --> 可以配置的HTTP参数有：
1） http.conn-manager.timeout 当某一线程向连接池请求分配线程时，如果连接池已经没有可以分配的连接时，该线程将会被阻塞，直至http.conn-manager.timeout超时，抛出ConnectionPoolTimeoutException。
2） http.conn-manager.max-per-route 每个路由的最大连接数；
3） http.conn-manager.max-total 总的连接数；
连接的有效性检测是所有连接池都面临的一个通用问题，大部分HTTP服务器为了控制资源开销，并不会
永久的维护一个长连接，而是一段时间就会关闭该连接。放回连接池的连接，如果在服务器端已经关闭，客
户端是无法检测到这个状态变化而及时的关闭Socket的。这就造成了线程从连接池中获取的连接不一定是有效的。这个问题的一个解决方法就是在每次请求之前检查该连接是否已经存在了过长时间，可能已过期。但是这个方法会使得每次请求都增加额外的开销。HTTP Client4.0的ThreadSafeClientConnManager 提供了
closeExpiredConnections()方法和closeIdleConnections()方法来解决该问题。前一个方法是清除连接池中所有过期的连接，至于连接什么时候过期可以设置，设置方法将在下面提到，而后一个方法则是关闭一定时间空闲的连接，可以使用一个单独的线程完成这个工作。
HTTP是一种无连接的事务协议，底层使用的还是TCP，连接池复用的就是TCP连接，目的就是在一个TCP连接上进行多次的HTTP请求从而提高性能。每次HTTP请求结束的时候，HttpClient会判断连接是否可以保持，如果可以则交给连接管理器进行管理以备下次重用，否则直接关闭连接。这里涉及到三个问题：
1、如何判断连接是否可以保持？
要想保持连接，首先客户端需要告诉服务器希望保持长连接，这就是所谓的Keep-Alive模式（又称持久连接，连接重用），HTTP1.0中默认是关闭的，需要在HTTP头加入”Connection: Keep-Alive”，才能启用Keep-Alive；HTTP1.1中默认启用Keep-Alive，加入”Connection: close “，才关闭。
但客户端设置了Keep-Alive并不能保证连接就可以保持，这里情况比较复。要想在一个TCP上进行多次的HTTP会话，关键是如何判断一次HTTP会话结束了？非Keep-Alive模式下可以使用EOF（-1）来判断，但Keep-Alive时服务器不会自动断开连接，有两种最常见的方式。
使用Conent-Length
顾名思义，Conent-Length表示实体内容长度，客户端（服务器）可以根据这个值来判断数据是否接收完成。当请求的资源是静态的页面或图片，服务器很容易知道内容的大小，但如果遇到动态的内容，或者文件太大想多次发送怎么办？
使用Transfer-Encoding
当需要一边产生数据，一边发给客户端，服务器就需要使用 Transfer-Encoding: chunked 这样的方式来代替 Content-Length，Chunk编码将数据分成一块一块的发送。它由若干个Chunk串连而成，以一个标明长度为0 的chunk标示结束。每个Chunk分为头部和正文两部分，头部内容指定正文的字符总数（十六进制的数字 ）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF) 隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的Header信息。
对于如何判断消息实体的长度，实际情况还要复杂的多，可以参考这篇文章：https://zhanjindong.com/2015/05/08/http-keep-alive-header
总结下HttpClient如何判断连接是否保持：
检查返回response报文头的Transfer-Encoding字段，若该字段值存在且不为chunked，则连接不保持，直接关闭。
检查返回的response报文头的Content-Length字段，若该字段值为空或者格式不正确（多个长度，值不是整数），则连接不保持，直接关闭。
检查返回的response报文头的Connection字段（若该字段不存在，则为Proxy-Connection字段）值：
如果这俩字段都不存在，则1.1版本默认为保持， 1.0版本默认为连接不保持，直接关闭。
如果字段存在，若字段值为close 则连接不保持，直接关闭；若字段值为keep-alive则连接标记为保持。
2、 保持多长时间？
保持时间计时开始时间为连接交换至连接池的时间。 保持时长计算规则为：获取response中 Keep-Alive字段中timeout值，若该存在，则保持时间为 timeout值*1000，单位毫秒。若不存在，则连接保持时间设置为-1，表示为无穷。
3、保持过程中如何保证连接没有失效？
很难保证。传统阻塞I/O模型，只有当I/O操做的时候，socket才能响应I/O事件。当TCP连接交给连接管理器后，它可能还处于“保持连接”的状态，但是无法监听socket状态和响应I/O事件。如果这时服务器将连接关闭的话，客户端是没法知道这个状态变化的，从而也无法采取适当的手段来关闭连接。
针对这种情况，HttpClient采取一个策略，通过一个后台的监控线程定时的去检查连接池中连接是否还“新鲜”，如果过期了，或者空闲了一定时间则就将其从连接池里删除掉。ClientConnectionManager提供了 closeExpiredConnections和closeIdleConnections两个方法。
