【tcpdump】详细解读网络数据包

最新推荐文章于 2024-08-18 21:24:04 发布

QAQiiii

最新推荐文章于 2024-08-18 21:24:04 发布

阅读量672

点赞数

分类专栏：网络文章标签：网络 tcpdump tcp/ip

本文链接：https://blog.csdn.net/QAQiiii/article/details/131453136

版权

网络专栏收录该内容

2 篇文章 0 订阅

订阅专栏

详细解读抓取的数据包

前提知识：

什么是三次握手和四次挥手?
三次握手和四次挥手是在 TCP 协议中用于建立和终止连接的过程。

三次握手是在客户端和服务器之间建立连接时使用的过程。该过程包括以下步骤：

客户端向服务器发送一个连接请求报文段，其中包含一个随机生成的序列号（SYN标志位被设置为1）。
服务器接收到请求后，向客户端发送一个确认报文段，其中包含服务器的序列号和一个确认号（SYN和ACK标志位都被设置为1）。
客户端接收到服务器的确认后，再向服务器发送一个确认报文段，其中包含客户端的序列号和确认号（ACK标志位被设置为1）。通过这个过程，客户端和服务器之间建立了一个可靠的连接，可以开始数据传输。

四次挥手是在连接关闭时使用的过程。该过程包括以下步骤：

客户端向服务器发送一个连接终止请求报文段，其中的标志位被设置为FIN=1。 2 .服务器接收到请求后，发送一个确认报文段给客户端，确认接收到了客户端的终止请求。
服务器发送一个连接终止请求报文段给客户端，标志位被设置为FIN=1。
客户端接收到服务器的终止请求后，发送一个确认报文段给服务器，确认已收到服务器的终止请求。通过这个过程，客户端和服务器结束了数据传输并关闭了连接。

以上是三次握手和四次挥手的基本过程。这些步骤是确保在数据传输前后都建立和终止连接的关键步骤。

验证过程:

使用到的命令

[root@hai-10037 ~]# curl www.baidu.com 
[root@hai-10037 ~]# sudo tcpdump -i eth0 -n 'tcp port 80'

tcpdump抓取客户端(本台机器) ->服务端(百度)的过程

