CloudFront基础

CloudFront不仅是用于优化用户网络体验，还可以减少服务器和网络的压力。更重要的，它可以防御DDoS攻击，因为攻击者需要同时攻击所有edge节点。

CloudFront原理

比如你在中国，想请求一张 Web 服务器位于美国的图片，在检索到图片之前，这个请求会从一个网络路由到另一个网络，在经历N多个路由后，才能到达该图片所在的服务器，这是一个非常大的跳数，同时会对性能、可用性和可靠性产生很大影响。

但是如果将原始服务器与 CloudFront 关联（关联后 CloudFront 知道从哪些原始服务器获取资源），这时不再通过原始服务器访问图片，而是通过 CloudFront 分配的 URL 访问图片，则该请求将被路由到迟延最短的 CloudFront 边缘站点。

如果该内容在迟延最短的 CloudFront 边缘站点的缓存中存在，则将直接从该边缘站点的缓存中返回图片。如果请求的内容不在该边缘站点的缓存中，才从源去取。这样大大减少了路由数，从而提高了性能。

如果请求的内容不在迟延最短的边缘站点的缓存中，CloudFront 的处理如下：

① CloudFront 将比较该请求与分配中的说明，然后根据对应的文件类型将文件请求转发到适用的源服务器。例如，对于图像文件，转发到 Amazon S3 存储桶；对于 HTML 文件，转发到 HTTP 服务器。

② 原始服务器将这些文件发回 CloudFront 边缘站点。

③ 当从源返回的第一个字节到达 CloudFront 时，CloudFront 就开始将这些文件转发给用户，同时将这些文件添加到边缘站点的缓存中，方便有人再次请求这些文件。

Regional Edge Cache

除了POP点外，CloudFront还有regional edge caches来进一步提升性能， 它工作在POP点和源服务器的中间。

POP点的缓存空间有限，当缓存的对象过期后会将它移除；而Regional edge cache有更大的缓存，它接近用户所在的region，可以将文件缓存的更久，这样CloudFront不用再重新请求源服务器。

当用户请求的内容不在POP点时，POP点通常先请求最近的Regional edge cache，如果内容在里面就返回给POP点。

整个过程如下：

image-20220819103107216

下面的场景，POP点直接回源，不会请求Regional Edge Cache:
1.Proxy HTTP 请求 (PUT, POST, PATCH, OPTIONS, DELETE)
2.动态API请求

Multiple Origin

根据请求路径，CloudFront可以将请求路由到不同的Origin

• /images/*

• /api/*

• /*

image-20220912181418375

Origin Group

CloudFront支持Origin级别的failover，以提升可用性。它是通过origin group实现的，里面有两个源， 一个主一个备。当主挂了，CloudFront自动切换到备。流程如下：

.image-20220912181911518

参考： Creating an origin group .