Android Support Library v22.1 轻度使用感受

前两天Google出了新的Support Library v22.1,这两天轻度使用了一下,贴点使用感受,慢慢更新

  1. Google又改Activity的基类了,原来是ActionbarActivity,现在是AppCompatActivity。很多逻辑也发生变化,之前是用Toolbar作为Actionbar的,现在也不需要了,直接自带Actionbar了,也是Material Design的设计,这个改动如果是从新写App的话挺好,如果是之前的老项目。。估计要改的吐血吧
  2. 各种Material Design的组件更新极其缓慢,这次确实又加了几个,但是设置不了深度,从用户的角度根本看不出来有多大变化。Annimation什么的通通没有,Google看这样子是不打算支持4.x用户了么?
  3. AlertDialog出了新的了,改下import就行了,好评。

发现一个有趣的东西:Docker

最近在写一个新的应用,后端用的是Nginx +  Python + Django + Gunicorn + Celery + libav,Celery又依赖RabbitMQ,为了让Celery和Gunicorn跑起来又用了Supervisor,东西太多配置又太繁琐,写代码调试和部署都是一个挑战,时间长了怕是配置文件和日志的location都要忘光光。我的工作环境是Mac和Windows,服务器则是Ubuntu或者Centos,像libav这种东西基本上算是Linux独有的,Mac虽然是*nix like但是毕竟不是Linux,想了半天最后决定放弃在Mac做Celery worker的调试,改在Ubuntu的服务器上用最原始的Log来分析调试,简直蛋疼到不行。

这两天在网上看到了Docker这个玩意,看起来确实不错:在Linux上有近乎Native的性能,在其它平台上则通过类似虚拟机的机制来构建运行环境,通过remote debug机制和IDE沟通,而部署则有点像拷贝虚拟机镜像:Docker的每一个优势都直击开发部署的痛点,下次部署的时候一定要用一下。

愿让我满怀期望的Docker,不要像Cygwin一样让我失望。

Overload vs Override, Java vs Groovy

Groovy is one of my favorite languages. It is simple yet powerful. More importantly, it can be integrated into Java stack easily, bringing us thousands of libraries that are ready to use.

One interesting thing about Java and Groovy is the difference in treating overload. A lot of scripting languages do not have function overloading. For example, in Python you need to use named parameters if you want to have some kinds of workaround for that. In JavaScript you need to check if a parameter is defined manually in the function, which brings complexity and lacks intuition. Same things happen to Matlab, where you have to check the number of arguments like the old C code:

Java has overloading, and it is reasonable that Groovy also has overloading. However, they treat overloading differently.

Java dispatch overloading during compile time. In other words, it is fixed and cannot be changed during run-time. However, as a dynamic language, Groovy dispatch overloading at run-time, which causes a different result in the following program.

These two pieces of code are identical to each other, except for the class name. However, the results are quite different. In Java, the output is String and Object, while in Groovy, the output is String and String.

What if we call the Java code in Groovy, and call the Groovy code in Java?

For the Java code, the output is String and Object, and for Groovy, String and String.

This experiment tells us the only deciding factor of which kind of dispatch method is being used is your code type that you are actually writing. If you are writing Java, not matter you are referring a code from Java or Groovy,  overloading functions are dispatched at compile time. If you are writing Groovy, overloading functions are dispatched at run time. This brings us a very essential problem: we need to be really careful with overloaded functions that come from Java library when we are writing Groovy code: it is the devil in the detail.

The good news is that, for function override, both Java and Groovy treat it in run-time and share the same behaviour.

改用CloudFlare的CDN并且启用了SSL

前段时间申请了StartSSL的免费SSL证书,但是由于Incapsula的免费版不支持SSL,也就一直没有部署。这两天看到Github的DDOS攻击事件,看到即使是一个毫不相关的网站,也有可能被别有用心的用来进行一些网络攻击,遂决定部署起来。

