服務產生大量TIME_WAIT如何解決

當TIME_WAIT超過linux系統(tǒng)tw數量的閥值(可用數量不會大于65535)，系統(tǒng)會把多余的time-wait socket?刪除掉，并且顯示警告信息，如果是NAT網絡環(huán)境又存在大量訪問，會產生各種連接不穩(wěn)定斷開的情況，從而影響了服務的穩(wěn)定性。

創(chuàng)新互聯(lián)建站長期為上1000+客戶提供的網站建設服務，團隊從業(yè)經驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網生態(tài)環(huán)境。為重慶企業(yè)提供專業(yè)的網站建設、成都網站建設，重慶網站改版等技術服務。擁有十多年豐富建站經驗和眾多成功案例,為您定制開發(fā)。

一、狀態(tài)的產生

要解決TIME_WAIT狀態(tài)過多的問題，先來研究下TIME_WAIT狀態(tài)的產生，下面是TCP連接斷開時的四次揮手狀態(tài)轉換圖，說明一點，途中顯示的是客戶端主動斷開連接，tcp連接也可以由服務器端主動斷開連接。我們先來描述一下斷開的狀態(tài)：

1）客戶端進程發(fā)出連接釋放報文，并且停止發(fā)送數據。釋放數據報文首部，F(xiàn)IN=1，其序列號為seq=u（等于前面已經傳送過來的數據的最后一個字節(jié)的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數據，也要消耗一個序號。

2）服務器收到連接釋放報文，發(fā)出確認報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態(tài)。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處于半關閉狀態(tài)，即客戶端已經沒有數據要發(fā)送了，但是服務器若發(fā)送數據，客戶端依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。

3）客戶端收到服務器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務器發(fā)送連接釋放報文（在這之前還需要接受服務器發(fā)送的最后的數據）。

4）服務器將最后的數據發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，F(xiàn)IN=1，ack=u+1，由于在半關閉狀態(tài)，服務器很可能又發(fā)送了一些數據，假定此時的序列號為seq=w，此時，服務器就進入了LAST-ACK（最后確認）狀態(tài)，等待客戶端的確認。

5）客戶端收到服務器的連接釋放報文后，必須發(fā)出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經過2MSL（最長報文段壽命,RFC規(guī)定一個MSL為2min，linux中一般設置為30s）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態(tài)。

6）服務器只要收到了客戶端發(fā)出的確認，立即進入CLOSED狀態(tài)。同樣，撤銷TCB后，就結束了這次的TCP連接?？梢钥吹?，服務器結束TCP連接的時間要比客戶端早一些。

可以看到TIME_WAIT狀態(tài)產生是在tcp連接主動關閉的一端產生的正常tcp狀態(tài)，超過兩個MSL之后，就會關閉，釋放占用的端口?；谝陨系姆治鑫覀兛梢酝茢?，在我們的應用中產生大量TIME_WAIT狀態(tài)的根本原因是頻繁創(chuàng)建斷開連接TCP連接。要解決TIME_WATIT狀態(tài)過多的問題，就要分析我們的應用把頻繁創(chuàng)建的短連接改為長連接。

二、常見的短連接產生的場景

1.服務連接服務

后臺業(yè)務服務器，通常需要調用redis、mysql以及其他http服務和grpc服務，在服務相互調用中，如果使用的是短連接，高并發(fā)時就會產生大量TIME_WAIT，如何解決呢？一般情況下，redis等客戶端會有連接池，我們要做的是設置好相關的連接服用參數，一般會有連接數、連接重用時間、連接空閑數等。所以在應用中通過設置合理的連接池參數可以避免TIME_WAIT狀態(tài)過多的問題：

1.檢查http連接池

2.檢查grpc連接池

3.檢查redis連接池

4.檢查mysql連接池

...

我們來查看一個mysql連接池配置信息，最大連接數100，最大空閑連接數10，測試的并發(fā)數50，產生的效果如下：

可以看到TIME_WAIT狀態(tài)快速上升，我們查看redis客戶端的連接情況：

{MaxOpenConnections:100 OpenConnections:1 InUse:0 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:0 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:17 InUse:15 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:48 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:44 Idle:7 WaitCount:0 WaitDuration:0s MaxIdleClosed:82 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:90 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:49 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:126 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:49 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:131 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:49 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:181 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:51 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:233 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:51 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:240 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:46 InUse:38 Idle:8 WaitCount:0 WaitDuration:0s MaxIdleClosed:296 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:313 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:363 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:409 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:48 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:438 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:49 InUse:49 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:494 MaxLifetimeClosed:0}

分析發(fā)現(xiàn)MaxIdleClosed數據持續(xù)上升，此為mysql客戶端連接池配置不合理產生大量TIME_WAIT狀態(tài)的例子

