It's a common task to check network 'quality' - latency, number of dropped packets etc. But 'ping' has a number of drawbacks: - It uses ICMP. Many ISP has different shapers for ICMP and TCP traffic, so 'ping' will show 10ms latency, but TCP connections will experience 1000ms+. - It sends very small amount of packets. By default, one packet every second. Since TCP protocol tolerates packets loss (it can operate very well is half packets are lost - it's normal), it's absolutely unclear if ping's "30% packet loss" killing connection or if it's absolutely normal.
So, is it any alternative for ping that use TCP connection instead of ICMP and checks internet connection quality?
Regardless of the fact that TCP can tolerate packet-loss/packet-ordering issues, a ping loss of 30% is still quite significant if the "population" is large enough - i.e., more than say 100 pings.
But to answer the question, you can look at nmap. I'm sure examples will come flooding in shortly :)
More importantly though, you don't want just a round-trip time, you really want to see the performance from your machine to the server and back at every (possible) hop.
You can do this with
traceroute
- however the most commonly found version of this is done using ICMP or UDP, but search fortcp traceroute
- and start there.Here are some fun tools to try while you're at it...
Here's an example with
lft
...Netcat Power Tools describes how to do TCP Ping with netcat. Specifically, every unsolicited ACK packet should return RST.
I'm personally a big fan of mtr ( http://www.bitwizard.nl/mtr/ ), mtr is an ncurses based traceroute clone which can work using both icmp and udp. It shows you the weak spots in your link to a certain host and is in that way non intrusive.
When it really comes to some load tests I would go with iperf (which is client/server).
For Windows you can use something like tcping:
http://www.elifulkerson.com/projects/tcping.php
And for Linux the best utility is, already mentioned,
hping
.ICMP packets are generally delivered slower (if there is a difference at all), because most networks deprioritise them, especially ping packets. Generally, if you are seeing such divergent results from ICMP and TCP responses, the issue is either an overloaded server or specific TCP shaping at a firewall along the way.
You should investigate
traceroute -P tcp
,tcptraceroute
,lft
and of coursetelnet
.You could use some QoS application to measure this kind of network parameters. For example:
NetPerf (www.netperf.org/netperf/): Netperf is a benchmark that can be used to measure the performance of many different types of networking. It provides tests for both unidirecitonal throughput, and end-to-end latency. The environments currently measureable by netperf include:
OR
IPerf (sourceforge.net/projects/iperf) Iperf was developed by NLANR/DAST as a modern alternative for measuring maximum TCP and UDP bandwidth performance. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.
check out hping and then have a look at bing
TCP cannot "tolerate" 50% packet loss. It will simply grind to a halt, for a simple reason: it adapts its transmission speed based on the loss of packets. When packets are lost, they are understood to indicate congestion. If you drop 50% of packets (say, with a random drop firewall rule) regardless of traffic, it will see an ever decreasing bandwidth availability.
Furthermore I doubt ISPs shape ICMP vs TCP. Some might do, as there are some really stupid people out there, but it doesn't make much sense to do so. Most will shape the whole connection, or it will "shape itself" because of congestion. In either cases packets are typically dropped randomly.
That being said, you can ping with TCP, but there are several caveats. The first is to just send the initial packet in a TCP connection, which will elicit a response from a server with an open port, but will be seen as a connection attempt. Ideally you could use the "echo" service (TCP port 7) ... but actually you can't because it's now disabled by default everywhere. Anyway, if you can get someone to enable it for you on the machine you want to test, a program could use that to check the round-about time for packets inside a TCP connection.
That being said, you probably have the "tracepath" command installed on your machine; it's similar to traceroute but uses neither TCP or ICMP, but UDP. For TCP there are various utilities out there, you can try hping.
The alternative to ping, you can use 'netstat'
Options: 1.netstat -antp 2.netstat -anup
-a = all, -n = Address and port number of the local end of the socket, -t = tcp, -p = program
-u = udp.