參與項(xiàng)目中使用springcloud gateway，并結(jié)合nacos，做網(wǎng)關(guān)實(shí)現(xiàn)路由轉(zhuǎn)發(fā)以及負(fù)載均衡的功能。項(xiàng)目運(yùn)行一段時(shí)間后，出現(xiàn)springcloud gateway服務(wù)的TCP連接過(guò)多未釋放的問(wèn)題，針對(duì)此問(wèn)題，查閱相關(guān)資料，匯總TCP連接、Http Keep-Alive和Tcp Keepalive的基礎(chǔ)知識(shí)，并結(jié)合操作系統(tǒng)windows和linux對(duì)keepalive參數(shù)的設(shè)置問(wèn)題，最后落到部分常見(jiàn)的應(yīng)用服務(wù)對(duì)keepalive參數(shù)的配置上，并以此為基礎(chǔ)，實(shí)踐調(diào)整springcloud gateway設(shè)置keepalive參數(shù)并進(jìn)行了驗(yàn)證有效，其他有關(guān)操作系統(tǒng)以及Nginx與Tomcat的設(shè)置問(wèn)題，尚需后續(xù)實(shí)踐過(guò)程中進(jìn)行驗(yàn)證。于此進(jìn)行記錄，以便后續(xù)繼續(xù)研究與驗(yàn)證，也為后來(lái)者提供參考借鑒，文中不免疏漏之處，望讀者予以指正，不勝感激！

1.TCP連接介紹

為實(shí)現(xiàn)數(shù)據(jù)的可靠傳輸，TCP要在應(yīng)用進(jìn)程間建立傳輸連接。它是在兩個(gè)傳輸用戶之間建立一種邏輯聯(lián)系，使得通信雙方都確認(rèn)對(duì)方為自己的傳輸連接端點(diǎn)。

1.1 建立連接—三次握手

建立連接前，服務(wù)器端首先被動(dòng)打開其熟知的端口，對(duì)端口進(jìn)行偵聽(tīng)。當(dāng)客戶端要和服務(wù)器端建立連接時(shí)，發(fā)起一個(gè)主動(dòng)打開端口的請(qǐng)求（該端口一般為臨時(shí)端口）；然后進(jìn)入三次握手的過(guò)程。

圖片

第一次握手：建立連接時(shí)，客戶端發(fā)送SYN包(seq=x)到服務(wù)器，并進(jìn)入 SYN_SEND 狀態(tài)，等待服務(wù)器確認(rèn)；

第二次握手：服務(wù)器收到SYN包，必須確認(rèn)客戶的 SYN（ack=x+1），同時(shí)自己也發(fā)送一個(gè) SYN 包（seq=y），即 SYN+ACK 包，此時(shí)服務(wù)器進(jìn)入 SYN_RECV 狀態(tài)；

第三次握手：客戶端收到服務(wù)器的 SYN＋ACK 包，向服務(wù)器發(fā)送確認(rèn)包 ACK(ack=y+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入 ESTABLISHED 狀態(tài)，完成三次握手。

1.2 釋放連接—四次揮手

圖片

• 第一次揮手：Client發(fā)送一個(gè)FIN，用來(lái)關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入FIN_WAIT_1狀態(tài)。
• 第二次揮手：Server收到FIN后，發(fā)送一個(gè)ACK給Client，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同，一個(gè)FIN占用一個(gè)序號(hào)），Server進(jìn)入CLOSE_WAIT狀態(tài)。
• 第三次揮手：Server發(fā)送一個(gè)FIN，用來(lái)關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)。
• 第四次揮手：Client收到FIN后，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)ACK給Server，確認(rèn)序號(hào)為收到序號(hào)+1， Server進(jìn)入CLOSED狀態(tài)，完成四次揮手。

此時(shí)TCP連接還沒(méi)有釋放掉，必須經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間2MSL后，Client才進(jìn)入到連接關(guān)閉狀態(tài)。

