短連接：每次通信時夸盟，創(chuàng)建 Socket；一次通信結(jié)束像捶，調(diào)用 socket.close()上陕。這就是一般意義上的短連接，短連接的好處是管理起來比較簡單拓春，存在的連接都是可用的連接释簿，不需要額外的控制手段。
長連接：每次通信完畢后硼莽，不會關閉連接庶溶，這樣就可以做到連接的復用。長連接的好處便是省去了創(chuàng)建連接的耗時懂鸵。
連接的逼荩活：KeepAlive
首先想到的是 TCP 中的 KeepAlive 機制。KeepAlive 并不是 TCP 協(xié)議的一部分匆光，但是大多數(shù)操作系統(tǒng)都實現(xiàn)了這個機制套像。KeepAlive 機制開啟后，在一定時間內(nèi)（一般時間為 7200s终息，參數(shù)tcp_keepalive_time）在鏈路上沒有數(shù)據(jù)傳送的情況下夺巩，TCP 層將發(fā)送相應的KeepAlive探針以確定連接可用性，探測失敗后重試 10（參數(shù)tcp_keepalive_probes）次周崭，每次間隔時間 75s（參數(shù)tcp_keepalive_intvl）柳譬，所有探測失敗后，才認為當前連接已經(jīng)不可用续镇。
KeepAlive 機制是在網(wǎng)絡層面保證了連接的可用性美澳，但站在應用框架層面我們認為這還不夠。主要體現(xiàn)在兩個方面：
KeepAlive 的開關是在應用層開啟的，但是具體參數(shù)（如重試測試人柿，重試間隔時間）的設置卻是操作系統(tǒng)級別的柴墩，位于操作系統(tǒng)的/etc/sysctl.conf配置中，這對于應用來說不夠靈活凫岖。
KeepAlive 的苯龋活機制只在鏈路空閑的情況下才會起到作用，假如此時有數(shù)據(jù)發(fā)送哥放，且物理鏈路已經(jīng)不通歼指，操作系統(tǒng)這邊的鏈路狀態(tài)還是 ESTABLISHED，這時會發(fā)生什么甥雕？自然會走 TCP 重傳機制踩身，要知道默認的 TCP 超時重傳，指數(shù)退避算法也是一個相當長的過程社露。
KeepAlive 本身是面向網(wǎng)絡的挟阻，并不是面向于應用的，當連接不可用時峭弟，可能是由于應用本身 GC 問題附鸽，系統(tǒng) load 高等情況，但網(wǎng)絡仍然是通的瞒瘸，此時坷备，應用已經(jīng)失去了活性，所以連接自然應該認為是不可用的情臭。
看來省撑，應用層面的連接保活還是必須要做的俯在。
連接的本癸活：應用層心跳
如何理解應用層的心跳？簡單來說跷乐，就是客戶端會開啟一個定時任務肥败，定時對已經(jīng)建立連接的對端應用發(fā)送請求（這里的請求是特殊的心跳請求），服務端則需要特殊處理該請求劈猿，返回響應。如果心跳持續(xù)多次沒有收到響應潮孽，客戶端會認為連接不可用揪荣，主動斷開連接。不同的服務治理框架對心跳往史，建連仗颈，斷連，拉黑的機制有不同的策略，但大多數(shù)的服務治理框架都會在應用層做心跳挨决，Dubbo 也不例外请祖。
TCP和 HTTP 的 KeepAlive 區(qū)別對待
HTTP 協(xié)議的 KeepAlive 意圖在于連接復用，同一個連接上串行方式傳遞請求-響應數(shù)據(jù)
TCP 的 KeepAlive 機制意圖在于辈逼恚活肆捕、心跳，檢測連接錯誤盖高。
這壓根是兩個概念慎陵。
