Wireshark 跟踪 - 分析代理和服务之间的超时答案

【问题标题】：Wireshark trace - analyzing time out between proxy and serviceWireshark 跟踪 - 分析代理和服务之间的超时
【发布时间】：2020-04-05 16:10:52
【问题描述】：

我有以下设置（如附图所示）：

A（java 进程）-> B（kubernetes 大使代理）-> C（kubernetes pod 中的 java 服务）

A 和 B 之间使用 HTTPS 进行通信，然后大使剥离 HTTPS 并继续与 C 进行 HTTP 通信。

我遇到的问题是，有时，正在发送的 HTTP BODY 消息未在 A 和 B 之间 100% 传输，但仅在 B 端跟踪我可以看到它由于某种原因停止（在在 A 侧跟踪它显示为一切都发送OK）。然后，C 中的 java 进程（正在等待 B-proxy 转发所有数据）只是等待并在 30 秒后超时。

您可以在所附图像中看到，在 A trace 中写入了整个 BODY 已发送，但在 B 侧的 trace 中，只有一半 BODY 可见（已交付）。我怀疑这些TCP Previous segment not captured。

您还可以看到，在此之后它只是等待 30 秒，然后超时。

这在我的设置中经常发生。有谁知道可能是什么问题？

大使配置：

getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: TLSContext
      name: tls
      ambassador_id: some-stg
      secret: ambassador-tls-cert
      ---
      apiVersion: ambassador/v1
      kind: Module
      name: ambassador
      ambassador_id: some-stg
      config:
        service_port: 8443
        diagnostics:
          enabled: true
        envoy_log_type: json

      ---
      apiVersion: ambassador/v1
      kind: Module
      name: tls
      ambassador_id: some-stg
      config:
        server:
          enabled: True
          redirect_cleartext_from: 8080
          alpn_protocols: "h2, http/1.1"
          secret: ambassador-tls-cert
      ---
      apiVersion: ambassador/v1
      kind: TracingService
      name: tracing
      service: tracing-jaeger-collector.tracing:9411
      driver: zipkin
      ambassador_id: some-stg
      tag_headers:
        - :authority
        - :path

更新

这里还有关于cloudshark的痕迹：转储（发送方 - 外部 kubernetes）：https://www.cloudshark.org/captures/8cfad383c8fb B dump（kubernetes 大使代理接收者）：https://www.cloudshark.org/captures/50512920d898

【问题讨论】：

标签： kubernetes proxy wireshark tcpdump ambassador

【解决方案1】：

Previous segment not captured 就是说，tcp 流中的一个段还没有被捕获，这是由 tcp 序列号决定的。如果初始连接发生在捕获之前，则在捕获开始时很常见，如果捕获主机丢弃了一个数据包，或者如果有实际的数据包丢失，也会发生这种情况。

此外，始终通过将 ACK 号设置为接收到的有效负载的最后一个字节来指示数据包丢失。因此，如果有任何东西丢失，ACK 号将停留在最后一个成功的字节上，无论有多少数据包通过。仅当重传到达时才增加 ACK。

Ignored Unknown Record 发生是因为 TLS 解析器不理解数据。在您的情况下，这可能是由于 tcp 段丢失造成的。

注意TCP segment of a reassembled PDU 声明。

Wireshark 认为它知道在那个 TCP 段的 TCP 上运行什么协议；该 TCP 段不包含该高级协议的所有“协议数据单元”（PDU），即该高级协议的数据包或协议消息，并且不包含该 PDU 的最后部分，所以它试图重新组装包含更高级别 PDU 的多个 TCP 段。例如，在大多数网络中，包含大量数据的 HTTP 响应不适合单个 TCP 段，因此它将被拆分为多个 TCP 段；除了最后一个 TCP 段之外的所有段都将被标记为TCP segment of a reassembled PDU。

也可以看看debug-service:

kube 代理是否工作
检查 iptables

What is needed to enable a pod to control another deployment in kubernetes?

然后确保您已按照这些步骤tls-ambassador 特别是创建证书并存储它。

有用的文档： TCP Analysis.

【讨论】：

问题是这个消息总是在超时之前不断重复。每当有一些失败的 REST 调用时，这个Previous segment not captured 就在那里。这不是捕获的开始，我不认为wireshark 总是在那个时候丢包。接收数据的应用程序是否有可能只是挂在进一步读取套接字上（因为在发送端我可以看到发送的全部内容）？另外，我怎样才能看到A端所有的东西都发送了，而B端只收到了一半？
能否提供大使的配置文件（服务）？
这是失败的端点配置：ambassador_id: some-stg apiVersion: ambassador/v1 kind: Mapping name: some-somemore-rest prefix: ^/some/[0-9]+/somemore(/)? prefix_regex: true rewrite: '' service: some-some-more-lb-stg-service:9000 timeout_ms: 10000
这里还有cloudshark上的痕迹：A转储（发送方-kubernetes外部）：cloudshark.org/captures/8cfad383c8fbB转储（kubernetes大使代理接收器）：cloudshark.org/captures/50512920d898
您能否以其他格式/站点提供这些痕迹。我无权访问它们。

【解决方案2】：

看来我的同事发现了问题所在。这个大使 pod 前面有一个 AWS 负载均衡器，当他重新创建它时 - 它现在似乎可以正常工作了。我猜有人向客户端（A）发送了 ACK，但没有将所有消息传递给大使吊舱（B）。他重新创建了不同类型 (NLB) 的负载均衡器，因为经典的负载均衡器不起作用。

【讨论】：