可以通過編程方式終止TCP/IP協議棧嗎？

我們的服務器應用程序正在監聽一個端口，一段時間後它不再接受傳入的連接。（雖然我很想解決這個問題，但這不是我在這裏問的問題;）可以通過編程方式終止TCP/IP協議棧嗎？

奇怪的是，當我們的應用程序停止接受端口44044上的連接時，IIS（在端口8080上）。殺死我們的應用程序修復了一切 - IIS再次開始響應。

所以問題是，應用程序可以搞砸整個TCP/IP協議棧嗎？或者，應用程序如何做到這一點？

毫無意義的細節：我們的應用程序是用C＃寫的，在.Net 2.0下，在XP/SP2上。

說明：IIS不是「拒絕」嘗試的連接。它從來沒有看到他們。客戶正在收到一個「服務器沒有及時響應」的消息（使用.Net TCP客戶端）。

來源

2008-09-25 Gene

相反的解決方法呢？如果你殺了IIS，你的應用程序是否開始接受連接並響應流量？ – benc 2009-01-07 07:41:02

您可能捱餓的堆棧。每秒很高的開/關交易量很容易，例如， Web服務器提供大量未混合的請求。

這是由默認TIME-WAIT延遲exhacerbated - 一個插座具有被回收默認爲20世紀90年代之前被關閉（如果我沒記錯的話）的時間量

還有一堆註冊表項的那個可以調整 - 建議至少以下密鑰創建/編輯

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 

TcpTimedWaitDelay = 30 
MaxUserPort = 65534 
MaxHashTableSize = 65536 
MaxFreeTcbs = 16000

大量文檔的上MSDN &的Technet有關這些鍵的功能。

來源

2008-09-25 17:03:02 stephbu

這會幫助我們暫時避免這個問題。儘管如此，我們最終還是會停下腳步。感謝您的幫助。 – Gene 2008-10-09 18:34:23

您是否還沒有使用可用的端口句柄？
netstat -a

當應用程序打開和關閉端口時（但並未正確關閉它們），我看到類似的情況。

來源

2008-09-25 13:50:59 RichS

好的建議。我們一直在使用netstat和TCPView（http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx）進行診斷，但沒有發現我們。 – Gene 2008-09-25 15:27:00

netstat可能不是最好的工具，因爲它沒有提供關於創建連接的很多信息。 – benc 2009-01-07 07:42:16

使用netstat -a可以在發生這種情況時查看活動連接。也許，你的服務器應用程序沒有關閉/處理'關閉'連接。

來源

2008-09-25 13:52:17 leppie

我猜RichS的端口號評論是正確的。

除此之外，TCP/IP堆棧只是您操作系統中的一個模塊，因此可能存在可能導致應用程序終止它的錯誤。它不會是第一個被程序殺死的驅動程序。

（前端朝着安德魯的Tanenbaum的帽子堅持要求操作系統應該是模塊化的，而不是鐵板一塊。）

來源

2008-09-25 13:54:09 xmjx

我自己也遇到過幾次類似的情況。一個很好的故障排除步驟是嘗試從受影響的機器連接到目前尚未遇到任何連接問題的已知目標。如果連接嘗試失敗，您很可能會在錯誤消息/代碼中獲得更多有趣的細節。例如，它可以說沒有足夠的句柄或內存。

來源

2008-09-25 22:20:02 Alexander

來自大家的好建議，感謝您的幫助。

因此，發生了什麼事情：事實證明，我們有幾個服務競爭同一個端口，並且大多數時候「適當」的服務會獲得端口。有時候第二項服務會把端口拿走，第一項服務會嘗試打開不同的端口。從那時起，服務會在每次服務請求時繼續抓住新端口（因爲他們沒有使用他們的首選端口），最終我們會耗盡所有可用的端口。

當然，實際的問題是：「應用程序是否可以搞砸整個TCP/IP協議棧？」，這個問題的答案是：是的。一種方法是聽一大堆端口。

來源

2008-10-09 18:41:41 Gene

從支持和系統管理員的角度來看，我只在罕見的場合（不止一次）看到過這種情況，但它肯定會發生。

當您診斷問題時，您應該小心消除可能的原因，而不是在遇到問題時立即重啓系統。我只是這樣說，因爲許多與我合作的客戶都很想這麼做。

來源

2009-01-07 07:45:37 benc

可以通過編程方式終止TCP/IP協議棧嗎？

回答

相關問題