目錄

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

問題解決

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

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

現(xiàn)象

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

解決

過程

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

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

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層拋出了錯(cuò)誤，但是以日志內(nèi)容來看，其實(shí)nginx已經(jīng)是將請求的報(bào)文完整的接收了下來（這個(gè)也是在解決問題之后才反應(yīng)過來），所以其實(shí)問題應(yīng)該是出在Nginx將請求轉(zhuǎn)給被代理的應(yīng)用服務(wù)的時(shí)候。

當(dāng)時(shí)在排查問題的時(shí)候，沒有考慮到還有一層tomcat，導(dǎo)致哪怕是當(dāng)時(shí)懷疑了問題不在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建立一個(gè)服務(wù)端監(jiān)聽，客戶端通過socket向服務(wù)端監(jiān)聽發(fā)起連接， 雙方經(jīng)過TCP握手協(xié)議之后，數(shù)據(jù)開始傳輸，TCP協(xié)議規(guī)定連接在建立之后，雙方只要有一端發(fā)起關(guān)閉的信號，兩端就會走放手協(xié)議的流程（四次揮手），不再進(jìn)行數(shù)據(jù)傳輸。但是如果一端發(fā)起關(guān)閉信號之后，不再接收請求，另外一端依然不進(jìn)入關(guān)閉流程，而是依然不停的發(fā)送數(shù)據(jù)，或者是關(guān)閉的一端緩存區(qū)的數(shù)據(jù)沒有讀完就進(jìn)行了關(guān)閉，這時(shí)候，關(guān)閉的一端就會返回一個(gè)RST的信號，告訴另外一端連接被重置

其他情況的RST

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

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

Tomcat 的 Connector

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

Nginx 104

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

類似問題解決思路

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

1. nginx的buffer太小，timeout太小。
2. 長連接，增加長連接超時(shí)時(shí)間
3. 將 http version改到1.1 (其實(shí)也是使用長連接解決，因?yàn)閔ttp1.1默認(rèn)使用長連接)

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

總結(jié)

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

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