现在已经将CDN切换到了CloudFlare上,并且启用了Strict SSL,服务器端也设置了HTTPS的重定向,不过由于WordPress一直使用的是绝对地址来链接网站内容,所以还会有一些图片和视频的资源文件走HTTP,这个问题可能需要再过段时间想想怎么解决。

The DDOS attack against Github & HTTP Hijacking in China

It is well known that recently a large scale DDOS attack was carried out against Github. The obvious attacker: Great Fire Wall in China, did this by HTTP Hijacking.

A lot of Chinese websites use Baidu’s Analytic service to collect visiting information as an alternative to Google Analytics, which is not available in mainland China. The GFW hijacked the Baidu’s Analytic Javascript file of all in bounding requests, i.e. from outside China to inside China, and changed the content of it so that this piece of Javascript code will visit several certain Github pages every 2 seconds. This caused a heavy burden on Github’s servers and eventually became a DDOS attack in which GFW made use of millions of Chinese people who are outside China but visiting Chinese websites to achieve its goal.

HTTP hijacking is so common in China that it is not a surprise for me to hear that GFW eventually made use of this to attack Github. In China, every ISP is using HTTP hijacking to push ads to end users. In fact, some of the hijacking code is so ugly written that it will even hijack some API HTTP requests like Json response. It has been confirmed by some of the users of an open source android app which I contributed to. They reported this issue several days ago and such circumstances will only happen when using certain ISP service.

The reason why there are so many HTTP hijacking in China may lie in two reasons. First, the ISP market is not a free market and only some of nationally owned companies are allowed to provide Internet service. Second, few websites use HTTPS to deliver their contents, which made them vulnerable to MITM attacks.

 

搬瓦工已经没救了

一直以为搬瓦工最近速度越来越慢是因为港大的出口带宽吃不消了,今天有空在Digital Ocean上开了一个Singapore的VPS测试了一下,发现是搬瓦工的问题。

这个是新加坡到HostUs的:

Capture

这个是新加坡到搬瓦工的:

Capture2

这个是SFO到搬瓦工的:

Capture3

都是在西海岸,搬瓦工的跨洋线路慢成狗,西海岸内部连接倒是挺快但是对我没有半毛钱用处啊,再这样下去搬瓦工到期就可以扔掉了。

我的新玩具们

俗话说,”所有的男人都是孩子“。 即使已经不再是当初那个无忧无虑每天只知道玩耍的小男孩,我的玩心却依然还在。最近在网上买来了两个玩具,一个是Google Cardboard的华强北仿制版,另一个是PowerUp 2.0的仿制版。

  • Google Cardboard

Google Cardboard 是去年Google I/O大会时推出的一款廉价虚拟现实设备。之所以廉价,是因为它使用手机作为主要的显示和交互设备,而Cardboard本身就是几块硬纸板和两个凸透镜而已。

hero-home_2x

how-it-works_2x

至于我买的这个华强北山寨版,则是在Google Cardboard的原本设计上进行修改,使用塑料来构建机身,并且设计了三根松紧带来固定,镜片也可以调节焦距和瞳距,可谓是一个超级加强版。

IMG_20150223_171239

IMG_20150223_171504

构造和Google Cardboard基本一致,一边是有两个凸透镜,用于观测的孔,另一边则是用于防止手机的卡扣结构。把手机从这个位置放进去,就可以戴上这个玩意,在镜头这边进行观看了。那么看的时候呢,手机上显示的大致是这个玩意:

Screenshot_2015-03-09-13-01-30

左边是左眼看到的,右边是右眼看到的,两边的图像并不完全相同,就可以给人3D视觉。配合上手机里自带的陀螺仪,屏幕显示的内容可以根据头部的转动而变化,这就是沉浸式的虚拟现实体验了。不得不佩服Google的创意,把高大上的VR,用了一个这么小巧的廉价玩意就诠释的淋漓尽致。我的眼镜从淘宝上购入,不到100元。

