☰

带有大型 SSL 数据包的 TCP 窗口。专有名称长度 10kb

tag-icon • tag-icon ssl certificate-authority
带有大型 SSL 数据包的 TCP 窗口。专有名称长度 10kb

我们正在排除与 SSL 握手相关的网络延迟故障。这不一定每次都会导致延迟，但在某些情况下，服务器在确认客户端 Hello 数据包后需要 5-10 秒才能开始发送第一个 SSL 数据包。附件是在各个应用服务器上捕获的客户端和服务器端快照。请参阅下面的注释和查询。

感谢你的帮助。

  1. 在客户端和服务器端进行捕获，它们位于不同的位置，路径上有路由器和防火墙。
  2. 在 Windows 2016 上的 Tomcat 8.x 中，SSL 握手类型设置为“可选”。
  3. 客户端是 Linux 服务器。
  4. 客户端 TCP 窗口为 5840，服务器 TCP 窗口为 8192
  5. 客户端到服务器，DF（不分片）位设置为 0
  6. 服务器到客户端，DF（不分片）位设置为 1
  7. 服务器的 SSL 段（服务器 Hello、证书链、服务器密钥和证书请求）总共 15456 字节。
  8. 在 15456 字节中，证书请求的 SSL 段的最后一个部分包含长度为 10912 字节的“专有名称”数据包。此数据包中包含约 90 个信任存储列表。
  9. 服务器的 SSL 段被分成 12 个数据包（111330 字节 + 1851 字节），并且它们全部从服务器一次性推送，而无需等待来自客户端的任何 ACK。
  10. 服务器返回客户端 Hello ACK，客户端立即收到。
  11. 由于某种原因，服务器看到来自客户端的客户端问候的 DUP-ACK。在客户端捕获中，我们没有看到此 DUP-ACK 发送到服务器。这种情况在 TCP 会话中发生了 5 次。服务器会快速重新传输客户端问候 ACK。
  12. 客户端未看到此重新传输的客户端 Hello ACK，客户端在第 0.94 秒时看到第一个 SSL 数据包（在上述重新传输客户端 Hello 之后），并开始发送对收到的这 12 个 SSL 数据包的 ACK。
  13. 在服务器上可以看到 ACK，但是服务器逐个接收 ACK，发现它只接收了第 12 个数据包中的第 5 个数据包的 ACK。这导致服务器重新传输了第 6 个到第 12 个 SSL 数据包。
  14. 在客户端，它看到重新传输的 SSL 数据包（就像第一次到达一样）。它看不到之前一次性发送给客户端的原始 SSL 数据包 6 到 12。

问题：

  1. 服务器如何能够一次发送 15456 字节的 SSL 数据包（大于 8192 字节的 TCP 窗口）？

    1. 为什么服务器多次看到来自客户端的客户端 Hello 的 DUP-ACK，但在客户端捕获时我们发现这些 DUP-ACK 未被发送？

    2. 为什么 Tomcat 服务器在“证书请求”负载的“专有名称”中发送 CA 列表？它的长度为 10940 字节？这是由于某些 Windows 注册表设置造成的吗？

    3. 服务器无法在“证书请求”中发送 CA 列表，但 SSL 握手仍能正常工作？服务器证书不是由第三方 CA 颁发的，而是由服务器自己的 CA 颁发的。

    4. 如何解决 SSL 握手延迟问题并使此 TCP 会话高效？

    [1]:服务器端捕获图像 -https://i.stack.imgur.com/rhYNu.jpg

    [2]:客户端捕获图像 -https://i.stack.imgur.com/kzZnl.jpg

相关内容