测试之间的唯一变化是更改 TLS 版本。 Chrome 和 FireFox 之间的行为是相同的。
TLSv1 和 TLSv1.1 均达到 90 兆字节/秒。他们在 Java 6 (TLSv1) 和 Java 8 (TLSv1/TLSv1.1) 上获得了这个速度。
然而，TLSv1.2 大大降低了速度。我们得到 4 兆字节/秒。没有更改密码，没有其他设置等。不仅是我们的开发机器，而且客户也报告了同样的事情，Windows 操作系统，Java 8，TLSv1.2。我们使用的是 OS X、Java 8、TLSv1.2。所以这似乎是大势所趋。测试在本地主机、Xeon 6 核心处理器、SSD 驱动器上进行。如果我们不使用 HTTPS，我们将获得超过 200MB/秒的速度。所以 4MB/秒是对我们能力的极大侮辱。
这不是初始连接、缓存或重新协商等。这只是原始传输速度。我没有发现任何已知的 Java 错误，有人有任何猜测吗？
这是 Chrome 报告的连接和密码:
TLSv1.2
您与 127.0.0.1 的连接已使用现代密码学加密。
连接使用 TLS 1.2。
使用 AES_128_GCM 对连接进行加密和身份验证，并使用 ECDHE_RSA 作为 key 交换机制。
TLSv1.1
您与 127.0.0.1 的连接使用过时的密码术进行了加密。
连接使用 TLS 1.1。
连接使用 AES_128_CBC 加密，SHA1 用于消息认证，ECDHE_RSA 作为 key 交换机制。
想法？
最佳答案
讨厌回答我自己的问题，但我刚刚意识到 TLS v1.2 允许使用更新的密码。正是密码导致 Java 8 使用软件来处理加密方面而不是使用硬件加速，并导致可怕的速度。
在服务器上禁用所有 GCM 密码导致与 chrome 使用 CBC 密码相同的速度。
Slow AES GCM encryption and decryption with Java 8u20
--本
关于Java 服务器，TLSv1.1 快，TLSv1.2 极慢(90MByte/sec 对比 4MByte/sec)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29577804/