【guiminer 源码】【htmlapp项目实战源码】【JAVA公司项目源码】tcpdump源码

时间:2024-11-06 15:32:13 来源:rom 刷机工具源码 编辑:cnc助手源码

1.Netty 出现 Connection reset by peer 异常的几个原因
2.linux下安装tcpdump并用其抓包
3.你不知道的linux抓包神器—— tcpdump
4.在ESTABLISHED状态时,连接收到SYN会回复什么?

tcpdump源码

Netty 出现 Connection reset by peer 异常的几个原因

       æœ€è¿‘使用 netty 过程中发现了几个比较细节的 Connection reset by peer 异常,做个笔记。

        这个场景出现在用 Jedis ping 检测的场景,用完直接 close,服务端稳定出现 Connection reset by peer。

        tcpdump 一下就很容易定位到问题所在,客户端收到 PONG 响应后直接发了一个 RST 包给服务端:

        查看 Jedis 的源码发现 socket 有个比较特殊的配置 socket.setSoLinger(true, 0) 。

        先看一下 man7/socket.7 的解释:

        坦白说不是很明白啥意思。。。

        最终在 stackoverflow 上找到一个比较容易理解的解释:

        简而言之,设置 SO_LINGER(0) 可以不进行四次挥手直接关闭 TCP 连接,在协议交互上就是直接发 RST 包,这样的好处是可以避免长时间处于 TIME_WAIT 状态,当然 TIME_WAIT 存在也是有原因的,大部分评论都不建议这样配置。

        这个场景有点儿微妙,首先得理解一下 tcp 的两个队列。

        这篇文章讲得比较清楚: SYN packet handling in the wild

        accept 队列满通常是由于 netty boss 线程处理慢,特别是在容器化之后,服务刚启动的时候很容易出现 CPU 受限。

        为了模拟这个现象,我写了个示例程序 shichaoyuan/netty-backlog-test ,设置 SO_BACKLOG 为 1,并且在 accept 第一个连接后设置 autoRead 为 false,也就是让 boss 线程不再继续 accept 连接。

        启动第一个 Client,可以正常连接,发送 PING,接收 PONG。

        启动第二个 Client,也可以正常连接,但是没有收到 PONG:

        可见这个连接创建成功了,已经在 Accept Queue 里了,但是进程没有 accept,所以没有与进程绑定。

        启动第三个 Client,也可以正常连接,也没有收到 PONG:

        与第二个连接一样。

        启动第四个 Client,也可以正常连接,但是在发送 PING 后出现 Connection reset by peer:

        这个连接在服务端并没有进入 accept queue,处于 SYN_RECV 状态,并且很快就消失了(因为 accept queue 已经满了,无法转入 ESTABLISHED 状态)。

        抓包看一下:

        从客户端视角来看连接确实是建成功了,有一个比较特殊的地方在三次握手之后,服务端又向客户端发送了一个 [S.],客户端回复了一个 [.],这个交互看起来不影响连接。

        服务端后来销毁了连接,而客户端还认为连接是 ESTABLISHED 的,发送 PING 消息,服务端自然得回复一个 RST。

        PS:我在 Windows 的 WSL2 中实验这种场景是建连接超时,可能不同的操作系统或 linux 版本对这个交互的过程处理不同,在此不进行进一步测试了。

        以上,这个故事告诉我们判断连接是否可用,建成功之后应该发个心跳包测试一下。

linux下安装tcpdump并用其抓包

       在Linux环境中,为了深入探究网络协议,抓包分析数据是一种有效手段。尽管Windows用户可以轻松通过Wireshark进行抓包,但在Linux环境下,guiminer 源码尤其在空间有限或不支持Wireshark的版本中,安装和使用tcpdump成为更好的选择。本文将简述如何在Linux下安装tcpdump并进行抓包操作。

       首先,有两种安装tcpdump的方法。一是从源代码编译安装,可通过参考csdn博客(blog.csdn.net/tic_yx/article/details/...)获取详细的步骤。另一种更为便捷,就是在Ubuntu等系统中,通过命令行输入`sudo apt-get install tcpdump`,如果遇到安装问题,可以尝试更换国内的htmlapp项目实战源码软件源,如清华大学源。

       在使用tcpdump时,常用命令包括实时查看抓包信息,将捕获的数据保存为pcap文件以便后续分析,以及通过过滤指定端口号并保存至文件。这样,即使在Linux上完成抓包,也可以方便地将文件传输到Windows系统,利用Wireshark进行深入分析。

       总的来说,Wireshark提供了强大的抓包和分析功能,但在Linux环境中不便安装时,使用tcpdump进行抓包并导出至Windows进行后续处理,不失为一个实用且灵活的解决方案。

你不知道的linux抓包神器—— tcpdump

       在Linux世界中,tcpdump这款神器就像一个无与伦比的网络数据侦探,为网络分析提供了强大的JAVA公司项目源码工具。让我们深入了解这款工具及其众多强大的参数,它们将帮助你洞察网络世界的每一个细节。

-a:当你想要揭示网络的真实名字而非地址时,这个选项派上用场,让你的报告更具人性化。

-d, -dd, -ddd:想要深入到数据包的底层?这些选项分别展示了汇编、C语言代码和十进制代码,揭示了数据包的构造秘密。

-e:显示链路和网络层的头部信息,让你瞬间明白数据包的旅程起点和终点。

-n, -nn:增强细节呈现,nn选项甚至会揭示IP地址和端口,让你对数据包的交互了如指掌。

-t:如果时间不是你的关注点,-t则会移除包的发送时间,让关键信息更突出。

-v,网址打包iapp源码 -vv:从常规输出到深度解析,vv让你能够深入探究每个报文的来龙去脉。

-c:定义抓包数量限制,让你对流量进行精细管理。

-F:这个选项允许你自定义过滤规则,让你的抓包更具针对性。

-i:指定你感兴趣的网络接口,确保只捕获你需要的数据。

-p:非混杂模式下,只捕获指定接口的流量,提高抓包效率。

-r, -w:分别用于读取和写入包文件,为数据备份或长期分析提供方便。

-s:控制抓包的包大小,节省存储空间,同时保持关键信息完整。

-T:将报文类型进行解释,让你快速识别关键类型的怎样读PHP源码数据。

-X:原样显示协议,保留原始格式,方便深入理解协议细节。

       此外,学习之路并非孤立,加入我们的交流群,前名成员将有机会获得内核资料包的馈赠。这里有丰富的学习资源,如内核技术解析视频、源码解析,以及深入的Linux内核系统学习课程,助你提升网络知识。

       在实战中,你可以用tcpdump less greater 来过滤出大于字节且小于字节的报文,然后保存到文件或实时查看。抓取特定端口数据也轻而易举,比如跟踪..1.的端口交互,或者指定源/目的网段(如.//.)。通过观察数据包,你可以清晰地看到三次握手的整个过程,包括SYN(带有S标志)和SYN-ACK(带有S.标志)的发送和接收。

       总之,tcpdump是Linux网络分析的得力助手,通过掌握这些参数和技巧,你将能深入解析网络行为,解锁更多可能。现在就拿起你的工具,开始探索网络的无限奥秘吧!

在ESTABLISHED状态时,连接收到SYN会回复什么?

       最初的问题,读者在阅读我关于《TCP RST 攻击与如何杀掉一条 TCP 连接》时提出,即处于 ESTABLISHED状态的连接为什么还需要响应 SYN 包?接下来,我们通过实验、内核源码分析与工具介绍,详细解答这一问题。

       实验复现

       在机器 A(IP:...)使用 nc 启动服务监听 端口。同时,机器 B 使用 nc 连接 A 的 nc 服务器,并输入 "hello"。通过 tcpdump 观察此次连接信息。随后,机器 B 使用 scapy 模拟发送 SYN 包,并查看 tcpdump 显示的包结果。实验发现,对于一个序列号为随意的 SYN 包,TCP 回复了正确的 ACK 包,确认号为 。RFC 文档也指出,Linux 内核收到乱序 SYN 报文时,会回复携带正确序列号和确认号的 ACK 包,即 Challenge ACK。

       原因分析

       发送 SYN 包的一端记为 A,接收 SYN 的 ESTABLISHED 状态端记为 B。B 对收到的 SYN 包回复 ACK 的目的是验证先前的连接是否失效,以便采取相应处理。若 A 的连接仍在,则正常处理 ACK 包。若连接已不在,此 SYN 包试图发起新连接,收到 ACK 后,A 会立即回复 RST 包,序列号等于 ACK 包的序列号,B 收到合法的 RST 包后释放连接。若 A 想重新与 B 创建连接,则可再次发送 SYN 包。

       内核源码分析

       使用 SystemTap 工具插入探针,观察内核函数 tcp_send_ack 的调用过程。在端口号为 时,打印函数调用堆栈。通过 SystemTap 脚本执行后,发现 ACK 包经过了 tcp_validate_incoming 和 tcp_send_challenge_ack 函数。RFC 提出了 ACK Throttling 方案,限制每秒最多发送 个 Challenge ACK 报文,通过 sysctl 函数可以调整此限制。

       RST 攻击

       RST 攻击通过伪造 RST 包关闭正常连接。攻击难点在于构造序列号落在对方滑动窗口内的包。实验中,启动 tcpkill 工具并发送 RST 包,观察服务端与客户端进程退出。tcpkill 通过 libpcap 库抓取符合条件的包,从而获取序列号,伪造 IP 发送 RST 包。此外,介绍 killcx 工具,用于处理僵死连接。

       工具介绍

       杀掉 TCP 连接的工具包括 tcpkill 和 killcx。tcpkill 假冒 IP 发送 RST 包,依赖有数据传输的连接才能获取序列号。killcx 是一个 perl 编写的脚本,可以在任何 TCP 连接状态下关闭连接。

       总结,本文通过实验、内核源码分析和工具介绍,详细解答了 ESTABLISHED 状态连接为何响应 SYN 包,以及如何使用 Challenge ACK、ACK Throttling、tcpkill 和 killcx 来处理相关连接问题。

copyright © 2016 powered by 皮皮网   sitemap