tcpdump抓包与分析

2022-10-09 11:58:16

Tcpdump抓包

直接抓个网址先把，然后再来分析，首先抓取访问某个网站时的网络数据。比如网站 https://www.sina.com.cn/ 怎么做？**

. 1、通过tcpdump截获主机www.sina.com.cn发送与接收所有的数据包
```
 tcpdump -i ens33 host www.sina.com.cn
```

2.接着触发访问新浪网站（开多一个输出端口）
```
  - wget www.sina.com.cn
```

如果想要看详细的http报文，并且又想将转到的包保存在文件中和查看包文件应该怎么做呢？

1、首先输入命令

 tcpdump -A -i ens33 -w sinaFile host www.sina.com.cn

2、访问网站，输入命令

 - wget www.sina.com.cn

3、查看抓包文件，输入命令

 - tcpdump -A -r sinaFile

抓包成功之后抓包输出端不会像上面那个抓包一样直接将包的数据输出到输出端上，但保存的文件路径上会有多出一个抓包成功的文件（我操作的命令的时候把文件保存到桌面，所以我直接在桌面找就行了）

抓取tcp包分析

TCP传输控制协议是面向连接的可靠的传输层协议，在进行数据传输之前，需要在传输数据的两端（客户端和服务器端）创建一个连接，这个连接由一对插口地址唯一标识，即是在IP报文首部的源IP地址、目的IP地址，以及TCP数据报首部的源端口地址和目的端口地址。TCP首部结构如下：

注意：通常情况下，一个正常的TCP连接，都会有三个阶段:1、TCP三次握手;2、数据传送;3、TCP四次挥手

其中在TCP连接和断开连接过程中的关键部分如下：
源端口号：即发送方的端口号，在TCP连接过程中，对于客户端，端口号往往由内核分配，无需进程指定；
目的端口号：即发送目的的端口号；
序号：即为发送的数据段首个字节的序号；
确认序号：在收到对方发来的数据报，发送确认时期待对方下一次发送的数据序号；
SYN：同步序列编号，ACK：确认编号，FIN：结束标志

TCP三次握手

三次握手的过程如下：

step1.
由客户端向服务器端发起TCP连接请求。Client发送：同步序列编号SYN置为1，发送序号Seq为一个随机数，这里假设为X，确认序号ACK置为0；
step2.
服务器端接收到连接请求。Server响应：同步序列编号SYN置为1，并将确认序号ACK置为X+1，然后生成一个随机数Y作为发送序号Seq（因为所确认的数据报的确认序号未初始化）；
step3.
客户端对接收到的确认进行确认。Client发送：将确认序号ACK置为Y+1，然后将发送序号Seq置为X+1（即为接收到的数据报的确认序号）；

为什么是三次握手而不是两次对于step3的作用，假设一种情况，客户端A向服务器B发送一个连接请求数据报，然后这个数据报在网络中滞留导致其迟到了，虽然迟到了，但是服务器仍然会接收并发回一个确认数据报。但是A却因为久久收不到B的确认而将发送的请求连接置为失效，等到一段时间后，接到B发送过来的确认，A认为自己现在没有发送连接，而B却一直以为连接成功了，于是一直在等待A的动作，而A将不会有任何的动作了。这会导致服务器资源白白浪费掉了，因此，两次握手是不行的，因此需要再加上一次，对B发过来的确认再进行一次确认，即确认这次连接是有效的，从而建立连接。

对于双方，发送序号的初始化为何值有的系统中是显式的初始化序号是0，但是这种已知的初始化值是非常危险的，因为这会使得一些黑客钻漏洞，发送一些数据报来破坏连接。因此，初始化序号因为取随机数会更好一些，并且是越随机越安全。

TCP四次挥手

连接双方在完成数据传输之后就需要断开连接。由于TCP连接是属于全双工的，即连接双方可以在一条TCP连接上互相传输数据，因此在断开时存在一个半关闭状态，即有有一方失去发送数据的能力，却还能接收数据。因此，断开连接需要分为四次。主要过程如下：

step1. 主机A向主机B发起断开连接请求，之后主机A进入FIN-WAIT-1状态；
step2. 主机B收到主机A的请求后，向主机A发回确认，然后进入CLOSE-WAIT状态；
step3.
主机A收到B的确认之后，进入FIN-WAIT-2状态，此时便是半关闭状态，即主机A失去发送能力，但是主机B却还能向A发送数据，并且A可以接收数据。此时主机B占主导位置了，如果需要继续关闭则需要主机B来操作了；
step4. 主机B向A发出断开连接请求，然后进入LAST-ACK状态；
step5.
主机A接收到请求后发送确认，进入TIME-WAIT状态，等待2MSL之后进入CLOSED状态，而主机B则在接受到确认后进入CLOSED状态；

为何主机A在发送了最后的确认后没有进入CLOSED状态，反而进入了一个等待2MSL的TIME-WAIT主要作用有两个：
第一，确保主机A最后发送的确认能够到达主机B。如果处于LAST-ACK状态的主机B一直收不到来自主机A的确认，它会重传断开连接请求，然后主机A就可以有足够的时间去再次发送确认。但是这也只能尽最大力量来确保能够正常断开，如果主机A的确认总是在网络中滞留失效，从而超过了2MSL，最后也无法正常断开；
第二，如果主机A在发送了确认之后立即进入CLOSED状态。假设之后主机A再次向主机B发送一条连接请求，而这条连接请求比之前的确认报文更早地到达主机B，则会使得主机B以为这条连接请求是在旧的连接中A发出的报文，并不看成是一条新的连接请求了，即使得这个连接请求失效了，增加2MSL的时间可以使得这个失效的连接请求报文作废，这样才不影响下次新的连接请求中出现失效的连接请求。

为什么断开连接请求报文只有三个，而不是四个因为在TCP连接过程中，确认的发送有一个延时（即经受延时的确认），一端在发送确认的时候将等待一段时间，如果自己在这段事件内也有数据要发送，就跟确认一起发送，如果没有，则确认单独发送。而我们的抓包实验中，由服务器端先断开连接，之后客户端在确认的延迟时间内，也有请求断开连接需要发送，于是就与上次确认一起发送，因此就只有三个数据报了。