为Jetty启用SSL会话以加速HTTPS请求 [英] Enabling SSL session for Jetty to speed up HTTPS requests

问题描述

这是我的问题此处的后续跟踪，其中我发现了与HTTPS和HTTP的大查询时间差异请求：到服务器的距离越大，这个差异越大。

This is a follow up of my question here, where I found a big query time differences with HTTPS vs. HTTP requests: the larger the distance to the server was the bigger was this difference.

我找到了这个握手开销很好的解释。一个人无法真正解决这个问题，但对于进一步的请求，将SSL会话与keep-alive结合使用非常重要。保持活着状态。但是每个请求的SSL ID都不同（我正在使用jetty并阅读 ssl_session_id属性）。

I found a nice explanation of this handshake overhead. And one cannot really solve that, but for further requests it is important to use a SSL session in combination with keep-alive. Keep-alive is turned on. But the SSL ID is different for every request (I'm using jetty and reading the ssl_session_id property).

事实证明，我需要根据这个问题，但我仍然感到困惑和不确定（这个问题的答案似乎听起来不太稳固）：

It turns out that I need to change the client as well as the server according to this question, but I'm still confused and unsure (the answer for this question does not seem to sound solid):

对于浏览器：如果我对我的API进行javascript查询，是否需要以某种方式启用它？

For the browser: do I need to enable that somehow if I make javascript queries to my API?

对于Jetty：我是否还需要关闭如此处所述，允许重新协商码头设置？但看起来这会产生一些安全隐患，如果现在允许安全与否则我不完全（取自文档）：

For Jetty: Do I also need to turn off the allowRenegotiate setting for jetty as explained here? But it looks like this would have several security implications, where I do not fully if now allowing is safe or not (taken from the docs):

设置是否允许SSL重新协商。 CVE-2009-3555通过重新协商发现了SSL / TLS中的漏洞。如果您的JVM没有修复CVE-2009-3555，则不应允许重新协商。 CVE-2009-3555在Sun java 1.6中得到修复，禁止在u19中重新协商，在u22中禁止使用RFC5746。

推荐答案

我不太确定你真正要求的是什么。好的HTTPS总是比HTTP慢，因为它有更多的开销。

I'm not quite sure what you're actually asking for. Well HTTPS will always be slower than HTTP as it has more overhead.

但是你可以采取一些措施来缩短响应时间。 ？例如，大多数操作系统使用的tcp初始拥塞量太小。这导致仅针对TCP握手的附加往返。由于往返时间通常介于20ms到几秒之间（与海外服务器的网络速度较慢），因此可以大大缩短建立ssl连接所需的时间。

However there's things you can probably do to reduce the response times. For example most Operating Systems are using a too small tcp initial congestion size. This leads to an additional roundtrip just for the TCP handshake. As the roundtriptime is usually somewhere between 20ms and up to several seconds (slow network to a server overseas) this can severly improve the time taken to establish a ssl connection.

有了解linux系统的 https://lwn.net/Articles/427104/ 。内核> 2.6.39或> 3.x应该这样做。

Have a look at https://lwn.net/Articles/427104/ for linux systems. Kernels >2.6.39 or >3.x should do.

这篇关于为Jetty启用SSL会话以加速HTTPS请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！