GoAgent 证书问题一例

昨天准备在太太的电脑上用一下 GoAgent，结果发现很多网站都不能用。很奇怪的是，Twitter 页面能打开，但 CSS / JS 看起来基本上都不对。而在我自己的电脑（LAN 内部）上却是好的。所以很明显是 Local 而不是 Network 的问题。

看 GoAgent 控制台上的日志，问题似乎跟 SSL 的连接建立有关系。再把 Chrome 的「审查元素」功能打开，Console 里面一堆错误。随便挑了个页面试图打开，好了，这下清楚了，证书有问题。

看了看 GoAgent 的官方 Q & A，基本上只提到说证书需要导入。很多在网上问这类问题的人，得到的也是类似回答。但问题在于，证书的导入是没有问题的，重新导入也没有效果。而且并不是所有网站都不能通过 GoAgent 代理。

其实问题很简单：GoAgent 仿冒的证书被占用啦。
官方其实也提到过这个事情：

因为 GAE 平台限制，没法支持真正的 ssl 加密，goagent 只能通过伪造证书的方式做到代理 ssl 加密的网站，这个证书就是用来欺骗浏览器的。

GoAgent 实际上相当于一个「中间人」。当访问 HTTPS 站点时，就得采用 SSL 中间人攻击的类似方式，才能完成代理的工作。SSL 中间人攻击怎么弄？导入受信任的根证书，然后利用这个根证书签发的证书把内容拆开后重新组装、加密、封包，骗完甲方骗乙方，欺骗通讯双方。否则两端任何一方觉得这内容不对劲，SSL 传输就会失败。这其实也就是为什么必须要干掉 CNNIC 相关的根证书的原因。

所以，对于每一个 HTTPS 站点，GoAgent 都会生成一份用自己根证书签发的数字证书。看看 GoAgent 的 local 目录下，如果访问过 HTTPS 站点，则一定会有一个 certs 目录。这生成的证书，就放在这个 certs 目录下。其实一看这个目录里面都有些什么文件，就很明白了：

这次的问题在于，GoAgent 有不同的版本，其携带的根证书也是变化过的。至少我机器上随便打开 CertMgr 就见到了五个不同的版本：

如果升级的时候不把 certs 目录清空，就有可能会有部分站点对应的证书还是以前的老的、用旧的根证书签发出来的。GoAgent 客户端一看，噢，证书已经有了，就不再重新生成了。但 Chrome 觉得证书不对，于是 SSL 握手就被挡了。

解决办法很简单，每次升级 GoAgent 的时候，把 local/certs 目录删掉。或者干脆每次用新目录来升级好了。

自己给 iOS7 升级下载加速

通知出来了好几天了，今天准备给太太的手机升 iOS7。于是先把 iTunes 升到 11.1（下载速度还不错），然后连上手机。一检查，嗬，1.19G，告诉我下载要 18 个小时。
按照惯例，打开 IE 设上代理，准备用 GoAgent 加速。现在估计用时只要不到一个小时，完全可以接受。
但是担心的事情来了，免费 GAE 的每个 AppID 有 1GB / 天的流量限制，而我的 GoAgent 没能及时切换到下一个可用的 AppID，结果 iTunes 这边报了个错，然后下载又重新开始了。没想到这 iOS 升级包的下载居然不支持断点续传。我又试了下，哪怕是手动点「暂停」，也没法进行续传，每次下载都会重头开始。看来这乔布斯死了之后，苹果真是要没落了。

接下来的时间，我考虑了以下解决方案：
1. 开 VPN：可手头上的 VPN 速度都跟直接下载差不多。何况有些 VPN 还有流量限制。不肯花钱的后果就出来了。
2. 找代理：手头上没现成的。不管是去搜 Google 还是开 ProxyHunter 都得花时间。懒得去找了。
3. SSH Tunnel：目前手头上访问起来快一点的只有台 H3C 的交换机，大概是深圳的地址。不过 SSH 没开，要想架隧道还得要我去帮它开。由于担心被抓去集中营活摘器官，并且从这台交换机到 appldnld.apple.com 的 ping 值并不好，所以最后还是放弃了。

