公寓大楼里的土法炼钢：下载加速实践记录
说起这回折腾，就是被逼的。我不是什么大公司的架构师，我就是个爱搞点小玩意儿、喜欢分享给周围朋友的普通人。我的朋友们大部分都住在我这个片区，大家都是同一个公寓大楼群。我最近捣鼓了一个小游戏更新，几百兆的东西，按理说，传上去，大家下载就好了。
我开始没把这当回事。
我心想现在云盘这么方便，直接丢上去不就完事了？结果，我上传到某度云，朋友们下载的时候，那速度简直是蜗牛在散步。几百兆的文件，能下个把小时，中间还经常断线，下完了发现文件校验出错，重来！大家怨声载道的，搞得我分享的乐趣都没了。
我琢磨了一下，问题出在哪儿？我们这公寓大楼，网络看着挺光鲜，实际上出口带宽窄得跟针眼似的。所有人都往外跑，一堵车，谁都别想快。我一怒之下，决定自己搭个临时的服务器，就在我家里。
第一次失败：传统方法的碰壁
我把一台旧电脑翻出来，装了个轻量级的HTTP服务，端口定在了8080。我想着大家都是内网用户，直接走内网IP应该能飞快？
大楼网络安全简直是一团糟。
我把我的内网IP和端口发给朋友，让他们直接下载。结果？
- 住得近的朋友，能连上，但经常连着连着就断了，需要重试。
- 住得远的，跨了子网，连我的内网IP根本看不到，得通过我们大楼的公共路由器绕一圈，速度还不如云盘。
- 更狗屁的是，有些人被分配了更严格的防火墙规则，非标端口直接被封死了。
我折腾了两个晚上，光是教他们怎么设置代理、怎么避开防火墙，就耗费了我全部精力。我意识到，让用户为了下载一个游戏去改网络设置，是根本行不通的。我需要一个“傻瓜式”的解决方案，一个自带导航的“安装包”。
打造自适应“安装包”的策略
这个实践的核心，就是这个安装包。它不再仅仅是游戏的压缩文件，它成了一个智能的下载代理。
我开始研究自解压程序和脚本。我用了一个很小的脚本语言，把它编译进安装包的启动程序里。这个脚本只干两件事：
第一步：环境探测。
用户双击我的“安装包”时，它不会立刻开始解压，而是先执行一段代码，快速扫描用户的本地IP地址。我们这个公寓大楼的内网IP段是固定的（比如192.168.10.x）。如果用户的IP在这个范围内，那就说明他在我们的小区内网里。
第二步：源头切换。
如果检测到用户在内网，脚本就会把下载源地址（一个非常大的，被切割成小块的资源列表）从外部的公共CDN地址（慢且贵）自动切换成我家里那台旧电脑的内网IP地址（快且免费）。如果用户不在小区内，或者检测失败了，那就老老实实地走CDN，保证下载至少能完成。
最终的实现与效果
我把整个游戏资源拆成了十几个小块，让安装包里的下载器支持断点续传。我把我的旧电脑命名为“公寓大楼专属加速节点”。
我把这个新的“安装包”分发了出去。这回我什么都没跟朋友们解释，就让他们直接点。
那天晚上，我盯着服务器的流量统计，简直不敢相信自己的眼睛。
- 一个住在我楼下的朋友，平时下载我的旧版本需要四十分钟，这回只用了不到五分钟，文件完整，一次通过。
- 内网连接走的是我们内部的万兆网络（虽然实际达不到），但带宽完全拉满，下载速度直接从几百KB/s飙升到十几MB/s。
这回的实践让我明白了一个道理：很多时候，技术问题不在于你用多么先进的工具，而在于你是否真正理解了你所处的物理环境和限制。我愣是用一个笨办法，绕过了我们公寓大楼那堆奇葩的网络限制，让我的朋友们享受到了秒速下载的感觉。虽然这套方案不能推广到全世界，但在我们这个小小的“公寓大楼”生态里，它就是最好的“游戏下载”解决方案。用最土的办法，解决了最实际的问题，值了！