网站小于14kB，加载速度明显提升，关键在于TCP慢启动算法。

拥有更小的网站能让加载速度更快——这并不令人惊讶。但让人惊讶的是，14kB的页面可以比15kB的页面快加载612毫秒，而15kB与16kB之间的差异却微乎其微。这背后的原因是TCP慢启动算法。本文将探讨这一算法的工作原理，以及为什么你应该关注它。首先，我们来快速回顾一些基本概念。

什么是TCP？

传输控制协议(TCP)是一种通过互联网协议(IP)可靠传输数据包的方式——有时也称为TCP/IP。当浏览器请求你的网站(或图像、样式表)时，它是通过HTTP发出请求的，而HTTP则是建立在TCP之上的。一个HTTP请求通常由多个TCP数据包组成。

IP本身只是一种在互联网上从一个位置向另一个位置发送数据包的系统，它无法检查数据包是否成功到达目的地。而对于网站来说，确保所有数据都到达非常重要——否则网页可能会出现丢失的部分。然而，在网络的其他使用场景中，这一点并不那么重要——例如，直播视频的流媒体传输。

TCP是IP的扩展协议，允许浏览器和网站服务器互相确认数据包是否成功到达。服务器发送一些数据包，然后等待浏览器的确认(称为ACK)，确认收到后再发送更多数据包——如果没有收到ACK，服务器可以重新发送数据包。

什么是TCP慢启动？

TCP慢启动是一种算法，用于服务器确定一次可以发送多少数据包。

当浏览器首次连接到你的服务器时，服务器无法知道两者之间的带宽是多少。带宽是指网络每单位时间内可以传输的数据量，通常以每秒比特数(b/s)来衡量。管道常被用作类比——带宽相当于每秒钟从管道中流出的水量。

你的服务器不知道连接能处理多少数据，所以它开始发送一小部分安全的数据，通常是10个TCP数据包。如果这些数据包成功到达访问者的电脑，他们的电脑会发送一个ACK确认信息，表示数据包已接收。

随后，服务器会发送更多的数据包，但这次发送的数量会加倍。这一过程反复进行，直到有数据包丢失且服务器没有收到ACK为止(此时服务器会继续发送数据包，但速度会减慢)。这就是TCP慢启动的基本原理——在实际应用中，算法会有所不同，但原理大致如此。

14kB的来源是什么？

大多数网络服务器的TCP慢启动算法最初会发送10个TCP数据包。

每个TCP数据包的最大大小为1500字节。这一限制并不是由TCP规范设定的，而是以太网标准所决定的。

每个TCP数据包的头部占用40字节——其中16字节用于IP，24字节用于TCP。

这样每个TCP数据包剩下1460字节可用。10个TCP数据包总共为14600字节，即大约14kB！

因此，如果你能把网站或其关键部分压缩到14kB以内，你可以为访问者节省大量时间——即访问者与服务器之间一次往返所需的时间。

一次往返有多严重？

人们非常没有耐心，而一次往返的时间可能出乎意料地长。时间的长短取决于延迟……

延迟是指从数据包源头到达目的地所需的时间。如果带宽是每秒通过管道的水量，那么延迟就是一滴水进入管道并从另一端流出的时间。

让我们来看看延迟有多糟糕的一个有趣例子：

卫星互联网

卫星互联网通过地球轨道上的卫星提供服务，通常用于人口稀少地区、海上钻井平台、游轮和航空公司机上WiFi。

为了更好地说明延迟的严重性，假设一群海上钻井平台上的工人忘了带骰子，而他们需要使用出色的(小于14kB的)missingdice.com来玩龙与地下城。

首先，其中一人用手机请求网页……

手机将请求发送到平台的WiFi路由器——这只需1毫秒。

然后，卫星天线需要将数据发送到地球上空的卫星。通常，这个卫星位于距地球表面35786公里的地球同步轨道。光速为每秒299792458米，因此从地球发送消息到卫星需要120毫秒。卫星再将消息发回地面站，耗时同样为120毫秒。

