长链接、短链接与连接池

在了解连接池之前，我们需要对长、短链接建立初步认识。我们都知道，网络通信大部分都是基于 TCP/IP 协议，数据传输之前，双方通过“ 三次握手 ”建立连接，当数据传输完成之后，又通过“ 四次挥手 ”释放连接，以下是“三次握手”与“四次挥手”示意图：

三次握手建立连接示意图：

四次挥手释放连接示意图：

长、短连接是相对通信时间而言的。长连接相对短连接而言，多了一个 保持连接 的过程，可以在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。

短连接的操作步骤是：

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

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

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

长连接的操作步骤是：

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

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

TCP长连接保持的两种办法：

自定义心跳消息头.，一般客户端主动发送到服务端，服务器接收后进行回应(也可以不回应)，以便能够侦测连接是否异常断开。

通过设置TCP keepalive的属性，并设置发送底层心跳包的时间间隔。TCP keepalive是在底层定时发送心跳报文，服务器端接收到底层的心跳报文直接丢弃，不关心其内容。

HTTP协议是无状态的，在HTTP/1.0中默认使用短连接，客户端和服务器每进行一次HTTP操作，浏览器就会重新建立一个HTTP会话。

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

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

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

基于TCP/IP协议，我们可以知道，频繁的连接创建和销毁都需要消耗资源，而连接池是将已经创建好的连接保存在池中，当有请求来时，直接使用已经创建好的连接进行访问，这样省略了创建连接和销毁连接的过程。这样性能上得到了提高。

以数据库连接池为例，基本原理如下：

连接池技术带来的好处：

由于连接得到重用，避免了频繁创建、释放连接引起的大量性能开销。在减少系统消耗的基础上，另一方面也增进了系统运行环境的平稳性（减少内存碎片以及临时进程/线程的数量）。

连接池在初始化过程中，往往已经创建了若干连接置于池中备用。此时连接的初始化工作均已完成。对于业务请求处理而言，直接利用现有可用连接，避免了连接初始化和释放过程的时间开销，从而缩减了系统整体响应时间。

在较为完备的连接池实现中，可根据预先的连接占用超时设定，强制收回被占用连接。从而避免了常规连接操作中可能出现的资源泄漏。

以PHP开发为例，基于PHP-FPM机制实现的Web服务，并不容易实现连接池，而常驻内存的开发框架，例如workerman、swoole 则可以简单实现连接池功能。PHP-FPM机制下的连接池需要借助第三方Proxy实现，例如：

Http 长连接 和 短连接：

早期的 HTTP协议，如HTTP0.9之前也被称为是“无连接”的协议。不会与服务器保持长期的连接状态，所以也称为短连接，短连接每一次的请求都需要重新建立TCP连接，有10个请求就需要建立10次TCP连接，这个效率，可想而知是非常低的

到Http1.0就出现了长连接的通信方式，解决了短连接多次建立TCP连接的痛点，现在Http1.1基本都是默认开启Connection: keep-alive 长连接的， TCP连接只要建立一次，后续的请求都复用该通道，不用再重新建立TCP通道，效率大大提升

需要注意的是：不管是http短连接还是长连接，它们的请求和响应都有有序的，都是等上一次请求响应后，才接着下一个请求的，那能不能不等第一次请求回来，我就开始发第二次请求呢？这就引出http管道化了

http的管道化和非管道化：

在长连接的基础上，HTTP1.1进一步地支持在持久连接上使用管道化（pipelining）特性，这是相对于keep-alive连接的又一性能优化。在相应到达之前，可以将多条请求放入队列，当第一条请求发往服务器的时候，第二第三条请求也可以开始发送了，不用等到第一条请求响应回来，在高延时网络条件下，这样做可以降低网络的环回时间，提高性能。

非管道化与管道化的区别示意：

http队首阻塞：

简单理解就是需要排队，队首的事情没有处理完的时候，后面的人都要等着。

队头阻塞”与短连接和长连接无关，而是由 HTTP 基本的“请求 - 应答”机制所导致的。因为 HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。

而http的队首阻塞，在管道化和非管道化下，表现是不同的

http1.0的队首阻塞 ( 非管道化下 ) ：

可见，http1.0的队首组塞发生在客户端。

