繁体   English   中英

TCP连接是否占用大量资源?

[英]Are TCP Connections resource intensive?

我有一台TCP服务器,该服务器从一个(只有一个)客户端获取数据。 当此客户端发送数据时,它将与我的服务器建立连接,发送一条(逻辑)消息,然后不再通过该连接发送任何消息。

然后它将建立另一个连接以发送下一条消息。

我有一位同事说,从资源的角度来看,这是非常糟糕的。 他说建立连接需要大量资源,并且需要一段时间。 他说,我需要让该客户端建立连接,然后在我们需要沟通的时间内(或者直到出现错误)一直使用它。

使用单独的连接的好处之一是,我可以对它们进行多线程处理,从而获得更多的吞吐量。 我向我的同事提到了这一点,他告诉我,打开许多套接字会杀死服务器。

这是真的? 或者我可以允许它为每个需要发送的逻辑消息建立单独的连接。 (请注意,逻辑消息是指长度可变的xml文件。)

TCP连接的启动序列是一个非常简单的三向握手,开销很低。 无需保持恒定的连接。

另外,拥有许多TCP连接不会很快杀死您的服务器。 现代硬件和操作系统可以处理数百个并发的TCP连接,除非您担心拒绝服务攻击显然不在此问题范围之内。

如果您的服务器只有一个客户端,那么在实践中我无法想象每条消息打开一个新的TCP套接字会出现任何问题。 听起来您的同事喜欢过早地进行优化。

但是,如果您在服务器上充斥消息,则可能会成为问题。 但是,即使只有一个客户,我也不用担心。

完成后,只需确保关闭插座即可。 无需对服务器无礼:)

除了大家都说的,还要考虑UDP。 它非常适用于没有响应的小消息,并且在本地网络(相对于Internet)上实际上是可靠的。

从服务器的角度来看,打开大量连接不是问题。

Web服务器可以处理多少个套接字连接?

从客户端的角度来看,如果测量显示需要避免花费时间来启动连接,并且想要并行化,则可以创建一个连接池。 多个线程可以重新使用每个连接,并在完成后将它们释放回池中。 这确实提高了复杂性级别,因此请再次确保您需要它。 您还可能具有根据活动来缩小和扩展池的逻辑-在应用程序只是闲置的情况下,整夜保持对服务器的连接保持开放是很丢脸的。

这完全取决于您打算打开和关闭的连接数以及您打算打开它们的速率。

除非您通过中止连接而不是优雅地关闭连接来避免TIME_WAIT状态,否则您将在客户端或服务器上累积处于TIME_WAIT状态的套接字。 对于单个客户端,这些在哪里累积实际上并不重要,因为问题将是相同的。 如果您使用连接的速率快于TIME_WAIT连接的关闭速率,那么您最终将到达一个无法打开任何新连接的地步,因为没有临时端口,因为所有这些临时端口都在使用TIME_WAIT套接字。

我在这里对此进行了更详细的介绍: http : //www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html

通常,我建议您保留一个连接,并在重置后重新打开它。 逻辑看似有些复杂,但系统的伸缩性会更好。 您现在可能只有一个客户端,并且连接速率可能不会导致您不希望受到TIME_WAIT问题的困扰,但是这些事实在您的系统寿命中可能并不相同...

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM