Keepalive
Keepalive(简称:KA,中文:存活)是用于监测两个装置之间的数据链路是否正常工作,或防止链路中断的资讯。
概述
存活信号通常以一定的时间间隔发出,其在互联网上扮演了至关重要的角色。若一端在信号发出后未收到回复,则可判定数据链路离线并将之后的数据包重新路由到其他链路,直到旧链路重新上线为止。存活信号也可表示保留连接状态。若无存活信号,启用网络地址转换的路由器将于超时后中断连接。
由于存活资讯仅用于表示链路状态及保留连接,其应言简意赅且仅仅占用较少的带宽。但是,存活资讯的格式及用法根据传输协议的不同而有所差异。
TCP 存活
传输控制协议(TCP)存活包为可选特性,且默认关闭。[1]存活包内没有数据。在以太网网络中,存活包的大小为最小长度的几帧(64字节[2])。协议中[3],还有三个与存活包相关的参数:
- 存活时长(英语:Keepalive time)即空闲时,两次传输存活包的持续时间。TCP存活包时长可手动配置,默认不少于2个小时。
- 存活间隔(英语:Keepalive interval)即未收到上个存活包时,两次连续传输存活包的时间间隔。
- 存活重试次数(英语:Keepalive retry)即在判断远程主机不可用前的发送存活包次数。当两个主机透过TCP/IP协议相连时,TCP存活包可用于判断连接是否可用,并按需中断。
多数支持TCP协议的主机也同时支持TCP存活包。每个主机按一定周期向其他主机发送TCP包来请求回应。若发送主机未收到特定主机的回应(ACK),则将从发送主机一侧中断连接。 若其他主机在连接关闭后发送TCP存活包,关闭连接的一方将发送RST包来表明旧连接已不可用。其他主机将关闭它一侧的连接以新建连接。
空闲的TCP连接通常会隔每45秒或60秒发送一次存活包。在未连续收到三次ACK包时,连接将中断。此行为因主机而异,如默认情况下的Windows主机将在7200000ms(2小时)后发送首个存活包,随后再以1000ms的间隔发送5个存活包。若任意存活包未收到回应,连接将被中断。
在更高层的使用
由于TCP存活包为可选功能,多种协议(如SMB[4] 及TLS[5])在基于TCP协议的基础上研发了独立的存活指示功能。使用无连接协议来保持会话状态的协议通常也会如此,如使用UDP的OpenVPN[6]。
其他用途
HTTP 存活
超文本传输协议使用在“Connection”头部资讯中使用关键字“Keep-Alive”来指示连接应保持开启以接收之后的资讯(这是HTTP 1.1中的默认情形,而HTTP 1.0默认将为每对请求/回复对创建新连接)。[7]尽管名字相近,其功能却大相径庭。
其他装置
机动车维修时,存活(英语:Keep-alive)装置通常用于保持电池电压,使用小电池插入汽车的12伏电源接口。其目的一般是为了防止汽车的收音机或其他装置进入“编码”(安全锁定)模式。基本上使用9伏电池即可。
电子时钟常常带有使用电池的存活电路来保证在电源中断的情况下时间及其他设置的正常。部分电子装置使用电容电路来保持易失性内存。
另请参阅
参考文献
- ^ Requirements for Internet Hosts - Communication Layers. IETF. October 1989 [November 8, 2013]. (原始内容存档于2008-09-15).
- ^ 3.1.1 Packet format. IEEE Standard for Ethernet, 802.3-2015 – section one. 2016: 108. ISBN 978-1-5044-0078-7. doi:10.1109/IEEESTD.2016.7428776.
- ^ Using TCP keepalive under Linux. tldp.org. [2016-07-29]. (原始内容存档于2020-11-28).
- ^ Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods. IETF. March 1987 [June 18, 2015]. (原始内容存档于2020-10-18).
- ^ Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension. IETF. February 2012 [June 18, 2015]. (原始内容存档于2014-04-16).
- ^ OpenVPN manual page. [June 18, 2015]. (原始内容存档于2020-12-23).
- ^ HTTP Keep Alive discourse by Jim Driscoll. [2020-04-04]. (原始内容存档于2010-08-13).