說(shuō)明：

2MSL即兩倍的MSL，TCP的TIME_WAIT狀態(tài)也稱為2MSL等待狀態(tài)，當(dāng)TCP的一端發(fā)起主動(dòng)關(guān)閉，在發(fā)出最后一個(gè)ACK包后,即第3次握手完成后發(fā)送了第四次握手的ACK包后就進(jìn)入了TIME_WAIT狀態(tài)，必須在此狀態(tài)上停留兩倍的MSL時(shí)間，等待2MSL時(shí)間主要目的是怕最后一個(gè)ACK包對(duì)方?jīng)]收到，那么對(duì)方在超時(shí)后將重發(fā)第三次握手的FIN包，主動(dòng)關(guān)閉端接到重發(fā)的FIN包后可以再發(fā)一個(gè)ACK應(yīng)答包。在TIME_WAIT狀態(tài) 時(shí)兩端的端口不能使用，要等到2MSL時(shí)間結(jié)束才可繼續(xù)使用。當(dāng)連接處于2MSL等待階段時(shí)任何遲到的報(bào)文段都將被丟棄。不過(guò)在實(shí)際應(yīng)用中可以通過(guò)設(shè)置 SO_REUSEADDR選項(xiàng)達(dá)到不必等待2MSL時(shí)間結(jié)束再使用此端口。

如果有大量的連接，每次在連接、關(guān)閉時(shí)都要三次握手，四次揮手，會(huì)很明顯會(huì)造成性能低下。

2. KeepAlive與Keep-Alive介紹

TCP的KeepAlive和HTTP的Keep-Alive是完全不同的概念，不能混為一談。實(shí)際上HTTP的KeepAlive寫法是Keep-Alive，跟TCP的KeepAlive寫法上也有不同。

2.1 Http Keep-Alive

Http協(xié)議采用“請(qǐng)求-應(yīng)答”模式，當(dāng)使用普通模式，即非Keep-Alive模式時(shí)，每個(gè)請(qǐng)求/應(yīng)答，客戶端和服務(wù)器都要新建一個(gè)連接，完成之后立即斷開連接；當(dāng)使用Keep-Alive模式時(shí)，Keep-Alive功能使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對(duì)服務(wù)器的后繼請(qǐng)求時(shí)，Keep-Alive功能避免了建立或者重新建立連接。

http1.0中默認(rèn)是關(guān)閉的，需要在http頭加入”Connection: Keep-Alive”，才能啟用Keep-Alive；http 1.1中默認(rèn)啟用Keep-Alive，如果加入”Connection: close “才關(guān)閉。目前大部分瀏覽器都是用http1.1協(xié)議，也就是說(shuō)默認(rèn)都會(huì)發(fā)起Keep-Alive的連接請(qǐng)求了，所以是否能完成一個(gè)完整的Keep- Alive連接就看服務(wù)器設(shè)置情況。

開啟Keep-Alive的優(yōu)缺點(diǎn)：

? 優(yōu)點(diǎn)：Keep-Alive模式更加高效，因?yàn)楸苊饬诉B接建立和釋放的開銷。

? 缺點(diǎn)：長(zhǎng)時(shí)間的Tcp連接容易導(dǎo)致系統(tǒng)資源無(wú)效占用，浪費(fèi)系統(tǒng)資源。

2.2 Tcp KeepAlive

連接建立之后，如果客戶端一直不發(fā)送數(shù)據(jù)，或者隔很長(zhǎng)時(shí)間才發(fā)送一次數(shù)據(jù)，當(dāng)連接很久沒(méi)有數(shù)據(jù)報(bào)文傳輸時(shí)如何去確定對(duì)方還在線，到底是掉線了還是確實(shí)沒(méi)有數(shù)據(jù)傳輸，連接還需不需要保持，這種情況在TCP協(xié)議設(shè)計(jì)中是需要考慮到的。TCP協(xié)議通過(guò)一種巧妙的方式去解決這個(gè)問(wèn)題，當(dāng)超過(guò)一段時(shí)間之后，TCP自動(dòng)發(fā)送一個(gè)數(shù)據(jù)為空的報(bào)文（偵測(cè)包）給對(duì)方，如果對(duì)方回應(yīng)了這個(gè)報(bào)文，說(shuō)明對(duì)方還在線，連接可以繼續(xù)保持，如果對(duì)方?jīng)]有報(bào)文返回，并且重試了多次之后則認(rèn)為鏈接丟失，沒(méi)有必要保持連接。

