心跳信号

                                     数据通讯中的心跳信号

• 什么是心跳信号
• 心跳信号的作用
• 何时需要心跳信号
• 怎么建立心跳信号
  • 传送记录类型的数据时
  • 传送文件或者视频（数据）流时
  • 特别说明

---

什么是心跳信号

互联的双方中的一方，每隔固定的时间向另一方发送一个很小的数据包，另一方根据需要确定在收到数据包之后是否回复一个很小的数据包。每隔固定时间是很难达到的一个条件，实际情况是不超过某个时间间隔。

心跳信号的作用

心跳信号是为了确认一个事实——互联的双方在长时间没有通讯的情况下是否都还在线，或者说存在于互联的双方之间的通讯链路是否已经断开。而不是网上有些人所谓的“用来保持连接”，“用来维持长连接”。连接一旦建立，只能被异常或正常的断开，而不会因为没有数据传输而断开的，所以没有什么长连接的概念，更不需要用发送数据的方式来保持连接。

有些防火墙或者电脑管理软件会把超过一定时间没有通讯的连接当作死连接，这些软件会自动将死连接断开或者请求用户将死连接断开。当有心跳时，不会被这类软件当做死连接。看起来心跳信号像是保持了连接，这是只是心跳信号偶然间具有的作用。

长连接和短连接是应用层的概念。长连接表示当与某个目标创建应用层的连接后，目标不会因为没有数据通讯而去断开这个连接。短连接表示当需要与目标通信时创建连接通讯一结束立刻断开，否则目标有可能也会因为长时间不通讯而将连接断开，ftp服务器就会。

当ftp服务器允许长连接属性开启后，ftp服务器不会因为连接着的客户端没有长时间没有上传或者下载文件而关闭这个连接，对于ftp客户端来说就是不需要采用短连接的方式上传或者下载文件。

何时需要心跳信号

显然通过心跳信号的作用就可以知道，当应用层采用了长连接，并且会出现长时间不通讯的情况，并且双方中至少有一方需要知道对方是否仍然在线或者数据链路是否仍然通畅时，才需要使用心跳信号。不管何种通讯协议，只要不是采用传送数据时连接，传送完毕立即断开的方式那么就是在应用层采用了长连接。

不管采用是基于连接的协议（如TCP），还是基于流的协议（如UDP），当在应用层采用了长连接方式时，都可能需要心跳信号。首先让我们来看看这两类协议的区别。

基于流的协议不需要建立连接，也不需要断开，发送方向某个地址（IP加端口）发送数据，收取方从某个地址读取数据。对于基于流的协议来说，发送方是否成功发送数据或者发送的数据是否被成功收取，发送方是不知道的；收取方没有收到数据到底说明发送方没有发送还是发送了但是丢失了，也是不知道的。其实串口通讯协议也算作是一种基于流的协议，虽然有一个打开串口的过程，其实这只是相当于请求独占一个端口，这也是串口不能重复被打开的原因。

基于连接的协议，在通讯前首先要建立连接，建立连接的过程包括一定步骤的双向通讯；断开连接也是一样的，有心情的可以看一下TCP的通讯过程。基于连接的通讯协议每一次发送数据都是一个双向的通讯过程，发送方发送数据，接收放收到数据后回复，如果没收到回复重新发，重发0次或多次后会认为连接无故断开了，报告发送失败。显然基于连接的协议能够保证发送的数据被目标接收到了。数据包中对与应用来说有意义的部分数据是否正确是需要根据具体协议而定的，但是指明目的地址的包头部分有错误肯定会导致重发或者发送失败。

采用基于连接的协议通讯的双方中的一方由于停电、当机、崩溃等原因没有进行或者完成断开连接的过程那么另一方就不知道连接是否断开了。对于基于连接的协议，一旦在应用层采用了长连接绝大多少情况下都需要心跳信号，除非程序不用长时间运行，不在乎死连接的性能损失。

对于基于流的协议，采用了长连接并且有一方需要确认和区分数据的来源地址（ip端口或者其它标识）且需要知道来源方或发送方是否还在线时才需要采用心跳信号。归纳起来就是如果一方需要知道另一方是否在线那么一定需要心跳信号；如果一方需要知道另一方是否在线但是又不需要知道收到的数据来自何处，那么程序肯定设计的有问题。仅仅区分数据来源是没有必要为每一个来源都创建一个独立的连接（其实不应该叫做连接，可以看做tcp、udp通讯采用的socket），更没有必要采用心跳信号。收到数据之后就可以知道端口、IP，其它标识也可以添加到数据包里。

怎么建立心跳信号

传送记录类型的数据时

记录类型的数据长短差异不是特别巨大，数据类型多样，拥有一定的结构。发送这种类型的数据一般采用基于连接的协议（TCP），这样可以保证每条数据都能送到目标。此时心跳信号应该算作通讯协议（这是应用层的协议）中的一种数据，和其它数据发送到同一个端口号。在协议设计过程中要考虑到用一种特别的标记将一条条的数据隔开，以防粘包。将心跳信号和其他数据的结构设计成一致的。将某条数据解析出来后通过其中的某个字段来确认这条数据到底是心跳信号还是其他数据。

这种情况下心跳信号可以采用计时器每隔一段时间发送一次，而不用理会是否有其它类型的数据发送。接收方应该在至少经过2到3倍的约定时间没有收到心跳信号时才认为连接断开了。当然也可以有其它类型数据发送时，不发送心跳信号。这样一来双方的处理逻辑都复杂一些。不管采用何种方式，在的通讯协议都应该进行说明。

传送文件或者视频（数据）流时

传送文件时一般采用基于连接的协议。如果采用基于流的协议，就需要自己处理某一个包是否送达目标的过程，而这个过程恰好是基于连接的协议的底层内容。

传送视频流和其它类型的数据流时一般采用基于流的协议。因为网络环境不至于差到每一帧数据中都有丢包。传送视频流时，丢了一包，带来的影响也就是解码出来的图像花屏或者不能解码；花屏没什么大不了，不能解码直接丢弃也没什么影响。

传送其它的数据流，比如从传感器不断发回来的温度、湿度等，从GPS接收机不断发回来的定位信息。这些数据损坏了一帧，还有下一帧可以使用。所以也不在乎丢包。

对于这种流式数据不允许中间插入心跳数据。所以心跳数据的格式必须单独设计。心跳的发送也有两种方式。第一种，不管数据流是否在发送都每隔固定的时间将心跳数据发往不同于发数据流的端口。第二种，当发送数据流时不发送心跳信号。

特别说明

TCP已经包含了心跳信号。但是这个心跳信号受实现平台的限制比较多，并且默认是关闭的。如果开发服务器程序尽量不要依赖这个功能。如果开发一些简单的小应用时，并且可以预料到将来没有平台迁移任务时才可以使用。