StrongVPN 的用户反馈摘录

StrongVPN 是一家自 1994 家就成立的公司,它可以活到现在并依然有着很好的用户体验,足以表明它家的实力。以下是一些用户反馈的摘录,取自 StrongVPN 的用户反馈页面。原文都是英文的,附上我自己的翻译。


Jingui L.:主要使用 StrongVPN 上 YouTube、Facebook 和收发邮件。日本的服务器是我目前用过最好的 VPN 服务。它从来没有出过问题并且非常快。虽然它只在 Deluxe 套餐中才有,有点小贵但非常超值。


Zhongjie W.:主要使用 StrongVPN 访问国外站点。VPN 连接的速度很快并且非常稳定。连接配置方便,很容易就可以更换服务器。每当我遇到了连接问题,客服人员总能快速地帮我解决。


Nursat Y.:我在工作和生活中都使用 VPN。StrongVPN 的服务令我非常满意。物有所值,连接速度比其它大多数 VPN 提供商都快。StrongVPN 在工作和生活中都起到了很大的作用。


Margus M.:使用 VPN 来访问世界其它地区的网站。StrongVPN 已经没有瑕疵地为我服务了三年。即使在中国地区这么烂的网络环境下,StrongVPN 依然能提供最稳定的连接。更好的是,它家的客服非常高效。


Dominik J.:StrongVPN 是目前世面上最好的 VPN,没有之一。我和 Nathan 一起使用了四年 StrongVPN,它家的客服总是及时地出现在我需要帮助的时候,并且总能帮忙解决各种连接问题,让我访问到包括 Google 在内所有重要的网站。每当一个网站在中国被墙的时候,我只要提交一个工单,就可以获得及时的服务。我觉得已经没什么可以挑剔的了。

如果你也对 StrongVPN 的服务感兴趣,可以点击这里购买。它家现在有一个特价套餐,仅售不到 $5 一个月,非常合算。

注册过程中有任何困难的话,可以参考《StrongVPN 的详细购买攻略》,或联系 StrongVPN 的客服

博客 2015 年度访问数据统计

这大概是我第一次发布如此的统计,细心的读者大概可以发现本博客最早的文章发表于 2004 年,只是好多年来,访问量实在不值一提。直到去年,博客的访问量终于有实质的上升了。

2015 年全年博客的页面点击量(Pageview)为 2,217,504,比 2014 年上升了 42%。总访问人次为 804,116,比 2014 年上升 47%。也就是说,差不多平均一个人浏览 2、3 个页面就离开了。这符合博客的特性,毕竟我的博文都是全文输出,文章内容不分页,也没有其它骗点击的小把戏。大家看完一篇文章后,再回首页看看,然后就结束访问了。

看了坛子的文章,发现月光博客在 2015 年的文章访问量只有 75 万多一点。这么说来,我的博客还比月光博客热门那么一点。是不是该高兴一下下?

在 200 多万的页面访问中,有超过 80% 的用户来自中国(包括台湾和香港),剩下最多的是来自美国的访客(5%)。看来有能力出国的同学们,所阅读的技术文章都已转向了英文,我的博客自然对他们没什么吸引力了。

访客所使用的浏览器前三名分别 IE(52%)、Chrome(25%)、Safari(7%)。除了 Safari 比起 2014 来上升了 2% 之外,前两位的比例没有明显的变化,IE 依然是大众的主流浏览器。操作系统方面,Windows(76%)、Android(8.96%)和 iOS(8.75%)占据前三位,Mac OS X 只占了 3%,Windows Phone 更是只有可怜的 0.06%。在移动时代全面到来的时候,Windows 家族大势已去了。

博客的页面平均加载时间从 2014 年的 3.01 秒下降到了 1.90 秒,速度提升 37%。这和我在 2014 年底把博客迁移至 Google Cloud 密不可分。Google Cloud 的总体表现令人满意,希望在 2016 年全面使用 Google CDN 之后,页面的加载时间可以降到 1 秒以下。

新的一年,我会致力于改进用户体验,随着访客上网设备的改变,访客所浏览到的内容形式也在慢慢地变化。博客不能一直受限于文字模式,提供用户喜闻乐见的内容,才是博客存在的意义。

由快播的庭审说说加密解密的问题

今天是“快播”涉黄案开庭的日子,新浪网直播了庭审全过程,过程中充满了各种欢乐。我们来说说其中的一个:

