項(xiàng)目中使用了springcloud gateway作為網(wǎng)關(guān)，上游與負(fù)載均衡服務(wù)器連接。

近期通過監(jiān)控系統(tǒng)觀察，發(fā)現(xiàn)網(wǎng)關(guān)與上游負(fù)載均衡服務(wù)器保持的TCP連接有300+，初步懷疑是調(diào)用方未釋放連接

用如下方法進(jìn)行分析：

1）周期性采集當(dāng)前建立的連接及端口數(shù)據(jù)

首先是每隔10分鐘連續(xù)采集2兩個(gè)小時(shí)，發(fā)現(xiàn)在兩個(gè)小時(shí)之內(nèi)新出現(xiàn)的端口不到12個(gè)，再逐步縮短采樣周期，到最后每秒采集一次，分析發(fā)現(xiàn)每秒種建立一個(gè)連接，同時(shí)關(guān)閉一個(gè)連接，當(dāng)仍存在300+連接，這些連接對應(yīng)的端口稱為不活躍端口，記錄下這300+不活躍端口。

2）為了進(jìn)一步分析，用whireshark抓包

發(fā)現(xiàn)絕大部分情況下都是正常的連接和關(guān)閉，但這300+個(gè)不活躍端口對應(yīng)的連接上沒有任何數(shù)據(jù)，這300+個(gè)不活躍對應(yīng)的連接稱為不活躍連接。同步趕緊上馬接口調(diào)用實(shí)時(shí)監(jiān)控功能，發(fā)現(xiàn)實(shí)際的調(diào)用數(shù)量卻非常少（每分鐘不足10個(gè)）。

3）與上游的負(fù)載均衡工程師一起檢查

從負(fù)載均衡服務(wù)器看到的活躍連接也是個(gè)位數(shù)，并且并未找到在網(wǎng)關(guān)上的不活躍端口。也就是說在負(fù)載均衡服務(wù)器已經(jīng)已經(jīng)拆除了與網(wǎng)關(guān)上的不活躍連接對應(yīng)的連接。咨詢負(fù)載均衡工程師，負(fù)載均衡設(shè)備對于1超過1個(gè)小時(shí)的不活躍連接會主動拆除。

經(jīng)過以上分析，確定是外部系統(tǒng)經(jīng)過負(fù)載均衡設(shè)備與網(wǎng)關(guān)建立連接后，并未進(jìn)行任何操作，但網(wǎng)關(guān)會一直維護(hù)這個(gè)連接，導(dǎo)致網(wǎng)關(guān)的連接數(shù)持續(xù)上升。

為解決這個(gè)問題，需要首先回顧一下傳統(tǒng)的TCP長連接維護(hù)機(jī)制

針對長連接的維護(hù)，傳統(tǒng)的TCP服務(wù)采用心跳來維持，比如服務(wù)端每分鐘發(fā)送一個(gè)心跳報(bào)文，并啟動計(jì)數(shù)器并設(shè)置為1，客戶端收到后回應(yīng)一個(gè)報(bào)文，服務(wù)端收到回復(fù)報(bào)文后重置計(jì)數(shù)器，如果為收到應(yīng)答，則一分鐘再發(fā)送一個(gè)心跳報(bào)文，同時(shí)計(jì)數(shù)器加1，連續(xù)發(fā)送三個(gè)心跳報(bào)文并且未收到映帶，則服務(wù)端則認(rèn)為客戶端已經(jīng)失聯(lián)，會主動拆除這個(gè)連接，以避免不必要的資源占用。

我們現(xiàn)在使用的springcloud gateway，顯然很難直接修改源碼增加以上的心跳機(jī)制，所以我又想到了操作系統(tǒng)協(xié)議棧的連接?；顧C(jī)制。

TCP協(xié)議棧的?；顧C(jī)制與應(yīng)用層的長連接維護(hù)機(jī)制類似（當(dāng)然，應(yīng)用層的TCP長連接維護(hù)機(jī)制就是從協(xié)議棧的保護(hù)機(jī)制學(xué)習(xí)來的'&'），只不過是在協(xié)議棧層面完成，這樣避免了應(yīng)用層實(shí)現(xiàn)負(fù)載的長連接維護(hù)

?；顧C(jī)制如下：

1）服務(wù)器端判斷一個(gè)連接在指定的時(shí)間內(nèi)

（缺省為2小時(shí)）沒有任何數(shù)據(jù)，則發(fā)送一個(gè)探測報(bào)文，并啟動定時(shí)器

2）如果客戶端在正常運(yùn)行并且網(wǎng)絡(luò)可達(dá)

則客戶端則回復(fù)一個(gè)響應(yīng)報(bào)文，服務(wù)端認(rèn)為客戶端正常，則重新開始計(jì)時(shí)。

如果客戶端主機(jī)崩潰或網(wǎng)絡(luò)不可達(dá)，服務(wù)端將收不到應(yīng)答，定時(shí)器超時(shí)后（一般為75秒），服務(wù)端將再次發(fā)送探測報(bào)文，如此連續(xù)發(fā)送若干次（一般為10次），如果均未收到應(yīng)答，則服務(wù)端將主動關(guān)閉連接。

當(dāng)然，如果中間有任何一次服務(wù)端收到應(yīng)答，則認(rèn)為連接正常，不再發(fā)送探測報(bào)文。