然后，地面站将请求发送到服务器所在位置(光速在光纤电缆中减慢到每秒200000000米)。如果地面站与服务器之间的距离相当于纽约到伦敦的距离，则需约28毫秒——但如果距离类似于纽约到悉尼的距离，则需要80毫秒——我们取个方便计算的数字60毫秒。

然后，服务器处理请求可能需要10毫秒，接着服务器将响应发送回来。

数据经过地面站、再次返回卫星、再到卫星天线，最终回到钻井平台上的手机。

手机 -> WiFi路由器 -> 卫星天线 -> 卫星 -> 地面站 -> 服务器 -> 地面站 -> 卫星 -> 卫星天线 -> WiFi路由器 -> 手机

如果我们做个简单计算，这总共是10 + (1 + 120 + 120 + 60) x 2 = 612毫秒。

每次往返都会增加额外的612毫秒——也许这似乎不是很长的等待时间，但你的网站可能需要多次往返才能获取首个资源。

此外，HTTPS在首次请求前需要额外的两次往返——这将延迟提升到1836毫秒。

陆地上用户的延迟如何？

卫星互联网可能看起来是一个刻意夸张的例子——我选择它是为了说明问题且它确实很特别——但对于陆地上的用户，延迟在很多情况下可能更严重：

2G移动网络的延迟通常在300毫秒到1000毫秒之间
3G网络的延迟可能在100毫秒到500毫秒之间
噪声较大的移动网络——比如在音乐节等人流密集的地方。
服务器处理大量流量
其他问题

不稳定的连接也可能导致数据包丢失——这会导致需要再次进行数据包的往返传输。

了解14kB规则后你该怎么做？

当然，你应该尽量让你的网站尽可能小——你关心访问者，希望他们愉快。每个页面都应控制在14kB以内，这是一个好的目标。

这14kB包括了压缩数据——所以实际可能更接近于50kB的未压缩数据——这已经很慷慨了。考虑到阿波罗11号导航计算机只有72kB的内存。

一旦你移除自动播放视频、弹窗、Cookie、Cookie同意横幅、社交网络按钮、跟踪脚本、JavaScript和CSS框架，以及所有其他不受欢迎的垃圾，你可能就接近这个目标了。

但假设你已经尽力了，仍然无法将一切都压缩到14kB以内——14kB规则仍然有用。

确保你发送给访问者的前14kB数据包含一些有用的内容——例如一些关键的CSS、JS和解释如何使用你应用程序的前几段文字。

注意：14kB规则包括HTTP头部信息——这些信息是未压缩的(即使在第一次响应时使用HTTP/2)。它还包括图像，所以只加载页面可见区域的图像，并保持它们非常小，或使用占位符以便访问者知道他们在等待有价值的内容。

14kB规则的一些注意事项

14kB规则更像是经验法则，而不是计算机领域的基本定律：

一些服务器将TCP慢启动的初始窗口增大到30个数据包，而不是10个。
有时服务器可以在TLS握手时了解到可以使用更大的窗口，从而一开始就发送更多数据包。
服务器可以缓存路径可以管理的数据包数量，并在下次连接时发送更多。
还有其他注意事项——这里有一篇更深入的文章解释为什么14kB规则并非总是适用。

HTTP/2与14kB规则

有一种观点认为，在使用HTTP/2时，14kB规则不再适用。我读了所有能找到的相关资料，却没有看到任何证据表明使用HTTP/2的服务器已经停止使用10个数据包开始的TCP慢启动。

HTTP/3和QUIC

类似于HTTP/2，有人认为HTTP/3和QUIC将不再适用14kB规则——这并不是真的。QUIC推荐继续使用14kB规则。

本文译自 endtimes，由 BALI 编辑发布。

赞一个 (5)

PREV : 数字欧元让德国人很迷茫
NEXT : Reddit网友买了一本疑似AI生成的蘑菇识别书，导致家人中毒