RST：（Reset the connection）用於復位因某種原因引起出現的錯誤連接，也用來拒絕非法數據和請求。如果接收到RST位時候，通常發生了某些錯誤；
發送RST包關閉連接時，不必等緩衝區的包都發出去，直接就丟棄緩衝區中的包，發送RST；
接收端收到RST包後，也不必發送ACK包來確認。
哪些情況會發送RST
（1）server關閉的情況下client發送數據
如果連接是CLOSE狀態，所有收到的包都響應RST，仍然保持CLOSED狀態
如果收到的是ACK報文，RST取ACK報文的ACK序列號爲RST報文的SEQ；如果報文不是ACK報文，RST的SEQ爲0且ACK字段爲收到的報文SEQ+報文長度；
（2）tcp連接在non-synchronized狀態下收到的報文ACK的無效的序列號
如果連接在non-synchronized狀態（LISTEN/SYN-SENT/SYN-RECEIVED），收到的報文ACK的無效的序列號（發送的SYN沒有被確認），需要返回RST報文；連接保持原有狀態；
如果是ACK報文，RST取ACK報文的ACK序列號爲RST報文的SEQ；如果報文不是ACK報文，RST的SEQ爲0且ACK字段爲收到的報文SEQ+報文長度；
（3）tcp連接在synchronized狀態收到不可接受的報文
如果連接在synchronized狀態（ESTABLISHED,FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT）,如果收到不可接受的報文（序列號不在接收窗口內或者ack的字段不正確），只發送一個確認報文（ACK字段爲期望ACK的序列號，SEQ爲當前發送序列號），狀態變保持原樣；
如何處理髮送的RST
收到RST報文，除了SYN-SENT狀態，都需要校驗SEQ字段是否在接收窗口；SYN-SENT狀態下，如果RST的確認了剛剛發送的SYN報文，RST纔有效；
校驗了RST報文後，如果是在LISTEN狀態則保持該狀態不需要改變；
如果是在SYN-RECIEVED狀態且之前在LISTEN狀態，恢復爲LISTEN狀態，如果之前爲SYN-RECIEVED狀態且之前不是LISTEN狀態，則CLOSED；
其他狀態，關閉連接通知用戶，狀態變爲CLOSED
RST攻擊
A和服務器B之間建立了TCP連接，此時C僞造了一個TCP包發給B，使B異常的斷開了與A之間的TCP連接，就是RST攻擊了。實際上從上面RST標誌位的功能已經可以看出這種攻擊如何達到效果了。
那麼僞造什麼樣的TCP包可以達成目的呢？我們至頂向下的看。
假定C僞裝成A發過去的包，這個包如果是RST包的話，毫無疑問，B將會丟棄與A的緩衝區上所有數據，強制關掉連接。
如果發過去的包是SYN包，那麼，B會表示A已經發瘋了（與OS的實現有關），正常連接時又來建新連接，B主動向A發個RST包，並在自己這端強制關掉連接。
這兩種方式都能夠達到復位攻擊的效果。似乎挺恐怖，然而關鍵是，如何能僞造成A發給B的包呢？這裏有兩個關鍵因素，源端口和序列號。
一個TCP連接都是四元組，由源IP、源端口、目標IP、目標端口唯一確定一個連接。所以，如果C要僞造A發給B的包，要在上面提到的IP頭和TCP頭，把源IP、源端口、目標IP、目標端口都填對。這裏B作爲服務器，IP和端口是公開的，A是我們要下手的目標，IP當然知道，但A的源端口就不清楚了，因爲這可能是A隨機生成的。當然，如果能夠對常見的OS如windows和linux找出生成source port規律的話，還是可以搞定的。
序列號問題是與滑動窗口對應的，僞造的TCP包裏需要填序列號，如果序列號的值不在A之前向B發送時B的滑動窗口內，B是會主動丟棄的。所以我們要找到能落到當時的AB間滑動窗口的序列號。這個可以暴力解決，因爲一個sequence長度是32位，取值範圍0-4294967296，如果窗口大小像上圖中我抓到的windows下的65535的話，只需要相除，就知道最多只需要發65537（4294967296/65535=65537）個包就能有一個序列號落到滑動窗口內。RST包是很小的，IP頭＋TCP頭也才40字節，算算我們的帶寬就知道這實在只需要幾秒鐘就能搞定。
那麼，序列號不是問題，源端口會麻煩點，如果各個操作系統不能完全隨機的生成源端口，或者黑客們能通過其他方式獲取到source port，RST攻擊易如反掌。
參考鏈接
https://zhangbinalan.gitbooks.io/protocol/content/tcpde_rst.html
http://blog.csdn.net/russell_tao/article/details/7228923