标签：大量 环境 href 信息 nta 对比 私钥 服务 分析
一、前言
通常的http访问会遭到中间人攻击、网络嗅探等普通用户感知不到的恶意行为，这些行为会篡改用户浏览页面引导用户访问非法网站、抓取用户的上网行为以及个人信息、严重的会造成用户的个人资产损失。https由于采用了从用户端浏览器和网站服务端的证书加密认证机制，在信息的整个传输过程中都是以加密形式存在的，因而采用https可以解决http访问中所遭遇的中间人攻击、网络嗅探等问题。所以，目前大多数公司都将网站由http向https迁移，保护用户信息的安全。在进行https改造的过程中会遇到各种各样的问题，本人在infoq的网站上阅读了三篇有关BAT网站https的经历文章，下面就跟大家一起分享下，（如本人分享内容有错误、不足之处还请大家指出。）
二、博文整理
百度：
- 挑战：https相比于http，加解密需要的计算资源大量增加，导致同样的服务器从http切换到https后，QPS只能达到之前的10-20%。
解决方案：通过分析对比https与http连接耗时，发现https新建加密（非对称）连接握手时最消耗性能。采用https连接复用（session cache等方法）、专门设计的硬件加密卡（FPGA）来专门处理加解密操作，降低CPU的负载压力提升系统QPS。
- 挑战：因为https中不能包含http流量，因此需要全站https
解决方案：全站使用https可以保证网站的安全、用户数据的安全，还可以为将来向http2迁移做准备（http2基于https）。但是由于网站中很多地方引用外部的http资源，因此需要与各个部门沟通配合迁移（沟通、整合成本高）
腾讯：
- 当前网络中http与https的份额是6:4，原因主要是：https速度慢（未经任何优化）、证书申请成本高（流程复杂、花钱购买高级别证书）。因此，https迁移的主要关注点就是：1、运用多种技术手段提升https的速度，优化用户体验；2、降低证书申请的成本
- 挑战：https加密涉及到多种加密算法（非对称加密、对称加密、签名算法、一致性校验算法等）
解决方案：1、重点关注业界加密算法的动态，采用开源+自研组合的方式提升加密算法的性能；2、修改加密算法的调用方式，将加解密相关代码与其余代码解耦，然后利用专门设计的硬件加密卡（或者其他地方富余的GPU、CPU计算资源）来进行相关的加解密计算。
- 挑战：通常情况下采用完全握手的https连接方式的性能甚至不如http协议性能的10%
解决方案：采用session方案，通过减少https握手次数实现https性能的提升。具体做法：
- 分布式session cache：nginx集群将产生的session cache统一存储到后端同一个redis集群中，利用redis集群实现了nginx集群的session cache共享。
- 由于session cache会消耗大量内存，因此出现了将session 信息加密存储到用户设备的内存中，用户将加密的session信息发送到nginx集群，nginx利用保存的key来解密session，最终实现了session机制。可以将用户内存中加密的session信息写入磁盘，这样可以解决浏览器意外重启、app异常、网络切换等等问题导致的session丢失的问题；同时服务端将session 的key统一保存到redis集群中，或者一个集群采用同一个key来解决负载均衡带来的加解密失败的问题。
- 挑战：当用户网站位于多个云、CDN上面时，如果每个地方都部署一个私钥，可能会因为一个位置的私钥泄露引发整个网站的安全问题
解决方案：将私钥保存到某个位置，然后提供接口供相关服务调用，这样只需要保证私钥所在服务器的安全即可。
阿里：
- 挑战：淘宝、天猫、聚划算入口下有非常多的子项目，这些项目都在采用不同的网络架构为用户提供服务
解决方案：如果各个项目自己进行https改造，这样会给后期升级改造增加很多工作量，同时进度也不好把控。在用户端和网站服务器间添加统一的SSL/TLS加密层，由集团运维统一负责。
解决方案：1、将http://改成//（标准协议的一种），服务端判断有无https，如果有的话就采用https否则就用http；但是，//协议虽然是标准协议，但是由于用户少，所以主流语言框架支持较差，在linux等环境中甚至还有可能出现歧义。2、利用Tengine（nginx的一种变体）的sub_filter模块，将http替换成https，这种方式需要添加对应的正则表达式规则，但是随着正则表达数的增多，nginx的性能会下降。
解决方案：1. 减少https常规的完全握手次数：session cache、session ticket、TCP keepalive、SPDY3.1 & HTTP2协议（增加https多路复用，有效减少新建连接数）； 2. 合并域名（TLS新建连接成本高）； 3. Flase Start 采用1-RTT建连，降低握手成本； 4. CDN动态加速、前段预加速； 5. 采用ECDSA
三、个人总结
在阅读了BAT三家大厂的https迁移、优化的经历，发现在技术方面还是存在很多通用的解决方案的，以后在进行http到https迁移的时候可以借鉴相关经验。
- 采用session ticket来实现http状态保持。
- nginx集群+redis 实现分布式共享内存的方案。
- 解耦加解密模块，利用定制的硬件加密卡或者别处空闲的CPU、GPU资源来执行加解密操作，然后常规代码异步调用加解密模块，降低http服务器的cpu压力，提示QPS。
- 使用SPDY、HTTP2 等支持多路复用的协议来降低TLS建连的次数。
- 利用Flase Start的1-RTT建连，降低TLS握手次数。
- CDN动态加速、预建连接，提升用户体验
- 优化加解密算法
案例分析——BAT业务https化经历
标签：大量 环境 href 信息 nta 对比 私钥 服务 分析
原文地址：http://www.cnblogs.com/sxhlinux/p/7599673.html
