高并发httpClient原理与优化使用详解

忘是亡心i 2022-03-20 05:14 998阅读 0赞

# [HTTP长连接、短连接究竟是什么？][HTTP] #

**1. HTTP协议与TCP/IP协议的关系**

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。

## 2. 如何理解HTTP协议是无状态的 ##

HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和上一次打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。

## 3. 什么是长连接、短连接？ ##

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

### 3.1. TCP连接 ###

当网络通信时采用TCP协议时，在真正的读写操作之前，客户端与服务器端之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时可以释放这个连接。连接的建立依靠“三次握手”，而释放则需要“四次握手”，所以每个连接的建立都是需要资源消耗和时间消耗的。

经典的三次握手建立连接示意图：  
![image.jpg][]

![593345-20170204231325729-1747734402.png][]

经典的四次握手关闭连接示意图：  
![image.jpg 1][]

![593345-20170204231344745-1817753534.jpg][]

### 3.2. TCP短连接 ###

模拟一下TCP短连接的情况：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。

短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。

### 3.3. TCP长连接 ###

我们再模拟一下长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

TCP的保活功能主要为服务器应用提供。如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态：

*  客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位。
 *  客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。
 *  客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
 *  客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。

## 4. 长连接和短连接的优点和缺点 ##

由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户端适合使用长连接。在长连接的应用场景下，client端一般不会主动关闭连接，当client与server之间的连接一直不关闭，随着客户端连接越来越多，server会保持过多连接。这时候server端需要采取一些策略，如关闭一些长时间没有请求发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件允许则可以限制每个客户端的最大长连接数，这样可以完全避免恶意的客户端拖垮整体后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费较多时间和带宽。

长连接和短连接的产生在于client和server采取的关闭策略。不同的应用场景适合采用不同的策略。

由上可以看出，**长连接**可以**省去较多的TCP建立和关闭的操作，减少浪费，节约时间**。对于频繁请求资源的客户来说，较适用长连接。不过这里**存在一个问题**，**存活功能的探测周期太长**，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，**Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候**，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

**短连接**对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户**请求频繁**，将在**TCP的建立和关闭操作上浪费时间和带宽**。

长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

## **长连接短连接操作过程** ##

短连接的操作步骤是：

建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接

长连接的操作步骤是：

建立连接——数据传输...（保持连接）...数据传输——关闭连接

## **什么时候用长连接，短连接？**  　　 ##

**长连接**多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。   
    
　　而像WEB网站的http服务一般都用**短链接**，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

# http和socket之长连接和短连接区别 #

==============================================================================

TCP/IP

TCP/IP是个协议组，可分为三个层次：网络层、传输层和应用层。

在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。

在传输层中有TCP协议与UDP协议。

在应用层有:TCP包括FTP、HTTP、TELNET、SMTP等协议

UDP包括DNS、TFTP等协议

短连接

连接->传输数据->关闭连接

HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。

也可以这样说：短连接是指SOCKET连接后发送后接收完数据后马上断开连接。

长连接

连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。

长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。

http的长连接

HTTP也可以建立长连接的，使用Connection:keep-alive，HTTP 1.1默认进行持久连接。HTTP1.1和HTTP1.0相比较而言，最大的区别就是增加了持久连接支持(貌似最新的 http1.0 可以显示的指定 keep-alive),但还是无状态的，或者说是不可以信任的。

什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

总之，长连接和短连接的选择要视情况而定。

发送接收方式

1、异步

报文发送和接收是分开的，相互独立的，互不影响。这种方式又分两种情况：

(1)异步双工：接收和发送在同一个程序中，由两个不同的子进程分别负责发送和接收

(2)异步单工：接收和发送是用两个不同的程序来完成。

2、同步

报文发送和接收是同步进行，既报文发送后等待接收返回报文。 同步方式一般需要考虑超时问题，即报文发出去后不能无限等待，需要设定超时时间，超过该时间发送方不再等待读返回报文，直接通知超时返回。

在长连接中一般是没有条件能够判断读写什么时候结束，所以必须要加长度报文头。读函数先是读取报文头的长度，再根据这个长度去读相应长度的报文。