tcp KeepAlive是TCP的一種檢測(cè)TCP連接狀況的保鮮機(jī)制。tcp KeepAlive保鮮定時(shí)器，支持三個(gè)系統(tǒng)內(nèi)核配置參數(shù)：

net.ipv4.tcp_keepalive_intvl = 15  
net.ipv4.tcp_keepalive_probes = 5  
net.ipv4.tcp_keepalive_time = 1800

KeepAlive是TCP保鮮定時(shí)器，當(dāng)網(wǎng)絡(luò)兩端建立了TCP連接之后，閑置（雙方?jīng)]有任何數(shù)據(jù)流發(fā)送往來(lái)）了tcp_keepalive_time后，服務(wù)器就會(huì)嘗試向客戶端發(fā)送偵測(cè)包，來(lái)判斷TCP連接狀況(有可能客戶端崩潰、強(qiáng)制關(guān)閉了應(yīng)用、主機(jī)不可達(dá)等等)。如果沒(méi)有收到對(duì)方的回答(ack包)，則會(huì)在 tcp_keepalive_intvl后再次嘗試發(fā)送偵測(cè)包，直到收到對(duì)方的ack,如果一直沒(méi)有收到對(duì)方的ack，一共會(huì)嘗試 tcp_keepalive_probes次，每次的間隔時(shí)間在這里分別是15s, 30s, 45s, 60s, 75s。如果嘗試tcp_keepalive_probes，依然沒(méi)有收到對(duì)方的ack包，則會(huì)丟棄該TCP連接。TCP連接默認(rèn)閑置時(shí)間是2小時(shí)，一般設(shè)置為30分鐘足夠了。

3.操作系統(tǒng)有關(guān)Keepalive參數(shù)設(shè)置

3.1 Linux系統(tǒng)

• tcp_keepalive_time 7200// 距離上次傳送數(shù)據(jù)多少時(shí)間未收到新報(bào)文判斷為開始檢測(cè)，單位秒，默認(rèn)7200s(沒(méi)必要頻繁，浪費(fèi)資源)。
• tcp_keepalive_intvl 75// 檢測(cè)開始每多少時(shí)間發(fā)送心跳包，單位秒，默認(rèn)75s。
• tcp_keepalive_probes 9// 發(fā)送幾次心跳包對(duì)方未響應(yīng)則close連接，默認(rèn)9次?？赏ㄟ^(guò)對(duì)下列對(duì)應(yīng)的配置文件進(jìn)行修改參數(shù)：/proc/sys/net/ipv4/tcp_keepalive_time/proc/sys/net/ipv4/tcp_keepalive_intvl/proc/sys/net/ipv4/tcp_keepalive_probes

3.2 Windows系統(tǒng)

