网络长连接和短连接

什么是长连接和短连接

左边是短连接，右边是长连接。我们会看到短连接为每一次的数据传输准备了一个传输通道，比如客户端向服务端要传送数据的时候，它会先建立连接，然后传递数据，最后关闭连接。当要传递第 2 份数据的时候，又要重复这个过程。所以短连接就是在每一次传输数据前，建立一次连接的通道。

长连接则是建立了一条可以连接通道，并一直保持，每一次传输数据时会复用同一条连接通道。

建立长连接的前提

第 1 个是客户端使用长连接方式请求
第 2 个是服务端需要支持长连接。

keepalive_timeout 控制着长连接的时间周期。如果我们想要观察是否是客户端和服务端建立起来了 HTTP 长连接，可以在 Chrome 浏览器里打开开发者工具，请求一个网站指定的地址，然后就可以在"network"标签选项里看到请求头和请求返回头，Request Headers 里面有一个 Connection，如果数值是 keep-alive 则表示是以长连接的方式去寻求服务端。

HTTP 协议与长连接的关系

HTTP 1.0 是非常早的版本了，它对长连接是不支持的，如果老的浏览器只支持 1.0 版本，就无法建立 HTTP 协议的长连接。HTTP 1.1 版本的话,目前绝大部分的浏览器都是可以支持的， 通过 HTTP1.1 协议可以实现长连接但无法做到复用数据通道做传输，而 HTTP 2.0 是近几年来推出的新协议，不仅支持长连接，更可以支持连接复用数据通道来做传输。

HTTP2.0 复用数据的方式是这样的，建立起 TCP 连接通道以后，客户端向服务端请求的是 index html，接下来请求 aa.css 、 bb.js，可以做到同时发起两个请求到服务端，而服务端可以同时响应并行传送数据到客户端，这样就做到了多路“HTTP数据传送”。

长连接和短连接的优势与劣势

第 1 个就是 TCP 的建连资源开销，我们会看到短连接和长连接最大的开销就是 TCP 的建连，这一块的开销也是因为它们的差异性而引起的，由于短连接在每一次数据请求时都要建立连接，所以说它的 TCP 建连会比长连接的开销更大。长连接只用到了一次建连，所以相比短连接来说建连的开销更小。

第 2 个为是否存在探活资源开销。我们知道，长连接要保持一条连接通道的话，那么服务端和客户端要实时保持探活的状态。探活的资源开销对于长连接来说是存在的，而对于短连接来说是不存在的。

第 3 个我们要对比在承受同样的并发请求情况下服务端的支撑能力。可以这么理解，假设短连接和长连接，同样是 1000 个并发请求到服务端，在同样请求个数的前提下，长连接的服务端整体开销会更大一些，而短连接因为它建立起来就断掉了，所以它的时间周期更小，对服务端的影响略小一些。

第 4 个区别就是服务端是否支持主动连接客户端。长连接是可以轻易做到的，在很多聊天室的场景里面用长连接是一个不错的选择，而短连接往往是客户端去请求服务端连接就关闭了，无法做到在 TCP 连接基础上实现双向主动通信。

长连接和短连接的使用场景

在大部分 Web 服务或是 API 网站服务里，基本会使用短连接。

长连接的应用场景有三个：

第 1 种是运用在后端数据库的连接里，比如我们会看到 Java 有一个连接池，连接池就是配置的固定连接数据库的连接通道，连接后端数据库的场景里，长连接会更加常用。

第 2 种方式就是刚才讲到的聊天室场景，因为服务端要向客户端主动推送消息。

第 3 种是服务端向客户端主动推送消息，也就是消息推送，我们看到手机端的一些消息推送，也属于长连接常用到的一些场景。

接下来我们来分析连接和常见连接状态 Timewait 的关系。当我们做运维的时候，常会看到系统上报 Time wait 个数超过系统允许 bucket 队列的个数限制，那么这些警告对我们来说有多大的影响？接下来进行讲解。

Timewait 和 TCP 连接的关系

Timewait 的连接状态是由 TCP 的 4 次挥手过程产生的。4 次挥手的过程如图所示。我们可以看到，左边是主动关闭的一端，右边就是被动关闭的一端。

主动关闭的一端向服务端发送第 1 次挥手的请求，被动方返回了一个 ACK 的包，可以看到被动关闭端再一次发送完 FIN 和 ACK 包以后，主动关闭端就会会先发送一个 ACK 响应回去，然后进入 TIME_WAIT 状态。

我们看到在它进入 TIME_WAIT 状态之前，理论上 4 次挥手已经完成了，为什么 TIME_WAIT 还需要保留一段时间？

这是因为 TCP的协议标准，需要保证4 次挥手过程中最后一次连接发送的稳定性，如果ACK包发送不成功，就需要再次发送 ACK 包。

大量的 Timewait 产生会造成文件句柄、内存和端口的占用，由于系统会把过多的 time-wait socket 删除、回收，在网络条件不好的情况下，就可能会导致数据包重复的进行发送。

对 TimeWait 进行优化

了解了 Timewait 的影响（结论：通常不会直接造成服务连接的影响，但是会造成一些资源上及新建连接风险），为了避免过多的 Timewait 产生，我们需要考虑去进行一些优化。在单机系统上做性能优化的话，我们需要考虑两点：

第 1 点就是考虑把Timewait 队列加大。在操作系统资源、硬件资源能满足的情况下，我们可以把 tcp_max_tw_buckets 的值数调高，它的缓冲值也就越大。这个数字是我们可以进行操作系统内核优化的。

第 2 点即我们需要尝试修改操作系统内核优化的内容，也就是调整 TIME_WAIT 超出时间，如果它的操作时间能够更快地让操作系统进行回收，那么它就可以更快地释放资源。当然这个时间也不能调的太小，要不然 Timewait 的作用的意义就很小了。所以我建议操作系统内核的参数 tcp_fin_timeout 这个值调到 30，这就是一个比较合理的优化空间。