performance - 网络固有的瓶颈是什么？

Question

如果计算机必须获取某些信息，网络请求通常是最慢的来源之一。我的理解是，一般来说:

• 网络访问比磁盘慢得多
• 磁盘访问比 RAM 慢得多
• RAM 访问比 CPU 寄存器慢得多

我的问题是:是什么导致网络访问平均比磁盘访问慢得多？

显然这并不总是正确的:您可能拥有与同一房间中的服务器的超快网络连接和缓慢的硬盘驱动器。但就这个问题而言，请想象一下普通用户上网:从磁盘读取数据比从 Google 获取相同数据更快。

我能想到的一些涉及 HTTP 请求的部分是:

• IP 的 DNS 查找
• 建立 TCP 连接的三次握手
• 打包:将 HTTP 请求分解为 TCP 数据包，然后将其放入 IP 数据包中，并附带所有必要的计数器和校验和等
• 传输:电信号通过电线传输所需的时间
• 路由:路由器内部发生的决策、缓冲等
• 处理:服务器制定响应
• 响应的所有传输和路由，包括重新发送丢失的数据包
• 排序和组装 TCP 数据包的内容，并将 HTTP 响应传回客户端

如果我错过了任何主要步骤，请告诉我。

在这些步骤中，忽略服务器处理(这实际上不是网络问题)，是否有任何部分特别慢？它们中的任何一个是否是网络请求中大部分固有延迟的原因？

更新:一些数字

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!

• 来源:Chrome Networking: DNS Prefetch & TCP Preconnect作者:Ilya Grigorik，Google 开发者倡导者

Answer 1

物理传输延迟(即每个请求的开销至少为 2 * 距离/光速)往往胜过任何其他性能因素。您可以通过比较本地系统与远程系统的请求时间来检查这一点。例如，在极快的互联网连接上，我得到以下结果:

$ /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

假设 google 的网络服务器并不比我正在运行的 apache 慢(当涉及到带宽、内存、缓冲、HDD 等时)，这意味着即使使用这种极快且低延迟的连接，并且连接对于Google来说，通过网络的时间使任何其他问题(例如本地处理)相形见绌。

现在您可以假设这是因为路由开销，并且 buffers左右(让我们暂时排除丢失的数据包，因为它们高度依赖于介质)。您可以通过比较通过 Internet 发送数据包所需的时间与在直流网络电缆中发送数据包所需的时间来确定这些因素的影响。

例如，对于从杜塞尔多夫到洛杉矶的数据包，Wolfram Alpha计算出的物理距离为 31 毫秒(当前光缆为 43 毫秒)。假设两个城市之间的电缆在一条完美的线路上运行(当然事实并非如此)，这占了我测量的 85 毫秒实际延迟的一半。

因此，尽可能减少点之间的距离以及往返次数至关重要。如果消息与可用带宽相比较小，则 TCP 和 SSL/TLS 握手将成为网络缓慢的主要原因。显然，对于较大的文件(或者如果存在瓶颈，可能会发生 more often than you would expect )，带宽也会成为一个问题。