Chances are that you’ve probably used ping for troubleshooting purposes to test whether a host is available or you might have told someone that you’ll “ping them later” since the word has also seeped into common-ish lexicon. But what exactly is ping? Personally I have used it but not given it much thought so I wanted to dive a little deeper on how it works. Here are my findings!
Ping is a piece of networking system software that is used to test connectivity between a client and a host. You can use it to verify that an IP address exists and can accept requests. It turns out that its name was contrived from “Packet Internet Groper” and was meant to emulate the sound emitted from sonar technology that sends sound waves and listens back for the echo in order to determine whether there are objects under water. In order to understand what ping is doing, it would be good to familiarize oneself with network sockets and the Internet Control Message Protocol.
A network socket is an interface for talking to networks that is implemented as part of most operating system kernels (especially Unix-based kernels). Sockets allow you to open network connections and read/write to them as if they were ordinary files, which fits into the Unix philosophy that ‘everything is a file’. Although it seems like a standard feature, sockets themselves are independent of the underlying networking protocols used across the wire. It may be pretty much the standard but is actually just one particular interface that can talk to networks. It is possible to come up with other interfaces that also talk to networks that aren’t exactly like sockets.
A typical socket is uniquely identified by an IP address, a port number, and a communications protocol. Sockets are available in different flavours (each with its own purpose) and the type of socket that is relevant for understanding how ping works is the raw socket. A raw socket can be viewed as kind of an empty open-ended software object that is not even identified by an IP address or port number. You can stuff all kinds of raw network packets in there that do not rely on IPs or ports or any protocol-specific formatting. The raw socket allows you to send/receive data while bypassing the normal protocol stack by allowing you to directly access lower level protocols. This means that a raw socket receives unextracted packets. This also makes the test simple, fast, and effective.
Internet Control Message Protocol
The next thing to understand is the Internet Control Message Protocol, which is one of the many protocols in the Internet protocol suite. It differs from other transport protocols in that it does not have a concept of a port since it is not used between programs but between hosts as a whole. It is also not typically used to exchange data. ICMP packets are sent directly over IP and are not encapsulated in UDP or TCP. The port only comes up as a further differentiating field within UDP and TCP.
ICMP is a bit of an odd one out in terms of where it fits on the networking model because it is used to manage IP itself too in a way so sometimes it’s counted into the same layer as IP itself. It is halfway network layer, halfway above, since it is transferred via IP.
ICMP has different message types, including an Echo Request and an Echo Reply, which are very relevant to ping! So when we issue the ping command followed by a hostname, a raw socket is opened that connects to the remote host and an ICMP Echo Request packet is sent to it. The remote host sends back an ICMP Echo Reply packet. Interestingly, it is the responding host’s OS kernel that does the Echo Reply directly and so no application is involved that would use sockets. We can think of ICMP Echo Reply handling as an automated thing that happens in the kernel, without involving a particular process.
Ping has a very simple syntax (ping domain_name) and also has a fairly straightforward output.
will result in something like
PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data. 64 bytes from 126.96.36.199: icmp_seq=1 ttl=56 time=49.3 ms 64 bytes from 188.8.131.52: icmp_seq=2 ttl=56 time=42.1 ms 64 bytes from 184.108.40.206: icmp_seq=3 ttl=56 time=57.9 ms
Hitting Ctrl+C will give us more information
--- 220.127.116.11 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 42.149/49.811/57.968/6.467 ms
There is a lot of information in the output of ping, but I will just highlight a few things.
This refers to the time it took between sending a request and receiving a reply, in other words, the roundtrip time. This can depend on factors such as how close you are to the server and how many networking equipment is between you and the server.
? packets transmitted, ? received
Packets should always arrive at its destination, but failures can always happen. Ping will tell you how many packets have been sent and how many have been received so that you can be informed of the health of the connection.
You can use Wireshark to dissect ICMP packets and check out its packet structure:
These are all my findings so far on ping!
Here is my attempt at trying to graphically depict the process: