如何使用 tcpdump 区分 tcp 连接的第一个 fin 数据包和第二个 fin 数据包?

发布于 2024-12-24 16:50:03 字数 274 浏览 3 评论 0原文

我正在开发一个http服务器。现在我想做一些统计,具体来说,我想知道有多少个tcp连接被客户端关闭,有多少个tcp连接被我的服务器关闭。

我在我的http服务器上关闭了Keep-alive功能,所以正常情况是我的服务器发送第一个FIN数据包,客户端发送第二个FIN数据包,这意味着连接被我的服务器正常关闭。如果顺序相反,则表明关闭异常,这是我关心的。

这是问题,如何使用 tcpdump 区分第一个 FIN 数据包和第二个数据包?由于FIN和ACK标志位都被置位。

提前致谢,新年快乐!

I am developing a http server. And now i want to do some statistics, to be specific, I want to know how many of the tcp connections are closed by client, and how many of them are closed by my server.

I turned the Keep-alive feature off on my http server, so the normal case is that my server sends the first FIN packet and the client sends the second one, which means the connection is closed by my server normally. If they are in the reverse order, it indicates an abnormal closing, which I cares.

Here is the question, How can I tell the first FIN packet from the second with tcpdump? Since both of them are set in the FIN and ACK flag bit.

Thanks in advance and Happy new year!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

§对你不离不弃 2024-12-31 16:50:03

我通过 ssh 通过隧道连接到我的网络服务器,该服务器正在侦听 5000/tcp。我运行了会话的 tcpdump,即使您忽略时间戳,仍然清楚谁从 TCP 源端口号发送了什么。

05:42:06.344592 IP localhost.5000 > localhost.37924: Flags [F.], seq 243, 
    ack 419, win 529, options [nop,nop,TS val 120830308 ecr 120830308], length 0
05:42:06.381872 IP localhost.37924 > localhost.5000: Flags [.], ack 244, 
    win 513, options [nop,nop,TS val 120830318 ecr 120830308], length 0
05:42:06.382504 IP localhost.37924 > localhost.5000: Flags [F.], seq 419, 
    ack 244, win 513, options [nop,nop,TS val 120830318 ecr 120830308], length 0
05:42:06.382535 IP localhost.5000 > localhost.37924: Flags [.], ack 420, 
    win 529, options [nop,nop,TS val 120830318 ecr 120830318], length 0

05:42:06.344592,我的网络服务器从客户端确认字节并设置 FIN 标志。我知道它是网络服务器,因为源端口是 5000。在现实世界中,这更容易,您的源 IP 地址本身就可以泄露它。

05:42:06.382504,客户端向服务器的FIN发送了一个ACK。同样,我们知道,因为源端口不是 5000。

I am tunneling a connection through ssh to my webserver, which is listening on 5000/tcp. I ran a tcpdump of the session, and even if you ignore timestamps, it's still clear who sent what from the TCP source port number.

05:42:06.344592 IP localhost.5000 > localhost.37924: Flags [F.], seq 243, 
    ack 419, win 529, options [nop,nop,TS val 120830308 ecr 120830308], length 0
05:42:06.381872 IP localhost.37924 > localhost.5000: Flags [.], ack 244, 
    win 513, options [nop,nop,TS val 120830318 ecr 120830308], length 0
05:42:06.382504 IP localhost.37924 > localhost.5000: Flags [F.], seq 419, 
    ack 244, win 513, options [nop,nop,TS val 120830318 ecr 120830308], length 0
05:42:06.382535 IP localhost.5000 > localhost.37924: Flags [.], ack 420, 
    win 529, options [nop,nop,TS val 120830318 ecr 120830318], length 0

At 05:42:06.344592, my webserver ACK'd bytes from the client and set the FIN flag. I know it was the webserver, because the source port is 5000. In the real world, it's even easier, your source IP address alone gives it away.

At 05:42:06.382504 the client sent an ACK to the server's FIN. Again, we know because the source port is not 5000.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文