TCP連接流失是什麼意思？

Question

在web服務的上下文中，我使用過術語「TCP連接流失」。特別是Twitter finagle有辦法避免它發生。它是如何發生的？這是什麼意思？

Answer 1

這個術語可能有多種用途，但我總是看到它在很短的時間內進行很多TCP連接的情況下使用，從而導致客戶端和服務器上的性能問題。

當客戶端代碼被寫入時，通常會發生這種情況，該代碼會自動連接到任何類型的TCP故障。如果在連接失敗之前（或者在協議交換中很早）出現連接失敗，那麼客戶端可能會進入一個接近繁忙的循環，不斷進行連接。這可能會導致客戶端的性能問題 - 首先，在非常繁忙的循環中會有一個進程吸入CPU週期，其次，每次連接嘗試都會消耗一個客戶端端口號 - 如果速度足夠快，軟件可以環繞當它們達到最大端口號時（因爲端口只有16位數，這當然不是不可能的）。

雖然編寫健壯的代碼是一個有價值的目標，但這種簡單的「自動重試」方法有點太天真了。您可以在其他情況下看到類似的問題 - 例如一個父進程不斷重啓一個立即崩潰的子進程。避免這種情況的一種常見機制是某種增加的後退。所以，當第一次連接失敗時，您立即重新連接。如果在短時間內（例如30秒）再次失敗，則等待重新連接前2秒鐘。如果在30秒內再次失敗，則等待4秒鐘，以此類推。閱讀the Wikipedia article on exponential backoff（或this blog post可能更適合此應用程序）以獲取有關此技術的更多背景信息。

此方法的優點是不會壓倒客戶端或服務器，但這也意味着客戶端仍可以在無人工干預的情況下恢復（這對於無人蔘與的服務器上的軟件尤其重要，例如，或者大型集羣）。

在恢復時間很關鍵的情況下，TCP連接創建的簡單速率限制也是很有可能的 - 可能不會超過每秒1次。但是，如果每臺服務器的客戶端數量衆多，這種更簡單的方法仍然會使服務器受到負載的影響而關閉較高的連接速率。

如果您計劃採用指數回退，我會建議一個最大等待時間，或者您可能會發現，一旦服務器端再次開始接受連接，長時間的故障會使客戶端花費很長時間來恢復。在大多數情況下，我會建議像5分鐘這樣的合理的最大值，但當然這取決於應用程序。