socket之tcp如何維護長連接

 

 2.tcp長連接、心跳包

 1.TCP長連接與心跳保活

======

 2.tcp長連接、心跳包

長連接

TCP經過三次握手建立連接，長連接是指不管有無數據包的發送都長期保持建立的連接；
有長連接自然也有短連接，短連接是指雙方有數據發送時，就建立連接，發送幾次請求后，就主動或者被動斷開連接。

心跳

心跳是用來檢測一個系統是否存活或者網絡鏈路是否通暢的一種方式，做法是定時向被檢測系統發送心跳包，被檢測系統收到心跳包進行回復，收到回復說明對方存活。心跳能夠給長連接提供保活功能，能夠檢測長連接是否正常，一旦鏈路死了，不可用了，能夠盡快知道，然后做些其他的高可用措施，來保證系統的正常運行。

長連接的優勢

• 減少連接建立過程的耗時
  TCP連接建立需要三次握手，三次握手也就說需要三次交互才能建立一個連接通道，同城的機器之間的大概是ms級別的延時，影響還不大，如果是北京和上海兩地機房，走專線一來一回大概需要30ms，如果使用長連接，這個優化還是十分可觀的。

• 方便實現push數據
  數據交互－推模式實現的前提是網絡長連接，有了長連接，連接兩端很方便的互相push數據，來進行交互。

長連接保活

操作系統實現：
TCP的KeepAlive機制（此機制並不是TCP協議規范中的內容，由操作系統去實現）KeepAlive機制開啟后，在一定時間內（一般時間為7200s，參數tcp_keepalive_time）在鏈路上沒有數據傳送的情況下，TCP層將發送相應的KeepAlive探針以確定連接可用性，探測失敗后重試10（參數tcp_keepalive_probes）次，每次間隔時間75s（參數tcp_keepalive_intvl），所有探測失敗后，才認為當前連接已經不可用。這些參數是機器級別，可以調整。KeepAlive的保活機制只在鏈路空閑的情況下才會起到作用。

一個可靠的系統，長連接的保活肯定是要依賴應用層的心跳來保證的。

應用層實現：
如果客戶端已經消失而連接未斷開，則會使得服務器上保留一個半開放的連接，而服務器又在等待來自客戶端的數據，此時服務器將永遠等待客戶端的數據。保活功能就是試圖在服務端器端檢測到這種半開放的連接。

如果一個給定的連接在兩小時內沒有任何動作，服務器就向客戶發送一個探測報文段，根據客戶端主機響應探測4個客戶端狀態：

• 客戶主機依然正常運行，且服務器可達。此時客戶的TCP響應正常，服務器將保活定時器復位。
• 客戶主機已經崩潰，並且關閉或者正在重新啟動。上述情況下客戶端都不能響應TCP。服務端將無法收到客戶端對探測的響應。服務器總共發送10個這樣的探測，每個間隔75秒。若服務器沒有收到任何一個響應，它就認為客戶端已經關閉並終止連接。
• 客戶端崩潰並已經重新啟動。服務器將收到一個對其保活探測的響應，這個響應是一個復位，使得服務器終止這個連接。
• 客戶機正常運行，但是服務器不可達。這種情況與第二種狀態類似。

心跳包使用

方案一
最簡單的策略當然是客戶端定時n秒發送心跳包，服務端收到心跳包后，回復客戶端的心跳，如果客戶端連續m秒沒有收到心跳包，則主動斷開連接，然后重連，將正常的業務請求暫時不發送的該台服務器上。

方案二
這樣傳送一些無效的數據包有點多，可以做些優化。因為心跳就是一種探測請求，業務上的正常請求除了做業務處理外，還可以用作探測的功能，比如此時有請求需要發送到服務端，這個請求就可以當作是一次心跳，服務端收到請求，處理后回復，只要服務端有回復，就表明鏈路還是通的，如果客戶端請求比較空閑的時候，服務端一直沒有數據回復，就使用心跳進行探測，這樣就有效利用了正常的請求來作為心跳的功能，減少無效的數據傳輸。

