91久久国产精品若水,88蜜桃人妻无码精三,欧美日韩国产图片

一個客戶端主動行為導致499的例子
一個客戶端被動行為導致499的例子
服務端問題可能導致499？
nginx中的504判定相關超時配置
服務端耗時過長導致的499
通過proxy_ignore_client_abort配置解決499問題？
非高峰時期單個upstream偶發響應緩慢、導致超時的原因

總結

參考資料

背景

nginx 499在服務端推送流量高峰期長期以來都是存在的，間或還能達到告警閾值觸發一小波告警，但主觀上一直認為499是客戶端主動斷開，可能和推送高峰期的用戶打開推送后很快殺死app有關，沒有進一步探究問題根源。
然而近期在非高峰期也存在499超過告警閾值的偶發情況，多的時候一天幾次，少的時候則幾天一次，持續一般也就數分鐘，并且該類告警一般集中于一臺api機器，與推送高峰時多臺機器同時499告警明顯不同，不由得腦海中升起了問號，經過和小伙伴的共同探究，最后發現之前對于499是客戶端主動斷開因而和服務端關系不大的想當然認知是錯誤的，這里記錄一下。

499的含義與可能原因

499其實并不是HTTP協議的標準狀態碼，而是nginx自定義的狀態碼，并沒有在nginx官方文檔中找到對該狀態碼的明確說明，這里引用一個感覺比較專業的博文上的解釋：

HTTP error 499 simply means that the client shut off in the middle of processing the request through the server. The 499 error code puts better light that something happened with the client, that is why the request cannot be done. So don’t fret: HTTP response code 499 is not your fault at all.

大意是499一般意味著客戶端在HTTP請求還在處理時主動結束的處理過程–斷開了對應的網絡連接，499一般意味著客戶端側發生了一些問題，和服務端沒有關系。
以下則是nginx源碼中的注釋說明：

