低成本打造一个带宽无限的网站（上）

时间：2022-08-11 02:42:01 | 来源：网站运营

时间：2022-08-11 02:42:01 来源：网站运营

前言

前些年断断续续写的，最近突然想起来，于是翻出来又补充了一些，目前整理了一下，分享给大家。此文是上篇。

配图是 SVG 格式的，由于无法上传，目前放在 GitHub Pages 上。如果速度很慢或者被墙，可以开代理试试。

一、免费空间的遐想

免费空间

自从学习网页制作那天起，就开始期待有朝一日能有个自己的网站。

尽管当时有不少免费空间，对于简单的个人网站也够用了，然而像我这样挑剔的，试用后几乎都不怎么满意 —— 要么会偷偷插些广告，这对于有洁癖的我是无法容忍的；要么奇慢无比，而我那些「炫酷」的页面充斥了大量图片和特效，也不懂得优化，所以每次传到空间后，效果总是惨不忍睹。

也许你会说，为什么非要用免费的，花钱买个好点的配置不就得了。不过那时零花钱十分有限，每天几块钱除了早饭偶尔买些书之外，所剩无几。用在网站空间上？压根就没有过这样的念头！好在有大把的时光，于是每当闲暇时，便开始鼓捣一些极（diao）客（si）的方案，尝试将免费空间变废为宝。

有次耐下心来仔细分析，发现一些空间并没有想象中那么慢 —— 如果网页只有几个字符的话，还是很快就能出现的。只是我的网页里图片太多了，光背景就是一组高清大图。。。加上各种限速，所以才会显得十分缓慢。

客观地说，这些空间不算太差，至少延时并不高，只是带宽稍小而已。

既然找到痛点，那就能对症下药了。当然，前提还是不！能！花！钱！于是被迫开启脑洞，激发各种猥琐思路:)

改进

免费空间 —— 既然是免费的嘛，一个费用是 0，一百个也是 0，为何不多注册几个呢？

然后，从中选一家「延时最低」的专门放网页，其他的则用来放图片 —— 也许你也猜到了，只要对网页做些调整，把所有的图片都改成「绝对路径」，从不同的站点分别加载。这样，就能享受好几倍的免费带宽了~

事实上有些插广告的免费空间，只会篡改网页或脚本文件，图片倒不会变化。于是这些空间就能充分利用起来~

要是脸皮厚的话，甚至还可以打起论坛、相册、网盘、图床的主意，寻找那些附件可外链、下载速度快的网站，进一步扩充免费资源的节点~

只要节点充足，带宽显然是管够的！

不过，要同时维护这么多资源，显然是很麻烦的。因此需要一套自动化工具，用于各个节点的数据同步；若要利用论坛附件，还得实现更多功能，例如自动上传、外链检测、文件名记录、列表管理、定期维护。。。

此外，前端网页也需进行改造。为了方便使用，还得开发一个 JS 脚本，对页面中的图片路径自动调整。这其中涉及不少细节，例如站点选择的算法、无效资源的切换、本地缓存的命中。。。

看起来很有趣吧，似乎是一个前端版的负载均衡:) 要是算法够好、节点够多的话，估计 CDN 都可以省了~

缺陷

当然想象总是美好的，但真要放在现实中，估计没一个网站会这么做 —— 谁会为了省一点带宽费用，把原本很简单的东西搞得这么复杂呢。

除了复杂之外，风险也会大幅增加。某些节点要是往图片里加些水印、广告之类的倒还好，要是加入些非法反动内容，那简直就得不偿失了！

况且这样滥用免费资源，感觉也不太好意思。于是简单尝试了一段时间后，觉得意义不大又麻烦，便不再折腾。

直到多年后的一天，又回想起这个方案。。。

二、通过缓存防御网站

网站攻击

有次在讨论网站防护时，提到一个信息发布的站点 —— 它的结构很简单，只有几个页面而已，正常情况下打开是非常快的。然而一到关键时刻，流量如同洪水般涌来。网站无法访问，那些付费发布的信息就错过最佳展现时间了。

