HTTP是长连接还是短连接

既有长连接也有短链接

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

1  对比

HTTP 09 已过时

HTTP10：非持续连接，每个连接只处理一个请求响应事务，有些服务器端甚至还在用此，可以在一定时间内复用连接，具体复用时间的长短可以由服务器控制，一般在15s左右。

HTTP 11 默认使用持续连接，不必为每一个WEB对象建立一个新的连接，一个连接可以传送多个对象，但是服务器端可能还是会设置一个限制，太长时间没有读写事件，服务器可能关闭之。

HTTP 20  多路复用（一个域只要一个TCP连接）实现真正的并发请求，降低延时，提高了带宽的利用率。

 在持久连接或者HTTP pipelining出现之前，每个连接的获取都需要创建一个独立的TCP连接。

2  非持久连接示意

每个WEB对象都要建立新的连接。

假设某简单页面包含1个HTML，2个PNG图像，且都存储在一台服务器主机中。

客户端输入URL访问首页，http://wwwabcdefgcom/path/indexhtml

第一步，客户端与服务器主机中的HTTP服务端口（默认为）建立TCP连接

第二步，客户端发送HTTP请求/path/indexhtml

第三步，服务器接收请求消息，从服务器主机内存或硬盘拿去拿对象/sompath/indexhtml，发出该对象的响应。

第四步，服务器告知TCP关闭这个TCP连接(TCP要等客户收到这个响应消息后，才会真正终止这个连接)。

第五步，HTTP客户接收响应消息。TCP连接终止。 该消息标明所拆装的对象是一个HTML文件。客户取出文件，分析后发现2个JPEG对象的引用。

第六步， 给每一个引用到的JPEG对象重复第一步到第四步

非持久连接，每个对象有2个RTT延迟

持久连接，带管道线，所有引用对象，共经历一个RTT延时；

持久连接，无管道线，每个引用对象一个RTT延时。

首先：HTTP的长连接和短连接本质上是TCP长连接和短连接。

1 在HTTP10中，默认的是短连接，没有正式规定 Connection:Keep-alive 操作；

    在 HTTP11 中所有连接都是Keep-alive的，也就是默认都是持续连接的（Persistent Connection）。

2 两种的连接方式的区别如下图所示

3 从上图可以看出，客户端与服务器建立持续连接后，在连接期间可以处理多个请求/响应（Request/Response）

HTTP权威指南：

HTTP/11 允许HTTP设备在事务处理结束以后将TCP连接保持在打开状态，后面的HTTP Request/Response 依然可以通过这个TCP连接继续传送。

在事务结束之后仍然保持在打开状态的TCP连接成为持久链接。非持久连接会在每个事务结束后关闭，持久连接会在不同事务（Request/Response）之间保持打开状态，直到客户端或服务器决定将其关闭为止。

可以提高HTTP连接性能的方法：

并行连接

通过多条连接发起并发的HTTP请求。并行连接可以提高复合页面的传输速度，但其连接也有一些缺点

每个事务都会打开/关闭一条新的连接，会耗费时间和带宽。由于TCP慢启动特性存在，每条连接的性能都会有所降低。可打开的并行连接数量实际上是有限的

持久化连接

Web客户端经常会打开到同一个站点的连接。比如，一个Web页面上的大部分内嵌通常来自同一个Web站点，而且相当一部分指向其他对象的超链通常都指向同一个站点。初始化了对某服务器HTTP请求的应用程序很可能会不久的将来对那台服务器发起更多的请求，这种性质称为站点局部性。

因此， HTTP/11允许HTTP设备在事务处理结束之后将TCP连接保持在打开状态，以便为未来的HTTP请求重用现存的连接 。在事务处理结束之后仍然保持在打开状态的TCP连接称之为持久连接。持久连接会在不同事务之间保持打开状态，直到客户端或服务器决定其关闭为之。重用已对目标服务器打开的空闲持久连接，就可以避开缓慢的连接建立阶段。而且，已经打开的连接还可以避免慢启动的拥塞适应阶段，以便更快速地进行数据传输。所以，持久连接降低了时延和连接建立的开销，将连接保持在已调谐状态，而且减少了打开连接的潜在数量。

