我发现缓存 CDN 一直在限制我的日常浏览
缓存 CDN 和 ISP 路由上的一些怪癖，可能会让现代网络的很大一部分感觉“坏掉了”，即使基本连通性和测速结果看起来都正常。评论者认为，根本原因通常是住宅 ISP 与大型 CDN 之间的对等互联超载或管理不善，有时还会叠加流量整形、MTU 问题或“优化器”中间盒，而不是 CDN 故意限速用户。讨论还扩展到英国各 ISP 的对等互联质量、支持和带宽限额比较，以及在突然获得大量流量时自托管网站所面临的现实挑战。
诊断与根因推测
- 许多评论者认为，问题并不是 CDN 有意限速，而是 ISP 与大型 CDN（尤其是 Akamai）之间的链路超载或配置不足。
- 也有人提出经典的 ISP 流量整形，或者会对长 TCP 流（“elephant flows”）严厉对待的“优化器”中间盒，但这类机制对 VPN（UDP/WireGuard）流量的影响通常不同。
- 有人指出，VPN 或 IPv6 改变了路径和/或 CDN POP，这强烈暗示问题出在路由/对等互联，而不是终端站点本身。
- 少数人认为，像 MTU/MSS 或 PPPoE 配置错误之类的本地问题也可能导致部分故障，不过另一些人认为抓包并没有清楚显示分片问题。
ISP 质量，Zen 与其他供应商
- 几位用户报告称，在同一家 ISP 上也遇到类似的性能问题，包括对 CDN 和某些网站的减速。
- 也有人说他们在同一家 ISP 的服务很稳定，包括高速 FTTP 和 IPv6，这意味着问题可能是区域性的，或与特定路由变化有关。
- 线程中反复提到一家英国竞争 ISP，原因是它有很强的技术支持、详细的线路监控能力，以及有效向 Openreach 施压的能力。
- 有人认为支持质量很重要，因为 Openreach 的基础设施经常不可靠；也有人认为，在出问题之前，线路稳定性更重要。
对等互联、CDN 与网络中立性
- 线程中的多位网络运营者强调，性能往往取决于私有对等互联容量，以及 CDN 和 ISP 选择在哪里互联。
- 他们认为 CDN 的激励是尽可能快地传送数据；问题通常源于 ISP 在对等互联或回程上投入不足。
- 这里还简短讨论了网络中立性：有人担心 ISP 和“内容税”，但也有人声称真正的公平问题是 ISP 投资不足，而不是 CDN 的“优先级排序”。
流量整形、“无限”套餐与限额
- 几条评论描述了 ISP 长期以来的做法：限制长时间下载、先突发后限速（尤其是在有线/DOCSIS 上），以及利用拥塞信号迫使视频降低码率。
- 关于“无限”与限额套餐的争论：有人认为 TB 级限额对大多数用户来说足够；也有人认为在 2023 年，每月 1 TB 并不够用。
- 还有人指出，所谓“无限”套餐往往隐藏着公平使用条款或流量管理；也有人给出地区例子，称高流量使用并不会带来任何后果。
IPv6、MTU/PPPoE 与低层级调优
- 讨论中出现了不少技术建议：尝试 IPv6、用热点测试、降低 MTU 或调整 MSS、或者确保在 DSL 上正确处理 PPPoE 开销。
- 还建议使用基于浏览器的 PMTU 测试，以及与视频 CDN 相关的测速网站（fast.com、speed.cloudflare.com），以更现实地检测是否存在限速。
家庭托管、CDN 与 HN 流量
- 这篇博客最初是自托管在一条上传很低的家庭线路上，很快就被流量压垮（“hug of death”）。
- 评论者讨论家庭托管是否可行：有人说个位数 Mbps 对个人网站已经足够；也有人认为一旦有图片或突然流量激增，就会迅速恶化。
- 作者最终给网站前面加了 CDN，这与文章主题颇具讽刺意味；并被建议调整 CDN 缓存规则和优化图片。