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