多次RST以及不同場景下的RST報文的差異

在某個tcp互動過程中，我們發現在互動的後期，客戶端多次向伺服器端傳送rst報文，如下圖所示：

我們首先來看客戶端發出的第乙個rst報文的解碼：

rst與ack標誌位都置一了，並且具有ack number，非常明顯，這個報文在釋放tcp連線的同時，完成了對前面已接收報文的確認。

我們再來看看客戶端發出的後續rst報文的解碼：

我們可以看到，這些後續的rst報文僅reset位置一，ack位未置一，在這種情況下，該報文的ack確認號應該為0，但是我們留意到在這個報文中，其ack確認號與序列號是一致的。

這是為什麼呢？

因為ack位未置一，ack確認號也就失去了意義，因此，不論ack確認號是什麼值都不會對接收端產生影響，因此大部分的系統都會將ack確認號設定為0，之所以在這個報文中出現ack確認號非0而是與序列號一致的情況，個人認為應該是該主機端系統的處理機制與大部分系統不一樣導致的。

另外，我們也看到了wireshark的專家系統在此處給出了提示，由此可見wireshark在傳輸層的專家系統的強大之處。

為什麼前後rst報文會出現這種差異？

原因為第乙個rst報文是異常釋放tcp連線的，在端系統傳送rst報文之前，這個tcp連線尚在端系統的連線表中，因此其ack位置一並且具有ack確認號。而客戶端後續收到data報文，因其連線表中已經沒有相關資訊與之對應，此時客戶端傳送的rst報文ack位無需置一。

也許有朋友會問：伺服器端為什麼在收到客戶端的rst報文後，還繼續給客戶端傳送報文呢？

原因只有乙個，那就是tcp成塊資料流。伺服器端一次性向客戶端傳送數個資料塊，在客戶端發出第乙個rst報文之後，後續的報文已經在網路中傳輸了，並陸續達到客戶端。

其互動過程大致如下：

標籤: tcp

wireshark

rstack

連線表tcp成塊資料流

端系統ack確認號連線