tcp協議中rst異常關閉的問題，？

06-04

按我理解，發送方送rst後直接釋放連接，接收方收到rst後也釋放連接，不需要回復ack。那麼問題在於，如果發送方發送的rst包本身丟掉了，沒有到達接收端，而發送方發送之後就關閉連接，會不會造成接收方連接半關閉的狀態？

回答這個問題之前，先要了解在哪些情況下TCP的一方會發送RST（Reset）給另外一方。

學習TCP的很多讀者，會知道一個TCP連接在數據傳輸完畢，通常會關閉連接，以釋放通信雙方的資源，如內存、埠號，以便於其它程序使用，這種正常釋放連接的過程，通常使用FIN（Final）狀態位來完成。

但FIN狀態位不能用來處理異常情況。

異常情況一：

客戶端、伺服器端TCP連接一切正常，TCP連接由於沒有數據傳輸而出於空閑（Idle）狀態。

突然伺服器掉電，當伺服器重新啟動完畢，與客戶端的TCP連接狀態由於掉電而完全消失。

之後，客戶端發給伺服器任何消息，都會觸發伺服器發RST作為回應。

伺服器之所以發RST，是因為連接不存在，通過Reset狀態位，間接告訴客戶端異常情況的存在。

如果Reset順利到達客戶端，客戶端意識到異常發生了，會立馬釋放該TCP連接所佔用的內存資源（狀態、數據）、以及埠號。

客戶端TCP會通知數據的主人（應用程序），由於TCP連接被對方Reset，數據發送失敗。

客戶端無需超時等待，立即使用原有埠號，重新發起一個TCP連接，雙方狀態再一次同步，進入正常通信狀態。

這種情況是由於外界因素影響，使得雙方狀態不同步，一方為「established」，另一方為「closed」, 重置（Reset）連接狀態是最好的方法！

有讀者會問，如果客戶端一直沒有消息發給伺服器端，那雙方狀態的不同步是否會保持到天長地久？

會的！

但是考慮到當前的網路狀況，這種可能性是比較小的，因為目前的網路NAT無處不在，為了克服NAT表項沒有流量刷新而刪除NAT表項，進而影響客戶端、伺服器端通信，如今的TCP實現會在幾十秒發送一次Keepalive，這樣即使沒有用戶流量，Keepalive也會刷新NAT表項，從而避免NAT設備刪表操作。

所以雙方通信不同步狀態，在當今的TCP實現上會很快監測到、並予以糾正。

更詳細內容請關注微信公眾號：車小胖談網路https://mp.weixin.qq.com/s/oF4m39qkUBg1ylQMxomZRQ

如果在正常通信的過程中，雙方連接都處於established狀態時。一端因為某種原因發送了rst段後釋放了本端連接，如果這個rst段在傳輸過程中丟失沒有到達對端，對端仍然處於established狀態，此時對端的連接狀態成為半打開(Half open)狀態。如果對端沒有send的需求，並且也沒有開啟keepalive，那麼對端這個連接就永遠也不釋放，直到連接所屬的進程退出。

當然可以。某次 A機一個程序出了bug,發瘋的連接B機的redis 建了不知多少萬連接，然後A機hang住了，於是把A機重啟了事。。

。。隔了幾十分鐘，B機redis說連不上了，一頓strace搗鼓，居然看到進程fd不夠沒法accept了。。。

半關閉是指一方結束髮送後還能接收另一端發送的數據。

題主想表達的應該是半打開：一方已經關閉或者異常終止而另一方還不知道。

是會浪費資源，但是向半打開的連接寫數據也會收到RST的。

RST發送後就關閉，這是撒意思，發送FIN？這是沒有的，RST後鏈接就斷了，如果對方沒有收到RST繼續發送，那會收到後續的RST消息，而知道連接已經重置了。如果對方也沒有發送數據，那肯定不會進入半關閉狀態的，練路狀態的檢測只有靠keepalive 心跳了。

這種情況，如果應用層本身不做管理就只能等TCP超時，

DDos了解一下。

silverlight 使用943埠驗證，客戶端收到策略後，如果收到是rst，sl客戶端不會發起連接，如果收到是fin，客戶端正常發起連接，怪異