Socket是什么

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

![Image 1][]

通信过程：

![Image 1][]

主机 A 的应用程序要能和主机 B 的应用程序通信，必须通过 Socket 建立连接，而建立 Socket 连接必须需要底层 TCP/IP 协议来建立 TCP 连接。建立 TCP 连接需要底层 IP 协议来寻址网络中的主机。我们知道网络层使用的 IP 协议可以帮助我们根据 IP 地址来找到目标主机，但是一台主机上可能运行着多个应用程序，如何才能与指定的应用程序通信就要通过 TCP 或 UPD 的地址也就是端口号来指定。这样就可以通过一个 Socket 实例唯一代表一个主机上的一个应用程序的通信链路了。

建立通信链路

当客户端要与服务端通信，客户端首先要创建一个 Socket 实例，操作系统将为这个 Socket 实例分配一个没有被使用的本地端口号，并创建一个包含本地和远程地址和端口号的套接字数据结构，这个数据结构将一直保存在系统中直到这个连接关闭。在创建 Socket 实例的构造函数正确返回之前，将要进行 TCP 的三次握手协议，TCP 握手协议完成后，Socket 实例对象将创建完成，否则将抛出 IOException 错误。

与之对应的服务端将创建一个 ServerSocket 实例，ServerSocket 创建比较简单只要指定的端口号没有被占用，一般实例创建都会成功，同时操作系统也会为 ServerSocket 实例创建一个底层数据结构，这个数据结构中包含指定监听的端口号和包含监听地址的通配符，通常情况下都是“\*”即监听所有地址。之后当调用 accept() 方法时，将进入阻塞状态，等待客户端的请求。当一个新的请求到来时，将为这个连接创建一个新的套接字数据结构，该套接字数据的信息包含的地址和端口信息正是请求源地址和端口。这个新创建的数据结构将会关联到 ServerSocket 实例的一个未完成的连接数据结构列表中，注意这时服务端与之对应的 Socket 实例并没有完成创建，而要等到与客户端的三次握手完成后，这个服务端的 Socket 实例才会返回，并将这个 Socket 实例对应的数据结构从未完成列表中移到已完成列表中。所以 ServerSocket 所关联的列表中每个数据结构，都代表与一个客户端的建立的 TCP 连接。

备注：

Windows 下单机最大TCP连接数

调整系统参数来调整单机的最大TCP连接数，Windows 下单机的TCP连接数有多个参数共同决定：

以下都是通过修改注册表\[HKEY\_LOCAL\_MACHINE \\System \\CurrentControlSet \\Services \\Tcpip \\Parameters\]

1.最大TCP连接数      TcpNumConnections

2.TCP关闭延迟时间    TCPTimedWaitDelay    (30-240)s

3.最大动态端口数  MaxUserPort  (Default = 5000, Max = 65534) TCP客户端和服务器连接时，客户端必须分配一个动态端口，默认情况下这个动态端口的分配范围为 1024-5000 ，也就是说默认情况下，客户端最多可以同时发起3977 Socket 连接

4.最大TCB 数量  MaxFreeTcbs

系统为每个TCP 连接分配一个TCP 控制块(TCP control block or TCB)，这个控制块用于缓存TCP连接的一些参数，每个TCB需要分配 0.5 KB的pagepool 和 0.5KB 的Non-pagepool，也就说，每个TCP连接会占用 1KB 的系统内存。

非Server版本，MaxFreeTcbs 的默认值为1000 （64M 以上物理内存）Server 版本，这个的默认值为 2000。也就是说，默认情况下，Server 版本最多同时可以建立并保持2000个TCP 连接。

5. 最大TCB Hash table 数量  MaxHashTableSize TCB 是通过Hash table 来管理的。

这个值指明分配 pagepool 内存的数量，也就是说，如果MaxFreeTcbs = 1000 , 则 pagepool 的内存数量为 500KB那么 MaxHashTableSize 应大于 500 才行。这个数量越大，则Hash table 的冗余度就越高，每次分配和查找 TCP  连接用时就越少。这个值必须是2的幂，且最大为65536.