实际体验上来说,效果还是相当不错的。我的手机分辨率只有720p,如果手机的分辨率能到1080p甚至2k,体验会更好。我觉得最有趣的应用还是Google Cardboard Demo里面的Youtube,那个视频墙出来的时候,只能用震撼两个字来形容。更重要的是,这个Youtube Demo是一个完全能拿来用的Demo,里面可以用语音进行搜索,搜索结果也会显示在视频墙上,视频本身虽然是2D的,但是营造出的氛围,让人仿佛独自置身于一间偌大的放映厅中静静欣赏。

  • PowerUp 2.0

PowerUp 2.0是一款电动纸飞机工具。纸飞机还能电动?当然,它是一款可以加装在纸飞机上电动发动机,让纸飞机可以飞的更高、更远、更久。准确的说来,这个玩意并不能算是山寨,因为它本身就是国内玩具厂商的杰作,只不过墙内开花墙外香,到了国外才被人发现、热捧。

71cuTHt8jxL._SL1500_

头部是一个电容,可以存储一些电量,尾部则是一个小的电动发动机,用于驱动飞机,中间的纸飞机则可以用A4纸自己叠。结构和原理都很简单,飞行的好坏则主要取决于折出来纸飞机结构的动力学优劣了。先放一个别人飞的视频,来自Youtube:

再放上两段我自己飞的视频:

 

 

虽然不及第一个视频里飞的那么高和远,但也是远超一般的纸飞机了!

Unblock Everything

平时经常使用网易云音乐听歌,但是经常遇到“版权受限”的提示也够烦人的。要解决这个问题,简单的做法可以直接去装一个Unblock Youku的插件,复杂一点的可以用GoAgent加上放在国内PaaS上的服务器端搭一个本地代理。这两种办法的本质差不多,都是绕经国内的代理服务器进行访问。虽然这些方法都能work,但是都有一个共同的缺点,那就是普适性不高。Unblock Youku和其它代理性质的扩展有冲突,虽然并不是完全不能解决,但是折腾起来也是够呛;而GoAgent的PaaS实现在移动端上几乎不可用,我在Android平台上找了好久都没有找到一个能用的办法,更不要提iOS了。如果要说最好的解决方法,就是能在大陆有一个能放代理的服务器。这样PC端可以用ProxySwitchy来切换,Android有ProxyDroid,iOS则可以直接在系统设置里设置全局代理。

以目前国内的网络环境来看,单独拥有一台常规VPS的成本并不低,每个月费用大约在几十到上百不能,如果只是用来做偶尔的Unblock的话,未免成本太高。我知道的一个低价的,接近VPS的解决方案,是使用百度的BAE 3。

BAE 3相当于一个没有root权限的VPS,前提是你能申请到Port权限。所谓Port就是一个能在百度的IP上给你做端口转发的服务,能够在一定程度上将原本只能使用HTTP访问到的虚拟机,暴露给外部的网络。如果能够申请到Port服务,就可以用SSH登录到虚拟机上,虽然没有root权限,但是跑一个Python写的HTTP/SOCKS/SS代理还是没什么问题的,如果偷懒直接跑SSH也不是不行。由于负载很低,我们选择最便宜的128M内存Python Worker配置,加上端口服务每天的费用是0.3元,这样一个月9块钱,基本上啥都能做了。

BAE 3的缺点在于目前Port服务还在测试中,如果要使用的话需要额外申请。我当初申请的时候,还不算很难,现在的话就不太清楚了。不管难度如何,需要额外申请毕竟是一道门槛,不算普适性的解决方案。

