Question

If a computer has to fetch some information, a network request is generally one of the slowest possible sources. My understanding is that, in general:

• Network access is much slower than disk
• Disk access is much slower than RAM
• RAM access is much slower than CPU registers

My question is this: what makes network access so much slower, on average, than disk?

Obviously this isn’t always true: you could have a blazing-fast network connection to a server in the same room and a sluggish hard drive. But for the purposes of this question, please imagine an average user surfing the web: reading data from disk will be faster than fetching the same data from Google.

Some of the pieces I can think of involved in, say, an HTTP request are:

• DNS lookup of the IP
• The three-way handshake to establish a TCP connection
• Packetization: breaking the HTTP request into TCP packets, and putting those into IP packets, with all the necessary counters and checksums, etc
• Transmission: the time required for electrical signals to move across wire
• Routing: the decision-making, buffering, etc that happens inside routers
• Processing: the server’s formulation of a response
• All the transmission and routing of the response, including resending missing packets
• Ordering and assembling the TCP packets’ contents and handing the HTTP response back to the client

If I’ve missed any major steps, please let me know.

Of these steps, ignoring server processing (which isn’t really a network issue), are any parts particularly slow? Do any of them account for most of the inherent delay in network requests?

Update: Some numbers

An average DNS lookup takes 60~120ms, followed by a full round-trip
(RTT) to perform the TCP handshake – combined, that creates 100-200ms
of latency before we can even send the request!

• Source: Chrome Networking: DNS Prefetch & TCP Preconnect by Ilya Grigorik, Developer Advocate at Google

Answer 1

Physical transmission latency (i.e. having an overhead of at at least 2 * distance / speed of light for every request) tends to trump any other performance factors. You can check that by comparing the request time for local system to a remote one. For example, on a blazingly fast internet connection I get the following results:

$ /usr/bin/time --quiet -f %e wget -q -O/dev/null www.google.com/404
0.05
$ /usr/bin/time --quiet -f %e wget -q -O/dev/null localhost/404
0.01
# A machine in the same LAN
$ /usr/bin/time --quiet -f %e wget -q -O/dev/null 192.168.1.42/404
0.01

Assuming that google’s webservers are no slower (when it comes to bandwidth, memory, buffering, HDD, etc.) than the apache I’m running, that means that even with this extremely fast and low-latency connection, and connecting to google, the time to go through the network dwarfs any other concerns (such as local processing).

Now you could assume that that’s because of routing overhead, and buffers or so (let’s exclude lost packets for a second, since they highly depend on the medium). You can determine the influence of these factors by by comparing the time it takes to send a packet over the Internet to the time it would take in a direct current network cable.

For example, for packets from Düsseldorf to Los Angeles, Wolfram Alpha calculates a physical distance of 31ms (43 with current fiber cables). Assuming that the cables run in a perfect line between the two cities (which they certainly don’t), this make up half of the actual delay of 85ms I’m measuring.

Consequentially, it is paramount to reduce the distance between the peers as well as the number of roundtrips whenever possible. If the messages are small compared to the available bandwidth the TCP and SSL/TLS handshakes will therefore be the main reason for the slowness of networking. Obviously, for larger files (or if there is a bottleneck, which can happen more often than you would expect) bandwidth becomes an issue as well.