目錄

• 問題解決
• 應(yīng)用部署環(huán)境
• 現(xiàn)象
• 解決
• 過程
• 最終解決
• 問題分析
• 連接重置
• Tomcat 的 Connector
• Nginx 104
• 類似問題解決思路
• 總結(jié)

問題解決

應(yīng)用部署環(huán)境

• 語言：java
• 框架：ssm
• web容器：tomcat
• 負載：nginx
• 外層代理：F5

現(xiàn)象

根據(jù)客戶需求對接一個停車繳費的功能，發(fā)布到生產(chǎn)環(huán)境之后發(fā)現(xiàn)，少量賬單同時支付沒有問題，一旦同時支付的賬單數(shù)量超過某個值，就會出現(xiàn)網(wǎng)路連接問題，穩(wěn)定復現(xiàn)。

解決

過程

首先查看了應(yīng)用的日志，發(fā)現(xiàn)用戶提示網(wǎng)絡(luò)異常的時候，服務(wù)端沒有任何相關(guān)的日志打印，確定請求沒有發(fā)到服務(wù)端

查看Nginx Error日志發(fā)現(xiàn)打印了錯誤信息

2021/09/09 08:38:56 [error] 16299#16299: *240963 readv() failed (104: Connection reset by peer) while reading upstream, client: ****, server: ****, request: "POST ****?formData=E172Rfbkeuw2Z6fFYyg95hUMDmDwaOZT7Mqopwu07lo%3CVxsdDikPopy1XjjtjmvSusJwb7UF3erixZi5Wy099%3CewyDvM3wWhvE8X/z/vxKow2ttM1iHPSmWn...

通過nginx日志發(fā)現(xiàn)，雖然是nginx層拋出了錯誤，但是以日志內(nèi)容來看，其實nginx已經(jīng)是將請求的報文完整的接收了下來（這個也是在解決問題之后才反應(yīng)過來），所以其實問題應(yīng)該是出在Nginx將請求轉(zhuǎn)給被代理的應(yīng)用服務(wù)的時候。

當時在排查問題的時候，沒有考慮到還有一層tomcat，導致哪怕是當時懷疑了問題不在nginx這塊，還是不敢相信自己，去網(wǎng)上一頓亂搜。

最終解決

在tomcat/conf/server.xml中，增加Connector中的參數(shù)配置maxHttpHeaderSize="65536"，增加允許tomcat接收的最大請求頭大小

<Connector port="****" protocol="org.apache.coyote.http11.Http11NioProtocol"
       URIEncoding="UTF-8"
  maxHttpHeaderSize="65536" 
       connectionTimeout="20000"
       acceptCount="500" maxThreads="500"
       redirectPort="****" />

問題分析

連接重置

TCP RST

正常情況，服務(wù)端使用socket建立一個服務(wù)端監(jiān)聽，客戶端通過socket向服務(wù)端監(jiān)聽發(fā)起連接， 雙方經(jīng)過TCP握手協(xié)議之后，數(shù)據(jù)開始傳輸，TCP協(xié)議規(guī)定連接在建立之后，雙方只要有一端發(fā)起關(guān)閉的信號，兩端就會走放手協(xié)議的流程（四次揮手），不再進行數(shù)據(jù)傳輸。但是如果一端發(fā)起關(guān)閉信號之后，不再接收請求，另外一端依然不進入關(guān)閉流程，而是依然不停的發(fā)送數(shù)據(jù)，或者是關(guān)閉的一端緩存區(qū)的數(shù)據(jù)沒有讀完就進行了關(guān)閉，這時候，關(guān)閉的一端就會返回一個RST的信號，告訴另外一端連接被重置

其他情況的RST

除了上邊的一種情況，RST還可能出現(xiàn)在客戶端找不到服務(wù)端端口，服務(wù)端因為各種關(guān)閉不接收數(shù)據(jù)等等場景中，但是無一例外，最終就是一端的數(shù)據(jù)，沒有被另外一端完整讀取到 ,比如以下幾種情況

1. 客戶端直接找不到想要連接的服務(wù)端
2. 一端早就處于關(guān)閉的狀態(tài)了，另外一端還在傻乎乎的給他傳輸數(shù)據(jù)
3. 一端關(guān)閉的時候，沒有讀完另外一端發(fā)過來的數(shù)據(jù)

Tomcat 的 Connector

其實在一定程度上說，Tomcat和Nginx的作用相同，只不過兩者的職責不同，Nginx使用了異步非阻塞高性能的組合，可以代理各種各樣的URI資源，而Tomcat代理的是一個一個的Servlet容器，它可以容納所有遵循Servlet規(guī)范的應(yīng)用，并且統(tǒng)一將它們管理。Connector是其中最重要的一部分，它是一個HTTP連接器，它通過啟動一個Socket監(jiān)聽，用來接收不同類型的請求，然后把他們解析成對應(yīng)的Servlet規(guī)范的請求，才會將這些請求分發(fā)到不同的Servlet中進行處理。當然，內(nèi)部做了很多其他的事情包括請求校驗攔截，請求轉(zhuǎn)化，請求異步線程處理等等。這里只是簡單介紹一下，后續(xù)會增加關(guān)于tomcat部分的文章

Nginx 104

在我們這個案例的場景下分析，nginx要將拿到的請求轉(zhuǎn)發(fā)給tomcat中的應(yīng)用，需要跟tomcat的Connector建立連接，可以將nginx理解為客戶端，將tomcat中的Connector理解為socket服務(wù)端。tomcat給Connector一套默認的配置，其中maxHttpHeaderSize默認的值是4096字節(jié)，也就是4kb。超過4kb的請求頭大小的請求，不進行處理，當然這里也有可能發(fā)生兩種情況，第一種是Connector一開始就知道nginx發(fā)過來的請求頭過大，直接不接收，響應(yīng)回去RST標識，還有一種是Connector沒有管請求頭的大小，直接去接收，但是因為沒有將請求頭數(shù)據(jù)讀取完就關(guān)閉了，響應(yīng)了RST。這部分沒有細看，但是不論怎么說，都是因為上邊說過的，沒有正常處理完客戶端發(fā)送過來所有的數(shù)據(jù)。

類似問題解決思路

在開始無腦查詢的時候，其實有很多答案雖然錯誤碼是104，但是報錯的原因是不相同的，解決方案也是各不相同，看到過大概以下幾種解決思路

1. nginx的buffer太小，timeout太小。
2. 長連接，增加長連接超時時間
3. 將 http version改到1.1 (其實也是使用長連接解決，因為http1.1默認使用長連接)

雖然個人試其他解決方式的時候，都沒有成功，也有可能是因為tomcat Connector 連接器的最大請求頭4K大小的這個默認配置從最基礎(chǔ)的環(huán)節(jié)直接給把其他配置砍掉了。但是不論使用何種方式解決，最終來說我們就一個思路（雖然說了很像沒說），先找到是哪端沒有將數(shù)據(jù)讀取完畢，然后想辦法讓它正常讀取

總結(jié)

本片文章根據(jù)個人發(fā)生的實際生產(chǎn)問題，著手解決并且進行問題分析，通過對nginx104的跟蹤，對連接重置的概念有一個更詳細的了解。

到此這篇關(guān)于Nginx報錯104:Connection reset by peer問題的解決及分析的文章就介紹到這了,更多相關(guān)Nginx報錯104:Connection reset by peer內(nèi)容請搜索以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持！