原文：长连接、短连接和心跳（有图有案例）_统木木的博客-CSDN博客
文章目录
前言
网络通信过程中，主机与主机之前一般是通过TCP协议进行连接的，既然是连接，那么就会有连接时间的长短，长时间的连接称之为长连接，短时间的连接称之为短连接。在长连接的过程中，由于是长时间连接，所以对于服务器来说，需要去判断连客户端是不是还在线，这里就涉及到心跳的问题。就像人的心跳一样，每跳动一次，就发出一个消息，看看能不能得到回应，如果能得到回应，说明客户端仍然在线，如果得不到回应，在一定的心跳次数下依然得不到回应，就可以断开连接了。
因此本文的主题就是：长连接和心跳、短连接
一、TCP连接
首先要明确一点，不管是长连接还是短连接都是在TCP连接的过程中发生的，也就是发生在网络的传输层上面。
简单来说，当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立连接，当读写操作完成后，双方不再需要时释放连接，连接的建立是需要三次握手，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的。
二、长连接和心跳
1、概念
长连接是指在通信过程中，两台主机可以多次传输数据，但是只连接一次，做到连接的复用。一次数据传输后，不关闭连接，长期保持连接状态。如果两个应用程序之间有新的数据需要传输，则直接复用这个连接，无需再建立一个新的连接。示意图如下：
2、优缺点
优点：
（1）省时间：在多次通信中可以避免进行多次连接，从而节省了连接建立和关闭的开销，从总体上来看，进行多次数据传输的总耗时更少，减少网络阻塞的影响。
（2）当发生错误时，可以在不关闭连接的情况下进行提示
（3）节约资源：减少CPU及内存的使用，因为不需要经常的建立及关闭连接。
缺点：
（1）连接数过多时，影响服务端的性能和并发数量。
（2）我们就需要担心各种问题：比如**端对端连接的维护，连接的保活等。**需要花费额外的精力来保持这个连接一直是可用的，因为网络抖动、服务器故障等都会导致这个连接不可用，甚至是由于防火墙的原因。
3、长连接的生命周期
正常情况下一直存在。正常情况下，一条TCP长连接建立后，只要双方不提出关闭请求并且不出现异常情况，这条连接是一直存在的。操作系统不会自动去关闭它，甚至经过物理网络拓扑的改变之后仍然可以使用。所以一条连接保持几天、几个月、几年或者更长时间都有可能，只要不出现异常情况或由用户（应用层）主动关闭。客户端和服务端可一直使用该连接进行数据通信。
4、使用场景
高频请求的场景。
（1）数据库的连接就是采用TCP长连接.
（2）RPC，远程服务调用，在服务器，一个服务进程频繁调用另一个服务进程，可使用长连接，减少连接花费的时间。
5、心跳机制
既然是长连接，为了防止连接断开或者说判断连接是否依然存在，就需要有一种机制来进行判断，这种机制就是心跳机制（HeartBeat）。
心跳：用来检测网络链路是否通畅的一种方式，一般做法是定时向被检测对象发送心跳包（探测报文），被检测系统收到心跳包进行回复，发送方收到回复说明对方存活。心跳机制能够给长连接提供保活功能，能够检测长连接是否正常（这里所说的保活一方面可以理解为维持长连接，另一方面来说是一旦链路死了，不可用了，能够尽快知道，然后做些其他的可用措施，来保证系统的正常运行）。
心跳包机制：
心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。
在TCP的机制里面，本身是存在保活机制（keepalive）的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。
心跳包一般来说都是在逻辑层发送空的echo包来实现的。设置一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。
其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接保活。
在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。
总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。
心跳检测步骤：
1 客户端每隔一个时间间隔发生一个探测包给服务器
2 客户端发包时启动一个超时定时器
3 服务器端接收到检测包，应该回应一个包
4 如果客户机收到服务器的应答包，则说明服务器正常，删除超时定时器
5 如果客户端的超时定时器超时，依然没有收到应答包，则说明服务器挂了
三 短连接
1、概念
短连接意味着每一次的数据传输都需要建立一个新的连接，用完再马上关闭它。下次再传输数据的时候重新建立一个新的连接，如此反复。示意图如下：
2、优缺点
优点：
（1）管理简单，不需要操心连接状态的管理。
（2）由于每次使用的连接都是新建的，所以基本上只要能够建立连接，数据就大概率能送达到对方。并且哪怕这次传输出现异常也不用担心影响后续新的数据传输，因为届时又是一个新的连接。
缺点：
（1）频繁的连接就会浪费时间：每个连接都需要经过三次握手和四次握手的过程，耗时大大增加。
（2）致命的缺点：短时间内的大量连接导致端口数不够用。socket 通信过程包含通信协议、目标地址、状态等。实际当你在基于 socket 进行开发的时候，这些包含的具体资源主要就是这 5 个：源 IP、源端口、目的 IP、目的端口、协议，有个专业的叫法称之为五元组”。在一台计算机上只要这五元组的值不重复，那么连接就可以被建立。然而一台计算机最多只能开启 65535 个端口，如果现在两个进程之间需要通信，作为服务端的 IP 和端口必然是固定的，因此单个客户端理论上最多只能与服务端同时建立 65535 个 socket 连接。如果除去操作系统和其它进程所占用的端口，实际还会更少。所以，一旦使用不当，在很短的时间内建立了大量连接，端口很容易被占用完。这不但会导致自身无法正常工作，还会影响到同一台计算机上的其它进程。我们在项目中大多数情况使用的是短连接的方式，因为这对我们编程来说可以少考虑很多问题，潜在的这些缺点可能是你没有遇到或者意识到而已。
3、使用场景
并发量大，请求频率低的场景：通常浏览器访问服务器的时候就是短连接。对于服务端来说，长连接会耗费服务端的资源，而且用户用浏览器访问服务端相对而言不是很频繁的如果有几十万，上百万的连接，服务端的压力会非常大，甚至会崩溃。所以对于并发量大，请求频率低的，建议使用短连接。
四 长连接和短连接的选择
1 长连接：高频、服务端主动推送和有状态
你肯定见过一些监控或者实时报价类系统，比如股票软件，它需要在几秒之内刷新最新的价格。像这种场景中同时包含了需要运用长连接的三个主要因素：高频、服务端主动推送和有状态。
- 高频的原因我想你根据前面的内容也明白了，因为频次越高的话，使用短连接带来的建立连接和关闭连接的总开销越大。
- 而服务端主动推送也需要长连接的原因是，由于服务端往往是“中心化”的，一般都是 1 个服务端为多个客户端提供服务。所以，如果使用短连接的方式，那么在客户端未主动连接到服务端的情况下，服务端并不知道需要往哪些客户端去推送数据，这是原因之一。所以此时，长连接成为了一个很好的选择。另外一个原因是，哪怕客户端通过定时的短连接轮询方式进行主动连接，除了增加了额外的建立连接和关闭连接的开销外，还可能遇到通信完成后结果数据并未发生变化，做了无用功。
- 成熟股票软件的服务端，为了支撑更多的用户以及做高可用，必然部署了多台。但是这个业务场景，用户无法容忍由于多个服务端之间数据同步的误差导致他在客户端看到的价格刷新产生“回退”现象。所以，只能尽量保持一直连接在同一台服务器上，才能避免这个情况。这种场景被称之为“有状态”，也可以理解为是“串行”的，因为多次请求的前后需要保持“连续性”。
短连接使用场景：低频、无状态
短连接则更适用于诸如阅读类软件的场景中，例如，很多时候用户点开一篇文章后需要花一些时间进行阅读，这个时间有长有短，并且直到用户下一次操作之前都没有数据传输发生。这个场景中包含了运用短连接的两个主要因素：低频、无状态。
- 因为低频，所以更能容忍建立连接和关闭连接的开销。
- 用户的下一次点击往往跳转到了其它文章，并且新打开的与当前文章并不需要具有“连续性”，所以这种场景我们称之为“无状态”的。另外，理论上同一时刻打开几篇文章也不会存在什么不妥。
五、参考博客
参考博客1：长连接和短连接详细解析
原文链接：https://cloud.tencent.com/developer/article/1470024
参考博客2：聊聊 TCP 长连接和心跳那些事
原文链接：http://blog.itpub.net/31556476/viewspace-2375225/
参考博客3：长连接和心跳的那些事儿
原文链接：https://www.jianshu.com/p/c6af08f853d0
参考博客4：长连接、短连接、心跳机制与断线重连