• KeepAliveTimeKeepAliveTime的值控制系統(tǒng)嘗試驗(yàn)證空閑連接是否仍然完好的頻率。如果該連接在一段時(shí)間內(nèi)沒(méi)有活動(dòng)，那么系統(tǒng)會(huì)發(fā)送保持連接的信號(hào)，如果網(wǎng)絡(luò)正常并且接收方是活動(dòng)的，它就會(huì)響應(yīng)。如果需要對(duì)丟失接收方的情況敏感，也就是說(shuō)需要更快地發(fā)現(xiàn)是否丟失了接收方，請(qǐng)考慮減小該值。而如果長(zhǎng)期不活動(dòng)的空閑連接的出現(xiàn)次數(shù)較多，但丟失接收方的情況出現(xiàn)較少，那么可能需要增大該值以減少開銷。缺省情況下，如果空閑連接在7200000毫秒（2小時(shí)）內(nèi)沒(méi)有活動(dòng)，系統(tǒng)就會(huì)發(fā)送保持連接的消息。 通常建議把該值設(shè)為1800000毫秒，從而丟失的連接會(huì)在30分鐘內(nèi)被檢測(cè)到。具體操作：瀏覽至HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters注冊(cè)表子鍵，在Parameters子鍵下創(chuàng)建或修改名為KeepAliveTime的REG_DWORD值，為該值設(shè)置適當(dāng)?shù)暮撩霐?shù)。
• KeepAliveIntervalKeepAliveInterval的值表示未收到另一方對(duì)“保持連接”信號(hào)的響應(yīng)時(shí)，系統(tǒng)重復(fù)發(fā)送“保持連接”信號(hào)的頻率。在無(wú)任何響應(yīng)的情況下，連續(xù)發(fā)送“保持連接”信號(hào)的次數(shù)超過(guò)TcpMaxDataRetransmissions（下文將介紹）的值時(shí)，將放棄該連接。如果網(wǎng)絡(luò)環(huán)境較差，允許較長(zhǎng)的響應(yīng)時(shí)間，則考慮增大該值以減少開銷；如果需要盡快驗(yàn)證是否已丟失接收方，則考慮減小該值或TcpMaxDataRetransmissions值。缺省情況下，在未收到響應(yīng)而重新發(fā)送“保持連接”的信號(hào)之前，系統(tǒng)會(huì)等待1000毫秒（1秒），可以根據(jù)具體需求修改，具體操作：瀏覽至HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters注冊(cè)表子鍵，在Parameters子鍵下創(chuàng)建或修改名為KeepAliveInterval的REG_DWORD值，為該值設(shè)置適當(dāng)?shù)暮撩霐?shù)。

4.常用服務(wù)端配置Keepalive參數(shù)

4.1 Nginx設(shè)置Keepalive

當(dāng)使用nginx作為反向代理時(shí)，為了支持長(zhǎng)連接，需要做到兩點(diǎn)：

• 從client到nginx的連接是長(zhǎng)連接
• 從nginx到server的連接是長(zhǎng)連接

4.1.1 從 Client 到 Nginx 的連接是長(zhǎng)連接

http {
    # 客戶端連接的超時(shí)時(shí)間, 為 0 時(shí)禁用長(zhǎng)連接。 tcp連接在傳送完最后一個(gè)響應(yīng)后，還需要hold住 keepalive_timeout秒后仍沒(méi)有新的http請(qǐng)求，才開始關(guān)閉這個(gè)連接
    keepalive_timeout 120s;
    # 在一個(gè)長(zhǎng)連接上可以服務(wù)的最大請(qǐng)求數(shù)目, 當(dāng)達(dá)到最大請(qǐng)求數(shù)目且所有已有請(qǐng)求結(jié)束后, 連接被關(guān)閉, 默認(rèn)為 100, 即每個(gè)連接的最大請(qǐng)求數(shù)
    keepalive_request 10000;
  }

