默认参数下，DTU每分钟向服务器发送1个心跳包。
一、心跳包作用
1、维持链路
当DTU以TCP模式连接上服务(中心)时，如果在一定时间内(如:5-10分钟)DTU没有向服务(中心)发送数据，则运营商会强制把DTU与服务(中心)断开。所以我们的DTU就要随时的发送一包数据来维持链路。
2、告知数据中心DTU还在线
当DTU以TCP模式连接上服务(中心)时，且DTU每分钟发送一包数据，如果在两分钟或更多时间内服务(中心)没有收到DTU的数据，服务(中心)就会认定DTU已经掉线，从而阻碍通信。所以心跳包可以告知数据中心DTU还在线。
3、DTU检查自身是否掉线
当DTU以TCP模式连接上服务(中心)时，如果DTU不向服务中心发送任何数据，DTU或服务(中心)就不知道链路是否连通，然后DTU就会出现假死现象，从而造成意想不到的问题。假如每分钟发一个心跳包数据，而且每个心跳包数据都有回应，那么就可以检查DTU是否在线了。
当网络异常掉线的时候，多次没有收到回应，就认为网络连接已经异常断开
二、没有心跳包的情况
有的客户不想DTU产生心跳包发到服务器，他们认为心跳包数据和他们的用户数据混在一起会干扰到到他们。
这时客户要求关闭DTU的心跳包，但关闭心跳包之后，就会出现前一章说明的三个问题。
问题一：
问题2：
问题3：
方案A：
在使用上面的这个方法时，心跳包时间不宜设置为60秒，建议设置为300秒。上面这个现象和上面的“问题一”比较像，但更要相信自己实现的机制更加可靠，不过于依赖外部条件，不依赖运营商主动断开我们的连接，可以防止将来运营商改变机制时出现问题。
方案B：
有这两个办法，又可以保证在线了。
不过客户又说了，这两个办法都不需要，他们的PLC有心跳数据。
方案C：
压轴方案D：
这应该是所有办法里面最高端的了，keeplive包收发都隐藏在TCP/IP协议栈低层，DTU不用关心发送，数据中心不用关心回应，一切都在暗地里愉快的进行，只要在一开始设置好。目前只有linux系统开发的DTU支持这个方案。
题外话：隐形的回应ACK，判断网络断开的重要工具
用户使用DTU时，不用关心“ACK应答数据包”，不用担心还要回应“ACK应答数据包”。因为“ACK应答数据包”是自己产生的，只要使用TCP协议，就会有“ACK应答数据包”。而DTU就是判断发出数据以后，能否收到“ACK应答数据包”，来确定是否掉线的。