2.網絡抖動

? 網絡情況不好時，如果主動方無TIME_WAIT等待，關閉前個連接后，主動方與被動方又建立起新的TCP連接，這時被動方重傳或延時過來的FIN包過來后會直接影響新的TCP連接。同樣網絡情況不好并且無TIME_WAIT等待，關閉連接后無新連接，當接收到被動方重傳或延遲的FIN包后，會給被動方回一個RST包，可能會影響被動方其它的服務連接。

網絡抖動問題比較好排查，直接使用ping命令可以觀察到。

grpc原理

1）需要使用protobuf定義接口，即.proto文件

2）然后使用compile工具生成特定語言的執(zhí)行代碼，比如JAVA、C/C++、Python等。類似于thrift，為了解決跨語言問題。

3）啟動一個Server端，server端通過偵聽指定的port，來等待Client鏈接請求，通常使用Netty來構建，GRPC內置了Netty的支持。

4）啟動一個或者多個Client端，Client也是基于Netty，Client通過與Server建立TCP長鏈接，并發(fā)送請求；Request與Response均被封裝成HTTP2的stream Frame，通過Netty Channel進行交互。

對于GRPC的“鼓吹”，本文不多表述，截止到今日，GRPC仍然處于開發(fā)階段，尚沒有release版本，而且特性也很多需要補充；GRPC基于protobuf 3.x，但是protobuf 3.x也沒有release版本；雖然HTTP2協(xié)議已成定局，但尚未被主流web容器包括代理服務器支持，這意味著GRPC在HTTP負載均衡方面尚有欠缺；最終，在短期內我們還不能在production環(huán)境中實施，可以做技術儲備。不過GRPC的缺點，在將來將會成為它的優(yōu)點，我們需要時間等待它的成熟。

1）GRPC尚未提供連接池

2）尚未提供“服務發(fā)現(xiàn)”、“負載均衡”機制

3）因為基于HTTP2，絕大部多數HTTP Server、Nginx都尚不支持，即Nginx不能將GRPC請求作為HTTP請求來負載均衡，而是作為普通的TCP請求。（nginx將會在1.9版本支持）

4）GRPC尚不成熟，易用性還不是很理想；就本人而言，我還是希望GRPC能夠像hessian一樣：無IDL文件，無需代碼生成，接口通過HTTP表達。

5）Spring容器尚未提供整合。

在實際應用中，GRPC尚未完全提供連接池、服務自動發(fā)現(xiàn)、進程內負載均衡等高級特性，需要開發(fā)人員額外的封裝；最大的問題，就是GRPC生成的接口，調用方式實在是不太便捷（JAVA），最起碼與thrift相比還有差距，希望未來能夠有所改進。

GRPC 淺析

IDL(proto buffer) + RPC

netty：異步/事件驅動的 網絡應用程序服務器框架（高性能）

Http2：流式、雙向

protobuf：序列化（節(jié)省網絡帶寬）

IDL定義示例：

Starting from a service definition in a .proto file, gRPC provides protocol buffer compiler plugins that generate client- and server-side code.

Http：如果沒有API文檔就不知道細節(jié)，

GRPC：IDL就相當于API文檔，可以同時

開發(fā)順序：

Http：先服務端后客戶端

GRPC：可以同時

跨語言：都支持多語言

性能：GRPC遠差于Thrift，因為用了Http2，各大server目前支持不完善

易用性：GRPC尚未完全提供連接池、服務自動發(fā)現(xiàn)、進程內負載均衡等高級特性，需要開發(fā)人員額外的封裝；

多語言

Http2特性：如stream

易用性：GRPC尚未完全提供連接池、服務自動發(fā)現(xiàn)、進程內負載均衡等高級特性，需要開發(fā)人員額外的封裝

Golang gRPC實現(xiàn)內網穿透

內網穿透即是使用公網服務器作為代理，轉發(fā)內網（如辦公室、家里）的網絡請求使其能夠在外網中被訪問到。

server端監(jiān)聽兩個端口，一個用來和接收用戶的http請求，一個監(jiān)聽gRPC客戶端，和內網服務器進行通信；

client啟動時連接server端；

當User請求server http端口時，將http進行阻塞，并將User請求內容通過gRPC發(fā)給client；

client將從server收到的請求發(fā)往本地的http服務；

client將從本地程序收到的http response通過gRPC發(fā)送給server；

server結束http阻塞，將從client收到的http response發(fā)給User。

github地址：

GRPC的理解

