我只需要幫助理解下圖，但我會給出上下文背景。
我們有一個應用程式配置為使用連接埠 8080 上的代理並需要網路存取。在一天中的任意時間，應用程式無法連接並當機。我們正在努力找出原因。我們已經排除了韌體和代理 URL 規則（無論工作或失敗，它總是會存取相同的 URL）。我認為這個問題與代理本身的效能問題有關。為了弄清楚真相，我一直在發生這種情況時進行網路捕獲。
如果您查看下圖，您會發現它是刪除了 IP 詳細資訊的片段。來源「42」的第一行是用戶端電腦透過連接埠 8080 上的代理程式 (IP 35) 發出 TLS 請求。底部視窗是第一條綠線的詳細資訊。
反白的部分「下一個序號」與 35（第 2 行到最後一行）最後傳回的封包的 ACK 相符。這實際上是 35 回覆客戶端，聲明它已收到發送給它的所有資料（這表示裝置已啟動，因為它確認收到資料（意味著沒有韌體或網路問題））。請注意，它不會發回任何資料。此後客戶端立即發出 TCP RST。這是我的解釋，但我希望有人驗證一下，因為我的 TCP 技能有點生疏。
客戶端正在向代理程式發送某種形式的請求，但由於某種原因代理程式沒有回應（在應用程式層）。由於代理確實回覆了 TCP ACK，這意味著在網路層一切都很好。這意味著當資料透過網路堆疊傳遞到代理本身時，正是代理程式斷開了連線。為什麼會這樣，我還不知道，但我正在尋求澄清，以便我可以與代理團隊交談並告訴他們需要對此進行調查（他們認為這不是代理）。
支持我的觀點的其他證據是，您在 RST 之前的圖像中看到的前 4 行重複了很多次。同樣，這意味著客戶端正在重新發送它所收到的任何請求，但從未得到回應；然後它最終放棄並發出重置信號。
顯然，代理前面有一個負載平衡器，而代理實際上是幾台機器。我有一種感覺，其中一個後端存在問題，並且 LB 沒有從池中刪除該節點，因此可能會將資料發送到黑洞。
我正在尋求第二意見，根據捕獲的結果，我上面的總結看起來是否準確？
答案1
此後客戶端立即發出 TCP RST
不是立即。 RST 是在伺服器發送最後一個 ACK 後 30 秒由客戶端發送的。
……您在 RST 之前的圖像中看到的前 4 行重複了很多次
這些不是同一條線。它們的 ACK 值不同。
我的解釋是，客戶端正在發送一個具有更大負載的請求（因此來自伺服器的多個 ACK 來確認這一點），然後期望代理髮迴回應。 30 秒後沒有回應，客戶端將放棄並關閉與 RST 的連線。
目前尚不清楚代理商為何不發送回應。可能是代理的問題。但也可能是上游伺服器的問題，伺服器只是將問題傳播到客戶端。
但請注意，解釋可能是錯誤的。沒有提供太多上下文和資料包捕獲，因此這更像是一個有根據的猜測。