我正在为服务器编写测试程序。在测试应用程序中，我尝试将大量客户端连接到服务器，但过了一段时间后会出现类似这样的错误：
Connection reset by peer: socket write error
或
java.net.SocketException: Connection reset
或
java.net.ConnectException: Connection refused: connect
我为连接到服务器的每个客户端使用一个新套接字。
有人可以告诉我这种奇怪的行为吗？
答案 0 :(得分：0)
操作系统和网络服务器限制了您可以开始/接受的连接速度和连接数。如果您想在服务器上进行性能测试，请尝试使用Apache JMeter，因为它具有这些限制的解决方案。
答案 1 :(得分：0)
您的网络/应用服务器一次只能为有限数量的客户提供服务。
达到此限制时，您将收到拒绝/重置的连接。
希望能回答你的问题。
干杯
答案 2 :(得分：0)
很遗憾，您没有提供有关服务器性质的详细信息。我想你正在编写一个典型的TCP服务器。在这个答案中，我将不谈论任何特定于Java的细节。
简短的建议是：在客户端连接之间插入延迟。没有它，您正在积极模拟对服务器的DoS攻击。
对于较长的一个，请阅读以下内容。
通常，TCP服务器只通过调用（在可爱的C接口中）int sockfd = socket(...)函数创建1 监听，并将结果（在我们的情况下为sockfd）传递给{ {1}}和bind()个函数。在准备之后，服务器将调用listen()，这将使服务器陷入沉睡（如果套接字被标记为阻塞），并且地球另一端的客户端将开始呼叫accept()功能，而不是connect()（在服务器端），在OS内核的支持下，将创建连接的套接字。
通过查看accept()函数，可以了解可能的挂起连接的实际数量。 listen()有一个 backlog 参数，用于定义 OS内核应该排队到套接字的最大连接数（这基本上是{{{}中所有连接的总和。 1}}和listen()状态）。从历史上看，20世纪80年代积压的推荐值是5，这在我们这个时代显然是悲惨的。例如，在FreeBSD 7.2中，键入以下内容可能会猜到 backlog 的硬限制：
% sysctl kern.ipc.somaxconn kern.ipc.somaxconn: 128
并在Fedora 10中：
% cat /proc/sys/net/core/somaxconn 128
P.S。
对不起我糟糕的英语。