最终，还是自己找了组 appldnld.apple.com 比较快的地址，解决了这个问题。100ms 左右的 ping 值，偶尔丢包。放在 hosts 里用上去之后，显示的估计用时也是不到一小时，跟开 GoAgent 加速的效果相当。那就先这样用吧。话说这苹果的 DNS 设置咋自己就解析不到这组地址上去呢？是我 RP 问题？

GAE 升级 Python27 折腾手记

Google 把 GAE 的 Python 运行环境从 2.5 升级到 2.7，已经有好一些日子了。因为只扔了自己的两个小小的应用在上面，所以一直没去处理。最近总算有些时间，于是把这个折腾完了，还很花了一些工夫，特记录一下。

去看了 GAE 的在线文档。中文的文档是只有 2.5 的部分，繁体中文也只是对 2.7 给出了一个链接而已。技术方面的东西还是直接参考 英文资料 来得好。

具体的做法，官方文档上写得很清楚，就不在这里说了。但是我的升级过程并不是很顺利。最后总结一下有这么几个问题，供大家参考：

• 按照文档，app.yaml 里面的 handle script 要从 .py 改成 .app，但千万别手贱去把 .py 文件真的改名成 .app。其实只是 app.yaml 里面要改而已，文件还得是 .py 为后缀名。
• app.yaml 中还要引入 webapp2 这个 library，这个在官方文档中没有明确地指出。具体写法是：

libraries:
- name: webapp2
  version: "2.5.1"

其实 version 可以写 latest，但要承担最新库无法向下兼容的风险。

• 要更新就索性别留旧版（Python 2.5）的程序在 GAE 上，否则页面顶部的警告一直会有。

其余过程还算顺利，至少升级到 2.7 算是成功了。

修改 GoAgent 客户端以支持 Mega

为了能用来访问 Mega，对 GoAgent 客户端代码做了略微的修改。不过首先要说明一下为什么会有这个修改。

Mega 是个总部位于 New Zealand 的网盘服务。服务器当然全世界都有，但至少在我这边 ping 值不好。严重的时候 600ms 以上，并且丢包。这样的话，不管本地有多少带宽，实际上也是不可用的。总不可能花上一整天的工夫来传一个 ISO 吧。
开着 VPN 会快，但流量和费用都是问题。于是很自然地想到了是否可以通过 GoAgent 之类的 GAE 代理来访问。Google 服务器与 Mega 之间的带宽应该是不成问题的，而 Google 服务器与我之间的速度也是我可以在一定程度上控制的。不过测试下来发现 GoAgent 不支持 OPTIONS 这种 HTTP Method，而且这个局限性是 GAE 导致的。GAE 只支持GET / POST / HEAD / POST / DELETE 这五种 HTTP Method。偏偏 Mega 在登录和上传下载的时候都会发 OPTIONS 请求，于是这个方案一度被搁置了。
后来 Mega 的速度进一步下降，有时候一整天都传不完一个 100M 的文件。于是这个方案又被我拿出来考虑。这次我准备绕开服务端的限制，直接从客户端下手。OPTIONS 请求涉及的数据量是很小的，文件传输用到的 CONNECT 之类才是主要的带宽压力。因此可以让客户端在遇到 GAE 服务器无法处理的 HTTP 请求时，直接将其发到目标服务器。由于 Mega 目前还没有被 GFW 给 IP 黑洞，因此应该可以在一种「混合模式」下被通过 GoAgent 访问到。

下面介绍一下修改方法，以 GoAgent 2.1.15 版（2.1.17 还需要服务端改动才行）为例：

首先在 local/proxy.py 中找到这两行：
"""rules match algorithm, need_forward= True or False"""
need_forward = False
第一行是注释。而下面这个 need_forward，就是用来控制是否把一个请求直接送出（FWD），而不是送去 GAE 服务器进行中转。

