Java 服务器，TLSv1.1 快，TLSv1.2 极慢（90MByte/sec vs 4MByte/sec）答案

【问题标题】：Java Server, TLSv1.1 fast, TLSv1.2 extremely slow (90MByte/sec versus 4MByte/sec)Java 服务器，TLSv1.1 快，TLSv1.2 极慢（90MByte/sec vs 4MByte/sec）
【发布时间】：2015-06-17 03:20:08
【问题描述】：

测试之间的唯一变化是更改 TLS 版本。 Chrome 和 FireFox 的行为相同。

TLSv1 和 TLSv1.1 均获得 90 兆字节/秒。他们在 Java 6 (TLSv1) 和 Java 8 (TLSv1/TLSv1.1) 上获得了这种速度。

然而，TLSv1.2 大大降低了速度。我们得到 4 兆字节/秒。没有更改密码，没有其他设置等。不仅我们的开发机器，而且客户也报告了同样的事情，Windows OS、Java 8、TLSv1.2。我们正在使用 OS X、Java 8、TLSv1.2。所以这似乎是一个大趋势。测试是在 localhost、Xeon 6 核心处理器、SSD 驱动器上进行的。如果我们不使用 HTTPS，我们将获得超过 200MB/秒的速度。所以 4MB/秒对我们所能做的简直是一种极大的侮辱。

这不是初始连接、缓存或重新协商等。这只是原始传输速度。我没有发现任何已知的java bug，有没有人有任何猜测？

这是 Chrome 报告的连接和密码：

TLSv1.2

您与 127.0.0.1 的连接已使用现代密码术进行加密。

连接使用 TLS 1.2。

使用 AES_128_GCM 对连接进行加密和身份验证，并使用 ECDHE_RSA 作为密钥交换机制。

TLSv1.1

您与 127.0.0.1 的连接使用过时的加密技术进行加密。

连接使用 TLS 1.1。

使用 AES_128_CBC 对连接进行加密，使用 SHA1 进行消息验证，使用 ECDHE_RSA 作为密钥交换机制。

想法？

【问题讨论】：

标签： java performance ssl https

【解决方案1】：

讨厌回答我自己的问题，但我刚刚意识到 TLS v1.2 允许使用更新的密码。它的密码导致 Java 8 使用软件来处理加密方面而不是使用硬件加速，并导致可怕的速度。

禁用服务器上的所有 GCM 密码会产生与 chrome 使用 CBC 密码相同的速度。

Slow AES GCM encryption and decryption with Java 8u20

--本

【讨论】：