keepalive_requests：參數(shù)的真實(shí)含義，是指一個(gè)keepalive建立之后，nginx就會(huì)為這個(gè)連接設(shè)置一個(gè)計(jì)數(shù)器，記錄這個(gè)keep alive的長(zhǎng)連接上已經(jīng)接收并處理的客戶端請(qǐng)求的數(shù)量。如果達(dá)到這個(gè)參數(shù)設(shè)置的最大值時(shí)，則nginx會(huì)強(qiáng)行關(guān)閉這個(gè)長(zhǎng)連接，逼迫客戶端不得不重新建立新的長(zhǎng)連接。大多數(shù)情況下當(dāng)QPS(每秒請(qǐng)求數(shù))不是很高時(shí)，默認(rèn)值100湊合夠用。但是，對(duì)于一些QPS比較高（比如超過(guò)10000QPS，甚至達(dá)到30000,50000甚至更高) 的場(chǎng)景，默認(rèn)的100就顯得太低。簡(jiǎn)單計(jì)算一下，QPS=10000時(shí)，客戶端每秒發(fā)送10000個(gè)請(qǐng)求(通常建立有多個(gè)長(zhǎng)連接)，每個(gè)連接只能最多跑100次請(qǐng)求，意味著平均每秒鐘就會(huì)有100個(gè)長(zhǎng)連接因此被nginx關(guān)閉。同樣意味著為了保持QPS，客戶端不得不每秒中重新新建100個(gè)連接。因此，就會(huì)發(fā)現(xiàn)有大量的TIME_WAIT的socket連接(即使此時(shí)keep alive已經(jīng)在client和nginx之間生效)。因此對(duì)于QPS較高的場(chǎng)景，非常有必要加大這個(gè)參數(shù)，以避免出現(xiàn)大量連接被生成再拋棄的情況，減少TIME_WAIT。

4.1.2 從 Nginx 到 Server(upstream) 的長(zhǎng)連接

為了讓nginx和后端server（nginx稱為upstream）之間保持長(zhǎng)連接，典型設(shè)置如下：（默認(rèn)nginx訪問(wèn)后端都是用的短連接(HTTP1.0)，一個(gè)請(qǐng)求來(lái)了，Nginx 新開一個(gè)端口和后端建立連接，后端執(zhí)行完畢后主動(dòng)關(guān)閉該鏈接）

http {
    upstream  BACKEND {
        server   192.168.0.1：8080  weight=1 max_fails=2 fail_timeout=30s;
        server   192.168.0.2：8080  weight=1 max_fails=2 fail_timeout=30s;
        keepalive 300;        // 這個(gè)很重要！
    }
server {
        listen 8080 default_server;
        server_name "";
        location /  {
            proxy_pass http://BACKEND;
            proxy_http_version 1.1;         // 這兩個(gè)最好也設(shè)置
            proxy_set_header Connection "";
        }
    }
}

此處keepalive的含義不是開啟、關(guān)閉長(zhǎng)連接的開關(guān)；也不是用來(lái)設(shè)置超時(shí)的timeout；更不是設(shè)置長(zhǎng)連接池最大連接數(shù)。官方解釋：The connections parameter sets the maximum number of idle keepalive connections to upstream servers connections（設(shè)置到upstream服務(wù)器的空閑keepalive連接的最大數(shù)量） When this number is exceeded, the least recently used connections are closed. （當(dāng)這個(gè)數(shù)量被突破時(shí)，最近使用最少的連接將被關(guān)閉） It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open.（特別提醒：keepalive指令不會(huì)限制一個(gè)nginx worker進(jìn)程到upstream服務(wù)器連接的總數(shù)量）

keepalive: 這個(gè)參數(shù)是 nginx 連接后端的連接池中的最大空閑連接數(shù), 比如: 設(shè)置為 300; 如果 nginx 為了滿足請(qǐng)求的 qps; 創(chuàng)建了 1000 個(gè)連接的連接池, 這個(gè)時(shí)候只有 500 個(gè)請(qǐng)求過(guò)來(lái), 那么 1000- 500 = 500; 那么就會(huì)多出 500 個(gè)空閑的連接, 那么 500 > 300; 那么 nginx 就會(huì)根據(jù)這個(gè)配置; 斷開 200 個(gè)請(qǐng)求連接; 那么這個(gè)時(shí)候就只有 800 個(gè)連接的連接池, 如果下次過(guò)來(lái)了 1000 個(gè)請(qǐng)求, 那么 nginx 又會(huì)開始創(chuàng)建連接; 所有這個(gè)數(shù)值的配置要小心配置

