我有一臺TCP服務器從一個（也是唯一的）客戶端獲取數據。當這個客戶端發送數據時，它連接到我的服務器，發送一個（邏輯）消息，然後不再發送該連接。TCP連接資源密集？
然後它將發送另一個連接發送下一條消息。
我有一位同事說，從資源的角度來看，這是非常糟糕的。他說，建立聯繫需要資源，需要一段時間。他說我需要讓這個客戶端建立連接，然後只要我們需要溝通（或者直到出現錯誤）就繼續使用它。
使用單獨的連接的一個好處是，我可以多線程他們並獲得更多的吞吐量。我向我的同事提到了這一點，他告訴我，打開很多套接字將會終止服務器。
這是真的嗎？或者我可以讓它爲每個需要發送的邏輯消息建立一個單獨的連接。 （請注意，通過邏輯消息，我的意思是一個長度可變的xml文件。）
這完全取決於您打算打開和關閉的連接數以及打算打開它們的速率。
除非您通過中止連接而不是正常關閉連接來避免TIME_WAIT狀態，否則您將在客戶端或服務器上累積TIME_WAIT狀態的套接字。對於單個客戶來說，實際上這些問題並不重要，因爲問題會相同。如果您使用連接的速度快於連接關閉的速度，那麼您將最終達到無法打開任何新連接的程度，因爲您沒有臨時端口，因爲它們都在使用中插座在TIME_WAIT。
一般來說，我會建議你保持一個連接，只需重新打開它，如果它被重置。這個邏輯看起來可能稍微複雜一點，但系統的規模要好得多;你可能只有一個客戶現在和連接的速率可以使得你不要指望從TIME_WAIT問題遭受但這些事實可能不會留你的系統的生命一樣......
TCP連接的啓動順序是一個非常簡單的3路握手，開銷非常低。無需保持連接。
也有很多TCP連接不會如此快地殺死你的服務器。現代硬件和操作系統可以處理數百個併發TCP連接，除非您害怕顯然不屬於該問題範圍的拒絕服務攻擊。
如果你的服務器只有一個客戶端，我無法想象在實踐中，每個消息打開一個新的TCP套接字都會有任何問題。聽起來你的同事喜歡過早地優化。
但是，如果您使用消息氾濫服務器，則可能會成爲問題。但是，對於單個客戶，我不會擔心。
只要確保在完成後關閉套接字。不需要粗魯的服務器:)
除了大家所說的，考慮UDP。對於沒有預期響應的小型消息，以及在本地網絡（而不是互聯網），它非常適合實際可靠。
+1對於UDP。通知樣式消息更有意義。 – rossipedia
感謝您的提示，但我必須確認消息。 – Vaccano
從服務器的角度來看，打開大量連接不成問題。
How many socket connections can a web server handle?
從客戶的角度來看，如果測量表明您需要避免時間發起連接，你想並行，你可以創建一個連接池。多個線程可以重新使用每個連接，並在完成後將它們釋放回池中。這確實再次提高了複雜性級別，確保您需要它。您也可以根據活動使邏輯縮小和擴展池 - 在應用程序剛剛閒置的情況下，讓連接在服務器上保持打開狀態的過程會很尷尬。
你遇到任何問題與您目前的實施？不要創造比必要更難的解決方案。 – zerkms