/*
* HTTP does not define the code for the case when a client closed
* the connection while we are processing its request so we introduce
* own code to log such situation when a client has closed the connection
* before we even try to send the HTTP header to it
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST     499

意思是nginx引入了自定義的code 499來記錄客戶端斷開連接時nginx還沒有處理完其請求的場景。
回想多年以前首次碰到499場景時在網絡搜索資料也是看到了類似的解答，所以一直認為499和服務端關系不大，應該都是客戶端的原因。

一個客戶端主動行為導致499的例子

曾經遇到過一個搜索聯想接口，其499比例比其他api高上幾十倍–一騎絕塵，單看該api基本上長期位于告警閾值之上，也追蹤過其具體異常原因，最后聯合客戶端小伙伴給出了結論：搜索聯想接口的499比例偏高時正常的，因為：

該api的調用場景是用戶在搜索框輸入搜索詞時，用戶每輸入一個字符都會立刻用最新的輸入調用api并將返回的聯想結果展示給用戶，以此達到一個近實時搜索聯想的功能。
既然每次用戶輸入新字符都觸發了最新的api調用請求，那即便之前的調用請求還在進行中，客戶端也應該直接結束這些已無實際作用的舊請求，這反映在nginx log上就是客戶端主動斷開了連接的499。

所以搜索聯想api雖然有異于普通api的高比例499，卻是完全合理的，客戶端要負主動斷開連接的責任，但是并沒有做錯任何事情，服務端也沒有任何問題。

一個客戶端被動行為導致499的例子

另一個之前認為客戶端行為導致499的例子是推送高峰，部分用戶在通過推送打開app后可能會秒殺app，而推送高峰時期一般服務端壓力比較大本身響應就會比平峰時期慢一些，此時有些api請求可能還正在進行中，此時用戶殺死了app–app含冤而死無能為力–對應連接自然就被OS斷開回收了，于是也導致了499，這種場景下服務端也是沒有問題的。

服務端問題可能導致499？

通過上面兩個例子乍看下去，499都是客戶端側的原因，無論是其主動還是被動行為，也正是這兩個例子加深了博主心中對于499服務端應該無責任的意識。
總結服務端出錯可能導致的nginx錯誤碼，主要應該是以下幾個場景：

500：內部錯誤，一般為請求參數直接導致了upstream 的處理線程執行代碼出錯，業務代碼或者框架直接返回 Internal Error
502：一般為upstream server直接掛了無法連接，nginx無法訪問upstream所以返回 Bad Gateway
503： upstream負載過高–但是沒掛，直接返回了Service Unavailable
504: upstream處理請求時間過長，nginx等待upstream返回超時返回Gateway Timeout

所以無論是代碼執行出錯、服務掛了、服務過于繁忙、請求處理耗時過長導致HTTP請求失敗，都是返回的5XX，壓根不會觸發499。
一般情況來說確實是這樣的，但是這次新出現的平峰499并非一般情況，在網上查找資料時時有人提出過nginx 499可能是服務端處理耗時過長導致客戶端超時后主動斷開，但是這種情況按照上面的描述不應該屬于場景4– upstream處理請求時間過長，nginx返回504才對嗎？
所以看上去服務端處理耗時過長既可能導致客戶端主動斷開的499也可能導致nginx返回Gateway Timeout的504，那導致這個區別的關鍵因素是什么？
簡單來說就是如果客戶端先斷開被nginx檢測到那就是499，而如果upstream 耗時過長超時先被nginx判定就是504，所以關鍵就是nginx對于upstream 超時的時間設置，捋到這里趕緊去看了下nginx的超時相關配置，嗯，沒有明確配置相關超時時間–！

nginx中的504判定相關超時配置

由于api與nginx是通過uwsgi協議通信，因此關鍵的超時配置參數如下：

Syntax:	uwsgi_connect_timeout time;
Default:	
uwsgi_connect_timeout 60s;
Context:	http, server, location
Defines a timeout for establishing a connection with a uwsgi server. It should be noted that this timeout cannot usually exceed 75 seconds.
Syntax:	uwsgi_send_timeout time;
Default:	
uwsgi_send_timeout 60s;
Context:	http, server, location
Sets a timeout for transmitting a request to the uwsgi server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the uwsgi server does not receive anything within this time, the connection is closed.
Syntax:	uwsgi_read_timeout time;
Default:	
uwsgi_read_timeout 60s;
Context:	http, server, location
Defines a timeout for reading a response from the uwsgi server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the uwsgi server does not transmit anything within this time, the connection is closed.

在未明確指定的情況下其超時時間均默認為60s，簡單來說（實際情況更復雜一些但這里不進一步探討）只有在upstream處理請求耗時超過60s的情況下nginx才能判定其Gateway Timeout 并按照504處理，然而客戶端設置的HTTP請求超時時間其實只有15s–這其中還包括外網數據傳輸的時間，于是問題來了：每一個服務端處理耗時超過15s的請求，nginx由于還沒達到60s的超時閾值不會判定504，而客戶端則會由于超過本地的15s超時時間直接斷開連接，nginx于是就會記錄為499。
通過回查nginx log，非高峰期的499告警時段確實是存在單臺upstream 請求處理緩慢，耗時過長，于是可能導致：

用戶在需要block等待請求的頁面等待雖然不到15s但是已經不耐煩了，直接采取切頁面或者殺死app重啟的方式結束當前請求。
用戶耐心等待了15s、或者非阻塞的后臺HTTP請求超過了15s超過超時閾值主動斷開連接結束了當前請求。

服務端耗時過長導致的499

上面已經知道近期新出現的單臺upstream 偶發499是由于響應緩慢引起的，既然是由于客戶端超時時間(15s)遠小于nginx upstream超時時間(60s)引起的，這應該屬于一個明顯的配置不當，會導致三個明顯的問題：

將用戶由于各種原因(如殺app)很快主動斷開連接導致的499與客戶端達到超時時間(這里是15s)導致的499混在了一起，無法區分客戶端責任與服務端責任導致499問題。
對于nginx判定為499的請求，由于認為是客戶端主動斷開，不會被認為是服務端導致的unsuccessful attempt而被計入用于failover判定的max_fails計數中，所以即便一個upstream大量觸發了499，nginx都不會將其從可用upstream中摘除，相當于摘除不可用節點的功能失效，而由于負載過高導致499的upstream收到的請求依然不斷增加最終可能導致更大的問題。
對于判定為499的請求，也是由于不會被認為是unsuccessful attempt，所以uwsgi_next_upstream這一配置也不會work，于是當第一個處理請求的upstream耗時過長超時后，nginx不會嘗試將其請求轉發為下一個upstream嘗試處理后返回，只能直接失敗。

那是不是把客戶端超時時間調大？或者把nginx upstream超時時間調小解決呢？
調大客戶端超時時間當然是不合理的，任何用戶請求15s還未收到響應肯定是有問題的，所以正確的做法應該是調小upstream的超時時間，一般來說服務端對于客戶端請求處理時間應該都是在數十、數百ms之間，超過1s就已經屬于超長請求了，所以不但默認的60s不行，客戶端設置的15s也不能用于upstream的超時判定。
最終經過綜合考慮服務端各api的耗時情況，先敲定了一個upstream 5s的超時時間配置–由于之前沒有經驗首次修改步子不邁太大，觀察一段時間后繼續調整，這樣做已經足以很大程度解決以上的3個問題：

將用戶由于各種原因(如殺app)很快主動斷開連接導致的499與nginx達到upstream超時時間時主動結束的504區分開了。
504會被納入max_fails計算，觸發nginx摘除失敗節點邏輯，在單臺機器故障響應緩慢時可以被識別出來暫時摘除出可用節點列表，防止其負載進一步加大并保證后續請求均被正常可用節點處理返回。
當nginx等待upstream處理達到5s觸發超時時，其會按照uwsgi_next_upstream配置嘗試將請求(默認僅限冪等的GET請求)轉交給下一個upstream嘗試處理后返回，這樣在單一upstream由于異常負載較高超時時，其他正常的upstream可以作為backup兜底處理其超時請求，這里客戶端原本等待15s超時的請求一般在5~10s內可以兜底返回。

通過proxy_ignore_client_abort配置解決499問題？

在網上查找資料時還有網友提出解除nginx 499問題的一個思路是設置proxy_ignore_client_abort參數，該參數默認為off，將其設置為on 后，對于客戶端主動斷開請求的情況，nginx會ignore而以upstream實際返回的狀態為準，nginx官方文檔說明如下：

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

但是在客戶端主動斷開連接時，設置這個參數的意義除了使nginx log中記錄的狀態碼完全按照upstream返回確定，而非表示客戶端斷連的499之外，對于實際問題解決完全沒有任何幫助，感覺頗有把頭埋進沙子的鴕鳥風格，不知道這個參數設置到底會有什么實用的場景。

非高峰時期單個upstream偶發響應緩慢、導致超時的原因

這是個好問題，這個問題是近期才出現的，在解決了上面說的nginx錯配問題后嘗試排查這個問題，從現象上看應該是某些特定請求觸發了upsteam CPU飆升，響應緩慢后進一步影響了后續請求的處理，最終導致所有請求響應緩慢觸發客戶端499。
在nginx錯配問題解決后，再次出現這種單臺upstream緩慢超時情況后，nginx會很快通過failover摘除掉問題upstream避免情況進一步惡化，而對于首次訪問問題upstream超時的GET請求也會backup轉發至其他可用upstream處理后返回，已經很大程度上降低了此類異常情況的影響。
最終，修正配置后單upstream的偶發異常會以幾天一次的頻率觸發部分POST api的少量504閾值告警，其問題的根本原因還在探尋中。