淺析nginx 客戶端返回499的錯誤碼的問題

我們服務器客戶端一直有返回錯誤碼499的日志,以前覺得比例不高,就沒有仔細查過,最近有領導問這個問題,為什麼耗時隻有0.0幾秒,為啥還499瞭?最近幾天就把這個問題跟蹤定位瞭一下,這裡做個記錄

網絡架構和背景

我們服務架構和錯誤碼是上面這樣的,上遊服務日志沒有記錄,無法確定kong到上遊服務的連接和請求細節。

kong上的日志
rsp_cost:0.041
rsp_length:0
rsp_status:499
ups_rsp_cost:-
ups_rsp_length:0
ups_rsp_status:-
waf上的日志
rsp_cost:1.045
rsp_length:0
rsp_status:499
ups_rsp_cost:-
ups_rsp_length:0
ups_rsp_status:-

看日志,兩個負載均衡的現象一毛一樣,kong upstream到web服務上,不太確定是upstream 鏈接的問題或者是讀寫數據的問題,或者是kong自己的問題,根本就沒有反向代理到上遊服務

上遊服務抓包

打算在上遊服務上抓一下包,看看請求是在kong上出問題瞭,根本沒到上遊服務,還是說已經到瞭上遊服務,上遊服務出問題瞭。

83是kong的ip,82是上遊服務的ip
可以看到,83首先發瞭fin包,表示要斷開連接,之後82也回復瞭fin的ack包,之後82還在發送數據包,過瞭大概0.18秒,82才給83發瞭fin ack包,表示可以斷開連接瞭。這時候由於83早就斷開瞭連接,在這個中間的包,83回復瞭RST,我們使用的是長鏈接,83斷開連接之後,新的連接已經復用這個TCP連接瞭,這時候83隻能回復RST。大概過程就是這樣的。

kong為什麼要斷開連接?
由於我們使用upstream是長鏈接,猜測瞭很多種可能

  • keepalive_requests 超過keepalive_requests個請求後就會關閉長鏈接
  • keepalive_time 超過keepalive_time時間後就會關閉長鏈接
  • keepalive_timeout 打開上遊服務的超時時間,連接超過keepalive_timeout就認為上遊服務已經不可用瞭,這個參數就直接排除瞭,抓包已經看到請求已經到瞭上遊服務

最後都放棄瞭這個配置,覺得Nginx應該會處理完請求之後再受到keepalive_requests keepalive_time的限制關閉連接,不可能請求處理一半然後直接主動關閉連接,還有一個原因,我們的Nginx版本是1.13,也沒有這些配置可以修改。

負載均衡的問題?

最後懷疑是waf上的問題,waf上請求量太大,沒去waf機器上抓包,猜測waf抓包跟kong的結果是一樣的,然後向前推測waf為什麼要斷開連接,猜測是不是客戶端斷開瞭連接,如果是客戶端斷開連接的話,所有的看到的日志現象就是通的。
為瞭驗證這個猜測,我們在測試環境模擬瞭一下客戶端主動斷開連接的操作。
我們先在的上遊服務上模擬瞭一個耗時的請求,然後再沒有返回結果的時候主動斷開請求。

class TestController extends BaseController
{
    public function actionTest()
    {
        sleep(3);
        return $this->response->success(array("test","geekbang","es"));
    }
}

然後我們在終端上使用curl請求接口,在三秒之內取消請求。
curl https://test.com/test/test/testctrl+C 取消請求
然後觀察waf的日志,以及kong的日志,跟生產出現的499錯誤碼表現是一樣的。
基本上確定是客戶端主動斷開連接引起的。

修改配置 Nginx的配置

看一下proxy_ignore_client_abort說明

Syntax:	proxy_ignore_client_abort on | off;
Default:	
proxy_ignore_client_abort off;
Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.

確定當客戶端在不等待響應的情況下關閉連接時,是否應該關閉與代理服務器的連接。
客戶端不等待響應關閉連接時,默認會關閉與代理服務器的連接,改為on就是代理服務器不關閉,直到代理服務器處理完請求。
在kong上修改配置
proxy_ignore_client_abort on
改瞭一臺機器,觀察瞭一天,確定瞭是因為這個配置,後面把兩臺機器都改瞭之後就沒有再出現499的錯誤碼。修改瞭這個配置之後,盡管錯誤碼消失瞭,但是無效的請求會增加上遊服務的壓力,本來這個請求已經無意義被客戶端關閉瞭,然後上遊服務也被關閉瞭。打開之後,上遊服務不會被關閉,直到請求處理完畢,有利有弊,需要權衡和取舍。

到此這篇關於nginx 客戶端返回499的錯誤碼的文章就介紹到這瞭,更多相關nginx返回499錯誤碼內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: