CDN 和 Edge Functions

CDN（Content Delivery Network，内容分发网络）是一种网络结构，其目的是通过在各地部署多个服务器节点，将网站或网络应用的内容更接近地提供给用户，以提高访问速度和可靠性。以下是CDN的主要作用：

1. 提高访问速度：通过将内容缓存到距离用户较近的服务器上，用户可以从最近的节点获取所需的数据，从而降低延迟和加速内容加载。
2. 降低原始服务器的负担：由于CDN节点可以处理许多用户请求，原始服务器的负载会减轻，从而增强其稳定性和响应能力。
3. 全球覆盖：对于跨国或全球运营的网站和应用，CDN可以确保世界各地的用户都能获得较好的访问体验。
4. 负载均衡：在高流量时段，CDN能够有效地分散流量，使所有请求均匀地分配到各个服务器，防止某一服务器因流量过大而崩溃。
5. 增强网站安全性：许多CDN提供商提供额外的安全功能，如DDoS攻击防护、Web应用防火墙等，以帮助抵御各种网络攻击。
6. 容错与高可用性：如果某个CDN节点发生故障，流量可以被重定向到其他健康的节点，从而确保内容的持续可用性。
7. 动态内容优化：尽管CDN经常与静态内容关联，但许多现代CDN也优化动态内容的传输，如API调用、数据库查询结果等。
8. 边缘计算：某些CDN提供边缘计算功能，允许开发者在CDN的边缘节点上运行代码，从而进一步减少数据的往返延迟。
9. 实时流量和分析工具：CDN提供商通常会提供实时流量监控和分析工具，帮助网站拥有者了解用户行为、流量来源等信息。

总的来说，CDN通过将内容更近地分发给用户，不仅提高了内容的访问速度，还增强了网站的稳定性和安全性。

HTTP/2 引入了多项技术和优化，使得它可以更有效地处理并发的 HTTP 请求。相对于 HTTP/1.1，HTTP/2 在以下几个方面实现了并发的优化：

1. 多路复用（Multiplexing）：HTTP/2 允许在单一的 TCP 连接上并发地传输多个请求和响应消息。这是通过将 HTTP 消息分解为较小的帧来实现的，这些帧可以交错发送并在接收端重新组合。这消除了 HTTP/1.1 中的“队头阻塞”问题，该问题在一个早期请求因某种原因被延迟时会阻止后续请求的完成。
2. 头部压缩（Header Compression）：HTTP/2 引入了 HPACK 压缩，它可以减少请求和响应头的大小。这不仅减少了数据量，而且还允许更多的并发请求在网络上传输，因为每个请求和响应所需的带宽更小。
3. 请求优先级（Request Prioritization）：HTTP/2 允许客户端为其请求设置优先级，这意味着重要的资源（如主要的 CSS 或 JavaScript 文件）可以比其他资源更早地被下载和处理。
4. 服务器推送（Server Push）：HTTP/2 的另一个特点是服务器可以“推送”资源到客户端，即在客户端明确请求之前，服务器可以主动发送资源。这可以进一步提高页面加载时间，尤其是当服务器预知客户端可能会需要的其他资源时。

那么，为什么 HTTP/1.1 不支持这些功能呢？

HTTP/1.1 设计之初，并没有考虑到今天的 Web 的复杂性和大量资源的需求。当初的 Web 主要是文本为主，只有少量的图像和其他资源。随着时间的推移，Web 页面变得越来越复杂，需要加载的资源也越来越多，但 HTTP/1.1 的设计并没有适应这种变化。

在 HTTP/1.1 中，每个请求-响应周期都需要一个单独的 TCP 连接。为了实现并发，浏览器会开启多个并行的 TCP 连接到同一服务器，但这种方法有其限制，并且可能会对服务器和网络造成不必要的压力。

总的来说，HTTP/2 引入了多项技术和优化，使得它可以更有效地处理并发的 HTTP 请求，而 HTTP/1.1 在设计时并没有考虑到如今 Web 的复杂性和并发需求。

Service Workers 是 Web 平台上的强大特性，用于支持离线体验、消息推送和网络代理等功能。关于 Service Workers 使用 HTTP/1.1 而不是 HTTP/2 的观点，需要考虑以下几个方面：

1. 与协议无关：Service Workers 作为网络代理工作，并不直接决定所使用的 HTTP 协议版本。协议版本的选择主要取决于浏览器和服务器的能力和配置。如果浏览器和服务器都支持 HTTP/2，那么实际的请求很可能就会使用 HTTP/2。
2. 混淆来源：当我们看到 Service Worker 使用的请求标记为 HTTP/1.1，这可能是因为开发者工具在显示 Service Worker 请求时采用了这种表示。但实际上，背后的网络请求可能仍然使用 HTTP/2。
3. 缓存特性：Service Workers 的一个主要用途是拦截和缓存请求。由于缓存的内容不需要再次经过网络，所涉及的 HTTP 版本可能在某些情况下变得不那么相关。
4. 浏览器和服务器支持：虽然现代浏览器和许多服务器都支持 HTTP/2，但仍有一些环境或情况只支持 HTTP/1.1。为了兼容性，Service Workers 需要能够处理任何 HTTP 版本的请求。
5. 工具显示限制：在某些开发者工具中，由于显示限制或历史原因，请求可能标记为 HTTP/1.1，但这并不一定反映实际使用的协议版本。

综上所述，Service Workers 本身并不决定 HTTP 请求的版本。当我们看到 Service Worker 的请求显示为 HTTP/1.1，这可能是因为工具的显示方式、缓存行为或其他原因，而不是 Service Worker 强制使用 HTTP/1.1。在支持 HTTP/2 的环境中，Service Worker 拦截的请求完全可以利用 HTTP/2 的优点。

HTTP/2 引入了一个流优先级概念，该概念允许客户端向服务器提供关于如何最好地处理多个并行请求的建议。通过正确地设置优先级，客户端可以确保最重要的资源首先被传输，从而加快页面的渲染速度。

以下是 HTTP/2 请求优先级的主要概念：

1. 流（Stream）:

   在 HTTP/2 中，一个连接上的所有通信都被分解成小块并在多个流中发送。每个流都有一个唯一的整数标识符。

2. 权重（Weight）:

   每个流都有一个权重，该权重是介于 1 和 256 之间的整数。权重决定了与其他流的相对重要性。例如，一个权重为 200 的流有比权重为 100 的流双倍的优先级。

3. 依赖关系（Dependency）:

   一个流可以被设置为依赖另一个流。这意味着，除非父流已完成，否则当前流（子流）不应该开始。这样，你可以表达资源之间的关系，例如：CSS 应该在 JS 之前加载。

4. 独占标志（Exclusive Flag）:

   如果设置了这个标志，它表示当前流应该独占其父流的所有其他依赖关系。这是一个控制优先级的方法。

大多数时候，浏览器会为你处理优先级，并为关键请求（例如视窗内的资源）设置更高的优先级。然而，如果你在编写服务器代码或客户端库，并想要手动设置优先级，你需要使用库或工具的特定 API 来设置权重和依赖关系。

当有大量的并行请求时，知道哪个请求最重要就变得至关重要。例如，对于一个网页来说，首屏的 CSS 和关键的 JS 比较重要，因为它们可以阻止页面的渲染。通过设置正确的优先级，你可以确保关键资源先被加载和处理，从而提高性能。

并不是所有的服务器和中间设备都会完全遵循客户端的优先级建议。优先级在 HTTP/2 中是一个建议性的机制，而不是强制性的。

总之，HTTP/2 的请求优先级是一个强大的工具，可以用来优化网页的加载速度和性能，但它需要与服务器、CDNs 和其他中间设备一起正确地工作。

最近在互联网大善人加新学到了一个叫 br 的 Content-Encoding。然后问了下 ChatGPT。

Content-Encoding头部在HTTP中表示应用于实体主体的内容编码转换（通常是压缩）。以下是一些常见的Content-Encoding值：

1. identity

   • 描述: 不应用任何编码，即原始数据。

2. gzip (GNU zip)

   • 描述: 采用gzip压缩方法，使用Deflate算法并附加gzip的头部和尾部信息。

3. deflate

   • 描述: 基于Deflate压缩算法，但不包含gzip的附加头部或尾部信息。

4. br (Brotli)

   • 描述: 是一个现代的压缩算法，由Google开发，为HTTP内容设计，提供了很好的压缩效率。

5. compress

   • 描述: 使用LZW压缩算法。过去因专利问题被避免使用，现在已很少见到。

6. sdch (Shared Dictionary Compression over HTTP)

   • 描述: 使用共享字典进行压缩的方法。但此方法已被废弃并从许多浏览器中移除。

以上是最常见的Content-Encoding值。但理论上，其他编码算法也可以被定义和使用，只要客户端和服务器都进行了相应的支持。

Brotli 是一种通用的无损数据压缩算法，它是由 Google 的 Jyrki Alakuijala 和 Zoltán Szabadka 开发的。这个算法是为 HTTP 内容编码设计的，并在 Chromium、Firefox、Edge 和其他一些主流浏览器中得到了实现。Brotli 在大多数情况下相较于 gzip 提供了更好的压缩率。

Brotli 算法的原理包括以下几个关键技术：

1. LZ77 压缩：Brotli 和 gzip 都使用了 LZ77 压缩技术，这是一个基于字典的方法，它可以找到前面出现的相同的数据块，并用较短的引用替换它们。
2. 静态霍夫曼编码：Brotli 使用了预定义的静态霍夫曼编码表，这样可以避免在每次压缩时都传输这些表。这是 Brotli 和 gzip 之间的一个重要区别，gzip 使用动态霍夫曼编码，并将霍夫曼树包含在压缩数据中。
3. 上下文建模：Brotli 采用了复杂的上下文建模技术来改进霍夫曼编码，从而提供更好的压缩率。

相较于 gzip，Brotli 的主要提升包括：

1. 更好的压缩率：在多数情况下，Brotli 提供的压缩率比 gzip 更好。这意味着对于同样的数据，Brotli 生成的压缩文件通常更小。
2. 更快的解压速度：尽管 Brotli 的压缩速度可能比 gzip 慢，但它的解压速度往往更快。
3. 更高的资源消耗：Brotli 使用了更大的窗口大小和更复杂的上下文建模技术，这意味着它在压缩时通常需要更多的内存。
4. 多种压缩级别：Brotli 提供了不同的压缩级别，从 0（最快，压缩率最低）到 11（最慢，压缩率最高）。
5. 更适合现代网络：由于 Brotli 主要是为 HTTP 内容编码设计的，它在处理现代网页内容（例如 HTML、CSS 和 JavaScript 文件）时表现得尤为出色。

总的来说，Brotli 是一个在大多数情况下比 gzip 更高效的压缩算法，但它需要更多的资源来实现最高的压缩率。在选择使用哪种算法时，通常需要权衡压缩率、压缩速度和资源消耗之间的关系。