----

1.TCP長連接與心跳保活

可能很多 Java 程序員對 TCP 的理解只有一個三次握手，四次握手的認識，我覺得這樣的原因主要在於 TCP 協議本身稍微有點抽象(相比較於應用層的 HTTP 協議)。

前言

可能很多 Java 程序員對 TCP 的理解只有一個三次握手，四次握手的認識，我覺得這樣的原因主要在於 TCP 協議本身稍微有點抽象(相比較於應用層的 HTTP 協議);其次，非框架開發者不太需要接觸到 TCP 的一些細節。其實我個人對 TCP 的很多細節也並沒有完全理解，這篇文章主要針對微信交流群里有人提出的長連接，心跳的問題，做一個統一的整理。

 

在 Java 中，使用 TCP 通信，大概率會涉及到 Socket、Netty，本文會借用它們的一些 API 和設置參數來輔助介紹。

長連接與短連接

TCP 本身並沒有長短連接的區別，長短與否，完全取決於我們怎么用它。

• 短連接：每次通信時，創建 Socket;一次通信結束，調用 socket.close()。這就是一般意義上的短連接，短連接的好處是管理起來比較簡單，存在的連接都是可用的連接，不需要額外的控制手段。
• 長連接：每次通信完畢后，不會關閉連接，這樣就可以做到連接的復用。長連接的好處便是省去了創建連接的耗時。

短連接和長連接的優勢，分別是對方的劣勢。想要圖簡單，不追求高性能，使用短連接合適，這樣我們就不需要操心連接狀態的管理;想要追求性能，使用長連接，我們就需要擔心各種問題：比如端對端連接的維護，連接的保活。

長連接還常常被用來做數據的推送，我們大多數時候對通信的認知還是 request/response 模型，但 TCP 雙工通信的性質決定了它還可以被用來做雙向通信。在長連接之下，可以很方便的實現 push 模型。

短連接沒有太多東西可以講，所以下文我們將目光聚焦在長連接的一些問題上。純講理論未免有些過於單調，所以下文我借助 Dubbo 這個 RPC 框架的一些實踐來展開 TCP 的相關討論。

服務治理框架中的長連接

前面已經提到過，追求性能的時候，必然會選擇使用長連接，所以借助 Dubbo 可以很好的來理解 TCP。我們開啟兩個 Dubbo 應用，一個 server 負責監聽本地 20880(眾所周知，這是 Dubbo 協議默認的端口)，一個 client 負責循環發送請求。執行lsof -i:20880命令可以查看端口的相關使用情況：

 

image.png

• *:20880 (LISTEN)說明了 Dubbo 正在監聽本地的 20880 端口，處理發送到本地 20880 端口的請求
• 后兩條信息說明請求的發送情況，驗證了 TCP 是一個雙向的通信過程，由於我是在同一個機器開啟了兩個 Dubbo 應用，所以你能夠看到是本地的 53078 端口與 20880 端口在通信。我們並沒有手動設置 53078 這個客戶端端口，他是隨機的，但也闡釋了一個道理：即使是發送請求的一方，也需要占用一個端口。
• 稍微說一下 FD 這個參數，他代表了文件句柄，每新增一條連接都會占用新的文件句柄，如果你在使用 TCP 通信的過程中出現了open too many files的異常，那就應該檢查一下，你是不是創建了太多的連接，而沒有關閉。細心的讀者也會聯想到長連接的另一個好處，那就是會占用較少的文件句柄。

長連接的維護

因為客戶端請求的服務可能分布在多個服務器上，客戶端端自然需要跟對端創建多條長連接，使用長連接，我們遇到的第一個問題就是要如何維護長連接。

