[学习记录]
前言
TCP连接一旦建立，只要连接双方不主动 close ，连接就会一直保持。但建立连接的双方并不是一直都存在数据交互，所以在实际使用中会存在两种情况：一种是每次使用完，主动close，即短连接；另一种是使用完后，不主动close，即长连接。对于长连接而言，在长时间无数据交互的时间段内，交互双方都有可能出现掉电、死机、等各种意外，导致TCP连接并未来得及正常close，那么，连接的另一方并不知道对端的情况，它会一直维护这个连接，长时间的积累会造成端系统资源的消耗和浪费，为了解决这个问题，这就有了TCP Keepalive机制。
- TCP本身并没有长短连接的区别，长短与否，完全取决于程序怎么用它
- KeepAlive 并不是 TCP 协议的一部分，详见 TCP Keepalive
- 短连接：每次通信时，创建 Socket；一次通信结束，调用 socket.close()
- 长连接：每次通信完毕后，不会关闭连接，可以复用连接
TCP-KeepAlive机制
TCP长连接下，客户端和服务器若长时间无数据交互情况下，若一方出现异常情况关闭连接，抑或是连接中间路由出于某种机制断开连接，而此时另一方不知道对方状态而一直维护连接，浪费系统资源的同时，也会引起下次数据交互时出错。
为了解决此问题，引入了TCP KeepAlive机制（并非标准规范，但操作系统一旦实现，默认情况下须为关闭，可以被上层应用开启和关闭）。其基本原理是在此机制开启时，当长连接无数据交互一定时间间隔时，连接的一方会向对方发送保活探测包，如连接仍正常，对方将对此确认回应。
TCP Keepalive 协议解读
说是协议解读有点不准确，其实是 TCP Keppalive 的请求意见稿 RFC1122#TCP Keep-Alives
- TCP Keepalive 虽不是标准规范，但操作系统一旦实现，默认情况下须为关闭，可以被上层应用开启和关闭。
- TCP Keepalive 必须在 没有任何数据（包括ACK包）接收之后的周期内才会被发送
- KeepAlive 机制开启后，在一定时间内（一般时间为 7200s，参数 tcp_keepalive_time）在链路上没有数据传送的情况下，TCP 层将发送相应的 KeepAlive 探针以确定连接可用性，探测失败后重试 10（参数 tcp_keepalive_probes）次，每次间隔时间 75s（参数 tcp_keepalive_intvl），所有探测失败后，才认为当前连接已经不可用。
- 不包含数据的ACK段在被TCP发送时没有可靠性保证，即一旦发送，不确保一定发送成功。系统实现不能对任何特定探针包作死连接对待
- 规范建议keepalive保活包不应该包含数据，但也可以包含1个无意义的字节，比如0x0。
- SEG.SEQ = SND.NXT-1，即TCP保活探测报文序列号将前一个TCP报文序列号减1。SND.NXT = RCV.NXT，即下一次发送正常报文序号等于ACK序列号。
TCP keepalive 如何使用
以下环境是在Mac上进行，应用程序若想使用需要设置 SO_KEEPALIVE 套接口选项才能够生效。
查看TCP keepalive 系统内核参数配置
sysctl net.inet.tcp | grep -E "keepidle|keepintvl|keepcnt"
- tcp_keepalive_time，在TCP保活打开的情况下，最后一次数据交换到TCP发送第一个保活探测包的间隔，即允许的持续空闲时长，或者说每次正常发送心跳的周期，默认值为7200s（2h）。
- tcp_keepalive_probes 在tcp_keepalive_time之后，没有接收到对方确认，继续发送保活探测包次数，默认值为9（次）
- tcp_keepalive_intvl，在tcp_keepalive_time之后，没有接收到对方确认，继续发送保活探测包的发送频率，默认值为75s。
发送频率tcp_keepalive_intvl乘以发送次数tcp_keepalive_probes，就得到了从开始探测到放弃探测确定连接断开的时间；若设置，服务器在客户端连接空闲的时候，每90秒发送一次保活探测包到客户端，若没有及时收到客户端的TCP Keepalive ACK确认，将继续等待15秒*2=30秒。总之可以在90s+30s=120秒（两分钟）时间内可检测到连接失效与否。
设置TCP keepalive 系统内核参数配置
sudo sysctl -w net.inet.tcp.keepidle=300000 net.inet.tcp.keepcnt=3 net.inet.tcp.keepintvl=10000
抓包验证
与设置的时间一致
TCP Keepalive 注意事项
KeepAlive 机制是在网络层面保证了连接的可用性，但站在应用框架层面我们认为这还不够。主要体现在三个方面：
- KeepAlive 的开关是在应用层开启的，但是具体参数（如重试测试，重试间隔时间）的设置却是操作系统级别的，位于操作系统的 /etc/sysctl.conf 配置中，这对于应用来说不够灵活。
- KeepAlive 的保活机制只在链路空闲的情况下才会起到作用，假如此时有数据发送，且物理链路已经不通，操作系统这边的链路状态还是 ESTABLISHED，这时会发生什么？自然会走 TCP 重传机制，要知道默认的 TCP 超时重传，指数退避算法也是一个相当长的过程。
- KeepAlive 本身是面向网络的，并不面向于应用，当连接不可用，可能是由于应用本身的 GC 频繁，系统 load 高等情况，但网络仍然是通的，此时，应用已经失去了活性，连接应该被认为是不可用的。
KeepAlive 使用方式
推荐方式：应用层心跳 + TCP keepalive
应用层心跳 + TCP keepalive一起使用，互相作为补充，但TCP保活探测周期和应用的心跳周期要协调，以互补方可，不能够差距过大，否则将达不到设想的效果。
参考文章