百元改造家庭网络拓扑，享受极致网络体验

自从我去年购买了软路由和 NAS 后就开始折腾家庭网络，到目前为止已经 1 年多了。如果说去年还只是装装 openwrt，搞搞智能家居中枢家庭服务器这种小打小闹的玩意，今年则是彻底给家庭网络拓扑来了个大换血。同时我今年兼顾了成本，在去年软路由的基础上仅用了一个额外的网管交换机（成本约 100 元）解决了日常网络使用过程中的诸多痛点，包括单线复用、千兆 LAN 汇聚、IPTV 单播等等。虽然过程一直磕磕绊绊，有碰到 Mac 下奇怪的网络栈问题的，有碰到 IPTV 离奇卡死的，甚至动用反编译分析一个 CLI 工具参数的，但到今天总算有一个比较满意的结果了。

我个人同样在这次网络配置过程中受益匪浅，参考了很多国内外论坛的内容，其中也有一些是我自己研究出来的。因此我打算将整个网络方案分多篇博文一一介绍。一方面是希望能和更多人共同交流，另一方面则是为了避免对整个网络的配置过程产生遗忘，以免今后发生任何故障时难以下手。

另外，由于个人的拖延症，在写这篇博客的时候已经离完成整个家庭网络的建设过去了大约一个月的时间，部分内容可能有所遗忘或修改，但我也会尽量覆盖到。

快速编写一个装饰类的装饰器类 (a decorator class to decorate a class)，调用方便、扩展性强、内附代码实现

在我们会编写函数装饰器用于装饰函数、类装饰器用于装饰函数后，我们很自然会想到一个问题，能否编写类装饰器装饰一个类？我们能否通过仅仅对类装饰，却能 Hook 掉这个类的所有成员函数以达到方便扩展的目的？本文将快速回顾前几种装饰器，并最终得到一个装饰类的全能装饰器类。

使用先序遍历的节点访问顺序重新给左右儿子编号，大大节省了空间

自古以来，实现线段树所需要的数组空间大小有着比较激烈的争论。一种基于递归的线段树实现认为至少需要$\mathcal{O}(4n)$的空间，而另一种基于直接循环的方法认为其实只需要$2n-1$的空间。关于为什么基于递归的方法需要$\mathcal{O}(4n)$的严格证明可以去网上搜索，或者这里提供了一个简易的证明方法。总的来说，基于递归的线段树实现起来更加直观，但由于dummy node的存在造成了空间的浪费。而基于直接循环的方法对实现的要求更高。本文介绍了一个基于递归的线段树实现，通过改变每个节点的左右儿子的编号高效的利用了空间，使得基于递归的线段树也只需要$2n-1$的空间。另外，关于基于循环的线段树实现方法，可以参考这篇博客。

探索折腾博客的终极意义

折腾博客的意义是什么？这两天看到群里有个人说的很对：虽然明知没人来看自己博客，但是折腾起来就是很爽。就像虽然看起来我像是博客3个多月没更新了，但实际上实际上我网站已经折腾了好几个月了，只是没有新写文章而已。总的来说，我把我原来对NexT主题的修改重新集成为一个npm插件，方便其他人使用。另外我添加了更多自动化的操作，不但以后只需要push新的文章，CI就能自动更新网站。并且，Travis的定时运行任务功能可以方便地自动拉取主题的最新代码，自动更新主题版本，从此再也没有主题过时的烦恼，简直爽歪歪。

使用对象存储部署静态网站，并通过亚马逊CDN(CloudFront)大大加快网站的访问速度

我原来的Hexo博客部署在GitHub Pages上，因为GitHub Pages在国外，所以为了加快访问速度，我做了很多优化的工作。然而，连接的响应延迟实在是不能忍，初次打开网站的时间有时候可能要半分钟之久，另外GitHub Pages无法被百度访问到，因此百度也不会收录GitHub Pages部署的网站，所以我最近在不断寻找其他的代替方案。

用尽各种手段，进一步将网站的传输开销缩短70%以上！

去年的一篇文章提到，把图片以及绝大部分的第三方JS和CSS文件转移到CDN加速服务上，源站的总传输大小从500多KB缩短到了110KB，大约节省了80%的传输开销。今天，我又进一步优化了整个网站，最终测试下，首页仅有33.3KB的数据来自于源站，相比之前的约110KB又进一步节省了70%的大小。

使用CDN和对象存储OSS来优化博客的访问速度

由于我的整个博客部署在GitHub Pages上，从国内直接打开的访问速度是很慢的。过慢的访问速度会使得用户在访问网站的时候失去耐心，导致有些用户可能会直接关闭你的网站，这就会使得网站的用户留存率降低。说句题外话，这就是为什么很多网站在设计进度条的时候并没有反映网站的真实访问速度，而是先给你一个很快的加载动画，让会让你产生好像网站就要加载好的错觉，在一定程度上能增加用户的耐心。这种手段除了应用在微信的网页进度条上，还包括比如一些清理软件设计的清理系统进度条上，还有之前Windows 7在文件浏览器中的文件扫描进度条上等等——好像说的有点远了。总之在这篇文章中，我会以我的Hexo博客为例，介绍一些优化网站访问速度的方法，这也是我在优化这个博客时使用的方法。

一个开源的评论系统，可惜已经不太维护了，于是我进行了一些简单的修改，并做好了Docker镜像。

我这两天还在寻找合适的评论系统，主要是因为当前可用的评论系统都不能满足基本的要求。我的基本要求其实也就两点，第一，可以通过邮箱直接评论，不需要注册。第二，在有人回复的时候可以发送邮件进行通知。同时，评论者被回复时也可以收到相应的通知。上一篇中提到的Valine勉强支持，可惜Valine在安全性上存在很大的问题。Livere总的来说还不错，但缺乏邮件提醒功能。最终，我还是使用了一个开源评论系统isso，并进行了一部分的调整，部署在了我自己的服务器上。我进行了一些修改，并已经做好了Docker镜像，可供直接拉取使用。

前几天还在说，使用Hexo搭建博客比较顺利，没什么大坑，后来就接二连三的遇到各种问题。

其实这些问题也不全是Hexo的原因，这些问题在搭建一个静态博客的时候都有可能遇到，不过还是能拿来讲讲，以供参考。Hexo的配置确实非常容易，这一点不可否认。只需要安装好Node.js以及其他必要的依赖，按照官网提供的文档一步一步做就行了。我把博客部署在GitHub Pages上，这样就省去了自己搭建服务器的成本，为了加快访问GitHub的速度，我配置了CDN和对象存储的优化，这在后续的博客中也会慢慢介绍。