尽管启用了 Keep-Alive 和 Session Identifier/Ticket，但多次 SSL/TLS 握手
Multiple SSL/TLS handshakes despite Keep-Alive and Session Identifier/Ticket enabled
我很难找出为什么我在同一页面上经历了几次 SSL/TLS 握手（对于同一页面上的多个资源，即多个 HTTP 请求），当 Keep-Alive 和 Session Identifiers/Tickets 在 website/server 上活跃。
我最近在我的网站上激活了 TLS (https)，因此我想检查这对网站的 speed/load 性能有何影响。通过互联网上的各种速度测试（例如 tools.pingdom.com 和 webpagetest.org）和 Chrome 开发人员工具查看瀑布图时，我在同一页面上看到多个 SSL handshakes/negotiations , 内容不同。你可以在这里看到一张图片：
可以看出，同一个域内的不同http请求有多个SSL协商。我想知道这一点，因为 Keep-Alive 和 Session identifiers & -tickets 都处于活动状态（通过多个测试检查，例如来自 webpagetest.org 和 ssllabs.com/ssltest/ 的测试）。另请注意，我无法访问服务器 (apache) 配置，因为我在共享主机上。
我可能遇到的是：
- 由于服务器配置限制了一定数量的连接？
- 某种配置错误？
- 完全不同的东西？
- 我是不是误会了什么？
请注意，我是该领域的菜鸟，但我已尝试查找有关该主题的尽可能多的信息，但遗憾的是找不到答案。
如果您想自己测试一些东西，网站是 https://www.aktie-skat.dk
浏览器对同一站点建立多个并行连接是正常的，因为每个连接一次只能请求和加载一个资源。即使使用 HTTP keep-alive，这些资源也不会通过单个 HTTP/1.x 连接并行加载，而是一个接一个地加载。这仅与 HTTP/2 不同。除此之外，某些请求可能会导致来自服务器的Connection: close，这要求客户端为下一个请求使用不同的连接。
详细说明：前两次握手从 0.362 秒和 0.333 秒开始，每次大约需要 100 毫秒。这些是完整的握手。所有其他 TLS 握手都更短（大约 50 毫秒），因此是使用会话恢复的缩写握手。第二个 TCP/TLS 连接无法使用会话恢复，因为第一个连接的 TLS 握手尚未完成，因此没有可用于恢复的会话。
我很难找出为什么我在同一页面上经历了几次 SSL/TLS 握手（对于同一页面上的多个资源，即多个 HTTP 请求），当 Keep-Alive 和 Session Identifiers/Tickets 在 website/server 上活跃。
我最近在我的网站上激活了 TLS (https)，因此我想检查这对网站的 speed/load 性能有何影响。通过互联网上的各种速度测试（例如 tools.pingdom.com 和 webpagetest.org）和 Chrome 开发人员工具查看瀑布图时，我在同一页面上看到多个 SSL handshakes/negotiations , 内容不同。你可以在这里看到一张图片：
可以看出，同一个域内的不同http请求有多个SSL协商。我想知道这一点，因为 Keep-Alive 和 Session identifiers & -tickets 都处于活动状态（通过多个测试检查，例如来自 webpagetest.org 和 ssllabs.com/ssltest/ 的测试）。另请注意，我无法访问服务器 (apache) 配置，因为我在共享主机上。
我可能遇到的是：
- 由于服务器配置限制了一定数量的连接？
- 某种配置错误？
- 完全不同的东西？
- 我是不是误会了什么？
请注意，我是该领域的菜鸟，但我已尝试查找有关该主题的尽可能多的信息，但遗憾的是找不到答案。
如果您想自己测试一些东西，网站是 https://www.aktie-skat.dk
浏览器对同一站点建立多个并行连接是正常的，因为每个连接一次只能请求和加载一个资源。即使使用 HTTP keep-alive，这些资源也不会通过单个 HTTP/1.x 连接并行加载，而是一个接一个地加载。这仅与 HTTP/2 不同。除此之外，某些请求可能会导致来自服务器的Connection: close，这要求客户端为下一个请求使用不同的连接。
详细说明：前两次握手从 0.362 秒和 0.333 秒开始，每次大约需要 100 毫秒。这些是完整的握手。所有其他 TLS 握手都更短（大约 50 毫秒），因此是使用会话恢复的缩写握手。第二个 TCP/TLS 连接无法使用会话恢复，因为第一个连接的 TLS 握手尚未完成，因此没有可用于恢复的会话。