且不说这位审判员对于法律是多么地无知,用户的文件无论有没有加密都属于个人隐私,能问出这样的问题显然是对隐私保护没有一丁点的认识。

接下来我们从技术的角度来说说,为什么不能解密。

加密解密实际上是纯数学的东西。如果把一个需要加密的文件看成是一串数字,比如一个文件由一串数字序列(A0, A1, A2, ..., An)构成,这个序列可以被人阅读和理解。加密的过程就是把上述 A 序列转换为(B0, B1, B2, ..., Bn),这个 B 序列是完全杂乱无章,看不懂的内容。然后解密就是加密的逆过程,把 B 序列再翻译回 A 序列。这两个转换过程中都需要大量的计算,而计算机的产生使用大规模加密解密成为可能。

加密解密的一个典型应用场景是寄信。比如小张要写一封信给小红,为了防止信件在寄送过程中被别人看到内容,小张可以把信的内容先加密,然后收小红收到信之后再解密,即可确保寄送过程中没有人可以看懂信件的内容。

加密解密的一个重要工具是密钥。密钥的本质也是一串数字序列(C0, C1, C1, ..., Cn),把它和 A 序列以某种方式混合,即可产生 B 序列。然后再把 C 序列和 B 序列以某种方式混合,即可产生 A 序列。这种方式称为对称密钥加密。常见的对称密钥加密方式是 AES,暴力破解 AES 加密需要千百万年的计算时间,因此被认为是安全的。

使用对称密钥加密的前提条件是,传递信息的双方事先要约定一个密钥,有了统一的密钥,才能顺利地加密和解密。我们在谍战剧里经常看到的,战争的一方截获对另一方的密码本,从而监听到了重要的信息。这个密码本,就是这里说的密钥。密钥需要定期更新,否则就有可能被对方暴力破解,或是以其它的方式窃取。

从谍战剧中我们可以看到,对称密钥加密的主要缺点就是,交换密钥不方便。虽然后续的通信都加密了,但是密钥的传输过程中却是公开的。密钥的传输过程成了加密解密中的薄弱环节。

那么有没有办法解决这个问题呢?当然是有的。这种方法称为非对称密钥加密

非对称密钥加密的密钥包含两部分:公钥和私钥,公钥可以公开,私钥需要保密。而非对称密钥加密是一个外人看来很玄乎的东西。先说说它的过程:小张手里有一对公钥 P 和私钥 X,小红手里有一对公钥 Q 和私钥 Y。小红先把自己的公钥 Q 告诉小张。小张使用 Q 和自己的私钥 X 把信件的内容 A 加密成 B,然后把 B 和小张自己的公钥 P 一起告诉小红。然后小红使用自己的私钥 Y 和小张的公钥 P 对加密内容 B 进行解密,即可还原出 A 来。相信看到这里多数人都已经晕了。

具体原理这是不多说,它和素数分解有关。它对于密钥的保护措施是加密的双方只需要交换公钥即可进行加密和解密,而即使公钥被第三个人知道,他也没有办法破解加密过的文本。常见的非对称密钥加密方式是 RSA,暴力破解 RSA 同样也需要千百万年。非对称密钥加密最常见的应用是 HTTPS。这下知道为什么 HTTPS 是安全的了吧。

于是这里就解答了那位审判员的疑惑,为什么不能对用户上传的文件进行解密,因为根本解不开。如果快播的用户在上传视频时使用了非对称加密,下载视频的用户在观看时解密,这个过程中快播是没有办法知道其中的内容的。聊天软件 Telegram 也使用了类似的方式进行端到端的加密,使用聊天内容就连 Telegram 自己也不知道。

和加密相关的另一个技术称为哈希(Hashing),哈希的作用是验证源文本的真实性。举个例子,小张立了一份遗嘱,他显然不需要对这份遗嘱加密,因为遗嘱最终是要公开的。而他要做的是,确保最终公布的那份遗嘱和他最初立下的是一样的。于是小张可以在立下遗嘱的时候对这份遗嘱做一个哈希,在遗嘱公开的时候,对公开的遗嘱再做一次哈希,如果两份哈希码一致,才说明遗嘱没有被改动过。当然这其中还涉及到一些哈希保密的步骤,这里不细说了,大家知道这个意思就可以了。

