最近有几天比较闲，更新了一下几个用于翻墙的小项目。其中变化比较大的是 Flora_Pac，我一直很关注 PAC 在实际应用场景的效率问题，因为这直接和翻墙体验密切相关。能省一次 DNS 请求、一次正则匹配，就意味着用户可以把更多的延迟容忍度分配到代理通道上来。有天 @googollee 提出了使用二分搜索加速路由匹配的想法很不错，于是我们对其可行性做了比较多的分析和研究，最终于今天完成了代码。
然后前几天我在 Github 上看到了一个很不错的项目，叫做 bestroutetb ( Best Route Table )，能把 VPN 路由表条目压缩到原来的 2% 大小，且基本不影响使用。我立刻研究了优化思想 ，发现作者 @ashi009 的思路相当有趣，并且行之有效。我开始思考把这种算法移植到 Flora_Pac 的可能性，但是在详细研究之后，我觉得并不适合。首先，bestroutetb 项目要达到最佳压缩比其实是对路由表进行有损压缩的，虽然能满足大部分使用场景，但我直觉上认为这不是完美的方法，仅让有限几个国家走 VPN，哪么其他被墙的小国网站还是无法访问；其次，通过合并子网后，Flora_Pac 实际的条目数是 1700 条的量级，距离 bestroutetb 仅包括 US / UK / HK 的情况下实现 1200 条的成绩差距并不大，反而前者路由规则更完善；再次，路由表和 PAC 很不一样，路由表简单地匹配规则，无法（由于原理不同路由表也没有必要）使用更好的算法加速匹配，而 PAC 却能够（且必要）实现算法来进行更复杂的匹配，问题在于如选用 bestroutetb 的思路，必然会破坏列表顺序的连续性，使二分搜索失效，反而让匹配时间变长。综上考虑，我还是放弃了使用 bestroutetb 优化 Flora_Pac 的念头。PS：以上讨论只表明 bestroutetb 的优化思路不适合 port 到 PAC 上，而`不能`否定 bestroutetb 是一个很好的项目。
Mac 翻墙用户应该都碰到了一个问题，OS X 10.7 之后，由于系统贯彻 sandbox 策略，网络配置中不能再通过文件系统直接指定 PAC 脚本，而必须把 PAC 文件 host 到 HTTP 服务器上。针对此情况，我在新版本的 Flora_Pac 中内建了 HTTP PAC 服务器。PAC 服务器使用相当简单，只需要在使用 Flora_Pac 的时候指定一个本地监听端口即可，见下图。
目前 Shadowsocks + Flora_Pac 是我所有设备的翻墙方式，包括 Mac、Linux、iOS、Windows 使用都很平滑，对比 VPN 方式更轻松灵活，基本上不用再关心网站被墙的问题。Shadowsocks-iOS 我有一个 Fork，目前推上去的改动比较少，这个 Fork 主要是想让开发者更容易在 iOS 上 build 一个能跑在后台的翻墙代理。但由于系统限制，目前障碍较多，等有进一步的成果我再写写吧。
近期我在 Twitter 上关于 #开房记录 数据库的事情惹来一些争议 ，我原想写篇文章总结一下想法，后来想想也就算了，有时间还是多写写代码吧。我不善雄辩，且由始至终我都`没`觉得我做错了，我认为无须费唇舌解释什么。总有一天，当体制的黑幕完全吞噬蓝天的时候，大家才会发现原本死守那一点点私隐，有多么可笑。
为什么我会在这里谈 #开房记录 数据库的事情？和翻墙有关系吗？其实私隐数据泄露的本质是公共服务实名制，这和 GFW 其实同样来源于“体制的高墙”，他们背后代表着同样一个邪恶的目的。翻墙的本质，无论你是否认同，你就是在对抗村上春树老先生所唾弃的“体制的高墙”。Flora_Pac 的目的其实和网上其他开源翻墙辅助工具一样，在“努力通过技术手段让翻墙变得更轻松”。我坚信，面对“体制的高墙”，技术永远是一把利剑，所以在我眼中 WikiLeaks、Snowden，以及开发翻墙工具的工程师们，你们都是英雄，是这个时代的游侠。
每一行代码都在改变世界，你希望你的代码把世界改造成什么样？