仔细思考了一下,对于像我这样在搬瓦工上有VPS的情况,一个廉价、方便的解决方案并非没有。其实我大概想到了两个解决办法:

  1. 在国内的PHP空间或者PaaS上部署GoAgent的服务器端,然后在搬瓦工的VPS上部署客户端,让客户端监听广域网上的请求,这样就相当于有了一台出口IP在国内的HTTP代理服务器。
  2. 在国内的PaaS上部署一个“反向代理”客户端。这里的“反向代理”,并不是指Nginx这一类的反向代理,而是指让服务器主动连接客户端的代理服务。由于大多数的PaaS服务大多只会暴露一个经过层层转发只能跑HTTP的80端口,根本监听不到任何客户端发来的Socket请求,所以没有办法做代理服务器。但是,通常情况下PaaS对于从代理服务器出来的Socket连接往往没有什么限制。因此我们只要在PaaS上部署一个反向代理,让PaaS主动连接搬瓦工的VPS并建立Socket连接,再在搬瓦工上建立一个转发服务,将某个端口上的流量转发到这个PaaS连过来的Socket连接上,我们就相当于有了一个端口在搬瓦工VPS出口却在国内的代理服务器。

两种方法各有优劣:

第一种方法:优点是实现起来比较简单,比如GoAgent就算一个Implementation,自己基本不需要写什么代码,只要搭一下就好了。此外对于两头的环境要求不高,国内端找个能跑PHP的空间就行,PHP基本上是个PaaS都会支持,就算去淘宝上买一个也很物美价廉;而VPS端只要能支持Python即可,Python又是几乎所有Linux发行版里都自带的组件。两头的环境都是非常常见,非常好弄的。缺点在于只支持HTTP,HTTPS的话就要导入根证书,有潜在的安全风险,Socks的话则根本不支持。

第二种方法:优点是支持什么协议都可以。由于是建立在Socket上的,不管是HTTP、HTTPS还是SOCKS甚至Shadowsocks,想支持都是可以的。缺点在于国内端不如第一种方法来的方便,PHP肯定是不行了,得是能跑Worker的Python或者是Java才行。此外这种方法网上并没有现成的实现,得自己写代码(目测大概得1000行左右)。

两相比较之下我选择了第一种方法,毕竟从现在的需求来看,对两头环境的宽容度比较重要。虽然只支持HTTP协议,但是目前国内的网站很少有强制HTTPS的,在可预见的时间范围内,应该不存在不够用的情况。

具体到实现上,虽然GoAgent是我一开始想到的做法,但实际上比较之后我还是选择了WallProxy. 原因有二,一是GoAgent本身还是给GAE用的,PaaS的部分只是顺带做了一下,支持的并不完善;相较之下WallProxy则要好得多。二是WallProxy在浏览器代理端支持使用用户名密码进行验证,虽然只是一个防君子不防小人的验证但毕竟总比把代理端口直接暴露在广域网上要好一些。

总体而言部署还是很容易的,首先去Github把WallProxy的repo给checkout出来:https://github.com/wallproxy/wallproxy,注意选择master分支。然后在国内端只要把WallProxy里的index.php放到空间里去即可,为了防止被滥用也可以在index.php的头部设置一个密码。VPS端跑的相当于是WallProxy的客户端,需要对proxy.ini进行一定的修改。

由于我们并不需要使用WallProxy的GAE特性,那些所有和GAE,PAC有关的功能统统可以关掉了。我们要关注的其实只有两个地方,第一节是[listen]段

ip = 0.0.0.0
port = 8086
username = xxx
password = xxx

其实就这么几个参数,ip改成0.0.0.0让它能监听广域网请求,端口看着设,用户名密码则是代理端需要输入的,随便设就好了——HTTP的代理用户名密码都是明文传输的,这也是我说这玩意防君子不防小人的原因。另外一个原因是如果不设置用户名密码的话,被搬瓦工看到你有一个公开的代理端口会被直接关端口,所以还是设一个比较好。

[paas]
enable = 1
password = 123456
;listen = 8088
fetchserver = http://demo1.app.com/

[paas]这一节设置成enable, 密码设置成和之前php里一致即可,listen注释掉,我们在之前[listen]一节里已经设置了监听端口,这里的listen端口就不需要了;fetchserver设置好php的地址,再把剩下的所有配置节中,包含enable的全部设置成0,也就是disable掉所有其它的feature,我们的VPS端也就配置好了。只要用

python startup.py

一个用VPS中转的,出口IP在国内的HTTP代理服务器就搭建完成了。当然还有一些扫尾工作可以做,比方说在开机脚本里把刚才的命令加进去等等,就不多说了。