哈希和加密解密的一个重要区别是,哈希生成的哈希值,是没有办法解密的,就是还原不回去,只能把 A 哈希成 B,不能再从 B 推导出 A。哈希在计算机领域的一个常见用途是保存密码。比如你在某个网站上注册了一个帐号,这个帐号包含用户名和密码。而网站的管理员不希望除了你之外的其它人看到这个密码,于是网站上所保存的内容只是密码的哈希值,而不是密码本身。在你每次登录网站的时候,网站都会对你输入的密码做一次哈希,如果哈希值和网站数据库中存放的一致,则表示你输入的密码正确。而即使有人偷取了网站所保存的哈希值,也没办法还原出密码来,也就不能登录你的帐号。

现在主流的哈希算法是 SHA-2。一个常见的应用场景是两步验证

好了,说了这么多加密解密相关的东西,回过头来说说快播。我没有用过快播的软件,也不太清楚快播对色情视频的打击做到了什么程度。但从技术的角度来看,P2P 的加密内容分享是无法被解密的,这也加速了全球日益高涨的恐怖威胁。全世界的政府都在要求商业公司提供用户的解密数据,与之相对的是数学领域的加密理论已经远远把监控和破解甩在了身后。我不认为任何公司需要对技术的进步负责,科技的进步是大势所趋,而需要改进的,是那些仍处于落后状态的事物。

Go 语言中奇怪的 if 语句

上篇文章提到过 Go 语言中带有强烈的设计者的主观想法,Go 的 if 语句就是其中一例

常见的 if 语句大约是这个样子的(C++):

这样有一个问题:变量 event 定义在了 if 语句的外面,也就是说,在 if 语句之后,也可以继续使用 event 变量;而如果后续的操作中不需要 event 变量了,它实际上就造成了命名空间的污染。这并不是一个严重的问题,多数情况下不会造成任何问题,而如果一定要解决的话,在 C++ 中可以在 event 的定义之外套一层大括号来限定它的作用域。虽然代码看上去有一些奇怪,但无伤大雅。比如这样:

但是 Go 的设计者不知是出于什么原因,非要从语法上解决这个问题。于是 Go 中的 if 语句可以写成这个样子:

对,你没有看错。虽然 event 是定义在了 if 中,但它在 else 中也是可以用的。也就是说,这种写法实际上是上述的 C++ 写法的语法糖。

并不清楚 Go 的设计者添加这个语法糖的目的是什么。它仅仅是为了解决变量的作用域问题而提出,却牺牲了代码的可读性。if 语句可能会变得过长而不易阅读;在后续重构的过程中,拆分 if 语句也会变得困难。为了解决一个小问题而增加一种有问题的语法,看上去有点得不尝失。

吐槽一下 Go 语言

由于公司一直都在大力推广 Go 语言,我也有幸接触了一下。虽然 Google 内部已有三大语言(C++、Java、Python),Go 在公司内部的政治意义大于它的实际使用,但它的设计却有着很多亮点。比如 Go 自带了代码格式化工具(gofmt)和自动化测试工具(go test),这些标准化的工作在其它语言中一直都存在着多方争议,一直都不能统一,而 Go 从一开始就搞定了这些琐碎问题,让广大程序员可以把重心都放在开发新程序上,而不是争一些有的没的。

当然,这篇文章并不想表扬 Go 语言,而是要吐槽一下它的缺点。

Go 的设计者有着强烈的 Unix 背景,有一些平台依赖的东西都默认甚至是强制成 Unix 的。比如 Go 语言中有一个名为“path”的包,用来操作路径,而它强制路径分隔符为“/”,而无视 Windows 中的“\”。后来估计是开发中遇到一些问题,又做了一个叫“filepath”的包,来兼容 Windows 的使用。又比如 Go 语言中对环境变量的解析,强制环境变量的标识符为“$”,而不视 Windows 中的“%”,甚至整个标准库中都找不到对“%”的处理方法。这些基本的区别都不做处理,很难想象 Go 语言在跨平台设计中有哪些更为隐藏的坑。

这还不是主要的问题。更严重的问题是,Go 语言中有过多的“私有”特性,对使用者不公平。

先来举一个 C++ 的例子,C++ 中有一些运算符,比如加减乘除,这些运算符可以使用于 C++ 的基础类型(如 int)上。基础类型是 C++ 语言本身提供的,如果运算符只能作用于基础类型,那么 C++ 也可被视为“自私”的。然而 C++ 的设计者并没有这么做,这些运算符,不仅可以用于基础类型,也可以在自定义类型中,通过重载的方式来使用,使得 C++ 中不仅两个 int 可以相加,两个 class 的实例也可以相加。这样一来,运算符对于使用者就是公平的。

