Leask

Sixia "Leask" Huang

break the wall or bring the war

测试为 Flora_Pac 提供 HTTP host

测试为 Flora_Pac 提供 HTTP host

有 Flora_Pac 用户（yyxst***@gmail.com 等）提出能不能提供官方 HTTP host 方式，通过 request 参数来返回适用的 PAC 文件（类似于 autoproxy2pac）。这个需求我早前就有考虑，起初主要担心集中提供 PAC host 会导致服务器被墙而徒劳无功。但最近又想了想，很多朋友的机器上其实是没有开发环境的，他们也不见得全都熟悉 Python 等工具，本着让翻墙能尽可能简单便利，尽可能降低门槛的期望，我简单实现了一下这个功能。目前的实现相当简陋，但凑合能用。 使用相当简单，我就不写什么教程了，直接上几个 demo 大家一看就懂了： 创建代理地址为 SOCKS 127.0.0.1:8964 的 PAC 文件: $ curl http://flora.leaskh.com/pac?proxy=SOCKS%20127.0.0.1%3A8964 创建代理地址为 SOCKS5 127.0.0.1:8964 的 PAC 文件: $ curl http://flora.leaskh.com/pac?proxy=SOCKS5%20127.0.0.1%3A8964 创建代理地址为 HTTP 127.0.0.1:6489 的 PAC 文件: $ curl http://flora.leaskh.com/pac?proxy=PROXY%20127.0.0.1%3A6489 当第一代理 ( SOCKS5 127.0.0.1:8964 ) 失败时尝试第二代理 ( SOCKS 127.0.0.1:8964 ): $ curl http://flora.leaskh.com/pac?proxy=SOCKS5%20127.0.0.1%3A8964%3B%20SOCKS%20127.0.0.1%3A8964 基本上就这样，如 demo 所示，直接把代理服务器地址转义后填入 proxy 参数中，请求 Flora_Pac 服务器（http://flora.leaskh.com/pac）就行。其中 URL 参数的转义规则 Google 一下很容易查到。下面列出可能会被用到的几个符号： 空格 ‘ ‘ ===> %20 或者 + 冒号 : ===> %3A 分号 ; ===> %3B 先写到这里，有疑问欢迎联系我。最后，再一次期望有一天我们不再需要翻墙。

每一行代码都在改变世界

每一行代码都在改变世界

最近有几天比较闲，更新了一下几个用于翻墙的小项目。其中变化比较大的是 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，以及开发翻墙工具的工程师们，你们都是英雄，是这个时代的游侠。 每一行代码都在改变世界，你希望你的代码把世界改造成什么样？