摘要：猜測原因是一端異常關閉了連接卻沒有通知對端，或者通知了對端但對端沒有收到。序號請求設置了超時時間為，因此發送包。之后繼續測試，沒有發現丟包。序號空閑分鐘后，主動發起報文，關閉連接。

基本架構如圖所示，客戶端發起 http 請求給 nginx，nginx 轉發請求給網關，網關再轉發請求到后端微服務。

故障現象是，每隔十幾分鐘或者幾個小時不等，客戶端就會得到一個或者連續多個請求超時錯誤。查看 nginx 日志，對應請求返回 499；查看網關日志，沒有收到對應的請求。

從日志分析，問題應該處在 nginx 或者 spring-cloud-gateway 上。

nginx 版本：1.14.2，spring-cloud 版本：Greenwich.RC2。

nginx 主要配置如下：

[root@wh-hlwzxtest1 conf]# cat nginx.conf

worker_processes  8;

events {
    use epoll;
    worker_connections  10240;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile       on;
    tcp_nopush     on;
    tcp_nodelay    on;

    keepalive_timeout  65;
    #gzip  on;

    upstream dbg2 {
        server 10.201.0.27:8888;
        keepalive 100;
    }

   server {
        listen       80;
        server_name  localhost;

        charset utf-8;

        location /dbg2/ {
            proxy_pass         http://dbg2/;
            proxy_http_version  1.1;
            proxy_set_header    Connection "";
         }
    }
}

為了提高性能，nginx 發送給網關的請求為 http 1.1，可以復用 tcp 連接。

[root@10.197.0.38 logs]# ss -n | grep 10.201.0.27:8888
tcp    ESTAB      0      0      10.197.0.38:36674              10.201.0.27:8888
tcp    ESTAB      0      0      10.197.0.38:40106              10.201.0.27:8888

[root@10.201.0.27 opt]# ss -n | grep 10.197.0.38
tcp    ESTAB      0      0        ::ffff:10.201.0.27:8888                 ::ffff:10.197.0.38:40106
tcp    ESTAB      0      0        ::ffff:10.201.0.27:8888                 ::ffff:10.197.0.38:39266

可以看到 nginx 和網關之間建立的 socket 連接為 （10.201.0.27:8888，10.197.0.38:40106），另外的 2 條記錄就很可疑了。猜測原因是：一端異常關閉了 tcp 連接卻沒有通知對端，或者通知了對端但對端沒有收到。

先看下 nginx 的抓包數據：

序號 8403：轉發 http 請求給網關；

序號 8404：在 RTT 時間內沒有收到 ack 包，重發報文；

序號 8505：RTT 約等于 0.2s，tcp 重傳；

序號 8506：0.4s 沒收到 ack 包，tcp 重傳；

序號 8507：0.8s 沒收到 ack 包，tcp 重傳；

序號 8509：1.6s 沒收到 ack 包，tcp 重傳；

...

序號8439：28.1s（128RTT）沒收到 ack 包，tcp 重傳。

序號 8408：請求設置了超時時間為 3s，因此發送 FIN 包。

再看下網關的抓包數據：

序號 1372：17:24:31 收到了 nginx 發過來的 ack 確認包，對應 nginx 抓包圖中的序號 1348（nginx 那臺服務器時間快了差不多 1 分 30 秒）;

序號 4221：2 小時后，發送 tcp keep-alive 心跳報文，（從 nginx 抓包圖中也可以看出這 2 小時之內該 tcp 連接空閑）；

序號 4253：75s 后再次發送 tcp keep-alive 心跳；

序號 4275：75s 后再次發送心跳；

連續 9 次；

序號 4489：發送 RST 包，通過對端重置連接。

2 小時，75s， 9 次，系統默認設置。

[root@eureka2 opt]# cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
[root@eureka2 opt]# cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
[root@eureka2 opt]# cat /proc/sys/net/ipv4/tcp_keepalive_probes
9

具體這幾個參數的作用，參考文章：為什么基于TCP的應用需要心跳包

通過以上抓包分析，基本確認了問題出在 nginx 上。19:25 時，網關發送 tcp keep-alive 心跳包給 nginx 那臺服務器，此時那臺服務器上保留著該 tcp 連接，卻沒有回應；22:20 時，nginx 發送 http 請求給網關，而網關已經關閉該 tcp 連接，因此沒有應答。

nginx 中與 upstream 相關的超時配置主要有如下參數，參考：Nginx的超時timeout配置詳解

proxy_connect_timeout：nginx 與 upstream server 的連接超時時間；
proxy_read_timeout：nginx 接收 upstream server 數據超時, 默認 60s, 如果連續的 60s 內沒有收到 1 個字節, 連接關閉；
proxy_send_timeout：nginx 發送數據至 upstream server 超時, 默認 60s, 如果連續的 60s 內沒有發送 1 個字節, 連接關閉。

這幾個參數，都是針對 http 協議層面的。比如 proxy_send_timeout = 60s，并不是指如果 60s 沒有發送 http 請求，就關閉連接；而是指發送 http 請求后，在兩次 write 操作期間，如果超過 60s，就關閉連接。所以這幾個參數，顯然不是我們需要的。

查看官網文檔，Module ngx_http_upstream_module，

Syntax:    keepalive_timeout timeout;
Default:    
keepalive_timeout 60s;
Context:    upstream
This directive appeared in version 1.15.3.

Sets a timeout during which an idle keepalive connection to an upstream server will stay open.

設置 tcp 連接空閑時間超過 60s 后關閉，這正是我們需要的。

為了使用該參數，升級 nginx 版本到 1.15.8，配置文件如下：

http {
    upstream dbg2 {
        server 10.201.0.27:8888;
        keepalive 100;
        keepalive_requests 30000;
        keepalive_timeout 300s;
    }
    ...
}

設置 tcp 連接上跑了 30000 個 http 請求或者空閑 300s，那么就關閉連接。

之后繼續測試，沒有發現丟包。

序號 938：空閑 5 分鐘后，nginx 主動發起 FIN 報文，關閉連接。