4.1.3 Nginx出現(xiàn)大量TIME_WAIT的情況

1）導(dǎo)致 nginx端出現(xiàn)大量TIME_WAIT的情況有兩種：keepalive_requests設(shè)置比較小，高并發(fā)下超過(guò)此值后nginx會(huì)強(qiáng)制關(guān)閉和客戶端保持的keepalive長(zhǎng)連接；（主動(dòng)關(guān)閉連接后導(dǎo)致nginx出現(xiàn)TIME_WAIT）keepalive設(shè)置的比較小（空閑數(shù)太?。?，導(dǎo)致高并發(fā)下nginx會(huì)頻繁出現(xiàn)連接數(shù)震蕩（超過(guò)該值會(huì)關(guān)閉連接），不停的關(guān)閉、開啟和后端server保持的keepalive長(zhǎng)連接；

2）導(dǎo)致后端server端出現(xiàn)大量TIME_WAIT的情況：nginx沒(méi)有打開和后端的長(zhǎng)連接，即：沒(méi)有設(shè)置proxy_http_version 1.1;和proxy_set_header Connection “”;從而導(dǎo)致后端server每次關(guān)閉連接，高并發(fā)下就會(huì)出現(xiàn)server端出現(xiàn)大量TIME_WAIT

4.2 Tomcat設(shè)置Keepalive

瀏覽器在請(qǐng)求的頭部添加 Connection:Keep-Alive，以此告訴服務(wù)器 “我支持長(zhǎng)連接，你支持的話就和我建立長(zhǎng)連接吧”，而倘若服務(wù)器的確支持長(zhǎng)連接，那么就在響應(yīng)頭部添加“Connection:Keep-Alive”，從而告訴瀏覽器“我的確也支持，那我們建立長(zhǎng)連接吧”。服務(wù)器還可以通過(guò) Keep-Alive:timeout=10, max=100 的頭部告訴瀏覽器“我希望 10 秒算超時(shí)時(shí)間，最長(zhǎng)不能超過(guò) 100 秒”。

在 Tomcat 里是允許配置長(zhǎng)連接的，配置 conf/server.xml 文件，配置 Connector 節(jié)點(diǎn)，該節(jié)點(diǎn)負(fù)責(zé)控制瀏覽器與 Tomcat 的連接，其中與長(zhǎng)連接直接相關(guān)的有兩個(gè)屬性，它們分別是：keepAliveTimeout，它表示在 Connector 關(guān)閉連接前，Connector 為另外一個(gè)請(qǐng)求 Keep Alive 所等待的微妙數(shù)，默認(rèn)值和 connectionTimeout 一樣；另一個(gè)是 maxKeepAliveRequests，它表示 HTTP/1.0 Keep Alive 和 HTTP/1.1 Keep Alive / Pipeline 的最大請(qǐng)求數(shù)目，如果設(shè)置為 1，將會(huì)禁用掉 Keep Alive 和 Pipeline，如果設(shè)置為小于 0 的數(shù)，Keep Alive 的最大請(qǐng)求數(shù)將沒(méi)有限制。也就是說(shuō)在 Tomcat 里，默認(rèn)長(zhǎng)連接是打開的，當(dāng)我們想關(guān)閉長(zhǎng)連接時(shí)，只要將 maxKeepAliveRequests 設(shè)置為 1 就可以。

Tomcat在server.xml 中的Connector 元素中：

• ? keepAliveTimeout：?jiǎn)挝皇莔illiseconds，表示在下次請(qǐng)求過(guò)來(lái)之前，tomcat保持該連接多久。這就是說(shuō)假如客戶端不斷有請(qǐng)求過(guò)來(lái)，且未超過(guò)過(guò)期時(shí)間，則該連接將一直保持。
• ? maxKeepAliveRequests：最大長(zhǎng)連接個(gè)數(shù)（1表示禁用，-1表示不限制個(gè)數(shù)，默認(rèn)100個(gè)。一般設(shè)置在100~200之間），表示該連接最大支持的請(qǐng)求數(shù)。超過(guò)該請(qǐng)求數(shù)的連接也將被關(guān)閉（此時(shí)就會(huì)返回一個(gè)Connection: close頭給客戶端）。

