HttpClient连接池

HttpClient连接池，发现对于高并发的请求，效率提升很大。虽然知道是因为建立了长连接，导致请求效率提升，但是对于内部的原理还是不太清楚。后来在网上看到了HTTP协议的发展史，里面提到了一个属性Connection:keep-alive，引起了我极大的兴趣，觉得两者之间必然存在联系，果真当我查阅了一些资料之后，发现了HttpClient连接池连接保持、超时和失效的机制。

为什么要用Http连接池

1、降低延迟：如果不采用连接池，每次连接发起Http请求的时候都会重新建立TCP连接(经历3次握手)，用完就会关闭连接(4次挥手)，如果采用连接池则减少了这部分时间损耗，别小看这几次握手，本人经过测试发现，基本上3倍的时间延迟

2、支持更大的并发：如果不采用连接池，每次连接都会打开一个端口，在大并发的情况下系统的端口资源很快就会被用完，导致无法建立新的连接

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（HTTP协议）

顾名思义，Conent-Length表示实体内容长度，客户端（服务器）可以根据这个值来判断数据是否接收完成。当请求的资源是静态的页面或图片，服务器很容易知道内容的大小，但如果遇到动态的内容，或者文件太大想多次发送怎么办？

使用Transfer-Encoding（HTTP协议）

当需要一边产生数据，一边发给客户端，服务器就需要使用 Transfer-Encoding: chunked 这样的方式来代替 Content-Length，Chunk编码将数据分成一块一块的发送。它由若干个Chunk串连而成，以一个标明长度为0 的chunk标示结束。每个Chunk分为头部和正文两部分，头部内容指定正文的字符总数（十六进制的数字）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF) 隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的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两个方法