IBM WebSphere Voice Server 在windows server 2003 下的典型配置

MaxUserPort = 65534 (Decimal)

MaxHashTableSize = 65536 (Decimal)

MaxFreeTcbs = 16000 (Decimal)

这里我们可以看到 MaxHashTableSize 被配置为比MaxFreeTcbs 大4倍，这样可以大大增加TCP建立的速度

链接：https://www.jianshu.com/p/b68d2b26f5f4

==============================================================================

# HTTP 的长连接和短连接 #

==========================================================================

### 一、什么是长连接 ###

HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

HTTP首部的Connection: Keep-alive是HTTP1.0浏览器和服务器的实验性扩展，当前的HTTP1.1 RFC2616文档没有对它做说明，因为它所需要的功能已经默认开启，无须带着它，但是实践中可以发现，浏览器的报文请求都会带上它。如果HTTP1.1版本的HTTP请求报文不希望使用长连接，则要在HTTP请求报文首部加上Connection: close。《HTTP权威指南》提到，有部分古老的HTTP1.0 代理不理解Keep-alive，而导致长连接失效：客户端–>代理–>服务端，客户端带有Keep-alive，而代理不认识，于是将报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端–>代理”连接和“代理–>服务端”连接不关闭，但是，当客户端第发送第二次请求时，代理会认为当前连接不会有请求了，于是忽略了它，长连接失效。书上也介绍了解决方案：当发现HTTP版本为1.0时，就忽略Keep-alive，客户端就知道当前不该使用长连接。其实，在实际使用中不需要考虑这么多，很多时候代理是我们自己控制的，如Nginx代理，代理服务器有长连接处理逻辑，服务端无需做patch处理，常见的是客户端跟Nginx代理服务器使用HTTP1.1协议&长连接，而Nginx代理服务器跟后端服务器使用HTTP1.0协议&短连接。

在实际使用中，HTTP头部有了Keep-Alive这个值并不代表一定会使用长连接，客户端和服务器端都可以无视这个值，也就是不按标准来，譬如我自己写的HTTP客户端多线程去下载文件，就可以不遵循这个标准，并发的或者连续的多次GET请求，都分开在多个TCP通道中，每一条TCP通道，只有一次GET，GET完之后，立即有TCP关闭的四次握手，这样写代码更简单，这时候虽然HTTP头有Connection: Keep-alive，但不能说是长连接。正常情况下客户端浏览器、web服务端都有实现这个标准，因为它们的文件又小又多，保持长连接减少重新开TCP连接的开销很有价值。

以前使用libcurl做的上传/下载，就是短连接，抓包可以看到：1、每一条TCP通道只有一个POST；2、在数据传输完毕可以看到四次握手包。只要不调用curl\_easy\_cleanup，curl的handle就可能一直有效，可复用。这里说可能，因为连接是双方的，如果服务器那边关掉了，那么我客户端这边保留着也不能实现长连接。

如果是使用windows的WinHTTP库，则在POST/GET数据的时候，虽然我关闭了句柄，但这时候TCP连接并不会立即关闭，而是等一小会儿，这时候是WinHTTP库底层支持了跟Keep-alive所需要的功能：即便没有Keep-alive，WinHTTP库也可能会加上这种TCP通道复用的功能，而其它的网络库像libcurl则不会这么做。以前观察过[WinHTTP库不会及时断开TCP连接][WinHTTP_TCP]。

### 二、长连接的过期时间 ###

客户端的长连接不可能无限期的拿着，会有一个超时时间，服务器有时候会告诉客户端超时时间，譬如：

![082313431229684.png][]

上图中的Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒。另外还可能有max=XXX，表示这个长连接最多接收XXX次请求就断开。对于客户端来说，如果服务器没有告诉客户端超时时间也没关系，服务端可能主动发起四次握手断开TCP连接，客户端能够知道该TCP连接已经无效；另外TCP还有心跳包来检测当前连接是否还活着，方法很多，避免浪费资源。

### 三、长连接的数据传输完成识别 ###

使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1是判断传输数据是否达到了Content-Length指示的大小；2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。更细节的介绍可以看[这篇文章][Link 1]。

