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

Question

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

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

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

我遇到的问题是有时，正在发送的 HTTP BODY 消息并没有在 A 和 B 之间 100% 传输，但只有在 B 端跟踪我可以看到它由于某种原因停止了（在 A 侧的跟踪中显示为所有发送都正常）。然后，java C 中的进程（正在等待 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 ambassador proxy receiver): https://www.cloudshark.org/captures/50512920d898

Answer 1

Previous segment not captured的意思就是，tcp流中有一段没有被捕获，这是由tcp序列号决定的。如果初始连接发生在捕获之前，则在捕获开始时很常见，如果捕获主机丢弃数据包，或者如果确实有数据包丢失，也可能发生。

此外，数据包丢失总是通过将 ACK 编号设置为无间隙接收的有效负载的最后一个字节来发出信号。因此，如果有任何丢失，无论有多少数据包通过，ACK 编号都会保留在最后一个成功的字节上。 ACK只有在重传到达时才会增加。

发生忽略的未知记录是因为 TLS 解析器不理解数据。在您的情况下，这可能是由于 tcp 段丢失。

注意 TCP segment of a reassembled PDU 声明。

Wireshark 认为它知道运行在该 TCP 段中 TCP 之上的协议是什么；该 TCP 段不包含该更高级别协议的所有 "protocol data unit" (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.

Answer 2

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

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

Wireshark trace - analyzing time out between proxy and service

kubernetes

proxy

wireshark

tcpdump

ambassador