Fatal编程技术网
  • nginx/
  • Nginx 如何调试未关闭的关闭等待连接的原因？（tcpdump等）

Nginx 如何调试未关闭的关闭等待连接的原因？（tcpdump等）

nginx networking tcp

Nginx 如何调试未关闭的关闭等待连接的原因？（tcpdump等）,nginx,networking,tcp,wireshark,tcpdump,Nginx,Networking,Tcp,Wireshark,Tcpdump,我们在同一台主机上安装了Java应用程序和Nginx作为反向代理。周期性地，我们得到CLOSE\u WAIT长时间挂起的连接： $ ss -n4t | head State Recv-Q Send-Q Local Address:Port Peer Address:Port CLOSE-WAIT 1 0 127.0.0.1:8180 127.0.0.1:36599 CLOSE-WAIT 1 0 127.0.

我们在同一台主机上安装了Java应用程序和Nginx作为反向代理。周期性地，我们得到
CLOSE\u WAIT
长时间挂起的连接：

$ ss -n4t | head
State      Recv-Q Send-Q  Local Address:Port    Peer Address:Port
CLOSE-WAIT 1      0           127.0.0.1:8180       127.0.0.1:36599
CLOSE-WAIT 1      0           127.0.0.1:8180       127.0.0.1:36467
CLOSE-WAIT 1      0           127.0.0.1:8180       127.0.0.1:36154
而且它们的数量在增加，那么应用程序就有问题了。 互联网上说：

Your server is failing to detect client disconnects, or ignoring them, and not closing the socket.
Nginx说：

2020/06/28 04:59:15 [error] 65506#0: *31719640 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 55.55.55.55, server: app.mycompany.com, request: "POST /url/url HTTP/1.0", upstream: "http://127.0.0.1:8180/url/url/provider", host: "app.mycompany.com"
好的，
tcpdump
在正常行为期间显示：

2020-06-08 06:58:23.073139 IP 127.0.0.1.8180 > 127.0.0.1.57786: Flags [P.], seq 1:738, ack 1211, win 1365, options [nop,nop,TS val 2780380992 ecr 2780380974], length 737
2020-06-08 06:58:23.073233 IP 127.0.0.1.8180 > 127.0.0.1.57786: Flags [F.], seq 738, ack 1211, win 1365, options [nop,nop,TS val 2780380992 ecr 2780380992], length 0
2020-06-08 06:58:23.073302 IP 127.0.0.1.57786 > 127.0.0.1.8180: Flags [F.], seq 1211, ack 739, win 353, options [nop,nop,TS val 2780380992 ecr 2780380992], length 0
两侧的
[F.]
表示连接已正确关闭（基于）

接下来，
tcpdump
在异常行为期间（当
CLOSE\u WAIT
borns时）显示：

这里我们只看到一个
[F.]

我已经阅读了数千篇文章，但仍然难以回答以下问题：

tcpdump
[F.]
标志实际上是什么意思？文档中说：
占位符，通常用于确认。
，但第一个初始FIN（没有确认）在哪里，如：

我的问题是，
tcpdump
将FIN和FIN/ACK组合成
[F.]
标志？如果是这样，在正常行为期间，我们会看到以下操作顺序：

  • 客户端将FIN发送到服务器：
    被tcpdump忽略
  • 服务器向客户端发送FIN/ACK:
    127.0.0.1.8180>127.0.0.1.57786:标志[F.]
  • 服务器将FIN发送到客户端：
    被tcpdump忽略
  • 客户端向服务器发送FIN/ACK:
    127.0.0.1.57786>127.0.0.1.8180:标志[F.]
    • 如果是这样，在异常行为期间，客户端根本不向我们发送FIN，因此，我们的服务器不发送FIN/ACK，即
    [F.]
    对吗？

    第二个问题是Nginx。正如我在
    netstat
    上所理解的：

    CLOSE-WAIT 1      0           127.0.0.1:8180       127.0.0.1:36467
    连接正在从本地主机连接到本地主机是因为Nginx反向代理吗？这就是为什么我看不到真正的客户端IP？如果是这样，Java应用程序和Nginx之间会有问题吗？我这样问是因为我想调试/监视HTTP通信，包括从localhost到localhost的请求和响应头以及消息体：

    tcpdump -A -s 0 'tcp port 8180 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' -i lo

    tcpdump-A-s0'tcp端口8180和（（ip[2:2]-（（ip[0]&0xf）2））！=0）–i低
    因为我们在Nginx上有SSL终止，我相信我会看到服务器/客户端流内部发生了什么。第三个问题是，这是正确的方法吗/有没有其他方法可以清楚地理解我们“接近”等待的根本原因？

    CLOSE-WAIT 1      0           127.0.0.1:8180       127.0.0.1:36467

    tcpdump -A -s 0 'tcp port 8180 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' -i lo