[学习记录]
前言
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保活探测周期和应用的心跳周期要协调,以互补方可,不能够差距过大,否则将达不到设想的效果。
参考文章
- TCP Keepalive机制刨根问底
- 聊聊 TCP 长连接和心跳那些事
- TCP KeepAlive机制理解与实践小结