### 四、并发连接数的数量限制 ###

在web开发中需要关注浏览器并发连接的数量，[RFC文档][RFC]说，客户端与服务器最多就连上两通道，但服务器、个人客户端要不要这么做就随人意了，有些服务器就限制同时只能有1个TCP连接，导致客户端的多线程下载（客户端跟服务器连上多条TCP通道同时拉取数据）发挥不了威力，有些服务器则没有限制。浏览器客户端就比较规矩，[知乎这里有分析][Link 2]，限制了同域名下能启动若干个并发的TCP连接去下载资源。并发数量的限制也跟长连接有关联，打开一个网页，很多个资源的下载可能就只被放到了少数的几条TCP连接里，这就是TCP通道复用（长连接）。如果并发连接数少，意味着网页上所有资源下载完需要更长的时间（用户感觉页面打开卡了）；并发数多了，服务器可能会产生更高的资源消耗峰值。浏览器只对同域名下的并发连接做了限制，也就意味着，web开发者可以把资源放到不同域名下，同时也把这些资源放到不同的机器上，这样就完美解决了。

### 五、容易混淆的概念——**TCP的keep alive和****HTTP的Keep-alive** ###

TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点。它们是不同层次的概念。

TCP keep alive的表现：

当一个连接“一段时间”没有数据通讯时，一方会发出一个心跳包（Keep Alive包），如果对方有回包则表明当前连接有效，继续监控。

这个“一段时间”可以设置。

WinHttp库的设置：

> WINHTTP\_OPTION\_WEB\_SOCKET\_KEEPALIVE\_INTERVAL  
> Sets the interval, in milliseconds, to send a keep-alive packet over the connection. The default interval is 30000 (30 seconds). The minimum interval is 15000 (15 seconds). Using WinHttpSetOption to set a value lower than 15000 will return with ERROR\_INVALID\_PARAMETER.

libcurl的设置：

http://curl.haxx.se/libcurl/c/curl\_easy\_setopt.html

> CURLOPT\_TCP\_KEEPALIVE
> 
> Pass a long. If set to 1, TCP keepalive probes will be sent. The delay and frequency of these probes can be controlled by the CURLOPT\_TCP\_KEEPIDLE and CURLOPT\_TCP\_KEEPINTVL options, provided the operating system supports them. Set to 0 (default behavior) to disable keepalive probes (Added in 7.25.0).
> 
> CURLOPT\_TCP\_KEEPIDLE
> 
> Pass a long. Sets the delay, in seconds, that the operating system will wait while the connection is idle before sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)
> 
> CURLOPT\_TCP\_KEEPINTVL
> 
> Pass a long. Sets the interval, in seconds, that the operating system will wait between sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)

CURLOPT\_TCP\_KEEPIDLE是空闲多久发送一个心跳包，CURLOPT\_TCP\_KEEPINTVL是心跳包间隔多久发一个。

打开网页抓包，发送心跳包和关闭连接如下：

![082323582627054.png][]

从上图可以看到，大概过了44秒，客户端发出了心跳包，服务器及时回应，本TCP连接继续保持。到了空闲60秒的时候，服务器主动发起FIN包，断开连接。

### 六、HTTP 流水线技术 ###

使用了HTTP长连接（HTTP persistent connection ）之后的好处，包括可以使用HTTP 流水线技术（HTTP pipelining，也有翻译为管道化连接），它是指，**在一个TCP连接内，多个HTTP请求可以并行，下一个HTTP请求在上一个HTTP请求的应答完成之前就发起。**从wiki上了解到这个技术目前并没有广泛使用，使用这个技术必须要求客户端和服务器端都能支持，目前有部分浏览器完全支持，而服务端的支持仅需要：按HTTP请求顺序正确返回Response（也就是请求&响应采用FIFO模式），wiki里也特地指出，只要服务器能够正确处理使用HTTP pipelinning的客户端请求，那么服务器就算是支持了HTTP pipelining。

