我有一台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