Netty SSL性能调优

标签: 技术架构 Netty SSL | 发表时间:2016-10-28 23:40 | 作者:liuchi1993
出处:http://www.importnew.com

嗯,这篇不长的文章,是一个晚上工作到三点的血泪加班史总结而成。多一个读,可能就少一个人加班。

《 TLS协议分析 与 现代加密通信协议设计》 首先要感谢这篇文章,如果没有它,我可能还要花更多的时间才能完成。文章有点长,能看多少是多少,每句都是收获。

1.背景知识

1.1 协议史

1996: SSL3.0. 写成RFC,开始流行。目前(2015年)已经不安全,必须禁用。

1999: TLS1.0. 互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版。

2006: TLS1.1. 作为 RFC 4346 发布。主要fix了CBC模式相关的如BEAST攻击等漏洞。

2008: TLS1.2. 作为RFC 5246发布 。增进安全性,目前的主流版本。

2015之后: TLS 1.3,还在制订中。

1.2 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模式并不需要。

两者的差别,在于 Block Cipher+HMAC 类的算法都爆出了各种漏洞,下一代的TLS v1.3干脆只保留了Authenticated-Encryption 类的算法,主要就是AES-GCM,AEAD模式(Authenticated-Encryption With Addtional data)里Encrypt和MAC直接集成为一个算法,在算法内部解决好安全问题。

1.3 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,还差着一个量级。

1.4 Netty 对SSL的支持

Netty既支持JDK SSL,也支持Google的boringssl, 这是OpenSSL 的一个fork,更少的代码,更多的功能。

依赖netty-tcnative-boringssl-static-linux-x86_64.jar即可,它里面已包含了相关的so文件,再也不用管Linux里装没装OpenSSL,OpenSSL啥版本了。

2. 性能问题的出现及调优

2.1 性能问题的出现

忘掉前面所有的背景知识,重新来到问题现场:

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

2.2 原因分析

带着上面的记录,经过一晚的奋战,得出了文章一开始的背景信息,再回头分析就很好理解了,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放进可选列表里。

2.3 实现

经过一轮学习,平时是这样写的:

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();

3 结论

  • OpenSSL(boringssl)在我们的测试用例里,比JDK SSL 快10倍,10倍!!! 所以Netty下尽量都要使用OpenSSL。
  • 在确定两端都使用OpenSSL时,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 仍然是好的,毕竟更安全,也是主流。
  • 对端如果是JDK8 SSL时,Server端要把GCM算法从可选列表里拿掉。

可能感兴趣的文章

相关 [netty ssl 性能调优] 推荐:

Netty SSL性能调优

- - ImportNew
嗯,这篇不长的文章,是一个晚上工作到三点的血泪加班史总结而成. 《 TLS协议分析 与 现代加密通信协议设计》 首先要感谢这篇文章,如果没有它,我可能还要花更多的时间才能完成. 文章有点长,能看多少是多少,每句都是收获. 目前(2015年)已经不安全,必须禁用. 互联网标准化组织ISOC接替NetScape公司,发布了SSL的升级版TLS 1.0版.

nginx配置ssl

- - 邢红瑞的blog
先生成网关证书 ,仿照CA模式.

Netty系列之Netty高性能之道

- - CSDN博客推荐文章
最近一个圈内朋友通过私信告诉我,通过使用Netty4 + Thrift压缩二进制编解码技术,他们实现了10W TPS(1K的复杂POJO对象)的跨节点远程服务调用. 相比于传统基于Java序列化+BIO(同步阻塞IO)的通信框架,性能提升了8倍多. 事实上,我对这个数据并不感到惊讶,根据我5年多的NIO编程经验,通过选择合适的NIO框架,加上高性能的压缩二进制编解码技术,精心的设计Reactor线程模型,达到上述性能指标是完全有可能的.

Netty代码分析

- LightingMan - 淘宝JAVA中间件团队博客
Netty提供异步的、事件驱动的网络应用程序框架和工具,用以快速开发高性能、高可靠性的网络服务器和客户端程序[官方定义],整体来看其包含了以下内容:1.提供了丰富的协议编解码支持,2.实现自有的buffer系统,减少复制所带来的消耗,3.整套channel的实现,4.基于事件的过程流转以及完整的网络事件响应与扩展,5.丰富的example.

HBase性能调优

- - 学着站在巨人的肩膀上
我们经常看到一些文章吹嘘某产品如何如何快,如何如何强,而自己测试时却不如描述的一些数据. 其实原因可能在于你还不是真正理解其内部结构,对于其性能调优方法不够了解. 本文转自TaoBao的Ken Wu同学的博客,是目前看到比较完整的HBase调优文章. 原文链接:HBase性能调优. 因官方Book Performance Tuning部分章节没有按配置项进行索引,不能达到快速查阅的效果.

Hadoop性能调优

- - 开源软件 - ITeye博客
是否对任务进行profiling,调用java内置的profile功能,打出相关性能信息. 对几个map或reduce进行profiling. 非常影响速度,建议在小数据量上尝试. 1表示不reuse,-1表示无限reuse,其他数值表示每个jvm reuse次数. reuse的时候,map结束时不会释放内存.

hbase性能调优

- - 数据库 - ITeye博客
   1)、hbase.regionserver.handler.count:该设置决定了处理RPC的线程数量,默认值是10,通常可以调大,比如:150,当请求内容很大(上MB,比如大的put、使用缓存的scans)的时候,如果该值设置过大则会占用过多的内存,导致频繁的GC,或者出现OutOfMemory,因此该值不是越大越好.

MapReduce - 性能调优

- - CSDN博客云计算推荐文章
        Hadoop为用户作业提供了多种可配置的参数,以允许用户根据作业特点调整这些参数值使作业运行效率达到最优.         对于一大批MapReduce程序,如果可以设置一个Combiner,那么对于提高作业性能是十分有帮助的. Combiner可减少Map Task中间输出的结果,从而减少各个Reduce Task的远程拷贝数据量,最终表现为Map Task和Reduce Task执行时间缩短.

Java 性能调优

- - 编程语言 - ITeye博客
1.用new关键词创建类的实例时,构造函数链中的所有构造函数都会被自动调用. 但如果一个对象实现了Cloneable接口,我们可以调用它的clone()方法. clone()方法不会调用任何类构造函数. 在使用设计模式(Design Pattern)的场合,如果用Factory模式创建对象,则改用clone()方法创建新的对象实例非常简单.

Spark性能调优

- - zzm
通常我们对一个系统进行性能优化无怪乎两个步骤——性能监控和参数调整,本文主要分享的也是这两方面内容. Spark提供了一些基本的Web监控页面,对于日常监控十分有用. http://master:4040(默认端口是4040,可以通过spark.ui.port修改)可获得这些信息:(1)stages和tasks调度情况;(2)RDD大小及内存使用;(3)系统环境信息;(4)正在执行的executor信息.