HTTPS网站的seo优化技术建议

企鹅SEO
企鹅SEO
企鹅SEO
6393
文章
74
评论
2018年7月27日 评论 28.7K views
广告也精彩

CSDN:Https优化方案与测试结果
背景
https 是基于http 和 ssl(安全套接字层) 的安全传输协议,使用ssl 协议作为会话层协议。这个协议最早是由网景公司 开发,但是随着网景的没落,现在由ietf负责维护,最初的版本也已经重新冠名(re-banded)tls(安全传输层协议) 1.0(1999年)。因此现在大部分协议是基于TLS的,尽管是相似的东西。
针对https,能够保证数据更加安全,但是副作用是访问会变慢(相对于http),因为服务端增加了更多的计算,客户端和服务端之间多了一层协议协商过程。因此,我们要做的优化主要是针对这里
优化点和优化方案
大概阐述了优化的几个方向,下面我来具体的展开讨论下。如有疏漏请指正。
同时,我也整理了一份针对https 的握手过程详解,可以帮助大家科普下。
客户端优化
客户端优化是针对发起 ssl client hello 的一端进行的优化。主要有两个大的方向:
减少请求次数,提高效率
优化加密效率
规避完整握手
针对减少请求次数,主要的一个点是 SSL Session 的复用,Client Hello 请求中的 Session ID可以唯一的区分一个ssl 会话的ID。这个ID在Client Say Hello的时候被填写,
如果是第一次与server发生会话,那么Session ID可以是空。 如果之前与ssl 服务器建立过会话,而且客户端开启了Session Ticket;并且Server cache了这个Session Ticket的时候,服务端与客户端的握手就会简化,省略掉pre master 交换的过程,直接复用之前的ssl 会话
优化加密效率
这里是一个比较复杂的点,我们先来看下有哪些过程可能耗时:
密钥协商阶段的非对称加密
协商过后的针对通信的对称加密
@协商密钥阶段
密钥协商过程中,客户端的计算量相对小:
生成 random1
生成 pre-master (填充过的随机数)
根据服务端的 random2 和自己的 random1 还有 pre-master 生成 master-secret
使用服务端通知的(经过验证的)公钥加密 pre-master
这个过程中大部分是在生成随机数,只有生成 master-secret 和 使用公钥加密 是消耗cpu 的。
@加密通信阶段
再看下ssl协商之后的过程中的加密方式,因为是采用之前协商后的secret 来进行对称加密通信,因此这里的加密算法显得尤为重要,基本上协商ssl之后的过程中一直会使用这个算法在进行加密和解密。目前采用的大部分是AES 128位密钥的方式,但是在某些不支持硬件AES加速的处理器上,性能还是有一定的限制
另一种加密方式是 chacha20.
ChaCha20-Poly1305是Google所采用的一种新式加密算法,性能强大,在CPU为精简指令集的ARM平台上尤为显著(ARM v8前效果较明显),在同等配置的手机中表现是AES的4倍(ARM v8之后加入了AES指令,所以在这些平台上的设备,AES方式反而比chacha20-Poly1305方式更快,性能更好),可减少加密解密所产生的数据量进而可以改善用户体验,减少等待时间,节省电池寿命等。
因此作为一个可选的方案,chacha20 可能对于一些老旧的机型(据连荣讲,还有很多在使用arm v7 的硬件),chacha20 更具优势。
服务端优化
服务端的优化有几个方向
规避完全握手
优化加密效率
优化证书验证流程
因为针对的是ssl 服务端优化,所以下面结合我们常用的http server Nginx(Tenginx)来详细的讨论下优化点
规避完整握手
服务端规避完全握手也是通过回复会话的方式,但是对于如何成功命中Session ID恢复会话,有两个点:
开启 session ticket
配置session cache
对于1来说,服务端基本都会开启。对于nginx来说,session ticket 默认就是开启的状态。
session cache 这里就会涉及到很多问题。当前互联网场景下,大部分web服务采取了分布式的服务方式。如何共享session cache 使得经过负载均衡的请求无论落到哪个节点都可以命中cache 就是我们的一个目标。限于篇幅和验证的目的,这里就不做过多的展开。附带一篇文章可以了解
在这里我们先配置session cache 参数和cache 过期时间。确保单机可以命中cache
优化加密效率
第一个阶段是我们ssl 握手中的重点阶段,根据资料,密钥协商阶段基本占据了90%的时间。
在没有办法规避完全握手的时候,我们要尝试进行算法的优化。目前来看可以采用的非对称加密方式大约有以下的选择:
* RSA:算法实现简单,诞生于1977年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数(目前常用的是2048位)来保证安全强度,很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
* DH:diffie-hellman密钥交换算法,诞生时间比较早(1977年),但是1999年才公开。缺点是比较消耗CPU性能。
* ECDHE:使用椭圆曲线(ECC)的DH算法,优点是能用较小的素数(256位)实现RSA相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,没有经过长时间的安全攻击测试。
* ECDH:不支持PFS,安全性低,同时无法实现false start。
针对业内的选择,大部分是使用RSA加密的方式+椭圆曲线优化的DH加密
百度的加密算法:TLS_ECDHE_RAS_WITH_AES_128_GCM_SHA256,128位秘钥 TLS1.2
google的加密算法:TLS_ECDHE_RAS_WITH_AES_128_GCM_SHA256,128位秘钥 TLS1.2
因此我们可优化的空间不太大,目前来看有两个优化点:
针对椭圆曲线,选择更高效优化过的曲线模型。调优openssl 编译参数。
采用硬件加速的方式来优化,这就涉及到采用加速卡或专门硬件。
优化证书验证 OCSP
证书验证是客户端验证服务端的过程。
通常服务端会发送site的证书,这个证书是由可信机构签发的。clent在认证这个证书的时候,会先向可信机构查询站点证书的上一级中间证书的权威。然后再查询中间证书对应的根证书的权威。这个过程就是证书链查询
OCSP 是server 把自己的站点证书和中间证书以及根证书打包一起下发到客户端,省去客户端查询的过程。
测试中,我们使用了域名 varycloud.com ,这个域名对应申请了symentic证书。我们生成了相关的证书链。
测试
测试方案
采用压力测试的方式,对比不同配置下,相同压力服务端的服务能力和延迟表现。
服务端配置
CPU Info E5 6核心 12线程(超线程)
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
stepping : 4
microcode : 0x428
cpu MHz : 1331.367
cache size : 15360 KB
RAM 8G * 2
Array Handle: 0x0032
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: DIMM_A1
Bank Locator: DIMM_A1
Type: DDR3
Type Detail: Registered (Buffered)
Speed: 1333 MHz
Manufacturer: Kingston
Serial Number: 43153456
Asset Tag: DIMM_A1_AssetTag
Part Number: 9965433-091.A00
NCI 万兆网卡
Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Link detected: yes
测试服务器 版本
nginx version: nginx/1.10.2
压测工具 wrk
wrk 是一款压测工具,基于c开发
https://github.com/wg/wrk
测试使用 24线程 保持24链接 压测1分钟获得数据
nginx 配置
server {
listen 443 ssl;
server_name varycloud.com;
access_log off;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
# session tacket session cache option
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
ssl_session_ticket_key tls_session_ticket.key;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
# ssl_dhparam /path/to/dhparam.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# 认证证书链
# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
resolver 114.114.114.114 8.8.8.8 8.8.4.4 223.5.5.5 valid=300s;
resolver_timeout 5s;
ssl_trusted_certificate chain.pem;
location / {
root html;
index index.html index.htm;
}
基准测试过程
测试使用是
172.16.200.11(client)
172.16.200.21(server)
两台机器之间延迟大约在 0.2ms 左右
64 bytes from 172.16.200.21: icmp_seq=1 ttl=64 time=0.186 ms
64 bytes from 172.16.200.21: icmp_seq=2 ttl=64 time=0.229 ms
64 bytes from 172.16.200.21: icmp_seq=3 ttl=64 time=0.204 ms
原始数据
针对未开启任何优化的测试数据,作为对比的基础。对于请求主动关闭这种情况测试了两次
不主动关闭链接
./wrk -c 24 -t 24 -d 3m https://varycloud.com
Running 3m test @ https://varycloud.com
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 0.92ms 3.07ms 170.27ms 96.54%
Req/Sec 1.73k 248.31 2.64k 69.64%
7448946 requests in 3.00m, 2.25GB read
Non-2xx or 3xx responses: 7448946
Requests/sec: 41360.72
Transfer/sec: 12.78MB
每次请求链接关闭
./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com
Running 3m test @ https://varycloud.com
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 4.76ms 8.34ms 174.25ms 97.01%
Req/Sec 51.91 10.48 90.00 69.50%
223479 requests in 3.00m, 67.99MB read
Non-2xx or 3xx responses: 223479
Requests/sec: 1240.95
Transfer/sec: 386.58KB
开启session ticket 和 session cache
./wrk -c 24 -t 24 -d 3m https://varycloud.com
Running 3m test @ https://varycloud.com
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 468.71us 2.69ms 160.11ms 99.67%
Req/Sec 2.60k 343.14 3.50k 71.52%
11189348 requests in 3.00m, 3.38GB read
Non-2xx or 3xx responses: 11189348
Requests/sec: 62148.92
Transfer/sec: 19.20MB
./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com
Running 3m test @ https://varycloud.com
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.71ms 10.17ms 165.85ms 98.78%
Req/Sec 360.06 53.23 545.00 82.35%
1544216 requests in 3.00m, 469.78MB read
Non-2xx or 3xx responses: 1544216
Requests/sec: 8574.25
Transfer/sec: 2.61MB
相比基准数据 提升大约 49% 和 64%
开启ECDH + session ticket
./wrk -c 24 -t 24 -d 3m https://varycloud.com
Running 3m test @ https://varycloud.com
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 405.62us 558.95us 37.73ms 97.87%
Req/Sec 2.61k 349.92 3.57k 71.27%
11200203 requests in 3.00m, 3.38GB read
Non-2xx or 3xx responses: 11200203
Requests/sec: 62206.96
Transfer/sec: 19.22MB
./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com
Running 3m test @ https://varycloud.com
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.28ms 7.68ms 166.22ms 99.27%
Req/Sec 361.23 46.59 545.00 79.26%
1549916 requests in 3.00m, 471.52MB read
Non-2xx or 3xx responses: 1549916
Requests/sec: 8606.01
Transfer/sec: 2.62MB
相比基准数据 提升大约 56% 和 72.9%
相比开启 session ticket 提升大约 13.4% 和 25.1%
开启OCSP + session ticket
./wrk -c 24 -t 24 -d 3m https://varycloud.com
Running 3m test @ https://varycloud.com
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 538.57us 3.79ms 162.60ms 99.62%
Req/Sec 2.61k 369.00 3.55k 74.30%
11219121 requests in 3.00m, 3.38GB read
Non-2xx or 3xx responses: 11219121
Requests/sec: 62318.07
Transfer/sec: 19.25MB
./wrk -c 24 -t 24 -d 3m -H "Connection: Close" https://varycloud.com
Running 3m test @ https://varycloud.com
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 0.91ms 4.58ms 162.55ms 99.61%
Req/Sec 368.12 40.66 540.00 74.09%
1582284 requests in 3.00m, 481.37MB read
Non-2xx or 3xx responses: 1582284
Requests/sec: 8785.82
Transfer/sec: 2.67MB
相比基准数据 提升大约 41% 和 80%
相比开启session ticket后的数据 提升大约 -14.8% 和 46.8%
测试中资源消耗变化图
cpu 资源变化图 从左至右对应4种测试情况:
raw, session ticket, ECDH + session ticket , OCSP + session ticket
这里写图片描述
对于session ticket命中,cpu消耗降低了很多
网络消耗如下
这里写图片描述
由于session ticket 命中,节约了cpu计算资源,因此服务能力有了提升,贷款增加明显
测试总结
数据已经能很明确的说明问题了,简单总结下:
session ticket 可以简化握手,更重要的是,减少了服务端的计算量,如果能命中并且复用session ticket,会有很大的优化
ECDH 对于生成密钥有提升,而且消耗的资源并不太明显
OCSP 测试中有一定的抖动,但是总体趋向于降低了时延
疑惑
测试过程中,出现了一定的抖动。每次测试的结果都有一定的抖动,这个是困惑的点,还没有找到原因

继续阅读
广告也精彩
Google的三驾马车:都有优势,也难掩缺憾 php教程

Google的三驾马车:都有优势,也难掩缺憾

Google本身已经成功超越任何合理的设定,成为全世界人民所拥有的互联网入口(中国?)。Google提供给互联网用户的价值是巨大而难以估算的。而它提供给营销团队(卖主)的服务则是可量化的。Google...
Google又把事搞砸了 产品运营

Google又把事搞砸了

从CES(国际消费类电子产品展览会 International Consumer Electronics Show)的进展来看,Google现在确实在把语音交互这事儿搞砸,而越来越变成一家很能折腾但不...
如何构建一个便捷高效的App消息列表? 产品设计

如何构建一个便捷高效的App消息列表?

因地制宜,才能设计出一个便捷高效的消息列表。 消息列表的主要目的在于使用户获取消息,并完成处理,不同的软件对于消息的要求也不尽相同。即时通信类软件在于使用户尽可能快的获取和处理信息,同时保证私密性。资...
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: