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