也可以在dev.to上阅读（警告它远大于 14kB）
拥有一个较小的网站可以使其加载速度更快——这并不奇怪。
令人惊讶的是，一个14kB页面的加载速度比一个15kB页面快得多——也许更快——而一个页面和一个页面612ms之间的区别是微不足道的。15kB16kB
这是因为TCP 慢启动算法。本文将介绍它是什么，它是如何工作的，以及为什么你应该关心。但首先我们将快速回顾一些基础知识。
什么是 TCP？ #
传输控制协议 (TCP)是一种使用Internet 协议 (IP)可靠地发送数据包的方式——有时这被称为TCP/IP。
当浏览器请求您的网站（或图像或样式表）时，它会使用HTTP发出请求。
HTTP 建立在 TCP 之上，单个 HTTP 请求通常由许多 TCP数据包组成。
就其自身而言，IP 只是一个用于将数据包从 Internet 上的一个位置发送到另一个位置的系统。IP 无法检查数据包是否已成功到达其目的地。
对于网站来说，知道所有数据都已经到达很重要——否则我们最终可能会丢失大量的网页。网络还有其他用途，这并不重要——比如流式传输实时视频。
TCP 是 IP 的扩展，它允许浏览器和您网站的服务器相互告知哪些数据包已成功到达。
服务器发送一些数据包，然后等待浏览器的响应，说它已收到数据包（这称为确认或 ACK），然后它会发送更多数据包 - 或者如果它没有收到 ACK，它可以发送数据包再次。
什么是 TCP 慢启动？ #
TCP 慢启动是服务器用来确定一次可以发送多少数据包的算法。
当浏览器第一次连接到您的服务器时——服务器无法知道它们之间的带宽量。
带宽是每单位时间可以通过网络传输的数据量。通常它以每秒位数 ( b/s) 为单位。管道是一个常见的类比 - 将带宽视为每秒可以从管道中流出的水量。
您的服务器不知道该连接可以处理多少数据——因此它首先向您发送少量且安全的数据——通常是 10 个 TCP 数据包。
如果这些数据包成功到达您网站的访问者，他们的计算机会发回一个确认 (ACK)，说明数据包已收到。
然后，您的服务器会发回更多数据，但这一次它会使数据包数量增加一倍。
重复此过程，直到数据包丢失并且您的服务器没有收到 ACK。（此时服务器继续发送数据包，但速度较慢）。
这就是 TCP 慢启动的要点——在现实生活中，算法各不相同，但本质上它就是这样工作的。
那么 14kB 是从哪里来的呢？ #
大多数 Web 服务器 TCP 慢启动算法从发送 10 个 TCP 数据包开始。
TCP 数据包的最大大小为1500 bytes.
这个最大值不是由 TCP 规范设置的，它来自以太网标准
每个 TCP 数据包在其标头中使用40 个字节——16 个字节用于 IP，另外24 个字节用于 TCP
每个 TCP 数据包剩下1460 个字节。10 x 1460 = 14600 bytes或大约 14kB！
因此，如果您可以将您的网站（或其中的关键部分）调整为 14kB，您可以为访问者节省大量时间——他们与网站服务器之间的往返时间。
一次往返能有多糟糕？ #
人们非常不耐烦——一次往返可能会非常长。多长时间取决于延迟……
延迟是数据包从源传输到目的地所需的时间。如果带宽是每秒可以通过管道的水量 - 延迟是一滴水进入管道然后从另一端流出的时间。
这是一个有趣的例子，说明延迟有多糟糕：
卫星互联网 #
卫星互联网由环绕地球轨道的卫星提供。它被人烟稀少的地区、石油钻井平台、游轮和航空公司的机上 WiFi 使用。
为了说明这个延迟不好的例子，让我们假设一群石油钻井平台的兄弟忘记了他们的骰子，需要使用出色的（小于 14kB）missingdice.com来玩龙与地下城。
他们中的第一个使用手机请求网页……
手机将该请求发送到钻机的WiFi 路由器 ——该路由器将该数据发送到钻机上的卫星天线——让我们说得好听点1ms。
然后，卫星天线必须将该数据发送到地球上方轨道上的卫星。
通常，这是使用地球表面上方地球静止轨道上的卫星来实现的。35786km光速以光速传播299792458 m/s，因此从地球发送到卫星的信息需要120ms。卫星然后将消息发送回地面站，地面站需要另一个120ms。
然后地面站必须将请求发送到服务器在地球上的任何地方（光会减慢到200000000 m/s当它在光缆中时）。如果地面站和服务器之间的距离与纽约和伦敦之间的距离相同，则需要大约28ms- 但如果更像纽约和悉尼之间的距离，则需要80ms- 所以我们称之为60ms（我们的数学方便的数字）
然后请求需要由服务器处理，这可能需要10ms服务器再次将其发送回来。
回到地面站，进入太空，回到卫星天线，然后回到 wifi 路由器，再回到我们的加油机电话。
phone -> WiFi router -> satellite dish -> satellite -> ground station -> server -> ground station -> satellite -> satellite dish -> WiFi router -> phone如果我们做数学，那就是 10 + ( 1 + 120 + 120 + 60 ) x 2 = 612ms.
这是每次往返的额外费用612ms——也许等待的时间并不长，但您的网站可以轻松地进行多次往返，只是为了获取它的第一个资源。
此外，HTTPS 还需要两次额外的往返，然后才能执行第一次——这让我们达到了1836ms!
生活在旱地上的人的延迟呢？ #
卫星互联网可能看起来像是一个故意的坏例子——我选择它是因为它说明了这一点并且很奇怪——但对于旱鸭子来说，延迟可能会比这更糟，原因有很多：
- 2g 移动通常具有介于
300ms和之间的延迟1000ms - 3g 网络可以有任何介于
100ms和500ms之间的延迟 - 嘈杂的移动网络——比如在音乐节等异常拥挤的地方。
- 处理大量流量的服务器
- 坏的东西
断断续续的连接也可能导致数据包丢失——导致另一次往返以获取丢失的数据包。
既然您了解了 14kB 规则，那么您能做什么呢？ #
当然，您应该使您的网站尽可能小——您爱您的访问者并且希望他们快乐。将每个页面都放在 14kB 以下是很好的目标。
那 14kB 包括压缩——所以它实际上可能更像是大约 50kB 的未压缩数据——这是慷慨的。考虑到阿波罗 11 号制导计算机只有 72kB 的内存。
一旦你丢失了自动播放的视频、弹出窗口、cookies、cookie 同意横幅、社交网络按钮、跟踪脚本、javascript 和 css 框架以及所有其他没人喜欢的垃圾——你可能就在那里。
但是，假设您已尽最大努力将所有内容都放入 14kB 中，但不能 - 14kB 规则仍然有用。
如果您确保发送给访问者的前 14kB 数据可用于呈现有用的内容——例如一些关键的 CSS、JS 以及解释如何使用您的应用程序的前几段文本。
注意 — 14kB 规则包括未压缩的HTTP 标头（即使在第一个响应中使用 HTTP/2） — 它还包括Images，因此只加载首屏的内容并保持非常小，或者使用占位符让您的访问者知道他们'正在等待好的东西。
规则的一些注意事项 #
14kB 规则更像是一条经验法则，而不是计算的基本法则：
- 一些服务器已将 TCP 慢启动初始窗口增加到 30 个数据包而不是 10 个
- 有时服务器知道它可以从更大数量的数据包开始，因为它使用 TLS 握手来建立可以使用的更大窗口。
- 服务器可以缓存一条路由可以管理多少数据包，并在下次连接时发送更多数据包。
- 还有其他警告—— 这里有一篇更深入的文章，关于为什么 14kB 规则并非总是如此
HTTP/2 和 14kB 规则
有一种想法是 14kB 规则在使用 HTTP/2 时不再适用。我已经阅读了所有关于这方面的内容，但没有让自己感到无聊——但我没有看到任何证据表明使用 HTTP/2 的服务器已经停止使用 TCP 慢启动，从 10 个数据包开始。
HTTP/3 和 QUIC
与 HTTP/2 类似，有一种观点认为 HTTP/3 和 QUIC 将取消 14kB 规则——这不是真的。QUIC 推荐相同的 14kB 规则。
延伸阅读 #
这篇文章的大部分内容来自以下资源：
- Ilya Grigorik 的高性能浏览器网络
- 通过适应初始 TCP 慢启动窗口来提高 HTTP 性能作者 Simon Hørup Eskildsen
- 关键资源和前 14 KB - 回顾
- HTTP3 性能改进
- 发表
