CSDN:Https优化方案与测试结果 背景 https是基于http和ssl(安全套接字层)的安全传输协议,使用ssl协议作为会话层协议。这个协议最早是由网景公司开发,但是随着网景的没落,现在由ietf负责维护,最初的版本也已经重新冠名(rebanded)tls(安全传输层协议)1。0(1999年)。因此现在大部分协议是基于TLS的,尽管是相似的东西。 针对https,能够保证数据更加安全,但是副作用是访问会变慢(相对于http),因为服务端增加了更多的计算,客户端和服务端之间多了一层协议协商过程。因此,我们要做的优化主要是针对这里 优化点和优化方案 大概阐述了优化的几个方向,下面我来具体的展开讨论下。如有疏漏请指正。 同时,我也整理了一份针对https的握手过程详解,可以帮助大家科普下。 客户端优化 客户端优化是针对发起sslclienthello的一端进行的优化。主要有两个大的方向: 减少请求次数,提高效率 优化加密效率 规避完整握手 针对减少请求次数,主要的一个点是SSLSession的复用,ClientHello请求中的SessionID可以唯一的区分一个ssl会话的ID。这个ID在ClientSayHello的时候被填写, 如果是第一次与server发生会话,那么SessionID可以是空。如果之前与ssl服务器建立过会话,而且客户端开启了SessionTicket;并且Servercache了这个SessionTicket的时候,服务端与客户端的握手就会简化,省略掉premaster交换的过程,直接复用之前的ssl会话 优化加密效率 这里是一个比较复杂的点,我们先来看下有哪些过程可能耗时: 密钥协商阶段的非对称加密 协商过后的针对通信的对称加密 协商密钥阶段 密钥协商过程中,客户端的计算量相对小: 生成random1 生成premaster(填充过的随机数) 根据服务端的random2和自己的random1还有premaster生成mastersecret 使用服务端通知的(经过验证的)公钥加密premaster 这个过程中大部分是在生成随机数,只有生成mastersecret和使用公钥加密是消耗cpu的。 加密通信阶段 再看下ssl协商之后的过程中的加密方式,因为是采用之前协商后的secret来进行对称加密通信,因此这里的加密算法显得尤为重要,基本上协商ssl之后的过程中一直会使用这个算法在进行加密和解密。目前采用的大部分是AES128位密钥的方式,但是在某些不支持硬件AES加速的处理器上,性能还是有一定的限制 另一种加密方式是chacha20。 ChaCha20Poly1305是Google所采用的一种新式加密算法,性能强大,在CPU为精简指令集的ARM平台上尤为显著(ARMv8前效果较明显),在同等配置的手机中表现是AES的4倍(ARMv8之后加入了AES指令,所以在这些平台上的设备,AES方式反而比chacha20Poly1305方式更快,性能更好),可减少加密解密所产生的数据量进而可以改善用户体验,减少等待时间,节省电池寿命等。 因此作为一个可选的方案,chacha20可能对于一些老旧的机型(据连荣讲,还有很多在使用armv7的硬件),chacha20更具优势。 服务端优化 服务端的优化有几个方向 规避完全握手 优化加密效率 优化证书验证流程 因为针对的是ssl服务端优化,所以下面结合我们常用的httpserverNginx(Tenginx)来详细的讨论下优化点 规避完整握手 服务端规避完全握手也是通过回复会话的方式,但是对于如何成功命中SessionID恢复会话,有两个点: 开启sessionticket 配置sessioncache 对于1来说,服务端基本都会开启。对于nginx来说,sessionticket默认就是开启的状态。 sessioncache这里就会涉及到很多问题。当前互联网场景下,大部分web服务采取了分布式的服务方式。如何共享sessioncache使得经过负载均衡的请求无论落到哪个节点都可以命中cache就是我们的一个目标。限于篇幅和验证的目的,这里就不做过多的展开。附带一篇文章可以了解 在这里我们先配置sessioncache参数和cache过期时间。确保单机可以命中cache 优化加密效率 第一个阶段是我们ssl握手中的重点阶段,根据资料,密钥协商阶段基本占据了90的时间。 在没有办法规避完全握手的时候,我们要尝试进行算法的优化。目前来看可以采用的非对称加密方式大约有以下的选择: RSA:算法实现简单,诞生于1977年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数(目前常用的是2048位)来保证安全强度,很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。 DH:diffiehellman密钥交换算法,诞生时间比较早(1977年),但是1999年才公开。缺点是比较消耗CPU性能。 ECDHE:使用椭圆曲线(ECC)的DH算法,优点是能用较小的素数(256位)实现RSA相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,没有经过长时间的安全攻击测试。 ECDH:不支持PFS,安全性低,同时无法实现falsestart。 针对业内的选择,大部分是使用RSA加密的方式椭圆曲线优化的DH加密 百度的加密算法:TLSECDHERASWITHAES128GCMSHA256,128位秘钥TLS1。2 google的加密算法:TLSECDHERASWITHAES128GCMSHA256,128位秘钥TLS1。2 因此我们可优化的空间不太大,目前来看有两个优化点: 针对椭圆曲线,选择更高效优化过的曲线模型。调优openssl编译参数。 采用硬件加速的方式来优化,这就涉及到采用加速卡或专门硬件。 优化证书验证OCSP 证书验证是客户端验证服务端的过程。 通常服务端会发送site的证书,这个证书是由可信机构签发的。clent在认证这个证书的时候,会先向可信机构查询站点证书的上一级中间证书的权威。然后再查询中间证书对应的根证书的权威。这个过程就是证书链查询 OCSP是server把自己的站点证书和中间证书以及根证书打包一起下发到客户端,省去客户端查询的过程。 测试中,我们使用了域名varycloud。com,这个域名对应申请了symentic证书。我们生成了相关的证书链。 测试 测试方案 采用压力测试的方式,对比不同配置下,相同压力服务端的服务能力和延迟表现。 服务端配置 CPUInfoE56核心12线程(超线程) vendorid:GenuineIntel cpufamily:6 model:62 modelname:Intel(R)Xeon(R)CPUE52620v22。10GHz stepping:4 microcode:0x428 cpuMHz:1331。367 cachesize:15360KB RAM8G2 ArrayHandle:0x0032 ErrorInformationHandle:NotProvided TotalWidth:72bits DataWidth:64bits Size:8192MB FormFactor:DIMM Set:None Locator:DIMMA1 BankLocator:DIMMA1 Type:DDR3 TypeDetail:Registered(Buffered) Speed:1333MHz Manufacturer:Kingston SerialNumber:43153456 AssetTag:DIMMA1AssetTag PartNumber:9965433091。A00 NCI万兆网卡 Ethernetcontroller:IntelCorporation82574LGigabitNetworkConnection Advertisedpauseframeuse:No Advertisedautonegotiation:Yes Speed:1000Mbs Duplex:Full Port:TwistedPair PHYAD:1 Transceiver:internal Autonegotiation:on MDIX:off(auto) SupportsWakeon:pumbg Wakeon:g Linkdetected:yes 测试服务器版本 nginxversion:nginx1。10。2 压测工具wrk wrk是一款压测工具,基于c开发 https:github。comwgwrk 测试使用24线程保持24链接压测1分钟获得数据 nginx配置 server{ listen443ssl; servernamevarycloud。com; accesslogoff; sslcertificatecert。pem; sslcertificatekeycert。key; sessiontacketsessioncacheoption sslsessiontimeout1d; sslsessioncacheshared:SSL:50m; sslsessionticketson; sslsessionticketkeytlssessionticket。key; DiffieHellmanparameterforDHEciphersuites,recommended2048bits ssldhparampathtodhparam。pem; sslprotocolsTLSv1TLSv1。1TLSv1。2; sslciphersECDHERSAAES256SHA384:AES256SHA256:RC4:HIGH:!aNULL:!MD5; sslpreferservercipherson; HSTS(ngxhttpheadersmoduleisrequired)(15768000seconds6months) addheaderStrictTransportSecuritymaxage15768000; 认证证书链 OCSPStapling fetchOCSPrecordsfromURLinsslcertificateandcachethem sslstaplingon; sslstaplingverifyon; resolver114。114。114。1148。8。8。88。8。4。4223。5。5。5valid300s; resolvertimeout5s; ssltrustedcertificatechain。pem; location{ roothtml; indexindex。htmlindex。htm; } 基准测试过程 测试使用是 172。16。200。11(client) 172。16。200。21(server) 两台机器之间延迟大约在0。2ms左右 64bytesfrom172。16。200。21:icmpseq1ttl64time0。186ms 64bytesfrom172。16。200。21:icmpseq2ttl64time0。229ms 64bytesfrom172。16。200。21:icmpseq3ttl64time0。204ms 原始数据 针对未开启任何优化的测试数据,作为对比的基础。对于请求主动关闭这种情况测试了两次 不主动关闭链接 。wrkc24t24d3mhttps:varycloud。com Running3mtesthttps:varycloud。com 24threadsand24connections ThreadStatsAvgStdevMaxStdev Latency0。92ms3。07ms170。27ms96。54 ReqSec1。73k248。312。64k69。64 7448946requestsin3。00m,2。25GBread Non2xxor3xxresponses:7448946 Requestssec:41360。72 Transfersec:12。78MB 每次请求链接关闭 。wrkc24t24d3mHConnection:Closehttps:varycloud。com Running3mtesthttps:varycloud。com 24threadsand24connections ThreadStatsAvgStdevMaxStdev Latency4。76ms8。34ms174。25ms97。01 ReqSec51。9110。4890。0069。50 223479requestsin3。00m,67。99MBread Non2xxor3xxresponses:223479 Requestssec:1240。95 Transfersec:386。58KB 开启sessionticket和sessioncache 。wrkc24t24d3mhttps:varycloud。com Running3mtesthttps:varycloud。com 24threadsand24connections ThreadStatsAvgStdevMaxStdev Latency468。71us2。69ms160。11ms99。67 ReqSec2。60k343。143。50k71。52 11189348requestsin3。00m,3。38GBread Non2xxor3xxresponses:11189348 Requestssec:62148。92 Transfersec:19。20MB 。wrkc24t24d3mHConnection:Closehttps:varycloud。com Running3mtesthttps:varycloud。com 24threadsand24connections ThreadStatsAvgStdevMaxStdev Latency1。71ms10。17ms165。85ms98。78 ReqSec360。0653。23545。0082。35 1544216requestsin3。00m,469。78MBread Non2xxor3xxresponses:1544216 Requestssec:8574。25 Transfersec:2。61MB 相比基准数据提升大约49和64 开启ECDHsessionticket 。wrkc24t24d3mhttps:varycloud。com Running3mtesthttps:varycloud。com 24threadsand24connections ThreadStatsAvgStdevMaxStdev Latency405。62us558。95us37。73ms97。87 ReqSec2。61k349。923。57k71。27 11200203requestsin3。00m,3。38GBread Non2xxor3xxresponses:11200203 Requestssec:62206。96 Transfersec:19。22MB 。wrkc24t24d3mHConnection:Closehttps:varycloud。com Running3mtesthttps:varycloud。com 24threadsand24connections ThreadStatsAvgStdevMaxStdev Latency1。28ms7。68ms166。22ms99。27 ReqSec361。2346。59545。0079。26 1549916requestsin3。00m,471。52MBread Non2xxor3xxresponses:1549916 Requestssec:8606。01 Transfersec:2。62MB 相比基准数据提升大约56和72。9 相比开启sessionticket提升大约13。4和25。1 开启OCSPsessionticket 。wrkc24t24d3mhttps:varycloud。com Running3mtesthttps:varycloud。com 24threadsand24connections ThreadStatsAvgStdevMaxStdev Latency538。57us3。79ms162。60ms99。62 ReqSec2。61k369。003。55k74。30 11219121requestsin3。00m,3。38GBread Non2xxor3xxresponses:11219121 Requestssec:62318。07 Transfersec:19。25MB 。wrkc24t24d3mHConnection:Closehttps:varycloud。com Running3mtesthttps:varycloud。com 24threadsand24connections ThreadStatsAvgStdevMaxStdev Latency0。91ms4。58ms162。55ms99。61 ReqSec368。1240。66540。0074。09 1582284requestsin3。00m,481。37MBread Non2xxor3xxresponses:1582284 Requestssec:8785。82 Transfersec:2。67MB 相比基准数据提升大约41和80 相比开启sessionticket后的数据提升大约14。8和46。8 测试中资源消耗变化图 cpu资源变化图从左至右对应4种测试情况: raw,sessionticket,ECDHsessionticket,OCSPsessionticket 这里写图片描述 对于sessionticket命中,cpu消耗降低了很多 网络消耗如下 这里写图片描述 由于sessionticket命中,节约了cpu计算资源,因此服务能力有了提升,贷款增加明显 测试总结 数据已经能很明确的说明问题了,简单总结下: sessionticket可以简化握手,更重要的是,减少了服务端的计算量,如果能命中并且复用sessionticket,会有很大的优化 ECDH对于生成密钥有提升,而且消耗的资源并不太明显 OCSP测试中有一定的抖动,但是总体趋向于降低了时延 疑惑 测试过程中,出现了一定的抖动。每次测试的结果都有一定的抖动,这个是困惑的点,还没有找到原因