@Sharable public class NettyHandler extends SimpleChannelHandler { private final Map<String, Channel> channels = new ConcurrentHashMap<String, Channel>(); // <ip:port, channel> } public class NettyServer extends AbstractServer implements Server { private Map<String, Channel> channels; // <ip:port, channel> } 

在 Dubbo 中，客戶端和服務端都使用ip:port維護了端對端的長連接，Channel 便是對連接的抽象。我們主要關注 NettyHandler 中的長連接，服務端同時維護一個長連接的集合是 Dubbo 的設計，我們將在后面提到。

連接的保活

這個話題就有的聊了，會牽扯到比較多的知識點。首先需要明確一點，為什么需要連接的報活?當雙方已經建立了連接，但因為網絡問題，鏈路不通，這樣長連接就不能使用了。需要明確的一點是，通過 netstat，lsof 等指令查看到連接的狀態處於ESTABLISHED狀態並不是一件非常靠譜的事，因為連接可能已死，但沒有被系統感知到，更不用提假死這種疑難雜症了。如果保證長連接可用是一件技術活。

連接的保活：KeepAlive

首先想到的是 TCP 中的 KeepAlive 機制。KeepAlive 並不是 TCP 協議的一部分，但是大多數操作系統都實現了這個機制。KeepAlive 機制開啟后，在一定時間內(一般時間為 7200s，參數tcp_keepalive_time)在鏈路上沒有數據傳送的情況下，TCP 層將發送相應的KeepAlive探針以確定連接可用性，探測失敗后重試 10(參數tcp_keepalive_probes)次，每次間隔時間 75s(參數tcp_keepalive_intvl)，所有探測失敗后，才認為當前連接已經不可用。

在 Netty 中開啟 KeepAlive：

bootstrap.option(ChannelOption.SO_KEEPALIVE, true)

Linux 操作系統中設置 KeepAlive 相關參數，修改/etc/sysctl.conf文件：

net.ipv4.tcp_keepalive_time=90  
net.ipv4.tcp_keepalive_intvl=15  
net.ipv4.tcp_keepalive_probes=2 

KeepAlive 機制是在網絡層面保證了連接的可用性，但站在應用框架層面我們認為這還不夠。主要體現在兩個方面：

• KeepAlive 的開關是在應用層開啟的，但是具體參數(如重試測試，重試間隔時間)的設置卻是操作系統級別的，位於操作系統的/etc/sysctl.conf配置中，這對於應用來說不夠靈活。
• KeepAlive 的保活機制只在鏈路空閑的情況下才會起到作用，假如此時有數據發送，且物理鏈路已經不通，操作系統這邊的鏈路狀態還是 ESTABLISHED，這時會發生什么?自然會走 TCP 重傳機制，要知道默認的 TCP 超時重傳，指數退避算法也是一個相當長的過程。
• KeepAlive 本身是面向網絡的，並不是面向於應用的，當連接不可用時，可能是由於應用本身 GC 問題，系統 load 高等情況，但網絡仍然是通的，此時，應用已經失去了活性，所以連接自然應該認為是不可用的。

看來，應用層面的連接保活還是必須要做的。

連接的保活：應用層心跳

終於點題了，文題中提到的心跳便是一個本文想要重點強調的另一個 TCP 相關的知識點。上一節我們已經解釋過了，網絡層面的 KeepAlive 不足以支撐應用級別的連接可用性，本節就來聊聊應用層的心跳機制是實現連接保活的。

如何理解應用層的心跳?簡單來說，就是客戶端會開啟一個定時任務，定時對已經建立連接的對端應用發送請求(這里的請求是特殊的心跳請求)，服務端則需要特殊處理該請求，返回響應。如果心跳持續多次沒有收到響應，客戶端會認為連接不可用，主動斷開連接。不同的服務治理框架對心跳，建連，斷連，拉黑的機制有不同的策略，但大多數的服務治理框架都會在應用層做心跳，Dubbo 也不例外。

應用層心跳的設計細節

以 Dubbo 為例，支持應用層的心跳，客戶端和服務端都會開啟一個HeartBeatTask，客戶端在HeaderExchangeClient中開啟，服務端將在HeaderExchangeServer開啟。文章開頭埋了一個坑：Dubbo 為什么在服務端同時維護Map呢?主要就是為了給心跳做貢獻，心跳定時任務在發現連接不可用時，會根據當前是客戶端還是服務端走不同的分支，客戶端發現不可用，是重連;服務端發現不可用，是直接 close。

// HeartBeatTask if (channel instanceof Client) { ((Client) channel).reconnect(); } else { channel.close(); } 

熟悉其他 RPC 框架的同學會發現，不同框架的心跳機制真的是差距非常大。心跳設計還跟連接創建，重連機制，黑名單連接相關，還需要具體框架具體分析。

除了定時任務的設計，還需要在協議層面支持心跳。最簡單的例子可以參考 nginx 的健康檢查，而針對 Dubbo 協議，自然也需要做心跳的支持，如果將心跳請求識別為正常流量，會造成服務端的壓力問題，干擾限流等諸多問題。

 

image.png

dubbo protocol

其中 Flag 代表了 Dubbo 協議的標志位，一共 8 個地址位。低四位用來表示消息體數據用的序列化工具的類型(默認 hessian)，高四位中，第一位為1表示是 request 請求，第二位為 1 表示雙向傳輸(即有返回response)，第三位為 1 表示是心跳事件。

心跳請求應當和普通請求區別對待。

注意和 HTTP 的 KeepAlive 區別對待

• HTTP 協議的 KeepAlive 意圖在於連接復用，同一個連接上串行方式傳遞請求-響應數據
• TCP 的 KeepAlive 機制意圖在於保活、心跳，檢測連接錯誤。

這壓根是兩個概念。

KeepAlive 常見錯誤

啟用 TCP KeepAlive 的應用程序，一般可以捕獲到下面幾種類型錯誤

1. ETIMEOUT 超時錯誤，在發送一個探測保護包經過 (tcp_keepalive_time + tcp_keepalive_intvl * tcp_keepalive_probes)時間后仍然沒有接收到 ACK 確認情況下觸發的異常，套接字被關閉
2. java.io.IOException: Connection timed out
3. EHOSTUNREACH host unreachable(主機不可達)錯誤，這個應該是 ICMP 匯報給上層應用的。
4. java.io.IOException: No route to host
5. 鏈接被重置，終端可能崩潰死機重啟之后，接收到來自服務器的報文，然物是人非，前朝往事，只能報以無奈重置宣告之。
6. java.io.IOException: Connection reset by peer

總結

有三種使用 KeepAlive 的實踐方案：

默認情況下使用 KeepAlive 周期為 2 個小時，如不選擇更改，屬於誤用范疇，造成資源浪費：內核會為每一個連接都打開一個保活計時器，N 個連接會打開 N 個保活計時器。 優勢很明顯：

• TCP 協議層面保活探測機制，系統內核完全替上層應用自動給做好了
• 內核層面計時器相比上層應用，更為高效
• 上層應用只需要處理數據收發、連接異常通知即可
• 數據包將更為緊湊

1. 關閉 TCP 的 KeepAlive，完全使用應用層心跳保活機制。由應用掌管心跳，更靈活可控，比如可以在應用級別設置心跳周期，適配私有協議。
2. 業務心跳 + TCP KeepAlive 一起使用，互相作為補充，但 TCP 保活探測周期和應用的心跳周期要協調，以互補方可，不能夠差距過大，否則將達不到設想的效果。

各個框架的設計都有所不同，例如 Dubbo 使用的是方案三，但阿里內部的 HSF 框架則沒有設置 TCP 的 KeepAlive，僅僅由應用心跳保活。和心跳策略一樣，這和框架整體的設計相關。

 

以上文章轉自： https://www.cnblogs.com/awkflf11/p/12622274.html