4.3 Netty設(shè)置Keepalive

4.3.1 SO_KEEPALIVE

Socket參數(shù)。是否啟用心跳?；顧C(jī)制，即連接保活。 啟用該功能時(shí)，TCP會(huì)主動(dòng)探測(cè)空閑連接的有效性。

在雙方TCP套接字建立連接后（即都進(jìn)入ESTABLISHED狀態(tài)）并且在兩個(gè)小時(shí)左右（默認(rèn)的心跳間隔是7200s即2小時(shí)）上層沒(méi)有任何數(shù)據(jù)傳輸?shù)那闆r下，這套機(jī)制才會(huì)被激活。

默認(rèn)值：Netty默認(rèn)關(guān)閉該功能，即值為：false 。

代碼設(shè)置：

bootstrap.childOption(ChannelOption.SO_KEEPALIVE, true);

說(shuō)明：

• ? 如果一方已經(jīng)關(guān)閉或異常終止連接，而另一方卻不知道，我們將這樣的TCP連接稱為半打開的。TCP通過(guò)保活定時(shí)器(KeepAlive)來(lái)檢測(cè)半打開連接。
• ? 在高并發(fā)的網(wǎng)絡(luò)服務(wù)器中，經(jīng)常會(huì)出現(xiàn)漏掉socket的情況，對(duì)應(yīng)的結(jié)果有一種情況就是出現(xiàn)大量的CLOSE_WAIT狀態(tài)的連接。這個(gè)時(shí)候，可以通過(guò)設(shè)置KEEPALIVE選項(xiàng)來(lái)解決這個(gè)問(wèn)題。
• ? 設(shè)置SO_KEEPALIVE選項(xiàng)來(lái)開啟KEEPALIVE，然后通過(guò)TCP_KEEPIDLE、TCP_KEEPINTVL和TCP_KEEPCNT設(shè)置keepalive的開始時(shí)間、間隔、次數(shù)等參數(shù)。
• ? 當(dāng)然，也可以通過(guò)設(shè)置/proc/sys/net/ipv4/tcp_keepalive_time、tcp_keepalive_intvl和tcp_keepalive_probes等內(nèi)核參數(shù)來(lái)達(dá)到目的，但是這樣的話，會(huì)影響所有的socket。

4.3.2 SpringCloud Gateway設(shè)置Keepalive

@Configuration
public class NettyConfig {
    @Bean
    public NettyServerCustomizer nettyServerCustomizer() {
        return httpServer -> httpServer.tcpConfiguration(tcpServer -> {
            tcpServer= tcpServer.option(ChannelOption.SO_KEEPALIVE, true);
            tcpServer = tcpServer.doOnBind(serverBootstrap ->
                    BootstrapHandlers.updateConfiguration(serverBootstrap, "channelIdle", (connectionObserver, channel) -> {
                        ChannelPipeline pipeline = channel.pipeline();
                        pipeline.addLast(new ReadTimeoutHandler(5, TimeUnit.MINUTES));
                    }));
            return tcpServer;
        });
    }
}

5.參考資料

[1] https://www.cnblogs.com/xpfeia/p/10885726.html

[2] https://zhuanlan.zhihu.com/p/51560184

[3] https://blog.csdn.net/tennysonsky/article/details/45622395

[4] http://www.manongjc.com/detail/24-rcqeqovotuetucc.html

[5] https://www.jianshu.com/p/394a7883a139

[6] https://blog.csdn.net/bluetjs/article/details/80966148

[7] http://www.ttlsa.com/windows/parameter-optimization-of-tcp-under-windows-system/

[8] https://www.cnblogs.com/sunsky303/p/10648861.html