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).