Ping over IPv4

Q: Does ping use TCP or UDP?

Neither. Ping uses ICMP (Internet Control Message Protocol), which sits directly on top of IP at the same layer as TCP and UDP. It uses ICMP Echo Request (Type 8) and Echo Reply (Type 0) messages.

Q: What is a good ping time?

Under 30 ms is excellent for regional traffic. 30 to 100 ms is normal for intercontinental traffic. Over 200 ms is noticeable for interactive use such as gaming or VoIP. The acceptable threshold depends heavily on the geographic distance between source and destination.

Q: Can ping tell me if a website is working?

No. Ping only confirms that the host responds to ICMP Echo Requests. A web server can ping successfully while returning HTTP 500 errors. Use an HTTP check to verify the website itself is functioning correctly.

The original reachability test: send an ICMP Echo Request, wait for an Echo Reply, measure the round trip.

Run a live ping test from global worker nodes Try ping on QueryBox →

TL;DR

Ping sends small ICMP packets to a target IPv4 address and times how long the reply takes to return. It is the fastest way to confirm a host is online and reachable, and to spot packet loss or latency between you and it.

What it is

Ping is a network diagnostic that asks a remote host one simple question: "are you there?" If the host is online and not blocking the request, it answers back. The time between question and answer is the round-trip time, usually measured in milliseconds.

Ping runs on top of ICMP, the Internet Control Message Protocol. ICMP is not TCP or UDP; it sits directly on top of IP and exists for diagnostic and control messages rather than carrying application data.

How it works

A ping exchange uses two ICMP message types:

Echo Request (Type 8) — the probe you send
Echo Reply (Type 0) — the answer the target sends back

Each packet carries an identifier, a sequence number, and a payload (typically 32 to 56 bytes of arbitrary data the target must echo back verbatim). The IP header also carries a TTL (Time To Live) value that decrements at every router hop.

The flow:

Your client builds an Echo Request, sets a sequence number, starts a timer
The packet traverses routers, each decrementing TTL by 1
The target receives it, swaps source and destination, changes type from 8 to 0, recomputes the checksum, sends it back
Your client matches the reply by identifier and sequence, stops the timer
RTT equals the timer value, typically reported in milliseconds

When to use it

Confirm a host is online before deeper troubleshooting
Measure baseline latency between two points
Detect packet loss on a path
Verify a DNS record resolves to a live host
Sanity check after a firewall, routing, or DNS change

Running it on networktoolkit.io

Select ping with ipv4 as the parameter, enter a hostname or IPv4 address, and the test fires from our distributed worker pool. You get per-worker results so you can see regional differences. Sample output per worker:

PING example.com (93.184.216.34): 56 data bytes
64 bytes from 93.184.216.34: icmp_seq=0 ttl=56 time=12.4 ms
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=12.1 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=12.3 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=12.2 ms

--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
round-trip min/avg/max/stddev = 12.1/12.25/12.4/0.12 ms

Reading the results

Field	Meaning
`64 bytes`	Reply size (header + payload)
`icmp_seq`	Sequence number; gaps indicate packet loss
`ttl=56`	Hops remaining when reply arrived; subtract from likely starting TTL (64, 128, 255) to estimate hop count
`time=12.4 ms`	Round-trip time
`0% packet loss`	Reliability of the path
`stddev`	Jitter; high values suggest an unstable path

Common scenarios

Outcome	What it likely means
All replies, low RTT, 0% loss	Host is up, path is healthy
All replies, high RTT	Host is up but path is slow or congested
100% loss	Host is down, blocked by firewall, or path is broken
Partial loss	Congestion, flaky link, or rate limiting on the target
`Destination Host Unreachable`	A router on the path has no route to the target
`Request timeout`	No reply within the timeout window

Limitations & gotchas

Many hosts and edge firewalls drop ICMP by default. A failed ping does not prove a host is down; the application port may still be reachable. Use port check or HTTP check to confirm.
ICMP is often deprioritised by routers, so ping RTT can be worse than real traffic RTT.
Ping tests reachability, not service health. A web server can ping fine while returning 500s.
Cloud load balancers frequently terminate ICMP at the edge, so you ping the LB, not the backend.

Security & privacy notes

Ping reveals that an IP is in use and gives a rough latency fingerprint. It does not expose application data. Persistent or high-volume ping from one source can look like reconnaissance and may trigger rate limiting or IDS alerts.

Standards & references

RFC 792 — Internet Control Message Protocol (defines Echo Request and Echo Reply)
RFC 1122 — Requirements for Internet Hosts, ICMP behaviour
IANA ICMP Type Numbers

FAQ

Does ping use TCP or UDP?

Neither. Ping uses ICMP, which sits directly on IP at the same layer as TCP and UDP.

Why does a host fail to ping but the website still loads?

The host or its firewall is blocking ICMP Echo Requests while still allowing TCP traffic on ports 80 and 443.

What is a good ping time?

Under 30 ms is excellent for regional traffic, 30 to 100 ms is normal for intercontinental traffic, over 200 ms is noticeable for interactive use.

Can ping tell me if a website is working?

No. It only tells you the host responds to ICMP. Use http_check to verify the website itself.