[root@hai-10037 ~]# sudo tcpdump -i eth0 -n 'tcp port 80'
10:41:25.747450 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [S], seq 3227911074, win 29200, options [mss 1460,sackOK,TS val 1531931768 ecr 0,nop,wscale 7], length 0
10:41:25.759068 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [S.], seq 1377203765, ack 3227911075, win 8192, options [mss 1452,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0
10:41:25.759119 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [.], ack 1, win 229, length 0
10:41:25.759187 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [P.], seq 1:78, ack 1, win 229, length 77: HTTP: GET / HTTP/1.1
10:41:25.770904 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [.], ack 78, win 908, length 0
10:41:25.771920 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [P.], seq 1:2782, ack 78, win 908, length 2781: HTTP: HTTP/1.1 200 OK
10:41:25.771935 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [.], ack 2782, win 272, length 0
10:41:25.772078 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [F.], seq 78, ack 2782, win 272, length 0
10:41:25.781341 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [P.], seq 1453:2782, ack 78, win 908, length 1329: HTTP
10:41:25.781370 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [.], ack 2782, win 272, options [nop,nop,sack 1 {1453:2782}], length 0
10:41:25.783744 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [.], ack 79, win 908, length 0
10:41:25.783747 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [F.], seq 2782, ack 79, win 908, length 0
10:41:25.783795 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [.], ack 2783, win 272, length 0

为了解释方便我为每个过程进行了标号

 1   10:41:25.747450 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [S], seq 3227911074, win 29200, options [mss 1460,sackOK,TS val 1531931768 ecr 0,nop,wscale 7], length 0
 2   10:41:25.759068 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [S.], seq 1377203765, ack 3227911075, win  8192, options [mss 1452,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0
 3   10:41:25.759119 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [.], ack 1, win 229, length 0
 4   10:41:25.759187 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [P.], seq 1:78, ack 1, win 229, length 77: HTTP: GET / HTTP/1.1
 5   10:41:25.770904 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [.], ack 78, win 908, length 0
 6   10:41:25.771920 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [P.], seq 1:2782, ack 78, win 908, length 2781: HTTP: HTTP/1.1 200 OK
 7   10:41:25.771935 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [.], ack 2782, win 272, length 0
 8   10:41:25.772078 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [F.], seq 78, ack 2782, win 272, length 0
 9   10:41:25.781341 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [P.], seq 1453:2782, ack 78, win 908, length 1329: HTTP
 10  10:41:25.781370 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [.], ack 2782, win 272, options [nop,nop,sack 1 {1453:2782}], length 0
 11  10:41:25.783744 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [.], ack 79, win 908, length 0
 12  10:41:25.783747 IP 110.242.68.3.http > 192.168.0.248.41526: Flags [F.], seq 2782, ack 79, win 908, length 0
 13  10:41:25.783795 IP 192.168.0.248.41526 > 110.242.68.3.http: Flags [.], ack 2783, win 272, length 0

在 TCP 协议中，标志位（Flags）用于在 TCP 报文头部中传递特定的信息。下面是常用的 TCP 标志位：

SYN (Synchronize)：用于建立连接时发起连接请求。
ACK (Acknowledgment)：用于确认接收到的数据包。
PSH (Push)：表示紧急数据。
RST (Reset)：用于重置连接。
FIN (Finish)：用于关闭连接。
URG (Urgent)：指示这个包中存在紧急数据。
ECE (Explicit Congestion Notification Echo)：回送拥塞通知的标志位。
CWR (Congestion Window Reduce)：用于通知对方减少拥塞窗口大小。

这些标志位可以单独或组合使用，以进行不同的 TCP 功能和操作。例如，建立连接时通常使用 SYN 标志位，关闭连接时使用 FIN 标志位。

1-3是三次握手的过程

客户端（IP地址为192.168.0.248）向服务端（IP地址为110.242.68.3）发起连接的请求（SYN标志）。这个数据包的序列号为3227911074。
服务端作为回应（SYN-ACK标志）回复客户端的连接请求。这个数据包的序列号为1377203765，并确认了客户端的序列号3227911074。
客户端收到服务器的回复后发送的一个确认数据包（ACK标志）。

4-7是http请求和响应过程

客户端发送一个带有HTTP GET请求的数据包。
服务端收到客户端的HTTP GET请求后发送的一个确认数据包。
服务端发送HTTP响应的数据包，其中包含了HTTP/1.1 200 OK的响应头和主体内容。第7条数据包是客户端收到从服务端发送的HTTP响应数据包后发送的确认数据包。
客户端收到从服务端发送的HTTP响应数据包后发送的确认数据包。

8-13是四次挥手过程

第8条数据包是客户端发送的一个带有FIN标志的数据包，表示客户端希望关闭连接。
第9条数据包是服务端在收到客户端关闭连接请求后，将剩余的响应数据发送给客户端。
第10条数据包是客户端发送的确认数据包，表明它已经接收到了服务端发送的数据，并请求服务端断开连接。
第11条数据包是服务端发送的一个空的确认数据包（ACK标志），用于确认客户端发送的断开连接请求。
第12条数据包是服务端发送的一个带有FIN标志的数据包（FIN-ACK标志），表示服务端也希望关闭连接。这个数据包的序列号为2782，确认了客户端发送的序列号为79的数据包。
第13条数据包是客户端收到服务端发送的关闭连接请求后发送的一个确认数据包（ACK标志），用于确认服务端发送的断开连接请求。

为什么以上四次挥手过会有6条过程而不是4条过程？

因为第9条和第10条中是延迟引起的，并且在断开连接的过程中，服务端可能会继续发送数据包，直到接收到客户端发送的确认信号为止。其中TCP协议的断开连接过程是一个两步握手的过程。即客户端首先发送断开连接请求，然后服务端发送确认信号以及剩余的数据（如果有的话），最后客户端发送确认信号以完成断开连接。因此，在这个过程中，服务端仍然会发送数据包，直到最终的断开连接完成。

第9条和第10条之间的时间延迟可能是由于以下几种情况导致的：

网络延迟：网络中的数据传输需要一定的时间，可能会导致数据包在传输过程中有一定的延迟。这种延迟可能导致服务端在接收到断开连接请求之前继续发送数据。

服务端处理时间过长：在收到客户端发送的断开连接请求时，服务端可能还在处理之前的请求，例如发送响应数据。如果服务端的处理时间较长，可能会导致服务端在收到断开连接请求之前继续发送数据。

延迟确认（Delayed Acknowledgement）：TCP协议中的延迟确认机制可以推迟发送确认数据包，直到达到一个固定的时间间隔。这个机制被设计用来减少确认数据包的数量，从而提高网络传输效率。在这种情况下，服务端可能会延迟发送确认数据包，导致客户端继续发送确认数据包请求断开连接。

不同操作系统或设备的差异：不同操作系统或设备对于数据包传输和处理的方式可能存在差异。这些差异可能导致服务端在接收到断开连接请求之前继续发送数据。