在使用TCP長鏈接(複用已創建TCP鏈接)的場景下,須要對TCP鏈接進行保活,避免被網關幹掉鏈接。
在應用層,能夠經過定時發送心跳包的方式實現。而Linux已提供的TCP KEEPALIVE,在應用層可不關心心跳包什麼時候發送、發送什麼內容,由OS管理:OS會在該TCP鏈接上定時發送探測包,探測包既起到鏈接保活的做用,也能自動檢測鏈接的有效性,並自動關閉無效鏈接。html
創建TCP鏈接時,就有定時器與之綁定,其中的一些定時器就用於處理keepalive過程。當keepalive定時器到0的時候,便會給對端發送一個不包含數據部分的keepalive探測包(probe packet),若是收到了keepalive探測包的回覆消息,那就能夠判定鏈接依然是OK的。若是咱們沒有收到對端keepalive探測包的回覆消息,咱們即可以判定鏈接已經不可用,進而採起一些措施。但Keepalive會額外產生一些網絡數據包外,這些包將加大網絡流量,對路由器和防火牆形成必定的負擔。java
# cat /proc/sys/net/ipv4/tcp_keepalive_time 7200 # cat /proc/sys/net/ipv4/tcp_keepalive_intvl 75 # cat /proc/sys/net/ipv4/tcp_keepalive_probes 9
tcp_keepalive_time,在TCP保活打開的狀況下,若是在該時間內沒有數據往來,則發送探測包。即容許的持續空閒時長,或者說每次正常發送心跳的週期,默認值爲7200s(2h)。
tcp_keepalive_probes 嘗試探測的次數。若是發送的探測包次數超過該值仍然沒有收到對方響應,則認爲鏈接已失效並關閉鏈接。默認值爲9(次)
tcp_keepalive_intvl,探測包發送間隔時間。默認值爲75s。linux
如基於netty 4服務器程序安全
serverBootstrap.option(ChannelOption.SO_KEEPALIVE, true);
TCP鏈接被中間設備斷開,客戶端和服務端對此是得不到通知的。長鏈接的環境下,如IM服務,若某鏈接長時間沒有數據交換,可能被丟棄。那一旦有數據須要傳遞,且此時鏈接已經被中介設備斷開,應用程序沒有及時感知的話,那麼就會致使在一個無效的數據鏈路層面發送業務數據,結果就是發送失敗。服務器
在三層地址轉換中,咱們能夠保證局域網內主機向公網發出的IP報文能順利到達目的主機,可是從目的主機返回的IP報文卻不能準確送至指定局域網主機(咱們不能讓網關把IP報文廣播至所有局域網主機,由於這樣必然會帶來安全和性能問題)。爲了解決這個問題,網關路由器須要藉助傳輸層端口,一般狀況下是TCP或UDP端口,由此來生成一張傳輸層端口轉換表。
因爲端口數量有限(0~65535),端口轉換表的維護佔用系統資源,所以不能無休止地向端口轉換表中增長記錄。對於過時的記錄,網關須要將其刪除。如何判斷哪些是過時記錄?網關認爲,一段時間內無活動的鏈接是過時的,應定時檢測轉換表中的非活動鏈接,並將之丟棄。
更多參考:https://blog.chionlab.moe/201...網絡
在 HTTP 1.0 時期,每一個 TCP 鏈接只會被一個 HTTP Transaction(請求加響應)使用,請求時創建,請求完成釋放鏈接。當網頁內容愈來愈複雜,包含大量圖片、CSS 等資源以後,這種模式效率就顯得過低了。因此,在 HTTP 1.1 中,引入了 HTTP persistent connection 的概念,也稱爲 HTTP keep-alive,目的是複用TCP鏈接,在一個TCP鏈接上進行屢次的HTTP請求從而提升性能。tcp
HTTP1.0中默認是關閉的,須要在HTTP頭加入"Connection: Keep-Alive",才能啓用Keep-Alive;HTTP1.1中默認啓用Keep-Alive,加入"Connection: close ",才關閉。性能
二者在寫法上不一樣,http keep-alive 中間有個"-"符號。
HTTP協議的keep-alive 意圖在於鏈接複用,同一個鏈接上串行方式傳遞請求-響應數據
TCP的keepalive機制意圖在於保活、心跳,檢測鏈接錯誤。.net
鏈接池技術做爲建立和管理鏈接的緩衝池技術,減小建立和銷燬鏈接的開銷,是對多個鏈接的生命週期管理。keep-alive強調的是一個http鏈接自己的複用機制。netty
本文重點梳理了TCP keep alive概念和原理,並與http keep-alive對比區別,又引伸出http鏈接池與keep-alive的關係,幫助理清基礎概念。
https://blog.chionlab.moe/201...
http://time-track.cn/tcp-keep...
http://www.blogjava.net/yongb...
http://www.cnblogs.com/zhanji...