http1.1的队首阻塞 ( 管道化下 )

下图演示的是，第一个响应延迟后，后续响应跟着延迟

可见，应用管道化技术后，http1.1的队首阻塞发生在服务器端。

HTTP队头阻塞 的解决方法

并发TCP连接：

我们知道对于一个域名而言，是允许分配多个长连接的，那么可以理解成增加了任务队列，也就是说不会导致一个任务阻塞了该任务队列的其他任务，在RFC规范中规定客户端最多并发2个连接，不过实际情况就是要比这个还要多，Chrome中是6个，说明浏览器一个域名采用6个TCP连接，并发HTTP请求

域名分片

顾名思义，我们可以在一个域名下分出多个二级域名出来，而它们最终指向的还是同一个服务器，这样子的话就可以并发处理的任务队列更多，也更好的解决了队头阻塞的问题。

举个例子，比如baidu.com，可以分出很多二级域名，比如zhidao.baidu.com，xxx.baidu.com 这样子就可以有效解决队头阻塞问题。

利用HTTP2的多路复用解决：

对于HTTP1.1中管道化导致的请求/响应级别的队头阻塞，可以使用HTTP2的多路复用解决。

http2中将多个请求复用同一个tcp通道中，通过二进制分帧并且给每个帧打上流的 ID 去避免依次响应的问题，对方接收到帧之后根据 ID 拼接出流，这样就可以做到乱序响应从而避免请求时的队首阻塞问题，

当然，即使使用HTTP2，如果HTTP2底层使用的是TCP协议，仍可能出现TCP队头阻塞。

下图为http2多路复用，解决服务器响应时http队首阻塞演示

总结：

HTTP队头阻塞

对于每一个HTTP请求，会被放入一个任务队列中串行执行，一旦队首任务请求太慢时，就会阻塞后面的请求处理

有非管道化和管道化，两种阻塞方式：

非管道化：完全串行执行，请求->响应->请求->响应…，后一个请求必须在前一个响应之后发送，发生在客户端，http请求阻塞

管道化：请求可以并行发出，但是响应必须串行返回。后一个响应必须在前一个响应之后。原因是，没有序号标明顺序，只能串行接收，发生在服务端，http响应阻塞

管道化请求的致命弱点:

会造成队头阻塞，前一个响应未及时返回，后面的响应被阻塞

请求必须是幂等请求，也就是只有GET和HEAD请求才能管道化，不能修改资源。因为，意外中断时候，客户端需要把未收到响应的请求重发，非幂等请求，会造成资源破坏。

由于这个原因，目前大部分浏览器和Web服务器，都关闭了管道化，采用非管道化模式。

无论是非管道化还是管道化，都会造成队头阻塞(请求，响应阻塞)。

解决http队头阻塞的方法：

额外的：

http2中的多路复用和http1.1中的keep-alive有什么区别？

共同点： 都可以复用同一条TCP通道

区别：

https多路复用：并发请求，非阻塞的

详细描述：

keep-alive虽然可以复用同一条TCP通道，但必须等到服务端响应了前一次请求，才能发起第二次请求 ->阻塞。 按顺序发送请求，按顺序接收请求，这样接收端才不会乱掉。从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接，Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间

http2 的多路复用可以在一条TCP通道同时发送多个请求，不一定要按照顺序，非阻塞的，先响应先回来，响应式时也不用等上一个请求先响应，这些请求都有唯一标识，所以可以无序。

所谓短连接指建立SOCKET连接后发送后接收完数据后马上断开连接，一般银行都使用短连接解释2长连接就是指在基于tcp的通讯中，一直保持连接，不管当前是否发送或者接收数据。而短连接就是只有在有数据传输的时候才进行连接，客户－服务器通信/传输数据完毕就关闭连接。解释3长连接和短连接这个概念好像只有移动的CMPP协议中提到了，其他的地方没有看到过。通信方式各网元之间共有两种连接方式：长连接和短连接。所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接。短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接，即每次TCP连接只完成一对CMPP消息的发送。现阶段，要求ISMG之间必须采用长连接的通信方式，建议SP与ISMG之间采用长连接的通信方式。解释4短连接：比如http的，只是连接、请求、关闭，过程时间较短,服务器若是一段时间内没有收到请求即可关闭连接。

---