我們在介紹TCP頭的時候，提到過其中有個RST標志位。當一個TCP報文中這個標志位打開的時候，我們叫做reset包(嚴格的說應該叫做reset段，但是很多時候段包幀並不加以區分)或者簡單稱呼為reset、RST。通常reset的產生是由於一個異常包導致，reset一般會導致TCP連接的快速斷開。產生reset的幾種常見的情形如下
-
向一個未打開的端口發送連接請求
應用程序主動終止一個連接
應用程序還沒有接收緩存中的數據，連接被提前關閉
TWA(TIME-WAIT Assassination)
半開連接的情況下發送數據
注意我們這里是描述的reset產生的一些場景(而且是部分場景)，在具體reset的產生原因上可能會有重復，比如第1、4、5都可以認為是對端沒有打開相對應的TCP端口。
一、向一個未打開的端口發送連接請求
reset產生的一個常見的原因是，在一個未打開的端口發送連接請求。這里未打開的端口是指沒有應用程序在監聽這個端口等待連接。
如下圖wireshark抓包，再不開啟server情況下，沒有應用程序監聽9877端口，當client連接9877端口的時候就會產生reset消息。
注意我截圖中的系列號，在這個截圖中我設置了wireshark顯示絕對系列號(前面文章截圖顯示的都是相對系列號)，因為SYN包中的ACK標志沒有置位，ack number字段無效(實際是以0填充的)，所以在reset中的seq=0,ack則為SYN包中的seq+1(因為SYN標志和FIN標志在邏輯上占1byte)。一個reset包如果要被TCP endpoint接收，ACK標志必須置位且ack number落在有效的窗口區間內(窗口相關知識后面細講)。這幫助阻止了一個簡單的reset攻擊(RFC5961)，否則攻擊者可以通過偽造源IP地址、源端口號構造一個reset消息來中斷TCP連接。
二、應用程序主動通過reset消息終止一個連接
應用程序可以通過socket API接口設置主動reset一個TCP連接，這種情況下的連接中斷過程稱為abortive release。之前我們介紹過的四次揮手之類的通過FIN終止連接的過程我們稱呼為orderly release。在abortive release情況下，reset包的發送端緩存的待發送數據都會直接丟棄，接收端接收到reset后也可以知道是對端主動abort了這個tcp連接。
wireshark截圖如下，注意client發送reset后，並不會引起server回應ACK之類的消息。
可以看到RST消息的seq正好是對端期望接收的seq，按照RFC5961要求，非SYN_SENT狀態下，接收端需要判斷RST消息的系列號seq為正好為自己期望接收的seq，才會認為這個RST消息有效。如果RST的系列號seq落在接收窗口內但不是期望的seq時候，接收端需要發送challenge ACK，如果落在接收窗口外則會直接丟棄這個RST消息。(實際上challenge ACK也會引起RST，詳見RFC5961,此處不做介紹。)
三、應用層還沒有讀取完接收緩存中的數據，連接被提前關閉
當TCP接收端緩存中還有緩存數據而沒有被應用層接收，但是應用層直接關閉TCP連接時候就會產生reset，如下圖wireshark抓包所示，連接建立后client向server發送10bytes的數據，server應用層並沒有讀取這10bytes的數據而是直接關閉tcp連接就會產生reset。
四、TWA(TIME-WAIT Assassination)
TCP在TIME-WAIT狀態下的時候，如果接收到reset包，它可能會提前結束TIME-WAIT狀態，這種行為即叫做TIME-WAIT Assassination(TWA)，數據包的流程如下圖所示
為了避免TIME-WAIT狀態提前被reset結束，一些系統的TCP實現在TIME-WAIT狀態下不會響應rst消息。linux則可以通過net.ipv4.tcp_rfc1337設置TCP在TIME-WAIT下是否響應reset，如果設置tcp_rfc1337為0，在TIME-WAIT下如果接收到reset則會直接關閉tcp連接，而不會等到2MSL超時。
五、半開連接的情況下發送數據
關於半開連接我們前面已經進行了介紹，同時wireshark抓包中也有對應的reset的展示，此處不再介紹。