(聲明：本文引用了別人的的原創(chuàng)文章的內(nèi)容，因此只是作為一個學習筆記記錄港谊，若涉侵權(quán)則刪之，謝謝）
最近在用Jmeter進行性能測試時遇到了這樣個問題：Jmeter會failed to respond.盡管從圖像上看，似乎對關(guān)鍵指標的曲線的影響不大币呵，但是也有約0.05%左右的錯誤率悉尾。作為一個強迫癥患者突那，還是要對這個問題進行重視。
搜了一下度娘构眯，此處轉(zhuǎn)載一個鏈接 jMeter解決failed to respond Connection reset愕难；侵刪。
其最重要的原因就是當服務(wù)端超時之后，發(fā)送給Fin+ACK后务漩，jmeter端并不會再回一個Fin+ACK拄衰，而是回的ACK，這樣就不會理會服務(wù)端的主動關(guān)閉饵骨；
于是服務(wù)端存在很多的Fin_wait_2翘悉，而客戶端有很多的Close_wait。正基于此居触，客戶端的http請求發(fā)送給服務(wù)端時妖混，只到了tcp層面就被RST了，所以返回的http是空應(yīng)答轮洋，當返回給HttpClient進行頭解析時沒有Http的數(shù)據(jù)包制市，而是返回的TCP數(shù)據(jù)包。因此才有了以上的報錯信息弊予。
這里我有一個疑問祥楣，那就是當服務(wù)端處于Fin_wait_2狀態(tài)時，如果接收到了請求信息汉柒，那么tcp協(xié)議是如何處理這個連接請求的误褪。
最后終于在這篇文章中找到了答案主動關(guān)閉TCP連接的一方為什么要有TIME_WAIT狀態(tài)
TCP連接是全雙工通信，主動方和被動方都需要自主關(guān)閉通信鏈路碾褂，TCP正常情況下連接斷開會進行四次揮手（流程如上圖所示）：
1.由主動斷開方發(fā)起FIN
2.被動方回復ACK
3.待被動方數(shù)據(jù)傳輸完成兽间，被動方發(fā)送FIN
4.主動方回復ACK，并進入TIME_WAIT狀態(tài)
TIME_WAIT的狀態(tài)會持續(xù)2MSL （MSL是報文在網(wǎng)絡(luò)中生存的最大生命周期）正塌。
那這里為什么需要2MSL的狀態(tài)嘀略？原來TCP是建立在非連接鏈路的可靠傳輸通信方式，若在步驟4中發(fā)出ACK乓诽，由于網(wǎng)絡(luò)原因ACK報文被動方?jīng)]有收到帜羊，等到2MSL從而觸發(fā)被動方重新發(fā)送FIN包，若主動方不存在TIME_WAIT 會出現(xiàn)如下情況：
a. 原來的TCP信息已經(jīng)不存在问裕，主動方回復RST逮壁，引起被動方關(guān)閉流程錯亂
b.在原來端口上建立了新的TCP連接，影響新的流程
理解了上述的描述粮宛，回過頭來jmeter的這個問題原因就已經(jīng)找到了窥淆。
那么，如何解決呢巍杈？
- 首先忧饭，jmeter的在這里是客戶端的角色，它為什么只發(fā)了ACK筷畦，但不發(fā)FIN指令呢词裤？這個問題還無法搞清楚刺洒；
- 那么退而求其次，有沒有辦法讓它發(fā)送ACK+FIN呢吼砂？答案肯定是有的逆航。在jmeter.properties中有的idletimeout的時間設(shè)置上；
根據(jù)文章描述渔肩，idletimeout<connectionTime是最有效的方式因俐；此外還提供了一種方式：
那這個問題就落在服務(wù)端的主動關(guān)閉上了，不讓服務(wù)端主動關(guān)閉就行了周偎。----把 connectionTimeout 盡可能的調(diào)大抹剩，建議 connectionTimeout = 最耗時接口的一次并發(fā)的總時間 * 接口個數(shù)Ideltimeout <= 最耗時接口的一次并發(fā)的總時間----測試完，把connectionTimeout這個值在改回原值即可蓉坎。
我認為澳眷，最后這個提議是比較好的方式；這篇文章的分析非常好蛉艾，讓我對TCP/IP協(xié)議與HTTP協(xié)議的關(guān)系有了一定程度的了解钳踊；