grpc每個流只有一個grpc的數據幀，這個數據幀在傳輸的時候，會拆成多個http2的數據幀進行傳輸，然后在接受端，把所有http2的數據幀拼接成grpc的數據幀，再反序列化成請求的結構體。如果一次傳輸數據過大，在序列化和反序列化的時候，都會占用大量的cpu，不僅僅序列化，單純的內存復制，也會占用大量cpu，而且，傳輸的時候，對帶寬的影響也是很大的。因此，grpc不推薦一次傳輸大量數據，如果有大量數據要傳輸，則使用stream模式?！井斎?，grpc單次數據傳輸的大小限制是可以修改的，但是不建議你這么做】【默認最大消息大小為4MB

】

【不斷修改增加服務端和客戶端消息大小，每次請求不一定需要全部數據，會導致性能上和資源上的浪費】

【grpc協(xié)議層是基于http2設計的（但之前看一片測評文章，結構發(fā)現(xiàn)文件傳輸的時候速度有點慢，因為大量數據傳輸的場景瓶頸在于tcp，如果還在一個tcp上進行多路復用，那只會加劇鎖競爭）】

【4 MB 的限制是為了保護沒有考慮過消息大小限制的客戶端/服務器。 gRPC 本身可以提高很多（100 MB），但大多數應用程序可能會受到輕微攻擊或意外內存不足，從而允許該大小的消息?！?/p>

【grpc本質是為了提高單連接的利用率，如果單個stream上傳輸大量的數據，那么其他stream的數據就很難得到及時的傳輸，grpc適用于大量的請求，但是每次請求的傳輸數據量不大的情況】

【如果單次傳輸的數據量過大，建議從新開一個tcp連接，也就是用http1.1，因為在數據量很大的情況下，瓶頸在于底層的tcp】

【同理，在IM系統(tǒng)中，拉消息也建議使用http1.1的接口，避免占用大量的長連帶寬，影響下行推送及時性】

【http1.1有維護連接池，每次請求都會獨占一個tcp連接，所以，在傳輸大量數據的場景下，也不會影響到其他請求的數據傳輸，瓶頸在于機器性能】

grpc 連接池

gRPC服務開發(fā)和接口測試初探「Go」

之前寫過了Grpc服務開發(fā)和接口測試初探【Java】，中間耽擱了一些時間，Go版本的gRPC測試開發(fā)實踐才有時間學習使用。其中也是由于自己Go語言不夠熟悉導致的。之前有段時間想暫時放棄Go語言的學習，導致了Go的生疏，原因是從Groovy到Java性能。

回歸正題，Go語言版本的gRPC實踐相對Java來說是比較簡單的，但是總體的工具鏈是比較復雜的，可能是因為Go生態(tài)目前相比Java還是比較匱乏吧。下面我先簡述一下大致的步驟：

以上步驟親自操作可能會遇到一些小問題，我本人搜到的教程什么的也是亂七八糟，踩了一些坑。我沒有整理出一個親自實踐之后的可行的教程，原因有二：

Go語言的gRPC的 proto 編寫跟Java大致一致，只有一個報名的參數不太一樣。下面是我的 Hello.proto 內容：

這里主要 go_package 網上搜到的配置方式有些不一樣，我沒有全都嘗試，大家在搜索的資料時候，盡量先看看 syntax 這個參數的值，以及文章教程寫作的時間，如果距離現(xiàn)在太久了，我建議直接關掉。搜索引擎有過濾功能，可以過濾掉過時的教程。

這里Go語言gRPC的一點優(yōu)勢，就是在一個項目中即可實現(xiàn)，Java需要先弄一個SDK這樣。Go語言的gRPC的代碼可以通過生成代碼命令中的參數實現(xiàn)指定路徑。我是放在了和 proto 文件的同級目錄。

服務端代碼也是比較格式化的內容，如下：

其中 pb.RegisterHelloServiceServer(s, Ser{}) 如果報錯，請檢查自己安裝的工具 protoc-gen-go 或者 protoc-gen-gofast 版本，一般提取報錯 message 搜索也能得到解決辦法。

下面是客戶端的代碼，由于學藝不精，其中大部分參數的含義目前我也不是很清楚，特別是基于 stream 的請求響應的方式使用。后面我先把Java的學完，再回過頭來看Go的，按照這個順序學習和分享。

服務端輸出：

忘記打日志了。沒有輸出

客戶端輸出：

Go語言的gRPC測試開發(fā)實踐已經完事兒，大概率上我不會在工作中使用Go作為主力gRPC測試語言，后面測試實踐內容還是會以Java為主。

新聞標題：go語言grpc連接池 golang rpc 連接池
本文鏈接：http://chinadenli.net/article34/dodiipe.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站策劃、網站收錄、建站公司、軟件開發(fā)、ChatGPT、微信公眾號

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)