Edge腰果和POP

1）POP是什么，为什么"边缘"

• 潜伏期（低于客户的RTT）。
• 起源的负载和成本（离载）。
• 区域/云之间的流量（egress节省）。

Edge不仅仅是kesh。现代的POP支持L7路由，WAF/机器人滤波器，极限，A/B/金丝雀，转换和边缘匹配（脚本/功能）。

2） Edge Cashing体系结构

2.1平面vs分层（分层）

扁平：每个POP都起源。简单，但起源昂贵。
Tiered/Shield：POP → Shield POP（中央缓存）→起源。Shield累积了kesh错误，为起源创建了"伞"。

2.2个区域部分

按区域/辖区划分缓存域（GDPR/数据本地化）。
变体："EU-only POPs"和"Global POPs"，分开密钥/规则。

2.3 Anycast+latency/geo-aware路由

Anycast通过BGP将客户带到最近的POP。
Geo/latency-aware通过活动RTT/错误测量在 ROR/区域池之间切换。

3）缓存密钥，"Vary"，TTL和新鲜

3.1键设计

规范化查询：排序查询参数,删除噪音（utm, ref）。
包括语义轴："tenant"，"locale"，"schema版本"（"v=3"），但避免PII。
对于私人内容-共享公共和私人凯什（请参阅§7）。

3.2缓存控制（HTTP）

• `Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60, stale-if-error=120`
• "ETag"/"Last-Modified"用于条件GET（304）。
• Vary：最大限度地减少基数（"接受编码"，"接受语言"，有时是私有路径的"授权"/"Cookie"）。
• Micro-cache for"接近扬声器"：1-5秒+SWR。

3.3 Stale策略

SWR （stale-wile-revalidate）：我们给出过时的答桉,我们更新背景。
SIE （stale-if-error）：如果出现错误,起源将使用"SIE" -TTL之前的kesh。
Soft/Hard TTL：温和的时机（你可以打架），坚硬（完全失误）。

4）残疾： 如何更新"边缘"

4.1按键和标签

通过URL/前缀的 PURGE/BAN-粗略但快速。
Surrogate-Key/Tags：为对象分配标签（'article： 42'、'category： 7'）,按标签键入-大规模残障且没有URL过度使用。

4.2事件性残疾

如果将数据更改为起源，则发布事件（Kafka/NATS）→边缘残疾人调用BAN/PURGE/软外展。

4.3文物转化

对于静态-文件名中的content-hash。
对于API,如果更改不兼容,请更改密钥版本（'v=4'。

5）起源保护和性能

5.1 Origin shielding

将Shield POP作为唯一失误点,→减少风暴起源的倍数。

5.2 Coalescing/single-flight

在边缘，一个请求在错过时"刺穿"kesh；其他人正在等待（没有追赶stampede）。

5.3 Rate-limit/Queue/Shedding на edge

过载-将低优先级/匿名查询重置为POP而不是起源。

5.4 Signed URL / Signed Cookie

起源隐藏在边缘后面。通过带有TTL和属性（IP/Geo/Path）的签名链接/cookie访问私有内容，以免分发给"所有人"。

6）运输和转型

6.1 HTTP/2–3 и QUIC

HTTP/2：多路复用，头压。
HTTP/3/QUIC：在p95/p99 TTFB下方,HOL锁定更少,丢失通道→更好。

6.2压缩和映像

文本的Brotli，图像的AVIF/WebP，边缘的图像恢复（响应注释，DPR）。
按格式/大小划分的Kesh变体：键包括"width/format"（或"Vary：Accept"/Client-Hints）。

6.3 TLS/0-RTT（整洁）

重新启动会话可加快安装速度,0-RTT安装可能容易受到重播的攻击→仅启用等效的GET。

7）公共vs私人edge-kesh

7.1公共服务

"Cache-Control：public，s-maxage=……"和最小的"Vary"。
适用于目录,新闻,图像,静态CDN。

7.2私人/个性化

• 不要在shared级别缓存："Cache-Control： private"（浏览器kesh）。
• Key-segmentation：在密钥中包含tenant/user-id（或令牌哈希）并标记为私有共享（小心存储和PII）。
• 签名Cookie和Edge-auth：kesh是公开的，但是签名访问（边缘带有加密会话状态的选项）。

8) Edge-compute (Workers/Functions)

POP上的轻量级功能：路径/标头重写、A/B分割、密钥归一化、SWR逻辑、邻域资源预报。
POP上的本地KV/Cache API用于毫秒操作。
局限性：短时间/记忆，缺乏长寿连接，专心处理PII/区域性。

伪示例（像工人一样）

js export default {
async fetch(req, env) {
const key = normalize(req);
let res = await caches. default. match(key);
if (res) return withHitHeader(res, "HIT");

res = await fetch(req, { cf: { cacheEverything: true }});
const ttl = computeTTL(res);
eventWaitUntil(caches. default. put(key, res. clone(), { expirationTtl: ttl }));
return withHitHeader(res, "MISS");
}
}

9）配置示例

9.1 Nginx: micro-cache + SWR

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:200m inactive=30m;
map $request_method $skip_cache { default 0; POST 1; PUT 1; DELETE 1; }