持久连接和并行连接配合使用可能是最高效的方式。很多Web应用程序都会打开少量的并行连接，其中每个都是持久连接。持久连接有两种类型

1）HTTP/10 + keep-alive 连接

 2) HTTP/11 + persistent 连接

HTTP/10  keep-alive连接

现在很多客户端和服务器仍然在使用这些早期的keep-live连接。

实现HTTP/10 keep-live连接的客户端可以通过包含Connection:Keep-Alive 的请求头将一条连接保持在打开状态。

响应中Keep-Alive首部是可选的，但只有在提供Connection：Keep-Alive时才能使用它。

Connection:Keep-Alive

Keep-Alive:max=5,timeout=120

这个例子说明了服务器最多还会为另外5个事务保持连接的打开状态，或者将打开状态保持到连接空闲了2分钟以后。

注意：

1 在HTTP/10中，keep-alive并不是默认使用的。客户端必需发送一个Connection：Keep-Alive 请求首部来激活keep-alive连接。

2 如果服务器愿意为下一条请求将连接保持在打开状态，就在响应头中说明，如果响应头中没有Connection:Keep-Alive ，客户端就认为服务器不支持keep-live，会在发回响应报文后关闭连接。

3 只有在无需检测到连接的关闭就可以确定报文实体主体部分长度的情况下，才能将连接保持在打开状态--也就是说实体的主体部分必需有正确的Content-Length，

有多部件媒体类型（multipart/form-data  有boundary）或者用分块传输编码的方式进行了编码。在一条keep-live信道中回送错误的Content-Length是很糟糕的事情，这样的话，事务处理的另一端就无法精确地检测出一条报文的结束和另一条报文的开始了。

HTTP/11  持久连接 Persistent Connection

HTTP/11逐渐停止了对keep-alive连接的支持，用一种名为持久连接的改进型设计取代了它。持久连接的目的与keep-alive连接的目的相同，但是工作机制更优些。HTTP/11就吃连接在默认情况下是激活的，除非特别指明，否则HTTP/11假定所有的连接都是持久的。要想在事务处理结束之后将连接关闭，HTTP/11应用程序必须向报文中显示地添加一个Connection：close首部。

HTTP11客户端加载在收到响应后，除非响应中包含了Connection：close首部，不然HTTP/11连接就仍然维持在打开状态。但是，客户端和服务器仍然可以随时关闭空闲的连接。不发送Connection：close并不意味这服务器承诺永远将连接保持在打开状态。

注意：

1 只有当连接所有的报文都有正确的、自定义报文长度时，也就是说，实体主体部分的长度都和相应的Content-Length一致，或者用分块传输编码方式编码的，连接才能持久保持。

2 如果客户端不想在连接上发送其他请求了，就应该在最后一条请求中发送一个Connection：close请求首部

管道化连接

HTTP/11允许在持久连接上可选的使用请求管道。是相对于keep-alive连接的又一性能优化。在响应到达之前，可以将多条请求放入队列，当第一条请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。

对管道连接的说明：

1）如果HTTP客户端无法确认连接是持久的，就不应该使用管道

2）必须按照与请求相同的顺序回送HTTP响应。

3）HTTP客户端必须做好连接会在任意时刻关闭的准备，还要准备好重发所有未完成管道化的请求。

4）出错的时候，管道连接会阻碍客户端了解服务器执行的是一些列管道化请求中的哪一些。由于无法安全地重试POST这样的非幂请求，所以出错时，就存在某些方法永远不会被执行的风险。

是短连接。

短连接：客户端和服务端建立连接以后，只发一次数据后，就断开链接。

http连接是一种无状态的协议，建立连接后，当服务端向客户端反馈后，断开链接。

#短连接的操作步骤是#：

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

#长连接的操作步骤是#：

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

