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?

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Ping loss of %30 is death for any other connection between those addresses. %10 is near death. %1 is probably the limit before you start seeing serious issues.
–
samsmithJan 4 '12 at 4:03

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).

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 course telnet.

Define "slower." Your answer is wrong. Deprioritized packets are not noticeably "slowed down," they are just more likely to be dropped. It results in flow appearing slower, since for TCP for ex., it results in more retransmits, but a single packet is not slowed down, or if it is, only marginally so. Note that this would only affect slow links, for example DSL endpoints; on the internet itself, there is too much going on for anyone to bother filtering such packets, unless they're forced to.
–
niXarMay 29 '09 at 11:02

1

Sure, saying "slower" was lazy, "more likely to be dropped" is accurate. It's not that uncommon on the net either, just set up some mtr's to various locations across the net and you'll notice quite often various networks have issues delivering ICMP packets at various points.
–
Alex JurkiewiczMay 29 '09 at 12:43

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:

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.

hping is good, but it requires winpcap. Seems pcap is the only way windows can use such tools?
–
Eye of HellMay 29 '09 at 11:27

Yuck... Did not know that. That scuppers it on HP hardware - the HP interface teaming software appears to use some winpcap libraries. - I found this out when attempting to install wireshark.
–
MatthewMay 30 '09 at 13:06

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.