而 Go 语言中,则有着很多反例。比如它的泛型:Go 的官方说法是“我们不支持泛型”,具体原因就不深入讨论了。但是,Go 语言的自有类型 map 和 channel 却是支持泛型的。这就成了一个典型的“自私”的例子。类似的例子还有 Go 语言中的 internal 包有着特殊的作用域;Go 的官方库有着极短的包名,而第三方库通常是以“github”开头的很长一串文本。

这些“私有”特性,说明 Go 语言的设计者并没有为开发人员考虑过,自己设计得爽了,却徒增了学习曲线,不利于 Go 语言的推广。如果能把这些问题解决好,Go 还是可以成为一门不错的语言的。

电视剧播放模式即将被颠覆

这几天闹得沸沸扬扬的《芈月传》全集泄漏事件,着实让这部不怎么样的电视剧再火了一把。要泄漏一定得有内鬼,而版权方貌似对这个内鬼一点办法都没有,只能去谴责百度,因为百度云盘提供了部分影片的下载。后来百度乖乖地把涉事的文件全给删了。

这件事从一个侧面说明,百度云盘会监控用户的文件,涉及隐私的文件请不要传上百度云。

当然本文的重点不是这个。这里我们来关注一下泄漏事件的必然性。

大概二十年前,电视机成为了家家户户必不可少的娱乐设备。它不仅是一块屏幕,而是所有电视节目的入口。电视节目无论大小,上到每年一次的春晚,下到每天三十分钟的新闻,都要从这个几十寸或方或扁的盒子里观看。每天晚上全家围坐在电视机前嗑瓜子,也逐渐成为了常态。

有线电视业务也因此火暴了起来,全国有数百个电视台,每个电视台自负盈亏,为了利润不惜动用各种龌龊手段。就拿电视剧而言,本来是在电视剧中插播广告,现在是在广告中插播电视剧;而一部电视剧,每天只播一集两集,甚至有些一周才播一集,吊人胃口,让人不得不每天每周按时看电视。

而好景不长,也就十几年的功夫,互联网彻底改变了这一切。

在线看视频,和电视台有相当的不同。一是互联网视频随看随播,想什么时候看就什么时候看,想看哪一集就看哪一集,不怕因故错过了一集而连不下去;二是广告少,各种视频网站都可以通过加入会员,或者其它工具的方式,把广告取消,不必在广告中找寻电视节目;三是想在哪看就在哪看,冬天天冷不必待在客厅挨冻,抱个笔记本窝在被子里也可以流畅观看。就因为这几点,有线电视业务近几年迅速缩水,不得不在广电总局的庇护下才可以苟延。

正是有了互联网视频,电视机又做回了它的老本行:一块屏幕。

而在线视频的大杀器,则是全集一起上线。由于用户可以自由地选择想看的节目,互联网视频不再受限于播放渠道,相当于每个用户都有一个专属的电视台。只要网站的节目足够多,就可以吸引用户停留更多的时间,而不用像传统的电视台那样,用每天一集的方式来让用户回归。于是越来越多的网络剧,选择了一次放出所有剧集的方式,让大家一次看个够。实际上,虽然可以自由支配时间,用户每天花在娱乐上的时间也是有限的,即使有全集可以看,也不是所有用户都会一次性看完。于是在线视频就用更吸引人的方式,做了和电视台差不多的事情。

《芈月传》泄漏事件之所以火暴,还不是因为广大网民不能忍受每天两集的龟速。每个人都有自由支配自己时间的权力,那个大锅饭统一管理的年代已经一去不复返了。

在 Markdown 中设置链接由新窗口打开

尽管我对 Markdown 不是那么感冒,但工作和生活中总是难免会使用到一些,比如在向某些开源项目发 PR 的时候。于是对 Markdown 的一些小技巧也有所了解。

Markdown 中的链接语法是这样的:[文本](链接)。它相当于 HTML 中的

但众所周知,HTML 的 a 标签有一个实用的属性 target,当它的值为“_blank”的时候,浏览器会默认为这个链接打开一个新窗口,而不是在当前页面转向新页面。而 Markdown 中没有这个“_blank”选项,于是所有链接都只能在当前页面打开,有些情况会非常不方便。

在多数 Markdown 解释器中(如 GitHub Flavored Markdown),这个情况无解。如果一个 Markdown 解释器同时支持 HTML 语法,则这种情况可以通过直接写 HTML 解决。

于是我又多了一个不喜欢 Markdown 的理由。