尽管启用了Keep-Alive和Session Identifier / Ticket，但仍有多次SSL / TLS握手

Question

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

我最近在我的网站上激活了TLS（https），因此我想检查一下这对网站的速度/负载性能有何影响。当通过互联网上的各种速度测试（例如tools.pingdom.com和webpagetest.org）和Chrome开发者工具浏览瀑布图时，我会在不同的内容上看到同一页面上的多个SSL握手/协商。你可以在这里看到这个图像：

可以看出，同一个domaian中的不同http请求有多个SSL协商。我想知道这个，因为Keep-Alive和Session标识符＆amp; -tickets是活动的（通过多个测试检查，例如来自webpagetest.org和ssllabs.com/ssltest/的测试）。请注意，由于我在共享主机上，因此无法访问服务器（apache）配置。

我正在经历的是什么：

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

请注意我在这个领域是一个完整的新手，但我试图找到关于这个主题的更多信息，但遗憾的是没有答案。

如果您想为自己测试一些内容，网站为https://www.aktie-skat.dk

Answer 1

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

详细说明：前两次握手的起始时间为0.362s和0.333s，每次握手时间约为100ms。这些是完全握手。所有其他TLS握手都更短（约50ms），因此使用会话恢复缩短握手。第二个TCP / TLS连接无法使用会话恢复，因为第一个连接的TLS握手尚未完成，因此没有可用于恢复的会话。