If you're seeing a lot more duplicate ACK's followed by actual retransmission then some amount of packet loss is taking place. So - if you're seeing a few random duplicate ACK's but no (or few) actual retransmissions then it's likely packets arriving out of order. If this is the case, however, you're likely to see other problems on the link (.including other packets showing as dupes in Wireshark). Upon seeing #6 arrive, though, it would stop sending the duplicate acknowledgements.Ī less common cause would be certain media problems where certain packets might end up being seen more than once. As above, if the receiver sees (for example) a segment with sequence #5 followed by another with #7 before seeing sequence #6 then it might try to begin to trigger a fast retransmit. It's also possible that the same symptom of gaps in sequence numbers might be seen in a situation where packets are being delivered out of order. This can occur without waiting for the acknowledgement timeout for the lost packet to hit on the transmitter - which, as the name implies, means recovering a lot faster. The repeated acknowledgements at the last known value before the gap signal which packets the sender should retransmit. You can bypass limits in Squid by tweaking the configuration, but then again it is an unrealistic test.There can be several things going on - the most common would be the use of TCP Fast Retransmission which is a mechanism by which a receiver can indicate that it has seen a gap in the received sequence numbers that implies the loss of one or more packets in transit. Some browsers consider the proxy to be a single host but others also have different limits for the proxy (up to 15 concurrent, too).
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). 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.
If you are trying to simulate user load I'm afraid you're not doing it right. 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. The retransmissions you're seeing are probably due to someone else in the network dropping any other SYN packets from you. 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. 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. Reusing TCP ports is not a bad thing per se. Also FIN, ACK and RST received for the earlier request.Īttaching tcp dump screenshot for reference:Ĭan 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? 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". This URL I have blocked on URL filtering engine.Īfter some requests ~120 wget got hanged in between for exactly 1 min. This URL filtering engine which will allow/block URL according to the rule.įrom client I have run a script which does 500 wget to in a loop continuously. Squid then forwards to a URL Filter which has a list of whitelists and blacklists. I have a squid proxy installed on a unix machine which is sending handling http requests coming from an trusted source. Facing issues due to TCP Port Reuse and Retransmission for HTTP traffic.
0 kommentar(er)
