Facing issues due to TCP Port Reuse and Retransmission for HTTP traffic.

My deployment is as follows:

enter image description here

I have a squid proxy installed on a unix machine which is sending handling http requests coming from an trusted source. Squid then forwards to a URL Filter which has a list of whitelists and blacklists. This URL filtering engine which will allow/block URL according to the rule.

From client I have run a script which does 500 wget to www.naukri.com in a loop continuously. This URL I have blocked on URL filtering engine.

After some requests ~120 wget got hanged in between for exactly 1 min. During this hanged state, I took tcpdump on server and found that it is showing "TCP port numbers reused" and start sending sync packet with same port which was used earlier and showing "TCP Retransmisson". Also FIN, ACK and RST received for the earlier request.

Attaching tcp dump screenshot for reference:

enter image description here

Can you please let me know why it is using same port for the new request and re-transmitting the packet again? Is there a way to avoid port reuse?


why it is using same port for the new request and re-transmitting the packet again?

It reuses the same port because it's more efficient to do that.

There's a good exaplanation here: https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

re-transmit? What re-transmit? There may be packet re-transmissions but these should be completely seperate from the port re-use issue.


I have just hit a similar problem. (With lockd not httpd).

The problem here is that your remote server is the one that closed the connection, with a FIN packet.

When it does this, it puts the connection into a TIME_WAIT state - which is specifically supposed to ignore any additional packets, in case there's additional fragments still in flight/going different network routes.

So it's ignoring the addition packets sent by your application, until TIME_WAIT expires on the server.

Your client doesn't get an ACK for those packets, so it retransmits. (Which also get ignored, until TIME_WAIT expires.

As to why it sent a FIN packets? Hard to say. That's down to the server. But if you looked like a denial of service attack, that might be why.

But you should really trap the CLOSE_WAIT state on your client, and not reuse your socket if that happens.


Reusing TCP ports is not a bad thing per se. As symcbean pointed out, it is more efficient and it may be so evident on your example because you're quickly opening lots of new sockets. I see in your capture's screenshot that it has been 2 seconds since you started the process and you've mentioned getting stuck after ~120 connections, which is a good number of new connections in 2 seconds.

The retransmissions you're seeing are probably due to someone else in the network dropping any other SYN packets from you. 60 new connection per second from the same host is considered harmful by pretty much every network and security administrator out there and any default settings on a firewall or even on a proxy will start silently dropping your traffic.

If you are trying to simulate user load I'm afraid you're not doing it right. 60 new connections per second from several different hosts is more than OK, but it is unrealistic if they are coming from a single host. Actually, a user's browser will limit the connections to a single host to a number between 6 and 12 concurrent (depending on the browser and version). Some browsers consider the proxy to be a single host but others also have different limits for the proxy (up to 15 concurrent, too).

You can bypass limits in Squid by tweaking the configuration, but then again it is an unrealistic test.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.