长连接：客户端和服务端建立连接以后，发送多次数据后，才断开连接

HTTP是无状态的

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

HTTP11和HTTP10相比较而言，最大的区别就是增加了持久连接支持(貌似最新的 http10 可以显示的指定 keep-alive),但还是无状态的，或者说是不可以信任的。

如果浏览器或者服务器在其头信息加入了这行代码

Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了带宽。

实现长连接要客户端和服务端都支持长连接。

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

所谓短连接指建立SOCKET连接后发送后接收完数据后马上断开连接，一般银行都使用短连接

短连接：比如

http

的，只是连接、请求、关闭，过程时间较短

,

服务器若是一段时间内没有收到请求即可关

闭连接。

长连接：有些服务需要长时间连接到服务器，比如

CMPP

，一般需要自己做在线维持。

最近在看

“

服务器推送技术

”

，在

B/S

结构中，通过某种

magic

使得客户端不需要通过轮询即可以得到服务

端的最新信息（比如股票价格）

，这样可

以节省大量的带宽。

传统的轮询技术对服务器的压力很大，

并且造成带宽的极大浪费。如果改用

ajax

轮询，可以降低带宽的负荷

（因为服务器返回的不是完整页面）

，

但是对服务器

的压力并不会有明显的减少。

而推技术（

push

）可以改善这种情况。但因为

HTTP

连接

的特性（短暂，必须由客户端发起）

，使得推技术的实现比较困难，常见的做法是通过延长

http

连接的寿

命

，

来实现

push

。

接下来自然该讨论如何延长

http

连接的寿命

，

最简单的自然是死循环法

：

servlet

代

码

片

段

public

void

doGet(Request

req,

Response

res)

