Netty SSL性能调优
TLS算法组合
在TLS中,5类算法组合在一起,称为一个CipherSuite:
认证算法
加密算法
消息认证码算法 简称MAC
密钥交换算法
密钥衍生算法
比较常见的算法组合是 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 和 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 都是ECDHE 做密钥交换,使用RSA做认证,SHA256做PRF算法。
一个使用AES128-CBC做加密算法,用HMAC做MAC。
一个使用AES128-GCM做加密算法,MAC由于GCM作为一种AEAD模式并不需要。
SSL协议的握手过程
第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。
第二步,鲍勃确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。
第三步,爱丽丝确认数字证书(对证书信息进行md5或者hash后的编号==用证书机构的公钥对加密的证书编号解密后的证书编号)有效,然后生成一个新的随机数(Premaster secret),并使用数字证书中的公钥(鲍勃的公钥),加密这个随机数,发给鲍勃。
第四步,鲍勃使用自己的私钥,获取爱丽丝发来的随机数(即Premaster secret)。
第五步,爱丽丝和鲍勃根据约定的加密方法,使用前面的三个随机数,生成"对话密钥"(session key),用来加密接下来的整个对话过程。
https要使客户端与服务器端的通信过程得到安全保证,必须使用对称加密算法并且每个客户端的算法都不一样,需要一个协商过程,但是协商对称加密算法的过程,需要使用非对称加密算法来保证安全,直接使用非对称加密的过程本身也不安全,会有中间人篡改公钥的可能性,所以客户端与服务器不直接使用公钥,而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法,就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。
Java 对SSL的支持
JDK7的client端只支持TLS1.0,服务端则支持TLS1.2。
JDK8完全支持TLS1.2。
JDK7不支持GCM算法。
JDK8支持GCM算法,但性能极差极差极差,按Netty的说法:
Java 8u60以前多版本,只能处理1 MB/s。
Java 8u60 开始,10倍的性能提升,10-20 MB/s。
但比起 OpenSSL的 ~200 MB/s,还差着一个量级。
Netty 对SSL的支持
Netty既支持JDK SSL,也支持Google的boringssl, 这是OpenSSL 的一个fork,更少的代码,更多的功能。
依赖netty-tcnative-boringssl-static-linux-x86_64.jar即可,它里面已包含了相关的so文件,再也不用管Linux里装没装OpenSSL,OpenSSL啥版本了。
性能问题的出现
JDK7的JMeter HTTPS客户端,连接JDK8的Netty服务端时,速度还可以。
JDK8的JMeter HTTPS客户端,则非常慢,非常慢,非常吃客户端的CPU。
按套路,在JMeter端增加启动参数 -Djavax.net.debug=ssl,handshake debug 握手过程。
(OpenSSL那边这个参数加了没用)
*** ClientHello, TLSv1.2,可以看到,Client端先发起协商,带了一堆可选协议
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256…]
*** ServerHello, TLSv1.2 然后服务端回选定一个
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
还可以看到,传输同样的数据,不同客户端/服务端组合下有不同的纪录:
Client: JDK7 JDK SSL + Server: JDK7/8 JDK SSL
**TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
WRITE: TLSv1 Application Data, length = 32
WRITE: TLSv1 Application Data, length = 304
READ: TLSv1 Application Data, length = 32
READ: TLSv1 Application Data, length = 96
READ: TLSv1 Application Data, length = 32
READ: TLSv1 Application Data, length = 10336
Client: JDK8 JDK SSL + Server: JDK8 Open SSL
** TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Thread Group 1-1, WRITE: TLSv1.2 Application Data, length = 300
Thread Group 1-1, READ: TLSv1.2 Application Data, length = 92
Thread Group 1-1, READ: TLSv1.2 Application Data, length = 10337
原因分析
JMeter Https 用的是JDK8 SSL,很不幸的和服务端的OpenSSL协商出一个JDK8实现超慢的TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。
对于服务端/客户端都是基于Netty + boringssl的RPC框架,使用TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 仍然是好的,毕竟更安全。
但Https接口,如果不确定对端的是什么,JDK7 SSL or JDK8 SSL or OpenSSL,为免协商出一个超慢的GCM算法,Server端需要通过配置,才决定要不要把GCM放进可选列表里。
解决方法
平时是这样写的:
SslContext sslContext = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()) .sslProvider( SslProvider. OPENSSL).build();
如果不要开GCM,那把ReferenceCountedOpenSslContext里面的DEFAULT_CIPHERS抄出来,删掉两个GCM的。
List<String> ciphers = Lists.newArrayList(“ECDHE-RSA-AES128-SHA”, “ECDHE-RSA-AES256-SHA”, “AES128-SHA”, “AES256-SHA”, “DES-CBC3-SHA”);
SslContext sslContext = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).sslProvider( SslProvider.OPENSSL).ciphers(ciphers).build();
总结
OpenSSL(boringssl)比JDK SSL 快10倍,10倍!!! 所以Netty下尽量都要使用OpenSSL。
在确定两端都使用OpenSSL时,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 仍然是好的,毕竟更安全,也是主流。
对端如果是JDK8 SSL时,Server端要把GCM算法从可选列表里拿掉。
Netty SSL性能调优的更多相关文章
- Netty实战之性能调优与设计模式
设计模式在Netty 中的应用(回顾): 单例模式要点回顾: 一个类在任何情况下只有一个对象,并提供一个全局访问点. 可延迟创建. 避免线程安全问题. 在我们利用netty自带的容器来管理客户端链接的 ...
- 记一次Web服务的性能调优
前言 一个项目在经历开发.测试.上线后,当时的用户规模还比较小,所以刚刚上线的项目一般会表现稳定.但是随着时间的推移,用户数量的增加,qps的增加等因素会造成项目慢慢表现出网页半天无响应的状况.在之前 ...
- Advacned Puppet: Puppet Master性能调优
本文是Advanced Puppet系列的第一篇:Puppet master性能调优,谈一谈如何优化和提高C/S架构下master端的性能. 故事情节往往惊人地类似:你是一名使用Puppet管理线上业 ...
- Spark性能调优之Shuffle调优
Spark性能调优之Shuffle调优 • Spark底层shuffle的传输方式是使用netty传输,netty在进行网络传输的过程会申请堆外内存(netty是零拷贝),所以使用了堆外内存. ...
- HTTPS 之 TLS 性能调优
HTTPS(HTTP over SSL)是以安全为目标的 HTTP 通道,可以理解为 HTTP + SSL/TLS,即在 HTTP 下加入 SSL/TLS 层作为安全基础.其中 TLS 的前身是 SS ...
- Redis基础、高级特性与性能调优
本文将从Redis的基本特性入手,通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍.之后概览Redis提供的高级能力,并在部署.维护.性能调优等多个方面进行更深入的介绍和指导. ...
- Tomcat性能调优后, 启动出现警告问题 [did not find a matching property.]
http://blog.csdn.net/dracotianlong/article/details/8963594 Tomcat性能调优后, 启动出现警告问题 [did not find a mat ...
- Redis 基础、高级特性与性能调优
本文将从Redis的基本特性入手,通过讲述Redis的数据结构和主要命令对Redis的基本能力进行直观介绍.之后概览Redis提供的高级能力,并在部署.维护.性能调优等多个方面进行更深入的介绍和指导. ...
- Java性能调优:利用JMC分析性能
Java性能调优作为大型分布式系统提供高性能服务的必修课,其重要性不言而喻. 好的分析工具能起到事半功倍的效果,利用分析利器JMC.JFR,可以实现性能问题的准确定位. 本文主要阐述如何利用JMC分析 ...
随机推荐
- redis整理の主从复制
redis 主从复制配置和使用都非常简单.通过主从复制可以允许多个 slave server 拥有和 master server 相同的数据库副本. 特点: (1).master 可以拥有多个 sla ...
- Maven项目常见错误
一.Cannot change version of project facet Dynamic Web Module to 3.0. 和 One or more constraints have n ...
- Android-原生对话框
package liudeli.ui.all; import android.app.Activity; import android.app.AlertDialog; import android. ...
- day 21 01 序列化模块和模块的导入的复习以及包的初识
day 21 01 序列化和模块的导入的复习以及包的初识 1.序列化模块 什么是序列化模块:数据类型转化成字符串的过程就是序列卷 为什么要使用序列化模块:为了方便存储和网络传输 三种序列化模块: (1 ...
- [gcc warnings] -Wtrigraph warnings
[gcc warnings] -Wtrigraph warnings 背景 三字符组(trigraph)与双字符组(Digraph)是程序设计语言(如C语言)中3个或者2个字符的序列,在编译器预扫描源 ...
- ResorceGovernor--基础和Demo
资源调控器分为三部分:1:资源池,将资源CPU/MEMORY划分到不同的载体上2:负载组,承载负载并将负载映射到不同的资源池3: 分类函数,将不同回话映射到不同的负载组08提供两种预定义的系统资源池1 ...
- [BJOI2010] 严格次小生成树
题目链接 一个严格次小生成树的模板题. 看到次小生成树,我们有一个很直观的想法就是先构造出来最小生成树,然后将这个最小生成树上面最大的一条边替换成和它值最相近而且比他大的边. 那么首先就是用krusk ...
- [sloved] IDE JavaServlet "Error: Could not find or load main class Servlet"
[ sloved ] JavaServlet "Error: Could not find or load main class Servlet" 报错内容: 提供一份 Servl ...
- iBatis --> MyBatis
从 Clinton Begin 到 Google(从 iBatis 到 MyBatis,从 Apache Software Foundation 到 Google Code),Apache 开源代码项 ...
- Java学习--多态
1. 多态 多态:同一个对象(实物),在不同时刻体现出来的不同状态 多态的前提: A:要有继承关系 B:要有方法重写 C:要有父类引用指向子类对象 父类 f = new 子类() 多态中的成员访问特点 ...