有時候我們抓取網(wǎng)絡包發(fā)現(xiàn)TCP RESET幀，我們想知道此時網(wǎng)絡出了什么問題。僅看到TCP RESET幀不能說明網(wǎng)絡出現(xiàn)問題，因為RESET幀發(fā)送的原因有很多，并不是所有的原因都是網(wǎng)絡出問題導致的。事實上，RESET是個好東西，它可以用于關(guān)閉之前打開的連接。舉個例子，我們的應用建立了很多短連接，但我們不想在服務端time wait狀態(tài)時繼續(xù)保持連接，所以，客戶端通過RESET重置連接。
三次握手
先說下tcp連接。當網(wǎng)絡中的一個節(jié)點通過TCP協(xié)議向另一個節(jié)點通信，它們就會建立TCP連接。此時，客戶端節(jié)點向服務端節(jié)點發(fā)送Synchronization（SYN）幀。該數(shù)據(jù)包中包含了建立連接和傳送數(shù)據(jù)所需的所有信息，但這兒我們感興趣的是端口信息，連接通常在客戶端的源端口和服務端的目標端口之間發(fā)生。SYN幀中會包含發(fā)送者的源端口和節(jié)點想要連接到的目標端口。
下圖就是一個SYN幀數(shù)據(jù)包，你可以看到TCP:Flags= .......S，表示這是一個SYN幀。SrcPort是源端口，這是客戶端用來建立連接的客戶端端口。DstPort是目標端口，本例是445（Direct SMB端口）。服務端會監(jiān)聽該端口以便接收SYN數(shù)據(jù)包和后續(xù)通信。
接下來的兩幀會完成連接的建立。第二個幀是ACK+SYN幀，服務端確認接收第一個SYN幀，并發(fā)送自己的SYN幀。這兩個動作在同一個幀中發(fā)生。注意，此時源和目標端口與第一幀SYN中的源和目標端口是對換的。
最后一幀是客戶端收到服務端的SYN后巷服務端發(fā)送的確認幀，此后，兩節(jié)點之間的連接建立。
time wait狀態(tài)
什么是time wait狀態(tài)？為什么說它很重要？當TCP連接關(guān)閉（gracefully）時，主動關(guān)閉一端會向?qū)Χ税l(fā)送FIN幀。表示主動關(guān)閉端不再有數(shù)據(jù)發(fā)送。對端會發(fā)送ACK幀。當對端不再有數(shù)據(jù)發(fā)送，也會主動發(fā)送FIN幀給這一端，這一端也會向?qū)Χ税l(fā)送ACK幀。當兩端都發(fā)送了FIN幀，并且都收到了ACK幀，此時，TCP連接會進入time wait狀態(tài)。默認情況下，連接會保持time wait狀態(tài)4分鐘。這保證了仍然在網(wǎng)絡中的數(shù)據(jù)包可以使用該連接繼續(xù)傳輸。
現(xiàn)在我們知道了如何建立和優(yōu)雅關(guān)閉TCP連接，接下來讓我們討論一下如何/為什么我們會重置TCP連接。
resets
什么是reset？TCP reset表示立即關(guān)閉TCP連接。這保證了之前連接分配的資源能夠得以釋放，并為系統(tǒng)所用。以下是一些發(fā)生TCP重置的場景。
SMB reset（客戶端主動reset）
有的客戶端與服務端建立TCP連接時發(fā)送兩個SYN幀，分別使用不同的目標端口。服務端收到兩個SYN幀后，分別對兩個幀發(fā)送ACK+SYN。客戶端收到ACK+SYN后選擇一個發(fā)送ACK建立連接，另一個發(fā)送RESET關(guān)閉連接。
ACK+RESET（服務端主動reset）
客戶端發(fā)送SYN幀，服務端由于某些原因無法與客戶端建立連接，結(jié)果發(fā)送ACK+RESET幀。這些原因包括：
- 服務端沒有監(jiān)聽客戶端想要連接的端口；
- 服務端資源不足，不能分配連接所需要的資源等。
由于沒有響應導致的TCP重置
假設我們已經(jīng)經(jīng)過三次握手建立了一個TCP連接。當一個網(wǎng)絡數(shù)據(jù)包連續(xù)發(fā)送了六次都沒有收到響應，此時發(fā)送端會主動重置TCP連接。重置前的重傳次數(shù)是可以配置的，默認情況下是5。（默認情況下，建立連接時重傳SYN幀的最大值是2，但也是可配的）。
這里有幾個要點需要牢記，初學者很容易忽略并認為發(fā)生了TCP重置，而實際上沒有。注意重傳次數(shù)。在上例中，發(fā)送端發(fā)送幀，并且沒有收到確認，此時TCP發(fā)送重傳，每次都沒有收到確認。當數(shù)據(jù)包第五次重傳以后，發(fā)送端等待一定時間確認。如果仍然沒有收到確認，發(fā)送RESET幀重置連接。需要注意的要點：
- 同一個數(shù)據(jù)包重傳5次；
- 發(fā)送端發(fā)送了其他幀并收到了響應的確認沒有關(guān)系，我們關(guān)注的是重傳的幀；
- late acknowledgement不會導致該重置現(xiàn)象。
應用重置
如果我們觀察網(wǎng)絡通信狀況，但找不到TCP發(fā)送重置的原因，那么重置一定是來自應用程序本身。這在建立大量TCP短連接的應用程序里很常見。由于大量端口出在time wait狀態(tài)，這可能導致服務端端口枯竭。盡管如此，在重置所有連接之前，應用開發(fā)人員仍需要了解為什么time wait狀態(tài)的存在。
Note：看一下程序代碼里有沒有調(diào)用close(socket)。如果在發(fā)送數(shù)據(jù)的連接數(shù)調(diào)用了close，會產(chǎn)生一個RESET數(shù)據(jù)幀。如果在三次握手建立連接后，直接調(diào)用close，而沒有數(shù)據(jù)傳輸，這會產(chǎn)生一個FIN數(shù)據(jù)幀來優(yōu)雅關(guān)閉連接。
另一種可能性就是目標節(jié)點上的其他進程已經(jīng)監(jiān)聽了該目標端口，這也可能導致應用重置的發(fā)生。
對于高級用戶和網(wǎng)絡管理員
在網(wǎng)絡傳輸中發(fā)生的問題是最難以解決的問題。如果對reset的發(fā)生理解不深，很難跟蹤調(diào)試。網(wǎng)絡中的很多設備，如路由器、防火墻等，都可能重置網(wǎng)絡連接。解決這種特殊重置行為的唯一辦法就是跟蹤從源到目的節(jié)點的整個網(wǎng)絡路徑。比如，從一個節(jié)點捕獲到了RESET幀，并且期望在另一個節(jié)點也能捕獲到，而實際上沒有捕獲到，說明這兩個節(jié)點直接存在問題。
另一個有趣的現(xiàn)象是中間設備可以重置客戶端和服務端的連接。舉個例子，在兩個節(jié)點之間建立了TCP連接。源IP10.10.10.20，目的IP10.10.10.30，在TCP端口2301和445之間建立了連接。我們可能捕獲到了發(fā)往10.10.10.20:2301的重置幀和發(fā)往10.10.10.30:445的重置幀。
端口重用
如果應用程序試圖重用出在time wait狀態(tài)的端口，這可能導致Reset。當客戶端和服務端之間的連接已經(jīng)經(jīng)由優(yōu)雅關(guān)閉進入time wait狀態(tài)時，同一個客戶端通過發(fā)送SYN幀（相同的源和目標端口）試圖重用同一個端口對。根據(jù)RFC1122，這是允許的。但請注意，這樣做是有風險的，別忘了端口保持time wait是有原因的。
警告：SYN幀中的序列號（被發(fā)送以通過已有的連接建立新連接）應該大于之前連接中最后幀的序列號。如果不是，會導致連接重置。
總結(jié)
TCP重置是個好東西。如果沒有它們，當TCP遇到網(wǎng)絡連接問題時，會出現(xiàn)大量問題。請記住，連接重置可能發(fā)生自網(wǎng)絡棧和應用程序。僅僅因為存在重傳數(shù)據(jù)包并不能推斷連接會自動重置。重要的是，確定數(shù)據(jù)幀并理解發(fā)送重傳的原因。
詳情請看這里：Where do resets come from?