在后面的 if 语句前，加入这样的内容：
if self.method != 'GET' and self.method != 'POST' and self.method != 'HEAD' and self.method != 'PUT' and self.method != 'DELETE':
    if host not in http.dns:
        http.dns[host] = list(set(http.dns_resolve(host)))
    need_forward = True
非 Python 程序员也应该很容易读懂这段代码，不过要提醒一下：Python 中缩进是很关键的，改代码时一定要用空格正确地缩进。
最后，别忘了把下面那个原来的 if 改成 elif。

这样改过之后的 GoAgent 客户端，在遇到 GAE 服务端不能处理的那些 HTTP 请求类型时，就会把它们直接发到目标服务器上。
从理论上讲，这个小修改不会对 GoAgent 的翻墙能力有任何的增加，但可以让它具有更大的适用范围。一些原来不能用 GoAgent 访问的站点（比如上面提到的 Mega），现在可以用它来访问了。GAE 的流量按天计算（VPN 一般按月，VPS 也是）。并且因为可以使用多个 GAE 账号，因此流量基本上是免费且无限的。Mega 那 50GB 的大空间，终于具有一定的可用性了。

GAE 的 Frontend Instance Hours 高居不下咋办？

架设 GAE 用了 GoAgent 之后，对于 Dashborad 中的 Frontend Instance Hours 一项数字如此之高有些不解。查了 Google，发现有同样疑问的还有很多人。于是翻了翻 Google 的文档，做了做实验，基本上弄明白了。

其实这个数字高也不代表什么。不信你可以架一个 Hello world 上去，先不要急着访问，只是打开 Dashboard 看看。Number of Instances 应该是 0，Frontend Instance Hours 也是 0。然后再打开 WebBrowser 访问一下你的 Hello world，再看 Dashboard。现在 Number of Instances 是 1 了，而 Frontend Instance Hours 就开始了渐渐的增长，哪怕你把 WebBrowser 马上关掉也是如此。
说白了，Frontend Instance Hours 就是 GAE 记录的服务实例运行所用掉的时间配额。没访问过的话，实例数是 0。而一旦有 HTTP 请求，GAE 就得启动一个实例来响应这个请求。运行这个实例需要耗费相应的 CPU 和内存资源，于是 GAE 就开始计费了。实例不停，Frontend Instance Hours 就会一直长。而 GAE 为了能在短时间内响应下一个请求，通常是不会很快把实例给停掉的。（至于到底会等多久才停实例，据说是 15 分钟无新请求就不再增长 Frontend Instance Hours，但实例数还在，估计挂起了。不过你可以手动停掉它。）
既然叫做「Hours」，增长的速度当然就是指的实例实际运行的时间。实例跑了一个小时，那么 Frontend Instance Hours 就会增加 1.00。我没测过 Google 会不会在计费上面耍点小手段，大抵是不会的，个人感觉也基本上差不多。
所以看着 Frontend Instance Hours 一点一点地增长，也完全不必心慌。一天 24 小时，GAE 给了 28 的免费配额，如果你只跑一个实例，是不可能用完的。用到 23.99，下一分钟就第二天，重新计算，清零了。对于只跑 GoAgent 的用户，实在不放心的话，我觉得用两个 AppID 来跑也完全足够了。当然，流量超了的情况另算。

那么什么时候 Frontend Instance Hours 会超过 24 呢？据说一个请求如果在等待了超过 Min Pending Latency 的时间之后，仍然没有实例能来处理它，那么 GAE 就会开一个新实例来做这个事情。所以 GAE 给了免费用户 28 个 Frontend Instance Hours。Google 的解释是为了让用户能够应对一些紧急状况。
另外，这个「紧急情况」，除了指访问量大导致的多实例运行，也包括了一个功能，就是 GAE 允许用户调高 Frontend Instance Class。F2 级就比 F1 级多用一倍的计算资源，而 Frontend Instance Hours 也就增长得快一倍。这种情况下，多出来的 4 个小时就可以视为 GAE 给的「加力」之类的东西了。如果你只想在短期内进行一个高强度的计算，那么可以考虑用 F4 来跑一个 APP 看看。