server {
location /api/list {
proxy_cache api;
proxy_cache_key "$scheme://$host$uri$is_args$args";
proxy_cache_valid 200 2s;          # micro-cache proxy_cache_use_stale error timeout updating;# SIE + SWR proxy_cache_background_update on;
add_header X-Edge-Cache $upstream_cache_status;
proxy_pass http://origin_pool;
}
}

9.2 Varnish: surrogate keys и BAN

vcl sub vcl_recv {
if (req. method == "BAN") {
if (req. http. Surrogate-Key) {
ban("obj. http. Surrogate-Key ~ " + req. http. Surrogate-Key);
return (synth(200, "Banned"));
}
}
}

sub vcl_deliver {
set resp. http. Surrogate-Key = "article:42 tag:author:7";
set resp. http. Cache-Control = "public, s-maxage=300, stale-while-revalidate=60";
}

9.3 Envoy（边缘缓存过滤器）

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. http. cache. simple_http_cache. v3. SimpleHttpCacheConfig

9.4 CloudFront-style行为（草图）

Behavior A："/images/"是长的TTL，按压缩和格式排列。
Behavior B：'/api/'是短的TTL，SWR，签名cookie，WAF/机器人保护。
启用Origin Shield，状态500/502/504 → "stale-if-error"。

10）可观察性，SLO和报告

10.1个指标

cache_hit_ratio （POP/区域/路线），byte_hit_ratio。

origin_offload = 1 − (origin_requests / edge_requests).

TTFB/TTL按配额，stale_responses_total，revalidations_total。

stampede_prevented_total, coalesced_waiters.

shield_hit_ratio （tiered）、origin_egress_bytes（成本）。

10.2 Logi/Traces

标有"HIT/MISS/STALE/UPDATING/BYPASS"标签的徽标，钥匙，TTL，POP，tenant。
在分布式预告片中，标记来源（"edge"，"origin"）和原因（revalidate/stale/error）。

10.3个SLO示例

«Для `/api/list`: p99 TTFB ≤ 250 мс, edge hit ≥ 70%, byte-hit ≥ 80%, origin error-offload ≥ 90%».

""stale-if-error"响应的比例≤每天1％。"

11）安全、隐私、合规性

WAF/机器人管理-在边缘过滤到起源。
数据区域性：仅将私有文物存储在允许的POP中；使用区域特定的密钥和ACL。
Edge上的签名和令牌，不要从公共腰包中给出私人答桉。
PII最小化：不要在密钥中包含个人数据；加密cookie；用于个性化的短TTL。

12）典型食谱

12.1"接近扬声器"（磁带/列表）

带有+SWR的Micro-cache 1-3在边缘，shield启用，单飞，negative-cache用于空白1-5秒的结果。

12.2图像云/媒体

边缘重新设计/格式（WebP/AVIF），"width/format"缓存选项，长的TTL，内容标签障碍。

12.3个个性化API

"Cache-Control： private"或signed cookie+键分段（tenant）, TTL短,SWR for"近乎公开"的响应部分。

12.4大销售/高峰

加热关键资源（prewarm），增加TTL的静态，激进的SWR/SIE，Shield对起源的严格限制。

13）反模式

没有"Vary"，响应不同→泄漏/数据错误。
巨大的"Vary" →基调→低命中率。
prod/experiments的共享缓存→污染。
没有单飞→起源的风暴失误。
SWR →升级竞赛和验证查询雪崩没有限制。
Edge-kesh私人响应作为公共→安全事件。
在全球载荷下不存在tiered/shield →原点过热。

14）实施支票

• 绘制POP涂层，包括anycast+latency-routing。
• 选择tiered/shield和single-flight/coalescing策略。
• 设计密钥和Vary（最小基数,没有PII）。
• 配置TTL/SWR/SIE（软/硬TTL）和非主动缓存。
• 启用signed URL/cookie,串联起源,启用WAF/bot过滤器。
• 组织残疾：Surrogate-Key/BAN+事件驱动。
• 提高hit/byte-hit/offload/TTFB和per-POP dashboard的指标。
• 在高峰前加热，在风暴/超载时运行。
• 隐私/区域性测试，密钥审核和策略。
• Edge的SLO/错误预算和 TTL/SWR自动调整标准。

15) FAQ

Q： 如何在边缘选择TTL?

答：推开允许的过时性和命中率目标。对于"接近动力学"，带有+SWR的1-5；参考资料/图像-因事件/标记而残疾的分钟/小时。

Q： 什么时候需要Shield POP?

答：通过全球交通或热键：盾牌大大减少了起源的失误,并稳定了"追赶"波。

Q： 如何缓存授权响应?

答：要么是"私人"（浏览器），要么是带有签名Cookie/URL和密钥细分（没有PII）的公共，要么通常是用于关键个人数据的旁路。

问：HTTP/3该怎么办？
A：包括：移动/丢失频道特别获胜。控制HTTP/2上的代理和后退兼容性。

16）结果

Edge腰果和POP网络是速度和经济平台的基础。成功取决于正确的密钥和"Vary"，合理的TTL/SWR/SIE，标记/事件残疾，起源保护tiered/shield以及可观察性（hit/offload/TTFB）和安全/隐私纪律。按照支票单-"边缘"将成为您的加速器，而不是惊喜的来源。