由于要求服务端返回响应数据的顺序必须跟客户端请求时的顺序一致，这样也就是要求FIFO，这容易导致Head-of-line blocking：第一个请求的响应发送影响到了后边的请求，因为这个原因导致HTTP流水线技术对性能的提升并不明显（wiki提到，这个问题会在HTTP2.0中解决）。另外，使用这个技术的还必须是幂等的HTTP方法，因为客户端无法得知当前已经处理到什么地步，重试后可能发生不可预测的结果。POST方法不是幂等的：同样的报文，第一次POST跟第二次POST在服务端的表现可能会不一样。

在HTTP长连接的wiki中提到了HTTP1.1的流水线技术对RFC规定一个用户最多两个连接的指导意义：流水线技术实现好了，那么多连接并不能提升性能。我也觉得如此，并发已经在单个连接中实现了，多连接就没啥必要，除非瓶颈在于单个连接上的资源限制迫使不得不多开连接抢资源。

目前浏览器并不太重视这个技术，毕竟性能提升有限。

### 七、学习资料 ###

*  1、HTTP Keep-Alive模式：[http://www.cnblogs.com/skynet/archive/2010/12/11/1903347.html][Link 1]
 *  2、浏览器的并发请求限制：[http://www.zhihu.com/question/20474326][Link 2]
 *  3、RFC文档 connection部分：http://tools.ietf.org/html/rfc2616\#page-44
 *  4、C/C++网络编程中的TCP保活： [http://blog.csdn.net/weiwangchao\_/article/details/7225338][http_blog.csdn.net_weiwangchao_article_details_7225338]
 *  5、HTTP persistent connection： http://en.wikipedia.org/wiki/HTTP\_persistent\_connection
 *  6、HTTP pipelining：http://en.wikipedia.org/wiki/HTTP\_pipelining
 *  7、Head-of-line blocking：http://en.wikipedia.org/wiki/Head-of-line\_blocking
 *  8、《HTTP权威指南》第四章 连接管理

========================================================================

http://blog.jobbole.com/104108/

# HTTP持久连接 #

https://zh.wikipedia.org/wiki/HTTP%E6%8C%81%E4%B9%85%E8%BF%9E%E6%8E%A5

长连接

http://baike.baidu.com/view/2831907.htm

## 1.背景 ##

我们有个业务，会调用其他部门提供的一个基于http的服务，日调用量在千万级别。使用了httpclient来完成业务。之前因为qps上不去，就看了一下业务代码，并做了一些优化，记录在这里。

先对比前后：优化之前，平均执行时间是250ms；优化之后，平均执行时间是80ms，降低了三分之二的消耗，容器不再动不动就报警线程耗尽了，清爽~

## 2.分析 ##

项目的原实现比较粗略，就是每次请求时初始化一个httpclient，生成一个httpPost对象，执行，然后从返回结果取出entity，保存成一个字符串，最后显式关闭response和client。我们一点点分析和优化：

2.1 httpclient反复创建开销

httpclient是一个线程安全的类，没有必要由每个线程在每次使用时创建，全局保留一个即可。

2.2 反复创建tcp连接的开销

tcp的三次握手与四次挥手两大裹脚布过程，对于高频次的请求来说，消耗实在太大。试想如果每次请求我们需要花费5ms用于协商过程，那么对于qps为100的单系统，1秒钟我们就要花500ms用于握手和挥手。又不是高级领导，我们程序员就不要搞这么大做派了，改成keep alive方式以实现连接复用！

2.3 重复缓存entity的开销

原本的逻辑里，使用了如下代码：

HttpEntity entity = httpResponse.getEntity();
    String response = EntityUtils.toString(entity);

这里我们相当于额外复制了一份content到一个字符串里，而原本的httpResponse仍然保留了一份content，需要被consume掉，在高并发且content非常大的情况下，会消耗大量内存。

## 3.实现 ##

按上面的分析，我们主要要做三件事：一是单例的client，二是缓存的保活连接，三是更好的处理返回结果。一就不说了，来说说二。

提到连接缓存，很容易联想到数据库连接池。httpclient4提供了一个PoolingHttpClientConnectionManager 作为连接池。接下来我们通过以下步骤来优化：

3.1 定义一个keep alive strategy

关于keep-alive，本文不展开说明，只提一点，是否使用keep-alive要根据业务情况来定，它并不是灵丹妙药。还有一点，keep-alive和time\_wait/close\_wait之间也有不少故事。

在本业务场景里，我们相当于有少数固定客户端，长时间极高频次的访问服务器，启用keep-alive非常合适

再多提一嘴，http的keep-alive 和tcp的KEEPALIVE不是一个东西。回到正文，定义一个strategy如下：

ConnectionKeepAliveStrategy myStrategy = new ConnectionKeepAliveStrategy() {
        @Override
        public long getKeepAliveDuration(HttpResponse response, HttpContext context) {
            HeaderElementIterator it = new BasicHeaderElementIterator
                (response.headerIterator(HTTP.CONN_KEEP_ALIVE));
            while (it.hasNext()) {
                HeaderElement he = it.nextElement();
                String param = he.getName();
                String value = he.getValue();
                if (value != null && param.equalsIgnoreCase
                   ("timeout")) {
                    return Long.parseLong(value) * 1000;
                }
            }
            return 60 * 1000;//如果没有约定，则默认定义时长为60s
        }
    };

3.2 配置一个PoolingHttpClientConnectionManager

PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
    connectionManager.setMaxTotal(500);
    connectionManager.setDefaultMaxPerRoute(50);//例如默认每路由最高50并发，具体依据业务来定

也可以针对每个路由设置并发数。

3.3 生成httpclient

httpClient = HttpClients.custom()
                    .setConnectionManager(connectionManager)
                    .setKeepAliveStrategy(kaStrategy)
                    .setDefaultRequestConfig(RequestConfig.custom().setStaleConnectionCheckEnabled(true).build())
                    .build();

注意：使用setStaleConnectionCheckEnabled方法来逐出已被关闭的链接不被推荐。更好的方式是手动启用一个线程，定时运行closeExpiredConnections 和closeIdleConnections方法，如下所示。

public static class IdleConnectionMonitorThread extends Thread {
        
        private final HttpClientConnectionManager connMgr;
        private volatile boolean shutdown;
        
        public IdleConnectionMonitorThread(HttpClientConnectionManager connMgr) {
            super();
            this.connMgr = connMgr;
        }
    
        @Override
        public void run() {
            try {
                while (!shutdown) {
                    synchronized (this) {
                        wait(5000);
                        // Close expired connections
                        connMgr.closeExpiredConnections();
                        // Optionally, close connections
                        // that have been idle longer than 30 sec
                        connMgr.closeIdleConnections(30, TimeUnit.SECONDS);
                    }
                }
            } catch (InterruptedException ex) {
                // terminate
            }
        }
        
        public void shutdown() {
            shutdown = true;
            synchronized (this) {
                notifyAll();
            }
        }
        
    }

3.4 使用httpclient执行method时降低开销

这里要注意的是，不要关闭connection。

一种可行的获取内容的方式类似于，把entity里的东西复制一份：

res = EntityUtils.toString(response.getEntity(),"UTF-8");
    EntityUtils.consume(response1.getEntity());

但是，更推荐的方式是定义一个ResponseHandler，方便你我他，不再自己catch异常和关闭流。在此我们可以看一下相关的源码：

public <T> T execute(final HttpHost target, final HttpRequest request,
                final ResponseHandler<? extends T> responseHandler, final HttpContext context)
                throws IOException, ClientProtocolException {
            Args.notNull(responseHandler, "Response handler");
    
            final HttpResponse response = execute(target, request, context);
    
            final T result;
            try {
                result = responseHandler.handleResponse(response);
            } catch (final Exception t) {
                final HttpEntity entity = response.getEntity();
                try {
                    EntityUtils.consume(entity);
                } catch (final Exception t2) {
                    // Log this exception. The original exception is more
                    // important and will be thrown to the caller.
                    this.log.warn("Error consuming content after an exception.", t2);
                }
                if (t instanceof RuntimeException) {
                    throw (RuntimeException) t;
                }
                if (t instanceof IOException) {
                    throw (IOException) t;
                }
                throw new UndeclaredThrowableException(t);
            }
    
            // Handling the response was successful. Ensure that the content has
            // been fully consumed.
            final HttpEntity entity = response.getEntity();
            EntityUtils.consume(entity);//看这里看这里
            return result;
        }

可以看到，如果我们使用resultHandler执行execute方法，会最终自动调用consume方法，而这个consume方法如下所示：

public static void consume(final HttpEntity entity) throws IOException {
            if (entity == null) {
                return;
            }
            if (entity.isStreaming()) {
                final InputStream instream = entity.getContent();
                if (instream != null) {
                    instream.close();
                }
            }
        }

可以看到最终它关闭了输入流。

## 4.其他 ##

通过以上步骤，基本就完成了一个支持高并发的httpclient的写法，下面是一些额外的配置和提醒：

4.1 httpclient的一些超时配置

CONNECTION\_TIMEOUT是连接超时时间，SO\_TIMEOUT是socket超时时间，这两者是不同的。连接超时时间是发起请求前的等待时间；socket超时时间是等待数据的超时时间。

HttpParams params = new BasicHttpParams();
    //设置连接超时时间
    Integer CONNECTION_TIMEOUT = 2 * 1000; //设置请求超时2秒钟 根据业务调整
    Integer SO_TIMEOUT = 2 * 1000; //设置等待数据超时时间2秒钟 根据业务调整
    
    //定义了当从ClientConnectionManager中检索ManagedClientConnection实例时使用的毫秒级的超时时间
    //这个参数期望得到一个java.lang.Long类型的值。如果这个参数没有被设置，默认等于CONNECTION_TIMEOUT，因此一定要设置。
    Long CONN_MANAGER_TIMEOUT = 500L; //在httpclient4.2.3中我记得它被改成了一个对象导致直接用long会报错，后来又改回来了
     
    params.setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, CONNECTION_TIMEOUT);
    params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT, SO_TIMEOUT);
    params.setLongParameter(ClientPNames.CONN_MANAGER_TIMEOUT, CONN_MANAGER_TIMEOUT);
    //在提交请求之前 测试连接是否可用
    params.setBooleanParameter(CoreConnectionPNames.STALE_CONNECTION_CHECK, true);
     
    //另外设置http client的重试次数，默认是3次；当前是禁用掉（如果项目量不到，这个默认即可）
    httpClient.setHttpRequestRetryHandler(new DefaultHttpRequestRetryHandler(0, false));

4.2 如果配置了nginx的话，nginx也要设置面向两端的keep-alive

现在的业务里，没有nginx的情况反而比较稀少。nginx默认和client端打开长连接而和server端使用短链接。注意client端的keepalive\_timeout和keepalive\_requests参数，以及upstream端的keepalive参数设置，这三个参数的意义在此也不再赘述。

以上是全部设置。通过这些设置，成功地将原本每次请求250ms的耗时降低到了80左右，效果显著。

[HTTP]: https://www.cnblogs.com/gotodsp/p/6366163.html
[image.jpg]: /images/20220320/54ac7be8c8b84558a21a94eadf8b1637.png
[593345-20170204231325729-1747734402.png]: /images/20220320/10db6103ad55463790107ff6a083ade8.png
[image.jpg 1]: /images/20220320/d31e44a3ffaf4537a9d42da50349078d.png
[593345-20170204231344745-1817753534.jpg]: /images/20220320/9244ceb2b3634599967997e93ac200b7.png
[Image 1]: 
[WinHTTP_TCP]: http://www.cnblogs.com/cswuyg/p/3516417.html
[082313431229684.png]: /images/20220320/018f38c50d5a42e6a6d6adc99a683108.png
[Link 1]: http://www.cnblogs.com/skynet/archive/2010/12/11/1903347.html
[RFC]: http://tools.ietf.org/html/rfc2616#page-47
[Link 2]: http://www.zhihu.com/question/20474326
[082323582627054.png]: /images/20220320/92d425cb05444d90b7c5544480021637.png
[http_blog.csdn.net_weiwangchao_article_details_7225338]: http://blog.csdn.net/weiwangchao_/article/details/7225338