对于网站攻击，现成的解决方案有很多，例如用上 WAF、CDN 等服务，多少能分担一些。不过，通用的防御方案，自然就有通用的攻击方案。

例如通过 DNS 实现的负载均衡，攻击者使用现成的工具，就能轻易遍历出对应的 IP。更糟的是，有时域名会缓存很久，使得攻击都快结束了解析还没生效。

对于前端爱好者来说，这种传统的方案一点都不 Geek —— 理想的防护，显然应该从前后端同时入手。

提到前端，也许你会觉得奇怪，网站都被打垮了，还哪来的前端？别急。我们先来思考个本质问题：为什么网站容易垮。

相比网页，传统的应用程序在网络不好的情况下，表现的更为强劲。例如一些网络视频播放器，即使没连网也能启动，只是不能观看在线视频而已，但仍可作为普通播放器使用；而网页版的视频站点，显然就没这么强大了，如果没连网，连基本界面都看不到。

这个道理大家都懂。因为应用程序是事先下载到本地的，所以后期运行时，界面、程序可以直接启动，只有信息才依赖网络；而网页的界面、程序、信息，很多时候是混在一起的，每次都得实时传输。所以极端情况下，网页表现得更为脆弱。

改进

因此，我们需要对网页做一些改造，将「界面、程序」和「信息」彻底分离。

• 前者通常较少变动，因此可对相应的资源设置强缓存。强缓存是不走流量、直接从本地读取的，所以用户只要访问过一次，之后界面就可以瞬间展现、程序可以立即运行 —— 无论网站是否繁忙！
• 后者是动态加载的数据，存放位置并没有限制，因此可放在多个后备站点上 —— 无论自己的站点，还是免费空间。

当基本界面展现后，程序通过 AJAX 从外部站点获取信息，然后填充到页面里。如果获取失败，则尝试后备列表 —— 除非所有站点都垮了，否则只要有一个活着，信息仍能展示！

有了这样的机制，就能降低网站故障的影响了。除了没有缓存的「新用户」无法打开网站，那些曾经访问过的回头客，仍可正常浏览！

再改进

更进一步，只要不是服务崩溃、流量被封那种硬故障，我们还可继续优化，使新用户也有机会访问。

在带宽吃紧的情况下，我们需要对「界面和程序」进行精简，使其只需极小的传输流量，从而能在夹缝中求生。

那么，这究竟能精简到多小？事实上，只需一行 HTML 就够了：

我们可让网站所有的界面和功能，都由一个外部脚本来创建。这样，整个站点只需一个几十字节的页面，仅仅作为启动器而已！

尽管最终 99.99% 的流量都来自其他站点，但浏览器的地址栏，显示的仍是当前站点:)

现在，只要带宽还有一丝残喘的余地，新用户就有机会获取到这个迷你启动页，进而从互联网上各个节点加载出完整内容！

由于整个站点只承载一个极小的文件，因此防御策略可以简单很多。此外，外部脚本的路径可通过后端工具随时改变，用以避开速度缓慢的节点 —— 毕竟 HTTP 控制缓存的能力，比 DNS 丰富多了！

缺陷

当然，这个方案似乎过于激进 —— 不仅需要对业务做大量改造，而且对搜索引擎也不利，因此最终并没有实际应用。

此外，还有一个大问题也未能解决：用户刷新页面，会导致强缓存失效，从而产生网络请求。如果此时网站挂了，那么用户刷新后，不是长时间等待，就是直接显示错误。

如此美妙的防御方案，最终却防不住 F5 按钮。。。这个问题，直到 HTML5 时代的一项新科技才能解决 —— 应用缓存。

应用缓存

关于应用缓存，熟悉前端的小伙伴们都不陌生，它正是为提高 WebApp 的体验而设计。

应用缓存的用法很简单，通过一个列表清单，告诉浏览器预先缓存哪些资源：

之后访问列表中的资源时，浏览器就直接从本地读取。相比强缓存，应用缓存的离线程度更高 —— 不仅没连网也能访问，甚至还可以刷新！

