如何达成HTTPS在移动端的效能提升
HTTPS网站的广泛应用使得人们更加重视HTTPS的效能提升，通常HTTPS的优化多针对PC端，但在移动端的效果并不尽如人意。去年Google已经在移动端进行了HTTPS性能的加速，为Android平台的Chrome浏览器增添了新的TLS加密套件：ChaCha20-Poly1305，这是一款专为移动设备设计的加密套件，旨在提供更优的安全性和性能。
以下是在iPhone Chrome浏览器打开Google日本网站后所显示的加密信息截图。
野狗WildDog已经全面支持在移动设备上使用更高性能、更省电的加密套件ChaCha20-Poly1305。以下是在Chrome浏览器打开野狗官网后所显示的加密信息截图。
为了更好地理解ChaCha20-Poly1305，我们先简要介绍对称加密和AES-NI。
对称加密与AES-NI
对称加密
在HTTPS握手过程中，通过非对称加密协商出对称加密密钥，然后使用对称加密对双方通信的数据内容进行加密。非对称加密对服务器性能的损耗是巨大的，可以通过Session Resume等方法进行加速。常见的非对称加密算法有RSA、ECDHE等。
在协商出对称加密密钥后，HTTPS中所有数据内容的通信加密都使用对称加密进行。对称加密分为流式加密和分组加密。
常见的流式加密算法有：RC4，ChaCha20-Poly1305。
常见的分组加密算法有：AES-CBC，AES-GCM。
RC4由于存在严重的安全漏洞，已经基本不再使用；AES-CBC容易遭受BEAST和LUCKY13攻击，使用也逐渐减少，AES-GCM是它们的安全替代，AES-GCM也是目前最流行的对称加密算法。
安全风险可参考ssllabs上的相关文章：
AES-NI
AES-GCM解决了对称加密存在的安全问题，但带来了性能问题。为此，出现了AES-NI（Advanced Encryption Standard New Instruction）。AES-NI是Intel和AMD微处理器上x86架构的一个扩展，可以从硬件上加速AES的性能，目前在服务器和PC端，CPU对AES-NI的支持率已经非常普及。
测试结果显示：服务器开启AES-NI后，性能提高了5-8倍左右，这与Intel官方公布的数据基本一致。
测试方法：
可以使用OpenSSL测试，也可以使用其他SSL库测试，因为所有SSL库都支持AES-128-GCM。
OpenSSL AES-NI= OFF
OPENSSL_ia32cap=”~0x200000200000000″ openssl speed-elapsed-evp aes-128-gcm
OpenSSL AES-NI= ON
openssl speed-elapsed-evp aes-128-gcm
关于AES-NI的指令集，建议查看Shay Gueron编写的《Intel高级加密标准(AES)指令集(2010)》。
ChaCha20-Poly1305的优势在哪里？
Google推出新的加密套件并在所有移动端的Chrome浏览器上优先使用的原因：
ChaCha20-Poly1305避开了现有发现的所有安全漏洞和攻击；
ChaCha20-Poly1305针对移动端设备大量使用的ARM芯片进行了优化，能够充分利用ARM向量指令，在移动设备上加解密速度更快、更省电；
更加节省带宽，Poly1305的输出是16字节，而HMAC-SHA1是20字节，可以节省16%的overhead消耗。
通过实际的测试数据来看看ChaCha20-Poly1305在移动端使用的优势。
测试一：
在支持AES-NI扩展的设备上，AES加密的性能优势是明显的。目前最常用的对称加密AES-128-GCM的性能是ChaCha20-Poly1305的近5倍。
由于原生的OpenSSL目前还不支持ChaCha20-Poly1305，通过编译LibreSSL源码（最新源码进行测试。
测试方法：
进入到编译后的LibreSSL目录，通过下面的命令测试。
./apps/openssl/openssl speed-elapsed-evp chacha
./apps/openssl/openssl speed-elapsed-evp aes-128-gcm
./apps/openssl/openssl speed-elapsed-evp aes-256-gcm
./apps/openssl/openssl speed-elapsed-evp aes-128-cbc
./apps/openssl/openssl speed-elapsed-evp aes-256-cbc
测试二：
在不支持AES-NI扩展的移动设备上，ChaCha20-Poly1305的性能是AES-GCM的三倍左右。
对称加密最合理的使用方法是：在支持AES-NI的设备上，优先使用AES-128-GCM加密套件；在不支持AES-NI的移动设备上，特别是ARM架构的设备上，优先使用ChaCha20-Poly1305加密套件。
Nginx实现ChaCha20-Poly1305的三种途径
OpenSSL官方版本目前不支持ChaCha20-Poly1305，因此不能使用原生的OpenSSL版本。关注OpenSSL官方的动态
在Nginx上实现ChaCha20-Poly1305的主流方法有三种：
使用OpenBSD从OpenSSL分支出的LibreSSL；
使用Google从OpenSSL分支出的BoringSSL；
使用CloudFlare提供的OpenSSL Patch。
这三种主流方法，都已经在服务器上部署成功并经过流量测试，各有优缺点。具体的部署方法、Nginx配置、部署过程中可能遇到的错误及解决方法，涉及的内容较多，相关内容如下：
Nginx编译安**oringSSL
Nginx编译安装LibreSSL
Nginx编译安装CloudFlare提供的OpenSSL Patch
以下是我总结的这三种方法的优缺点，欢迎大家补充。
LibreSSL
编译安装方法最为简单；
OpenBSD小组对OpenSSL的代码进行了全面清理并重构，更为轻量；
已经发布稳定版本，相比于OpenSSL团队，问题修复更及时。
BoringSSL
支持等价加密算法组功能（Equal preference cipher groups），这个功能我认为很有意思，在后面的博客中再介绍；
与Nginx编译友好性不足，编译容易出错，至少需要修改两处源码；
不支持OCSP Stapling功能。这一点是比较有意思的，Google工程师在博客中说OCSP Stapling存在缺陷，目前不支持，但不排除后面支持的可能性。联想到Chrome浏览器默认也不使用OCSP，可见Google对OCSP的情感是复杂的。
不支持OCSP Stapling功能。这一点颇具趣味，谷歌工程师在博客中指出OCSP Stapling存在瑕疵，目前尚未支持，但未来有可能会采纳。联想到Chrome浏览器默认也不启用OCSP，可见谷歌对OCSP的态度是矛盾的。
OpenSSL修复包
编译安装流程较为繁琐；
OpenSSL自身较重，存在的安全隐患也较多，需要频繁更新版本；
稳定性有待进一步验证。
目前野狗WildDog网站采用的是LibreSSL，用以解决移动端的加速省电等新功能，如果您有疑问，或者想要更多交流，或者在使用ChaCha20-Poly1305时遇到问题，都欢迎与我们联系。最后附上野狗官网（www.wilddog.com）在ssllabs上评测结果的截图。
如何进行网站SEO手机端移动端百度排名优化
移动优化的三种途径
移动网站大致上有三种选择：
响应式设计（responsive design）：
PC站和移动站的URL完全一致（无论使用何种设备访问都相同），返回给浏览器的HTML代码也是相同的，不同宽度的屏幕排版不同是通过CSS控制的。以前也常称为自适应设计，因为排版是根据屏幕宽度自动适应的。
动态服务（dynamic serving）：
PC站和移动站的URL完全一致，这一点与响应式设计相同，但动态服务方式返回给浏览器的HTML代码（以及CSS）是不同的，PC设备得到的HTML代码是PC版，移动设备得到的HTML代码是专门针对移动端优化的版本。
独立移动站（separate site）：
移动站的URL和PC站不同，通常使用单独的子域名，例如PC站是，移动站是m.httseo.com，当然移动站的HTML代码（以及CSS）与PC站也是不同的，是专门针对移动端优化的。换句话说，这种方式下，移动站就是一个独立的网站。
这三种方式各有各的优缺点。
响应式设计
既然URL一致，所有设备得到的HTML代码也相同，好处显而易见：简单明了，搜索引擎不会被混淆。搜索引擎抓取、索引一套页面即可，提高索引效率，尤其对大网站，抓取份额浪费在多个URL上，就意味着降低深层页面被抓取的机会。自适应设计只有一个URL，链接、权重计算都集中在一个URL上，不会出现问题。
用户也不会被混淆，收藏书签、分享页面也不会因为URL的不同而出问题。
站长方面开发维护一套代码即可，后端开发成本相对较低。建设的外链也集中在一个URL上。不需要判断设备、浏览器类型，也不需要转向，也就不会出错。
当然也有缺点。比如，移动设备由于屏幕大小的关系，经常要隐藏一些内容和功能，但还是需要下载完整的HTML代码，经常还包括图片，所以会浪费带宽。手机网速慢的话，多下载文件就意味着速度变慢。而且，同一套代码要在所有设备显示正常，还要尽快开始渲染，前端设计需要较高的水平。
响应式设计的页面必须设置viewport，告诉浏览器按照屏幕宽度自动调整页面排版：
虽然有缺点，但随着移动网速、手机性能的提高，响应式的缺点逐渐显得不那么致命，而它的便捷性就更显优势了。所以，响应式设计是未来的趋势，是大势所趋。这也就是为什么我建议新网站，或者刚刚要做移动SEO的网站，肯定直接就做响应式了，不用考虑其他选项。（除非贵公司不差钱，可以考虑动态服务。）
独立移动站
与响应式设计相比，独立移动站显然开发成本要高，需要开发维护两套代码。随着国内人力成本提高，需要重复做的事情会越来越不划算。
独立移动站的更大潜在问题是URL的不同可能造成混乱和各种错误。比如，既然移动和PC版本URL不同，搜索引擎就需要建立对应关系，必须判断PC页面对应的移动版本URL是什么，移动页面对应的PC版本URL是什么。网站需要在页面添加代码帮助搜索引擎判断：
PC页面需要添加下面代码指明移动版本位置：
对应的移动页面需要添加下面代码指明PC版本位置：
<linkrel=”canonical”href=”
m.sg.httseo.com
cn.httseo.com
m.cn.httseo.com
等等。多语言hreflang标签和独立移动站的
动态服务
动态服务与独立移动站一样，首先在服务器端判断设备和浏览器类型，然后在同样的URL上、根据浏览器屏幕宽度返回不同的HTML和CSS代码。
所以动态服务方法相当于把响应式设计和独立移动站的优点结合起来，即有URL统一的简洁明了，又有独立移动站的代码优化，SEO效果是最好的。当然，代价是前后端成本都要提高。
对不差钱的公司来说，动态内容是最佳选择，比如amazon现在就是用动态服务做移动优化的，URL统一简单，不会出错，两个版本的代码还可以分别优化，据说，亚马逊移动版本节省了40%的文件下载量，对手机用户来说，页面打开速度的提升是至关重要的。
是否使用动态服务要看公司情况。对大部分网站来说，页面内容、排版、功能没那么复杂，响应式设计已经满足需要，用高成本实现动态服务，节省的下载量没那么明显，比如SEO每天一贴这种博客，还有大量内容型网站，页面连个图片都没有，除了留言也没有别的交互，那一点下载都节省不了，动态服务就没意义了。
是否采纳动态服务需视企业状况而定。对于多数网站而言，页面内容、布局、功能并不复杂，响应式设计已足够满足需求，采用高成本实现动态服务，所节省的下载量并不显著，例如SEO每日一文的博客，以及众多内容型网站，页面甚至没有图片，除了留言外并无其他交互，这根本无法节省任何下载量，动态服务便失去了意义。
搜索引擎爬虫访问动态服务页面时，从HTML代码中无法自动识别不同浏览器将获得不同的代码。例如，PC爬虫访问时，获取的是PC版代码，但爬虫并不必然知晓移动爬虫访问时会得到不同的代码，因此服务器端需要通过设置Vary页面的服务器头信息：
<Content-Type:text/html
<Content-Length:6400
<Connection:keep-alive
<Server:Server
<Date:Sat,27Jul201916:42:45GMT
<Vary:Content-Type,Host,Cookie,Accept-Encoding,X-Amzn-CDN-Cache,X-Amzn-AX-Treatment,User-Agent
<Edge-Control:no-store
<x-amz-rid:KH589YRZC8QEW3QEWGKD
<X-Cache:Errorfromcloudfront
<Via:1.11b52a5dd431f9e3c81753e61dfdf467a.cloudfront.net(CloudFront)
<X-Amz-Cf-Pop:SFO9
<X-Amz-Cf-Id:0qtVw99a2_AustEZ-dxC_cs9hfVzyll-DmHnmWFDtBSWKtinpxhB2Q==
其中Vary这一行是告知浏览器/爬虫，根据后面列出的不同情况，HTML代码将有所不同，Vary:User-Agent即表示根据不同浏览器用户代理的不同，HTML代码也将不同。
独立移动站的执念源于何方
众多企业和网站管理员对独立移动站情有独钟，认为m.移动站的SEO效果最佳，新网站还需构建独立m.站。这种观念可能源自两个方面。
一是以前百度更倾向于推荐独立移动站。然而，如今已过去四年，百度目前的正式官方立场我尚未见到，但两年前百度搜索主任架构师谭待明确告诉我，百度也认为响应式设计是未来趋势，百度也推荐转向响应式设计。我的观察是，百度目前对响应式设计的支持并无问题。
Google一直以来都是推荐响应式设计的。
当然，这里所说的推荐，并非表示响应式比独立移动站的SEO效果更佳，而只是表明，百度和Google对三种方法持同等态度，排名上并不偏袒任何一个，SEO效果相同。既然效果相同，自然推荐那个简单、经济的方案。
以一个例子来说明，数据显示，大部分车祸是由男性司机造成的，但这是否意味着男司机开车存在劣势呢？恐怕不能这样认为，因为必须考虑路上司机男女比例，很可能80%的司机是男性，造成了70%的车祸，因此70%的车祸是由男司机造成的，并不能说明男司机开车水平比女司机差。
移动搜索排名亦是如此。目前排名靠前的m.站居多，很可能这些站绝大部分是老站（才具有高排名能力嘛），而几乎所有老站当初开始做移动SEO时都是从m站入手的，不到万不得已，这些使用m站的老站不会去改为响应式设计，因为改动太大，冒险，又没有明显好处（如前所述，三种方式SEO效果相同），没有动力去改变。
因此，老站、大站排名较好，而老站、大站又以m站为主，所以我们看到m站排名较好。但这并不意味着新站就要模仿m站。