使用如下命令可以查看以上?；顣r(shí)間、發(fā)送探測報(bào)文的間隔和次數(shù)：

#sysctl -a|grep keepalive
net.ipv4.tcp_keepalive_time = 7200（單位為秒）
net.ipv4.tcp_keepalive_probes = 9 
net.ipv4.tcp_keepalive_intvl = 75  （單位為秒）

關(guān)于?；顓?shù)中兩個(gè)小時(shí)的時(shí)間設(shè)置存在爭議，通常人們希望這個(gè)值可以小很多，比如分鐘級，但?；铋g隔時(shí)間是系統(tǒng)級別的變量，如果改變該值會影響所有使用該功能的用戶。

所以，Host Requirements RFC提出一個(gè)實(shí)現(xiàn)方式，?；铋g隔是可配置的，但缺省不小于兩個(gè)小時(shí)，并且需要應(yīng)用程序設(shè)置才啟用。

如果使用協(xié)議棧的保活功能，那么缺省的兩個(gè)小時(shí)的時(shí)間還是太長，如果縮短這個(gè)時(shí)間會有什么影響，并無把握。

所以還是先想其他辦法，從網(wǎng)上看到可以通過以下代碼修改網(wǎng)關(guān)對長連接的維護(hù)辦法，以下代碼是設(shè)置?；顣r(shí)間為3分鐘，如果3分鐘內(nèi)連接上沒有數(shù)據(jù)，網(wǎng)關(guān)將主動關(guān)閉連接：

配置文件：

server:
    netty:
        idie-timeout: 300
@Configuration
public class NettyConfig {
    @Bean
    publiWebServerFactoryCustomizer<NettyReactiveWebServerFactory> idleTimeoutCustomizer(
        @Value("${server.netty.idle-timeout}") Duration idleTimeout) {
        return factory -> factory.addServerCustomizers(
            server -> server.tcpConfiguration(
                tcp->tcp.bootstrap(
                   bootstrap->bootstrap.childHandler(new ChannelInitializer<Channel>() {
                       @Override
                       protected void initChannel(Channel channel) {
                           channel.pipeline().addLast(
                               new IdleStateHandler(0, 0, idleTimeout.toNanos(), NANOSECONDS) {
                                   private final AtomicBoolean closed = new AtomicBoolean();
                                   @Override
                                   protected void channelIdle(
                                       ChannelHandlerContext ctx, IdleStateEvent evt) {
                                           if (closed.compareAndSet(false, true)) {
                                               ctx.close();
                                           }
                                       }
                                   }
                               );
                           }
                       }))));
    }
}

系統(tǒng)上線后，通過監(jiān)控系統(tǒng)發(fā)現(xiàn)網(wǎng)關(guān)連接數(shù)并未持續(xù)增長，剛松一口氣，線上業(yè)務(wù)系統(tǒng)頻頻報(bào)錯(cuò)，請求網(wǎng)關(guān)失敗，趕緊安排網(wǎng)絡(luò)抓包，然后馬上回退恢復(fù)業(yè)務(wù)。

然后對網(wǎng)絡(luò)抓包進(jìn)行分析，截圖如下：

從抓包結(jié)果來看，客戶端和網(wǎng)關(guān)經(jīng)過3次握手后，建立了連接，但后面的建立SSL的過程中，網(wǎng)關(guān)返回了400 Bad Request，所以導(dǎo)致業(yè)務(wù)系統(tǒng)請求失?。I(yè)務(wù)系統(tǒng)使用https請求網(wǎng)關(guān)），懷疑是上面的代碼中的配置覆蓋了配置文件中SSL的相關(guān)配置，所以導(dǎo)致SSL連接未建立。

我們優(yōu)秀的工程師，本著鍥而不舍的精神對gateway進(jìn)行源碼分析，經(jīng)過對代碼的分析，發(fā)現(xiàn)確實(shí)是這個(gè)配置覆蓋了原有的SSL配置，導(dǎo)致SSL配置未生效所致，所以對以上代碼進(jìn)行改寫，具體如下：

@Configuration
public class NettyConfig {
    @Bean
    publiWebServerFactoryCustomizer<NettyReactiveWebServerFactory> idleTimeoutCustomizer(
        @Value("${server.netty.idle-timeout}") Duration idleTimeout) {
        return factory -> factory.addServerCustomizers(
            server -> server.tcpConfiguration(
                tcp->tcp.bootstrap(bootstrap->{
                  //增加如下代碼，從而可保持原有配置并追加?；?
                   BootstrapHandlers.updateConfiguration(bootstrap, "IdleStateHandler",
                      (connectionObserver, channel) ->{
                       channel.pipeline().addLast(new IdleStateHandler(0, 0,
                           idleTimeout.toNanos(), NANOSECONDS) {
                                 private final AtomicBoolean closed = new AtomicBoolean();
                                 @Override
                                 protected void channelIdle(ChannelHandlerContext ctx,
                                     IdleStateEvent evt) {
                                     if (closed.compareAndSet(false, true)) {
                                         ctx.close();
                                     }
                                 }
                             });
                         });
                        return bootstrap;
                    }
                )));
    }
}

進(jìn)行測試驗(yàn)證，一切OK！

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評論