If this happens after the SSL connection has been negotiated, it is possible that the intermediate device considers encrypted traffic on port 2000 as a potential security threat (or in some way "unwanted") and makes two things:
- intercepts the "ACK" sent by the server so they do not reach the client that will consider the server as not responding
- sends a reset to the server so that it will not keep the connection open waiting for traffic that will never come from the client
My connection with server already is really poor - 120 ms ping in average.
I did a similar test to www.google.com, testing response time over TCP, and got 160 milliseconds. Does Google have poor connectivity? TCP was not designed for quick response times.
I measure my ping through flash client - send packet with timestamp and immediatly send from server to client.
TCP, by design, delays up to 200 milliseconds to provide more effective network utilization. You are not measuring anything except TCP specifically doing what it is designed to do. If you look closely at the network traffic, you'll see that most of the TCP packets actually contain much more than two bytes of data.
You are expecting horribly inefficient behavior. Sending 30 packets per second each containing only two bytes of data is incredibly dumb and TCP isn't stupid enough to do that.
Two suggestions:
Don't call this "ping". That makes people think it's a network round-trip measurement rather than a measurement of response time over TCP.
Don't say "30 packets/s" unless you actually measured the network traffic. When you write some bytes to a TCP connection, there is no reason to expect that will correspond to a packet. Packets are network things. Writes to a TCP connection are application things. Confusing application and network level concepts will really mess you up when you deal with TCP.
Also, why are you doing so many small writes? Gather the data into larger writes. Yes, TCP will do this for you, but it's still much more efficient if you do this in your application.
If you're just doing these horrible small writes to test performance, just stop doing it. It won't give you useful data. If these horrible small writes replicate your actual usage scenario and response time is important, then you need to work on fixing your protocol so that it makes some kind of sense.
Best Answer
Not exactly, it could be the firewall on the client router not allowing the required ports into the local network, the server's firewall stopping the outgoing packets or the servers router blocking the outgoing packets.
If the routers are blocking it it's still a firewall's packet filter. If the client or server are blocking it they will be doing so with the firewall's packet filtering.
It could also be a routing issue.
I hope that helps.