手里有一个中型的网站项目，项目上的图片等静态文件使用自己搭建的多台Nginx服务器做缓存加速，不要问我为什么不用OSS等云存储，当有持续的大量的请求量的时候你就知道按流量计费到底有多坑。

由于考虑到部分图片及js等静态文件可能会有更新的情况，所以缓存的有效期设为了1个小时。也就是每过一个小时Nginx缓存服务器都会去重新请求一次源服务器，以获取最新版本的静态文件。

整套系统稳定运行了几个月以后，通过流量监控系统分析了历史数据发现源服务器的带宽使用一直保持在1-3M之间，偶尔突发流量也会不超过5M，本着够用就好的原则，就把源服务器的带宽调整成了5M（这就是给自己挖了个大坑，真是自作孽不可活啊）。

带宽调整完的几个月里，系统运行也还算稳定，带宽使用也都在正常范围内。就在上个月的一天凌晨，产品经理一个电话把睡梦中我的给召唤起来，说是网站图片加载缓慢。第一反应是Nginx缓存服务器的带宽不够用了，马上查了一下各个节点的带宽使用情况，都不高，或者说低的有些不正常，而且伴随有持续的下行流量，这就不对劲了。

大约在17年底的时候，入手了一部Macbook Air笔记本电脑，主要用来做WEB开发及服务器调试等日常工作，性能足够续航超长，带着出差真的是爽到爆，在机场等个飞机都可以抽空撸几行代码，这才是移动办公应该有的feel吧。

然后到了18年的夏天，换了另外一家公司，主要负责带团队开发，出差的机会就少了，由于家里跟公司办公室都有闲置的外接显示器，又懒得来回往台式机上同步开发代码，很长一段时间Air就一直被当成主力开发电脑在用。

前一阵子苹果发布了一个叫HomePod智能音箱，网上看了一下测评发现还是有点意思的，但2799的售价对于我等穷屌丝也只能远远的流流口水了。不过对无线音乐播放倒提起了兴趣，我平时没事的时候喜欢听听音乐，书房里有电脑还好说，直接外接了一个漫步者的2.1，听个音乐看个视频什么的完全够用。但客厅就比较麻烦了，我的音乐都是存在电脑跟手机以及iPad里，每次想在客厅里听会音乐还得单独接根线，好麻烦。

HomePod要不起，那只能想办法曲线救国了。

首先想到的方案是蓝牙传输，家里有个小米的蓝牙音箱放在卧室里，但个头实在是太小了点，音质也很一般，某东上看了看其他靠谱点的蓝牙音箱也都不便宜，而且设备一多，连接起来也挺闹心。另外蓝牙的传输距离有限，有时候拿着手机在屋里走几步小米的蓝牙音箱就莫名其妙的断开了，所以这个方案只能PASS掉了。

时间过的还真是快啊，还没来得及回味呢，2018已经成了过去了，离最后一次更新文章已然过去了一年半了，这一年半的时间里发生了太多的事情，有好事也有坏事，既然已经过去了，就不再去追忆了，2019新的开始，努力，努力，努力！！

前些日子在公司的仿真系统的内网搭了一台FreeBSD的服务器，用来做业务系统的状态监测，由于需要使用到nat服务，所以把IPFW也配置上了，为了调试方便，日志最大记录数习惯性的设置了不做限制。

服务器正式上线以后，一直运行稳定，昨天突然就远程连接不上服务器了，于是进机房接上显示器一看，乖乖，1T的硬盘硬生生就撑爆了，可用空间为0了。要知道这台服务器上几乎没有任何会使用大量磁盘空间的应用，只跑了个状态监测系统，看应用目录使用了还不到100M的空间。完全有点匪夷所思啊，排查了一下各个目录，发现问题出在log文件夹下的ipfw的日志文件，一个文件就上百G啊。。。这才意识到自己挖了多大的一个坑啊。

赶紧把日志最大记录数设置上，然后删日志，重启IPFW。然后查看了一下新生成的日志文件，终于找到原因了。

出于安全考虑，我的IPFW设置的是最大安全策略，也就是只开放了几个需要使用的端口跟协议，其他的一率deny掉，为了知道都deny掉了哪些数据，自然就要把deny规则上加上日志记录。这样的设置在互联网的环境上是完全没有问题的，我以前为很多客户的web服务器都是这样做的策略。记录到的都是一些非法扫描之类的异常信息，每天的日志一般也不会超过10M。

可偏偏我们业务系统内部通讯大量使用了组播通讯，这就导致了所有的组播包都被IPFW认真的在log里给记录了下来。目测了一下，每秒能收到几千个组播包，这硬盘不爆才见鬼了呢。