缓存不耐刷的问题，总算是能解决了。只是此时兴致已过，并没有去尝试改进。对于浏览器缓存，当时觉得更好玩的还是攻击方面 —— 中间人和前端脚本相互结合，批量污染缓存。有兴趣的可以看之前写的流量劫持相关文章。

也许正是因为易受中间人污染，以及 不够灵活 等原因，应用缓存始终存在一些争议，以至于后来被 Web 标准废弃了。取而代之的，则是一个更逆天的标准。。。

三、前端代理服务

前端代理

HTML5 时代的黑科技层出不穷，但最具创新的也许要数 Service Worker，它甚至可以颠覆传统的 B/S 网络架构。

顾名思义，Service 是服务程序，而 Worker 常用于多线程。因此 Service Worker（以下简称 SW）是一种独立于页面、可持续运行的浏览器后台程序。

SW 提供了一组 API，可让网站开发者拦截自己站点下 所有页面 产生的 所有请求，并且能自定义响应结果。（除了一些特殊请求无法拦截）

这，如同在本地开启一个反向代理服务！

有了这么逆天的功能，在前端做负载均衡就非常容易了，甚至还能实现过去不敢想象的效果 —— 实时无缝的切换。

实时切换

作为代理，当 SW 加载上游资源失败时，可选择不返回错误结果，而是尝试后备站点再次加载，直到返回正确结果，才响应给下游网页：

在网页看来，这只是一次普通的请求与响应 —— 也许用时更长一些，但结果仍是正常的。SW 中的重试细节，对于业务是完全透明的！

相比 DNS 最少也有数秒的缓存时间，这种通过程序控制的方案，能在极短的时间内切换源站点。这样即使某些节点出现故障，页面甚至都毫无感知！

校验加密

除了能改变 URL 之外，SW 当然还能操作返回的数据。

这意味着，我们可以增加一个校验机制，用以检测资源是否遭到篡改。于是那些插广告、加水印之类的问题，就能很好解决了！

此外，我们还可以对原始数据进行加密，再由 SW 解密。这对于私密性不高的节点，很是有意义。

例如用 Raw Git 作为免费空间，我们所有的文件都能在 GitHub 仓库里找到，任何人都可以轻易查看。但如果对文件进行加密，同时对 SW 中的解密算法进行混淆保护，就能增加查看难度了 —— 至少 GitHub 的搜索功能、以及普通的蜘蛛，是不会抓到明文内容了。

更进一步，我们甚至还可以对文件名进行 Hash 再存储。这样，暴露的只是一堆乱七八糟、没有目录层次的文件！

离线启动

前面我们提到，SW 能拦截页面里的请求。事实上 SW 开启之后，访问页面本身也会经过 SW。

这意味着：用户只要装上 SW，之后所有的请求都可代理到外部节点上，于是可大幅减少自己网站的流量消耗！

这样就算我们的网站挂了，但只要有一个节点可用，用户仍能正常访问！

精简启动

为了能在带宽吃紧的情况下迎接新用户，我们参照之前「迷你启动器」的方案，把安装 SW 所需的资源，精简到最小 —— 最终只需两个极小的文件：html 和 js 文件。（SW 的脚本必须在当前站点下）

用户首次访问时，无论访问哪个 URL，我们都返回这个 html 文件，用以安装 SW 服务；安装完成后，页面自动刷新，这时所有请求都走 SW 代理了！

关于 html 的内容，和之前探讨的一样，所有功能都由外部脚本实现：

而 SW 脚本的内容，同样也可以放置在外部：

于是，我们的站点只需承载两个极小的文件，就能获得无尽的带宽！

改造成本

相比之前强缓存的方案，如今使用 SW 无需对前端做任何改造，页面里的资源仍保持原始路径即可。如同使用 VPN 一样，无需对应用程序对任何修改，开启后流量就能自动转发到代理上，用起来非常简单。

这样，任何一个网站都能轻松接入使用！

事实上 SW 可实现的效果远不止这些，我们继续深入挖掘吧。




作者：etherdream，阿里巴巴高级安全工程师

原文链接

更多技术干货敬请关注云栖社区本站机构号：阿里云云栖社区 - 本站