由于 TCP 端口重用和 HTTP 流量重传而面临问题。
我的部署如下：
我在一台 unix 机器上安装了一个 squid 代理，它负责发送处理来自可信来源的 http 请求。然后，Squid 转发到 URL 过滤器，该过滤器包含白名单和黑名单列表。此 URL 过滤引擎将根据规则允许/阻止 URL。
我从客户端运行了一个脚本，该脚本不断循环执行 500 次 wget 操作到 www.naukri.com。我已在 URL 过滤引擎上阻止了此 URL。
在一些请求之后，~120 wget 挂起了整整 1 分钟。在此挂起状态期间，我在服务器上运行 tcpdump，发现它显示“TCP 端口号已重用”，并开始使用之前使用的相同端口发送同步数据包，并显示“TCP 重新传输”。还收到了先前请求的 FIN、ACK 和 RST。
附上 tcp dump 截图以供参考：
您能告诉我为什么新请求使用相同的端口并再次重新传输数据包吗？有没有办法避免端口重用？
答案1
为什么它对新请求使用相同的端口并再次重新传输数据包？
它重用同一个端口，因为这样做更有效率。
重新传输？什么重新传输？可能会有数据包重新传输，但这些应该与端口重用问题完全分开。
答案2
我刚刚遇到了类似的问题。（没有lockdhttpd）。
这里的问题是您的远程服务器使用 FIN 数据包关闭了连接。
当它执行此操作时，它会将连接置于一种TIME_WAIT状态 - 具体来说是忽略任何额外的数据包，以防有额外的片段仍在飞行中/走不同的网络路由。
因此，它会忽略您的应用程序发送的附加数据包，直到TIME_WAIT在服务器上过期。
您的客户端无法收到ACK 这些数据包，因此它会重新传输。（这些数据包也会被忽略，直到TIME_WAIT过期。）
至于它为什么发送 FIN 数据包？很难说。这取决于服务器。但是如果你看起来像是拒绝服务攻击，那可能就是原因。
但你确实应该将CLOSE_WAIT状态困在你的客户端上，并且不是如果发生这种情况，请重新使用您的套接字。
答案3
重用 TCP 端口本身并不是一件坏事。正如 symcbean 指出的那样，它效率更高，并且可能在您的示例中如此明显，因为您正在快速打开大量新套接字。我看到您捕获的屏幕截图显示，自您启动该过程以来已经过去了 2 秒，您提到在约 120 个连接后卡住，这是 2 秒内相当多的新连接。
您看到的重新传输可能是由于网络中的其他人丢弃了您的任何其他 SYN 数据包。几乎每个网络和安全管理员都认为每秒来自同一主机的 60 个新连接是有害的，并且防火墙或甚至代理上的任何默认设置都会开始默默地丢弃您的流量。
如果您试图模拟用户负载，恐怕您做得不对。每秒来自多个不同主机的 60 个新连接是可以接受的，但如果它们来自单个主机，则不切实际。实际上，用户的浏览器会将到单个主机的连接限制为 6 到 12 个并发连接（取决于浏览器和版本）。有些浏览器将代理视为单个主机，但其他浏览器对代理也有不同的限制（最多 15 个并发连接）。
您可以通过调整配置来绕过 Squid 中的限制，但这又是一个不切实际的测试。