TCP零視窗攻擊？

摘自：

滑動視窗的概念大家可以自行搜尋，這裡就不贅述了，大致的概念是傳送和接受雙方都各有乙個傳送視窗和乙個接受視窗，其主要目的就是為了流量控制，使雙方的傳送、接收速度盡可能匹配。

當傳送方的傳送速度大於接收方的處理速度，接收方的緩衝塞滿後，就會告訴傳送方當前視窗size=0，請停止傳送，傳送方此時停止傳送資料。

零視窗出現後，如何繼續資料的傳輸呢。我們假設：接收方視窗更新為非0後，傳送ack給傳送方，更新window的size，是一種可行的方式。但是如果這個ack丟掉了（tcp不會給ack回覆ack），那麼傳送方和接收方就會處於一種尷尬的局面，乙個等著發，乙個等著收，直到超時。

此時引入了堅持定時器的概念，由傳送方主動建立，持續不斷地詢問接收方視窗是否更新，這個詢問被稱為視窗探測（window probes）。

終於到了問題的關鍵，這個定時器沒有時間限制，意味著這個tcp連線會永遠保持下去。

google了很久，沒有查到各大作業系統對於堅持定時器的時間設定，提到零視窗攻擊的資訊也很少，擷取其中乙個明確提到零視窗攻擊的頁面，來自乙個硬體負載均衡的廠商的產品介紹，貌似硬體防火牆或者負載均衡裝置應該有相關的防護設定：

原鏈結

public class client
system.out.print(line);
}......
}

修改tomcat原始碼，將socket物件暴露給業務**，業務**將所有socket和已經傳送的位元組數快取起來（每次傳送資料後即更新對應的位元組數），每隔一段時間掃瞄一遍，將超過閾值時間後傳送位元組仍然沒有變化的socket，強制呼叫socket.close()將其關閉。

socket.setsolinger(true, 0); // socket是阻塞io，資料不傳送完預設是關不掉的，需要設定solinger
socket.close();

寫這篇文章時，試了一下nio的connector會如何，測試結果也不盡人意，堅持定時器仍然生效，過一會兒連線狀態遷移為fin_wait1（抓包裡沒看到發fin，奇怪），連線控制代碼仍然被占用。

恐怖的是，./shutdown.sh關了tomcat，控制代碼仍不能釋放，堅持定時器仍然在持續不斷地探測…客戶端已經利用tcp的機制，綁架了服務端作業系統層面的控制代碼資源？

參考

[1]: