Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?


locked by HopelessN00b Dec 5 '14 at 12:24

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. –  samsmith Jan 4 '12 at 4:03

9 Answers 9

up vote 14 down vote accepted

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 for tcp traceroute - and start there.

Here are some fun tools to try while you're at it...

Here's an example with lft...

 % lft -S

 Hop  LFT trace to (
  1 ( 0.5ms
  2 ( 2.3ms
  3 ( 2.5ms
  4 ( 3.0ms
  5 ( 3.4ms
  6 ( 3.3ms
  7 ( 10.9ms
  8 ( 11.1ms
  9 ( 11.0ms
 10 ( 11.1ms
 **   [neglected] no reply packets received from TTLs 11 through 20
 **   [4.2-3 BSD bug] the next gateway may errantly reply with reused TTLs
 21   [target] ( 11.2ms
I've been trying to find paketto for hours but I had completely forgotten the name and most of the context. Thanks for the link! –  clee May 3 '12 at 21:45

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

also, theres a GTK variant of MTR for anyone interested –  Kent Fredric May 29 '09 at 10:36

For Windows you can use something like tcping:

And for Linux the best utility is, already mentioned, hping.

# hping -S -p 80
HPING (eth0 S set, 40 headers + 0 data bytes
len=46 ip= ttl=59 DF id=0 sport=80 flags=SA seq=0 win=5840 rtt=0.7 ms
len=46 ip= ttl=59 DF id=0 sport=80 flags=SA seq=1 win=5840 rtt=0.7 ms
len=46 ip= ttl=59 DF id=0 sport=80 flags=SA seq=2 win=5840 rtt=0.6 ms
--- hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.7/0.7 ms

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. –  niXar May 29 '09 at 11:02
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 Jurkiewicz May 29 '09 at 12:43

You could use some QoS application to measure this kind of network parameters. For example:

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:

* TCP and UDP via BSD Sockets for both IPv4 and IPv6
* Unix Domain Sockets
* SCTP for both IPv4 and IPv6


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

hping is good, but it requires winpcap. Seems pcap is the only way windows can use such tools? –  Eye of Hell May 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. –  Matthew May 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.


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.


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