Screen Shot 2015-02-28 at 17.55.39

PHP这一端我用的是新浪的SAE,IP就是北京电信的。整个系统的结构就是SAE的PHP做服务器端,搬瓦工VPS做客户端,代理端口暴露给外网,我们访问的时候,浏览器会先访问VPS上的代理客户端,然后转发到PHP上,PHP再访问目标服务器,整个访问过程变成了3段。

回到正题。搭建完代理服务器只是第一步,第二步是配置浏览器让它能够Unblock Everything。简单粗暴的做法就是把整个浏览器的代理直接设置成这个,当然我们有更优雅的做法,比方说利用rule来减少代理流量,加快速度(毕竟代理绕了3圈)。我用的插件是ProxySwitchy,当然现在已经改名叫SwitchyOmega,在Auto Switch中添加几条rule即可。我一般常用的就是网易云音乐和优酷,URL分别是

http://music.163.com/*

http://v.youku.com/player/getPlayList/*

Unblock Youku的Pac文件里有更多的规则可以参考,我因为一般需要的就是这两个,所以就配置了这两个Rule,其它的Rule用到了再配。不常用的Rule也可以到时候手动切换走全局代理,也不是什么大问题。

HostUS把服务器搬到洛杉矶了

前两天收到邮件,说要把服务器从vegas搬到LA去,对我来说当然是个好消息,理论上从国内连过去的速度能快上一些。搬好之后测试了一下,发现之前平均185的ping在搬迁后竟然略微上升到了190-200.估计是BGP还没更新,可能要等几天才会好。


今天又测试了一下,已经降到175了,但是和搬瓦工150-160的逆天延迟还是没法比啊。但是搬瓦工最近晚上高峰时间网速很慢,很烦人。


 

再更新一下,其实网速很慢不是搬瓦工的锅,而是因为港大网络的出国带宽不够大,一到高峰时间就堵住了,换成非港大网络就会好很多。

HTTPS & Referer

There are basically two usages of HTTP header “Referer”. One is to trace the origin of the visit, which could be used to analyse the visitor’s browsing path. The other is to identity and block illegal visits to some privately owned web resources, like images & files.

There are some tricky things about “Referer” when it comes to HTTPS. Generally speaking, for safety reasons, a redirect from a HTTPS page to a HTTP page will drop the “Referer” header. Thus, the server will never know where this request really comes from. Some websites use a https-http redirect to bypass the restrictions of private web resources. For example, a webpage quote an image from sinaimg.cn. Sinaimg.cn does not accept requests unless it has empty Referer or the Referer is one of Sina owned domains. To let the browser drop the Referer header, the <img> tag uses a src of https://example.com/redirect?url=sinaimg.cn?xxxxx instead of the original one. The only function of this https://example.com/redirect is to redirect the request to the URL that is specified by the “url” parameter. Therefore, the “Referer” header is dropped and the image file could be visited from other domains.

One known fact about Google is that it uses HTTPS on all of its search results. Most other websites, however, are still using HTTP. As a result, the referer info will be dropped when redirecting from google search result to the webpage. If there is some auto-tracing tools installed on the server, it may never know that the request comes from Google search result.

To solve the problem, two things have been done by Google. One thing is the introduction of “referrer policy” to webkit. Details of it can be found here: https://wiki.whatwg.org/wiki/Meta_referrer. Basically it uses a <meta> tag to tell the browser how to deal with referrers. The current policy used by Google is “origin”, which sets “https://www.google.com” as referrer with no extra information. This is only a little bit better than no referrer, since the tracing tool cannot collect keyword information from the referrer. The other thing is the redirecting page between Google search result and the real target page. Google owned tracing tool, like Google Analytics, can use this redirecting page to collect required data.

What about non-webkit bowsers? Google uses a http redirect page instead of  a https one. This page uses JavaScript for redirecting, not a 301 or 302 redirection. In that way, the target page can collect the correct “Referer” information.