tcpdump 基本分析

转载自  https://blog.youkuaiyun.com/a19881029/article/details/38091243

原文见:http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers/

 

如果你正在读这篇文章,很可能你对TCP“非著名”的“三次握手”或者说“SYN,SYN/ACK,ACK”已经很熟悉了。不幸的是,对很多人来说,对TCP的学习就仅限于此了。尽管年代久远,TCP仍是一个相当复杂并且值得研究的协议。这篇文章的目的是让你能够更加熟练的检查Wireshark中的TCP序列号和确认号

在我们开始之前,确保在Wireshark中打开示例(请到作者原文中下载)并亲自实践一下

示例中仅包含一个单独的HTTP请求,请求的流程是:web浏览器向web服务器请求一个单独的图片文件,服务器返回一个成功的响应(HTTP/1.1200 OK),响应中包含请求的文件。右键示例文件中任意一个TCP包并且选择Follow TCP Stream就可在单独的窗口查看原始的TCP流

客户端请求使用红色显示,服务端响应使用蓝色显示

TCP三次握手(参见:http://blog.youkuaiyun.com/a19881029/article/details/30241561

TCP在其协议头中使用大量的标志位或者说1位(bit)布尔域来控制连接状态,我们最感兴趣的3个标志位如下:

SYN - 创建一个连接

FIN -  终结一个连接

ACK - 确认接收到的数据

就像我们看见的那样,一个包中有可以设置多个标志位

选择Wireshark中的“包”1并且展开中间面板的TCP层解析,然后展开TCP头中的标志位域,这里我们可以看见所有解析出来的TCP标志位,需要注意的是,“包1”设置了SYN标志位

使用同样的方式操作“包2”。可以看到"包2"设置了2个标志位:ACK - 用来确认收到客户端的SYN包,SYN - 用来表明服务端也希望建立TCP连接

从客户端发来的“包3”只设置了ACK标志位。这3个包完成了最初的TCP3次握手

序列号和确认号

TCP会话的每一端都包含一个32位(bit)的序列号,该序列号被用来跟踪该端发送的数据量。每一个包中都包含序列号,在接收端则通过确认号用来通知发送端数据成功接收

当某个主机开启一个TCP会话时,他的初始序列号是随机的,可能是0和4,294,967,295之间的任意值,然而,像Wireshark这种工具,通常显示的都是相对序列号/确认号,而不是实际序列号/确认号,相对序列号/确认号是和TCP会话的初始序列号相关联的。这是很方便的,因为比起真实序列号/确认号,跟踪更小的相对序列号/确认号会相对容易一些

比如,在“包1”中,最初的相对序列号的值是0,但是最下方面板中的ASCII码显示真实序列号的值是0xf61c6cbe,转化为10进制为4129057982

如果想要关闭相对序列号/确认号,可以选择Wireshark菜单栏中的 Edit -> Preferences ->protocols ->TCP,去掉Relative sequence number后面勾选框中的√即可

需要注意的是,文章接下来的部分依然使用相对序列号/确认号

为了更好的理解在整个TCP会话期间,TCP序列号和确认号是如何工作的,我们可以使用Wireshark内置的绘制流功能,选择菜单栏中的 Statistics ->Flow Graph...->TCP flow ->OK

Wireshark会自动创建一个TCP流的图形摘要

每行代表一个单独的TCP包,左边列显示时间,中间列显示包的方向、TCP端口、段长度和设置的标志位,右边列以10进制的方式显示相关序列号/确认号,在这里选中任意行会高亮主窗口中该行所关联的包

我们可以利用这个流图更好的理解序列号和确认号是如何工作的

包1

TCP会话的每一端的序列号都从0开始,同样的,确认号也从0开始,因为此时通话还未开始,没有通话的另一端需要确认(我使用的Wireshark版本和原作者不同,Wireshark1.10.2中,包1不显示确认号)

包2

服务端响应客户端的请求,响应中附带序列号0(由于这是服务端在该次TCP会话中发送的第一个包,所以序列号为0)和相对确认号1(表明服务端收到了客户端发送的包1中的SYN)

需要注意的是,尽管客户端没有发送任何有效数据,确认号还是被加1,这是因为接收的包中包含SYN或FIN标志位(并不会对有效数据的计数产生影响,因为含有SYN或FIN标志位的包并不携带有效数据)

包3

和包2中一样,客户端使用确认号1响应服务端的序列号0,同时响应中也包含了客户端自己的序列号(由于服务端发送的包中确认收到了客户端发送的SYN,故客户端的序列号由0变为1)

此时,通信的两端的序列号都为1,通信两端的序列号增1发生在所有TCP会话的建立过程中

包4

这是流中第一个携带有效数据的包(确切的说,是客户端发送的HTTP请求),序列号依然为1,因为到上个包为止,还没有发送任何数据,确认号也保持1不变,因为客户端没有从服务端接收到任何数据

需要注意的是,包中有效数据的长度为725字节

包5

当上层处理HTTP请求时,服务端发送该包来确认客户端在包4中发来的数据,需要注意的是,确认号的值增加了725(725是包4中有效数据长度),变为726,简单来说,服务端以此来告知客户端端,目前为止,我总共收到了726字节的数据,服务端的序列号保持为1不变

包6

这个包标志着服务端返回HTTP响应的开始,序列号依然为1,因为服务端在该包之前返回的包中都不带有有效数据,该包带有1448字节的有效数据

包7

由于上个数据包的发送,TCP客户端的序列号增长至726,从服务端接收了1448字节的数据,客户端的确认号由1增长至1449

在抓包文件的主体部分,我们可以看到上述过程的不断的重复,客户端的序列号一直是726,因为客户端除了最初的725字节数据没有再向服务端发送数据,服务端的序列号则与此相反,由于服务端不断的发送HTTP响应,故其序列号一直在增长

序列号为当前端成功发送的数据位数,确认号为当前端成功接收的数据位数,SYN标志位和FIN标志位也要占1位

关闭连接

包38

在确认了服务端发送过来的最后一个数据段之后,客户端将处理整个HTTP响应并决定不需要进一步通信了。此时客户端发送设置了FIN标志位的包38,其确认号和之前的包37一样

包39

服务端通过将确认号加1的方式回应客户端期望关闭连接的请求(这里和包2中确认SYN标志位时所作的操作是一样的),同时设置当前包的FIN标志位

包40

客户端发送最终序列号727,通过将确认号加1的方式确认服务端的FIN包

此时,通信双方都终结了会话并且可以释放用于维持会话所占用的资源

 

 

 

在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN, FIN, ACK, PSH, RST, URG.
其中,对于我们日常的分析有用的就是前面的五个字段。

它们的含义是:

URG:Urget pointer is valid (紧急指针字段值有效)

SYN: 表示建立连接

FIN: 表示关闭连接

ACK: 表示响应

PSH: 表示有 DATA数据传输

RST: 表示连接重置。


其中,ACK是可能与SYN,FIN等同时使用的,比如SYN和ACK可能同时为1,它表示的就是建立连接之后的响应,如果只是单个的一个SYN,它表示的只是建立连接。TCP的几次握手就是通过这样的ACK表现出来的。但SYN与FIN是不会同时为1的,因为前者表示的是建立连接,而后者表示的是断开连接。RST一般是在FIN之后才会出现为1的情况,表示的是连接重置。一般地,当出现FIN包或RST包时,我们便认为客户端与服务器端断开了连接;而当出现SYN和SYN+ACK包时,我们认为客户端与服务器建立了一个连接。PSH为1的情况,一般只出现在 DATA内容不为0的包中,也就是说PSH为1表示的是有真正的TCP数据包内容被传递。

 

 

man 

https://man7.org/linux/man-pages/man7/tcp.7.html

 

tcp参数调优

https://www.cnblogs.com/pangguoping/p/5830328.html

 

 https://packetbomb.com/understanding-throughput-and-tcp-windows/

<think>我们正在讨论使用tcpdump进行网络包抓取和分析的方法。根据用户的问题,我们需要结合引用内容来回答。 引用[1]提到tcpdump是一个功能强大的网络流量捕获和分析工具,并强调了它在日常运维和故障排查中的重要性。 引用[2]给出了一个具体的例子,使用tcpdump抓取HTTP包的命令,其中使用了复杂的过滤表达式。 引用[3]则提到了结合Wireshark进行抓包分析,以及如何查看HTTP请求和DNS查询的详细信息。 因此,我们的回答应该包括: 1. tcpdump基本用法(如何启动捕获、常用选项) 2. 过滤表达式的使用(特别是根据协议、端口、主机等过滤) 3. 结合HTTP抓包的具体例子(如引用[2]所示) 4. 如何将捕获的数据包导入Wireshark进行更深入的分析(如引用[3]所示) 注意:用户要求使用中文回答,并且按照给定的格式要求(行内公式用$...$,独立公式用$$...$$,但本问题可能不涉及数学公式,所以可以忽略公式部分,但如果有需要,比如数据包长度计算等,再考虑使用公式)。 另外,根据系统级指令,我们需要在回答末尾生成相关问题。 下面开始组织回答:</think>### 使用 tcpdump 进行网络包抓取与分析的方法 #### 1. **基础抓包命令** - **捕获所有流量** ```bash tcpdump -i any -w capture.pcap ``` - `-i any`:监听所有网卡 - `-w capture.pcap`:将原始数据保存到文件(推荐优先保存原始数据再分析)[^1] - **指定网卡和数量** ```bash tcpdump -i eth0 -c 100 -vvv ``` - `-c 100`:捕获100个包后自动停止 - `-vvv`:显示最详细的数据包头信息 #### 2. **关键过滤技巧** - **协议过滤** ```bash tcpdump tcp # 只抓TCP包 tcpdump icmp # 只抓ICMP包 tcpdump port 80 # 抓取80端口流量 ``` - **主机/IP过滤** ```bash tcpdump host 192.168.1.100 # 抓取特定IP流量 tcpdump src 192.168.1.1 and dst 80 # 抓取源IP到目标80端口的流量 ``` - **高级内容过滤** ```bash tcpdump 'tcp[20:2]=0x4745' # 抓取HTTP GET请求(匹配"GE") tcpdump 'tcp[20:2]=0x504f' # 抓取HTTP POST请求(匹配"PO") ``` 通过偏移量匹配数据包载荷的特定字节(如HTTP方法)[^2] #### 3. **输出解析与增强** - **关键选项** `-X`:十六进制+ASCII格式显示载荷 `-n`:禁用域名解析(显示原始IP) `-l`:行缓冲输出(实时查看) 示例: ```bash tcpdump -nX tcp port 443 ``` - **典型输出解析** ``` 10:23:01.512 IP 192.168.1.10.54892 > 203.0.113.5.443: Flags [P.], seq 1:518, ack 1, win 502 0x0000: 4500 022e 0000 4000 4006 d8c0 c0a8 010a E....@.@....... 0x0010: cb00 7105 d66c 01bb 5018 01f6 3e7d 0000 ..q..l..P...>}.. ``` - `Flags [P.]`:带数据的TCP包(PUSH标志) - `seq 1:518`:数据序号范围 - 十六进制部分:包含IP头、TCP头和应用层数据 #### 4. **高级分析技巧** - **流量统计** ```bash tcpdump -r capture.pcap -q -n | awk '{print $3}' | sort | uniq -c | sort -nr ``` 统计目标IP的流量排名 - **结合Wireshark** 1. 保存为pcap文件:`tcpdump -w output.pcap` 2. 用Wireshark图形化分析: - 可视化流量时序图 - 解析HTTP/DNS等协议 - 提取文件传输内容[^3] - **抓取HTTP请求头** ```bash tcpdump -A -s0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' ``` 通过计算载荷长度过滤非空HTTP包 #### 5. **故障排查场景** - **TCP连接问题** ```bash tcpdump -nn "tcp[tcpflags] & (tcp-syn|tcp-ack) != 0" ``` 抓取SYN和ACK包分析三次握手 - **DNS解析问题** ```bash tcpdump -n udp port 53 ``` 直接查看DNS请求响应内容 - **HTTP响应延迟** ```bash tcpdump -ttt -s0 -l -n port 80 | grep "HTTP/1.[01]" ``` 显示请求间时间间隔(`-ttt`选项) > **最佳实践**: > - 生产环境先用`-w`保存原始数据,避免终端输出丢失 > - 复杂分析时结合`tshark`(Wireshark命令行工具)解析高级协议字段 > - 敏感数据抓包需遵守安全合规要求
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值