參考：https://blog.csdn.net/qq826654664jx/article/details/100864080
參考：https://blog.csdn.net/weixin_37672169/article/details/80283935
什么是 Keep-Alive
這個詞看着有點熟，很多地方好像都見過。
TCP 的 KeepAlive，Http 的 KeepAlive，現在就連一些前端框架都有類似 KeepAlive 的東西了（比如 VUE.js，保持路由）。
本文介紹 HTTP 和 TCP 中的 KeepAlive 機制，其他方面不在本文討論范圍。
Http 中的 Keep-Alive
HTTP 持久連接（HTTP persistent connection，也稱作 HTTP keep-alive 或 HTTP connection reuse，翻譯過來可以是保持連接或者連接復用）是使用同一個 TCP 連接來發送和接收多個 HTTP 請求 / 應答，而不是為每一個新的請求 / 應答打開新的連接的方式。
HTTP 協議采用 “請求 - 應答” 模式，當使用普通模式，即非 KeepAlive 模式時，每個請求 / 應答客戶和服務器都要新建一個連接，完成 之后立即斷開連接（HTTP 協議為無連接的協議），每次請求都會經過三次握手四次揮手過程，效率較低；當使用Keep-Alive模式時，客戶端到服務器端的連接不會斷開，當出現對服務器的后繼請求時，客戶端就會復用已建立的連接。
下圖是每次新建連接和連接復用在通信模型上的區別：
在 Http 1.0 中，Keep-Alive是沒有官方支持的，但是也有一些 Server 端支持，這個年代比較久遠就不用考慮了。
Http1.1 以后，Keep-Alive已經默認支持並開啟。客戶端（包括但不限於瀏覽器）發送請求時會在 Header 中增加一個請求頭Connection: Keep-Alive，當服務器收到附帶有Connection: Keep-Alive的請求時，也會在響應頭中添加 Keep-Alive。這樣一來，客戶端和服務器之間的 HTTP 連接就會被保持，不會斷開（斷開方式下面介紹），當客戶端發送另外一個請求時，就可以復用已建立的連接。
現在的 Http 協議基本都是 Http 1.1 版本了，不太需要考慮 1.0 的兼容問題
Keep-Alive 真的就這么完美嗎
當然不是，Keep-Alive 也有自己的優缺點，並不是所有場景下都適用
優點
- 節省了服務端 CPU 和內存適用量
- 降低擁塞控制 （TCP 連接減少）
- 減少了后續請求的延遲（無需再進行握手）
缺點
對於某些低頻訪問的資源 / 服務，比如一個冷門的圖片服務器，一年下不了幾次，每下一次連接還保持就比較浪費了（這個場景舉的不是很恰當）。Keep-Alive 可能會非常影響性能，因為它在文件被請求之后還保持了不必要的連接很長時間，額外占用了服務端的連接數。
連接復用后會有什么問題
在沒有連接復用時，Http 接收端（注意這里是接收端，並沒有特指 Client/Server，因為 Client/Server 都同是發送端和接收端）只需要讀取 Socket 中所有的數據就可以了，解決 “拆包” 問題即可；但是連接復用后，無法區分單次 Http 報文的邊界，所以還需要額外處理報文邊界問題。當然這個通過 Http 中 Header 的長度字段，按需讀取即可解決。
粘包拆包的介紹可以參考另一篇文章細說 Netty 中的粘包和拆包
Http 連接復用后包邊界問題處理
由於 Http 中 Header 的存在，通過定義一些報文長度的首部字段，可以很方便的處理包邊界問題。
在 Http 中，有兩種方式處理包邊界問題：
Content-Length 處理包邊界
這個是最通常的處理方式，接收端處理報文時首先讀取完整首部（Header），然后通過 Header 中的Content-Length來確認報文大小，讀取報文時按此長度讀取即可，超出長度的報文（“粘包”）不讀取，不夠長度的報文緩存等待繼續讀取（“拆包”）。
Chunked 處理包邊界
對於無法確認總報文大小的情況，可以使用 Chunked 的方式來對報文進行分塊傳輸，每一塊內標示報文大小。比如 Nginx，開啟 Gzip 壓縮后，就會開啟 Chunked 的傳輸方式。
通過 Wireshark 抓包，可以很直觀的看初 Chunked 的原理：
注意，這里的 chunk 包，和 tcp segment 不是一回事，chunk 只是應用層的一個分包，而 tcp 的 segment 是對應用層報文再次進行分組
每個 chunk 報文前，會攜帶當前 chunk 的大小。
Http 連接復用后怎樣斷開連接
通過 Keep-Alive 已經做到連接復用了，但復用之后什么時候斷開連接呢，不然一直保持連接，造成資源的浪費。
Http 協議規定了兩種關閉復用連接的方式：
通過 Keep-Alive Timeout 標識
如果服務端 Response Header 設置了Keep-Alive:timeout={timeout}，客戶端會就會保持此連接 timeout（單位秒）時間，超時之后關閉連接。
現在在服務端設置響應 Header:
Keep-Alive:timeout=5
通過 Wireshark 來看下配置了 timeout 的效果：
從上圖可以看出，客戶端發送請求后，在 15S 內（圖上沒有體現時間，就當 15S 吧）保持了連接不銷毀，超時后經過了 4 次揮手，斷開連接
但是如果在 15S 內再次請求，連接是可以復用的，不會重新 3 次握手。
下圖是 15S 內再次請求的效果：
通過 Connection close 標識
還有一種方式是接收端通在 Response Header 中增加Connection close標識，來主動告訴發送端，連接已經斷開了，不能再復用了；客戶端接收到此標示后，會銷毀連接，再次請求時會重新建立連接。
注意：配置 close 配置后，並不是說每次都新建連接，而是約定此連接可以用幾次，達到這個最大次數時，接收端就會返回 close 標識（服務端配置方法下面會介紹）
下面來測試下效果，客戶端發送兩次請求：
通過 wireshark 截圖可以發現，配置了 Connection:close 之后 (服務端設置了請求只可以用 1 此，所所以請求完成就銷毀連接)，兩次請求都重新建立了連接。
Nginx 中設置 Keep-Alive（服務端）
Keep-Alive timeout 配置:
Syntax: keepalive_timeout timeout [header_timeout]; Default: keepalive_timeout 75s; Context: http, server, location 第一個參數設置一個超時，在此期間保持活動的客戶機連接將在服務器端保持打開狀態。如果為0則禁用保Keep-Alive。第二個可選參數在“Keep-Alive: timeout=time”響應頭字段中設置一個值。 “Keep-Alive: timeout=time”報頭字段被Mozilla和Konqueror識別。MSIE在大約60秒內自動關閉保持連接。
Keep-Alive requests（連接可用次數）配置：
Syntax: keepalive_requests number; Default: keepalive_requests 100; Context: http, server, location 設置通過一個保持活動連接可以服務的請求的最大數量。在發出最大數量的請求之后，連接關閉。
Tomcat 中設置 Keep-Alive（服務端）
在<Connector>標簽中配置屬性：
Keep-Alive timeout 配置:
keepAliveTimeout="超時時間"，默認值是使用為 connectionTimeout 屬性設置的值 。值為 - 1 表示沒有（即無限）超時。
Keep-Alive requests（連接可用次數）配置：
maxKeepAliveRequests="連接可用次數"，-1 為永不失效。如果未指定，默認為 100。
例如：
<Connector port="8080"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
keepAliveTimeout="超時時間（單位秒）"
maxKeepAliveRequests="連接可用次數" />
Apache HttpClient 設置 Keep-Alive（客戶端）
Apache HttpClient 算是 Java 中最強的 HttpClient 了，也是最主流的（后端方向），功能強大。
Apache HttpClient 在處理 KeepAlive 的地方設計的比較靈活，提供了可配置的接口，使用者可以使用 Http 標准的策略，也自定定制策略。
1 HttpClients.custom() 2 //連接是否復用策略，通過此策略返回是否復用 3 //DefaultClientConnectionReuseStrategy是默認的Http策略，不設置也可以 4 .setConnectionReuseStrategy(new DefaultClientConnectionReuseStrategy()) 5 //連接復用后有效期（持久時間）策略，復用后通過此策略判斷復用超時時間 6 //DefaultConnectionKeepAliveStrategy是默認的判斷超時時間策略，讀取的是Keep-Alive:timeout=超時時間 7 .setKeepAliveStrategy(new DefaultConnectionKeepAliveStrategy()) 8 .build();
這里順帶說一下 Apache HttpClient 的使用，希望能幫助到有需要的人。（版本 Apache HttpClient 4.x）
1 //創建客戶端，此客戶端最好保持單例，這是個線程安全的類，並發下也沒有問題。 2 //HttpClient中的連接池等組件都包含在內，如果每次都新建的話， 3 //效率低，占用資源大，連接復用當然也不會生效了。 4 HttpClients.custom() 5 //禁用自動重試，默認有3次的重試策略 6 .disableAutomaticRetries() 7 //不用默認的重試策略，自定義 8 .setRetryHandler() 9 //設置默認請求配置，這里可以配置一些超時時間等參數 10 .setDefaultRequestConfig(requestConfig()) 11 //全局Header，每次請求都會攜帶 12 .setDefaultHeaders() 13 //當Https證書不受信任的時候，記得自定義此項 14 .setSSLHostnameVerifier() 15 //設置UA 16 .setUserAgent() 17 //設置代理 18 .setProxy() 19 //...還有很多配置，可以自行查閱文檔 20 .build();
TCP 中的 Keep-Alive
TCP 中的 KeepAlive 和 Http 的 Keep-Alive 可不是一回事，HTTP 中是做連接復用的，而 TCP 中的 KeepAlive 是 “心跳監測”，定時發送一個空的 TCP Segment，來監測連接是否存活。下面介紹下 Java 中設置 TCP KeepAive 的一些方式。
Netty 中設置 Keep-Alive
1 bootstrap.childOption(ChannelOption.SO_KEEPALIVE, true);
NIO（New NetWorking IO Lib）中設置 Keep-Alive
1 channel.setOption(StandardSocketOptions.SO_KEEPALIVE,true);
BIO 中設置 Keep-Alive
1 Socket socket = serverSocket.accept(); 2 socket.setKeepAlive(true);
HTTP和TCP的Keep-Alive timeout區別
Keep-Alive timeout：
Httpd守護進程，一般都提供了keep-alive timeout時間設置參數。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。這個keepalive_timout時間值意味着：一個http產生的tcp連接在傳送完最后一個響應后，還需要hold住keepalive_timeout秒后，才開始關閉這個連接。
當httpd守護進程發送完一個響應后，理應馬上主動關閉相應的tcp連接，設置 keepalive_timeout后，httpd守護進程會想說：”再等等吧，看看瀏覽器還有沒有請求過來”，這一等，便是keepalive_timeout時間。如果守護進程在這個等待的時間里，一直沒有收到瀏覽器發過來http請求，則關閉這個http連接。
Tcp的Keepalive：
連接建立之后，如果客戶端一直不發送數據，或者隔很長時間才發送一次數據，當連接很久沒有數據報文傳輸時如何去確定對方還在線，到底是掉線了還是確實沒有數據傳輸，連接還需不需要保持，這種情況在TCP協議設計中是需要考慮到的。
TCP協議通過一種巧妙的方式去解決這個問題，當超過一段時間之后，TCP自動發送一個數據為空的報文（偵測包）給對方，如果對方回應了這個報文，說明對方還在線，連接可以繼續保持，如果對方沒有報文返回，並且重試了多次之后則認為鏈接丟失，沒有必要保持連接。
tcp keep-alive是TCP的一種檢測TCP連接狀況的保鮮機制。tcp keep-alive保鮮定時器，支持三個系統內核配置參數：
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 1800
keepalive是TCP保鮮定時器，當網絡兩端建立了TCP連接之后，閑置（雙方沒有任何數據流發送往來）了tcp_keepalive_time后，服務器就會嘗試向客戶端發送偵測包，來判斷TCP連接狀況(有可能客戶端崩潰、強制關閉了應用、主機不可達等等)。如果沒有收到對方的回答(ack包)，則會在 tcp_keepalive_intvl后再次嘗試發送偵測包，直到收到對方的ack,如果一直沒有收到對方的ack,一共會嘗試 tcp_keepalive_probes次，每次的間隔時間在這里分別是15s, 30s, 45s, 60s, 75s。如果嘗試tcp_keepalive_probes,依然沒有收到對方的ack包，則會丟棄該TCP連接。TCP連接默認閑置時間是2小時，一般設置為30分鍾足夠了。