THE PING PROCESS
The source host generates an ICMP protocol data unit.
The ICMP PDU is encapsulated in an IPdatagram, with the source and *destination***IP addresses** in the IP header. At this point the datagram is most properly referred to as an ICMPECHOdatagram, but we will call it an IPdatagram from here on since that's what it looks like to the networks it is sent over.
The source host notes the local time on it's clock as it transmits the IPdatagram towards the destination. Each host that receives the IPdatagram checks the destination address to see if it matches their own address or is the all hosts address (all 1's in the host field of the IP address).
If the destination IP address in the IPdatagram does not match the local host's address, the IPdatagram is forwarded to the network where the IP address resides.
The destination host receives the IPdatagram, finds a match between itself and the destination address in the IPdatagram.
The destination host notes the ICMPECHO information in the IPdatagram, performs any necessary work then destroys the original IP/ICMPECHOdatagram.
The destination host creates an ICMPECHO REPLY, encapsulates it in an IP datagram placing it's own IP address in the source IP address field, and the original sender's IP address in the destination field of the IPdatagram.
The new IPdatagram is routed back to the originator of the PING. The host receives it, notes the time on the clock and finally prints PING output information, including the elapsed time.
The process above is repeated until all requested ICMPECHO packets have been sent and their responses have been received or the default 2-second timeout expired. The default 2-second timeout is local to the host initiating the PING and is NOT the Time-To-Live value in the datagram.
NOTES ON 'FAILED' RESPONSES
Note that an ICMPECHO REPLY might return after the default 2-second timeout. Thus the packet did return, it just did not do so in the 2 seconds alotted. When experiencing so-called packet loss when using ping, it is always a good idea to increase the default 2 second timeout to see if packets are no longer being dropped. If increasing the default timeout value seems to improve performance by reducing packet loss, then your problem is NOT a packet loss issue, it is a congestion issue caused by high load at one of the following locations (in order of frequency):
1.Your own Internet connection to your ISP
2.The remote server
3.The remote host's connection to their ISP
4.A peering point between two ISP's which your traffic transits over
Large companies maintaining websites (eg. Google, Yahoo, Microsoft, CNN, AOL etc.) usually monitor their Internet connections to help them prepare for upgrades to their Internet provider before any serious issues arise. They keep a five minute running average byte-count of the input and output of each Internet pipe and trend the utilization over weeks, months and years. This gives them the ability to predict when they will run out of bandwidth under normal usage.