京东数科七层负载 | HTTPS硬件加速 (Freescale加速卡篇)

京东数科JDDLB作为京东数科最重要的公网流量入口，承接了很多重要业务的公网流量。目前，已完全接替商业设备F5承载所有的流量，并在数次618、双十一大促中体现出优越的功能、性能优势。

一、京东数科JDDLB 整体架构

图1 京东数科JDDLB 整体架构

JDDLB 整体架构的核心包括：基于DPDK自主研发的四层负载SLB，定制开发扩展功能的NGINX，以及统一管控运维平台。其主要特点为：

• 高性能：具备千万级并发和百万级新建能力。
• 高可用 ：通过 ECMP、会话同步、健康检查等，提供由负载本身至业务服务器多层次的高可用。
• 可拓展：支持四层/七层负载集群、业务服务器的横向弹性伸缩、灰度发布。
• 四层负载能力：通过ospf 向交换机宣告vip；支持 ECMP、session 同步；支持均衡算法如轮询、加权轮询、加权最小连接数、优先级、一致性哈希；FullNAT转发模式方便部署；等等。
• 七层负载能力：支持基于域名和URL的转发规则配置；支持均衡算法如轮询、基于源 IP 哈希、基于cookie；等等。
• SSL/TLS能力：证书、私钥、握手策略的管理配置；支持 SNI 配置；支持基于多种加速卡的SSL卸载硬件加速；等等。
• 流量防控：提供一定的 Syn-Flood 防护能力；与应用防火墙结合后提供 WAF 防护能力；提供网络流量控制手段如 Qos 流控、ACL 访问控制；等等。
• 管控平台：支持多种维度的网络和业务指标监控和告警。

此外，借助于JDDLB现有能力特性，方便扩展其他新功能。例如，借助于NGINX的SSL/TLS硬件优化性能以及连接高并发处理能力，可以实现基于MQTT协议的、支持SSL/TLS协议、安全的推送长连接网关等。

本文针对JDDLB中七层负载的SSL/TLS性能优化方法之一——将耗CPU计算资源的加解密算法计算卸载到Freescale加速卡——进行概述性介绍。

二、本优化方案性能提升对比

本优化方案，通过NGINX进行HTTPS新建速率实测，与软件加解密场景做对比：

• 使用单加速卡，平均新建速率提升130%，且CPU利用率降低40%。
• 使用双加速卡，平均新建速率提升320%。

表1 性能提升对比

使用WRK性能压测工具作为HTTPS Client，在同一物理机上部署NGINX和加速卡，分别测试软件加解密、单加速卡卸载、双加速卡卸载场景下HTTPS平均新建速率：

• 使用OpenSSL软件加解密，不断增加WRK数量，直到CPU-idle接近于0%，CPU无法及时处理新连接请求，此时CPU达到瓶颈，可认为软件加解密的最大新建能力。
• 使用单加速卡卸载，不断增加WRK数量，直到出现硬件请求队列入队失败，此时可认为使用单加速卡正常工作时的新建能力，避免入队失败走软解导致CPU性能快速消耗。使用加速卡时，加解密请求入队失败后会进行软件加解密，不影响SSL/TLS协议处理。
• 使用双加速卡卸载，不断增加WRK数量，直到CPU-idle接近于0%，CPU无法及时处理新连接请求，此时CPU已到达瓶颈，并不是双加速卡的最大性能。

本优化方案所带来的性能提升主要依赖于：

• 采用定制开发的PCI加速卡，每个PCI卡上集成3~4个Freescale C291处理器，作为主CPU外的协处理器，处理耗时的加解密等计算。
• 驱动支持多加速卡同时进行卸载加速。
• 定制开发FSL Engine，通过OpenSSL Engine机制将FSL 硬件加解密计算能力集成到OpenSSL加密库中。
• NGINX采用异步模式调用OpenSSL API，代替传统的同步模式调用。

下面，本文会先介绍SSL/TLS协议的一些基本概念。在理解SSL/TLS基本概念基础上，分析SSL/TLS协议哪个环节存在性能问题。为了优化性能，介绍OpenSSL-API/OpenSSL-Engine/加速卡驱动程序的同步模式、异步模式，以及两种模式下各自对性能的提升。最后，介绍FSL加速卡驱动程序概览，了解驱动的基本流程。

三、SSL/TLS基本概念

图2 HTTP vs HTTPS

HTTPS简单理解成HTTP over SSL/TLS。客户端和服务端在使用HTTPS传输业务数据前，首先由SSL/TLS协议在两端之间建立安全信道（这个过程称作握手协商阶段），然后在该安全信道上对HTTP业务报文进行加密传输（这个过程称作加密数据传输阶段）。SSL/TLS的安全性体现在哪里，解决了哪些安全问题，如何解决的，下面一步步介绍。这里，先了解下客户端和服务端之间使用明文HTTP通信存在的安全问题。

图3 HTTP安全问题及HTTP到HTTPS的改造

关于HTTP协议的明文数据传输，攻击者最常用的攻击手法就是网络嗅探，试图从传输过程的数据包中分析出敏感的数据，例如，管理员对Web程序后台的登录过程，用户的隐秘信息如手机号码、身份证号码、信用卡号等重要资料，导致严重的安全事故。

HTTP协议在传输客户端请求和服务端响应时，唯一的数据完整性检验就是在报文头部包含了本次传输数据的长度，而对内容是否被篡改不作确认。因此攻击者可以轻易的发动中间人攻击，修改客户端和服务端传输的数据，甚至在传输数据中插入恶意代码，导致客户端被引导至恶意网站被植入木马。

SSL/TLS协议通过数字证书、非对称密钥、对称加密算法、消息验证码算法等技术，实现了通信双方的身份验证、数据传输加密、防篡改等安全保护措施，其主要目标是：

• 数据保密性：保证数据内容在传输的过程中不会被第三方查看，防止用户数据信息的泄漏。
• 数据完整性：及时发现被第三方篡改的传输内容，一旦发现数据被篡改过则拒绝接收。
• 身份校验安全性：保证数据到达用户期望的目的地。客户端需要验证目前正在通信的对端是否为期望的服务器，而非假冒的服务器。反之，服务器也可以对客户端进行有效性验证。

1、数据保密性

HTTPS中，数据保密性指对客户端和服务端传输的HTTP明文数据进行加密传输。使用的算法为对称加密算法，如AES。数据保密性实现流程如下图：

图4 数据保密性实现流程

数据保密性需要通信双方具有相同的密钥，而且这个密钥只能通信双方知道，不能被第三方获取。实际通信中，这个密钥并不是固定不变的，也不会保存到磁盘文件中。客户端每次和服务器建立新连接的时候，都会重新协商出相同的密钥。在SSL/TLS协议的第一阶段——握手协商阶段，服务器和客户端会交互一些报文信息，服务器和客户端根据报文中的信息各自生成