尽管启用了 Keep-Alive 和会话标识符/票证，但仍进行多次 SSL/TLS 握手 [英] Multiple SSL/TLS handshakes despite Keep-Alive and Session Identifier/Ticket enabled

问题描述

当 Keep-Alive 和 Session Identifiers/Tickets 都处于活动状态时，我很难找出为什么我在同一页面上遇到多次 SSL/TLS 握手(对于同一页面上的多个资源，即多个 HTTP 请求)在网站/服务器上.

I have some trouble finding out why I'm experiencing several SSL/TLS handshakes on the same page (for several resources on the same page, i.e. multiple HTTP requests), when both Keep-Alive and Session Identifiers/Tickets are active on the website/server.

我最近在我的网站上激活了 TLS (https)，​​因此我想检查这对网站的速度/负载性能有什么影响.通过互联网(例如tools.pingdom.com 和webpagetest.org)和Chrome 开发者工具上的各种速度测试的瀑布图时，我看到同一页面上不同内容的多个SSL 握手/协商.您可以在此处查看此图片:

I've recently activated TLS (https) on my website and therefore I wanted to check what impact this had on the speed/load performance of the site. When going through the waterfall diagram from both various speed tests on the internet (e.g. tools.pingdom.com and webpagetest.org) and Chrome Developer Tools, i see multiple SSL handshakes/negotiations on the same page, on different content. You can see an image of this here:

可以看出，同一个域内的不同 http 请求有多个 SSL 协商.我想知道这个，因为 Keep-Alive 和 Session 标识符 &-tickets 处于活动状态(通过多个测试进行检查，例如来自 pagestest.org 和 ssllabs.com/ssltest/的测试).另请注意，我无法访问服务器 (apache) 配置，因为我在共享主机上.

As can be seen, there are multiple SSL negotiations on different http requests within the same domaian. I'm wondering about this, as both Keep-Alive and Session identifiers & -tickets are active (checked via multiple tests such as the ones from webpagetest.org and ssllabs.com/ssltest/). Please do also note that I dont have access to the server (apache) configurations as I'm on a shared host.

我可能遇到的情况:

• 由于服务器配置限制了一定数量的连接?
• 某种配置错误?
• 完全不同的东西?
• 我误会了什么?

请注意，我是该领域的完全新手，但我已尝试查找有关此主题的尽可能多的信息，但遗憾的是没有找到答案.

Please note that I'm a complete rookie in this field, but I've tried to find as much information regarding this topic, but sadly not an answer.

如果您想自己测试一些东西，该网站是 https://www.aktie-skat.dk

In case you would like to test something for yourself, the website is https://www.aktie-skat.dk

推荐答案

浏览器与同一个站点建立多个并行连接是很正常的，因为每个连接一次只能请求和加载一个资源.即使使用 HTTP keep-alive，这些资源也不会通过单个 HTTP/1.x 连接并行加载，而是一个接一个地加载.这仅与 HTTP/2 不同.除此之外，某些请求可能会导致来自服务器的 Connection: close 要求客户端为下一个请求使用不同的连接.

It is normal for a browser to establish multiple parallel connections to the same site since each connection can only request and load a single resource at a time. Even with HTTP keep-alive these resources do not get loaded in parallel over a single HTTP/1.x connection but only one after the other. This is only different with HTTP/2. Apart from that some requests might result in an Connection: close from server which requires the client to use a different connection for the next requests.

详细说明:前两次握手从 0.362 秒和 0.333 秒开始，每次大约需要 100 毫秒.这些是完整的握手.所有其他 TLS 握手都更短(大约 50 毫秒)，因此使用会话恢复进行缩写握手.第二个 TCP/TLS 连接无法使用会话恢复，因为第一个连接的 TLS 握手尚未完成，因此没有会​​话可用于恢复.

In detail: The first two handshakes start at 0.362s and 0.333s and take each about 100ms. These are full handshakes. All the other TLS handshakes are way shorter (about 50ms) and are thus abbreviated handshakes using session resume. The second TCP/TLS connection could not use session resume yet since the TLS handshake for the first connection was not done yet and thus no session was available for resume.

这篇关于尽管启用了 Keep-Alive 和会话标识符/票证，但仍进行多次 SSL/TLS 握手的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！