{

PrintWriter

out

=

resgetWriter();

……

正

常

输

出

页

面

……

outflush();

while

(true)

{

outprint("

输

出

更

新

的

内

容

");

outflush();

Threadsleep(3000);

}

}

如果使用观察者模式则可以进一

步提高性能。

但是这种做法的缺点在于客户端请求了这个

servlet

后，

web

服务器会开启一个线程执行

servlet

的代码，而

servlet

由迟迟不肯结束，造成

该线程也无法被释放。于是乎，一个客户端一个线程，

当客户端数量增加时，服务器依然会承受很大的负担。

要从根本上改变这个现象比较复杂，目前的趋

势是从

web

服务器内部入手，用

nio

（

JDK

14

提出的

javanio

包）改写

request/response

的实现，再利

用线程池增强服务器的资源利用率，从而解决这个问题，目前支持这一非

J2EE

官方技术的服务器有

Glassfish

和

Jetty

（后者只是听说，没有用过）

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

nginx中http模块使用http长连接的相关配置（主要是keepalive指令）和http长连接的原理解释。

连接管理是一个 HTTP 的关键话题：打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在 HTTP/1x 里有多种模型：短连接, 长连接, 和 HTTP 流水线。在解释这三种模型之前，我们需要先明确一些前提知识：

接下来我们开始解释。

在早期，HTTP 使用一个简单的模型来处理这样的连接。这些连接的生命周期是短暂的：每发起一个请求时都会创建一个新的连接，并在收到应答时立即关闭。这就是类似上面说的三次握手，在互联网发展的早期一个网页的资源并没有现在这么多，很多可能只是一个简单的静态页面而已，所以这样的模型显然很OK。客户端获取完所需资源之后，就断开连接，不再占用服务器的资源。

HTTP 短连接模型是最早期的模型，也是 HTTP/10 的默认模型。每一个 HTTP 请求都由它自己独立的连接完成；这意味着发起每一个 HTTP 请求之前都会有一次 TCP 握手，而且是连续不断的。 实际上，TCP 协议握手本身就是耗费时间的，所以 TCP 可以保持更多的热连接来适应负载。短连接破坏了 TCP 具备的能力，新的冷连接降低了其性能。

后来，网页需要请求的资源越来越多，短连接模型显然已经十分吃力了。因为短连接有两个比较大的问题：创建新连接耗费的时间尤为明显（三次握手很耗费时间），另外 TCP 连接的性能只有在该连接被使用一段时间后(热连接)才能得到改善。因此在HTTP/11中引入了长连接模型和流水线模型。

一个长连接会保持一段时间，重复用于发送一系列请求，节省了新建 TCP 连接握手的时间，还可以利用 TCP 的性能增强能力。当然这个连接也不会一直保留着：连接在空闲一段时间后会被关闭(服务器可以使用 Keep-Alive 协议头来指定一个最小的连接保持时间)。

长连接也还是有缺点的；也就是前面提到的资源占用问题，就算是在空闲状态，它还是会消耗服务器资源，也更容易被DDoS攻击。 本质上长连接是因为不断地三次握手建立连接消耗的资源要大于维持连接所需要的资源才使用的 ，如果服务器处于高负载时段或者被DDoS，可以使用非长连接，即尽快关闭那些空闲的连接，也能对性能有所提升。

流水线模型的实现要复杂很多，而已效果也并不是特别好，主要还要考虑到各种兼容性，所以默认是不启用这个流水线模型的，而在HTTP/2中，流水线已经被更好的算法给代替，如 multiplexing 。

默认情况下，HTTP 请求是按顺序发出的。 下一个请求只有在当前请求收到应答过后才会被发出。 由于会受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。 流水线是在同一条长连接上发出连续的请求，而不用等待应答返回。这样可以避免连接延迟。 理论上讲，性能还会因为两个 HTTP 请求有可能被打包到一个 TCP 消息包中而得到提升。就算 HTTP 请求不断的继续，尺寸会增加，但设置 TCP 的 MSS(Maximum Segment Size) 选项，仍然足够包含一系列简单的请求。

并不是所有类型的 HTTP 请求都能用到流水线：只有 idempotent 方式，比如 GET 、 HEAD 、 PUT 和 DELETE 能够被安全的重试：因为有故障发生时，流水线的内容要能被轻易的重试，即出现了问题重试的成本要尽可能低，否则还不如使用长连接模型。

正确的实现流水线是复杂的：传输中的资源大小，多少有效的 RTT 会被用到，还有有效带宽，流水线带来的改善有多大的影响范围。不知道这些的话，重要的消息可能被延迟到不重要的消息后面。这个重要性的概念甚至会演变为影响到页面布局！因此 HTTP 流水线在大多数情况下带来的改善并不明显。此外，流水线受制于 HOL 问题。

我们还是使用上面的例子来进行解释，这次的握手请求就变了，A一次向B发出了三个请求：

最后这里补充一张来对比三种模型之间的差别：

了解了上面的原理之后，Nginx中的keepalive指令我们就非常好理解了，相关的指令主要有三个，我们逐个进行解释：

在upstream模块中配置，启用连接到upstream中的服务器的缓存， connections 参数的主要作用是设定每个Nginx的 单个worker进程（each worker process） 对于upstream中的server的最大空闲连接数，当超过该数字的时候，会关闭使用得最少的连接。

需要注意的是，keepalive指令并不会限制Nginx的 所有worker 进程能开启的连接到upstream服务器中的 连接总数（total number） 。也就是如果设得太大了，会导致过多的空闲连接占满了upstream中的server资源，导致新的连接无法建立，因此这个数值的设定需要根据worker进程数量来调整。

keepalive_requests 设定可以通过一个连接（connection）发送的请求（request）数量，超过最大请求数量之后，该连接会被关闭。为了释放每个连接的内存分配，定期关闭连接是很有必要的。因此，不建议将 keepalive_requests 设定过大，否则可能会导致过高的内存占用。

设定连接超时时间，在此设定的时间内，client与upstream中的server的空闲keepalive连接将保持打开状态（open）。此外，虽然官方文档说的默认值是60s，但是1179版本的Nginx在安装之后配置文件nginxconf上面设定的是65s。