如何通过Wireshark抓包深入的分析TCP 3次握手、4次挥手过程

分手后的思念是犯贱 2021-12-01 10:46 135阅读 0赞

原文地址：https://blog.csdn.net/weixin\_36794678/article/details/81491121

## 以下用到的符号解释： ##

（1）seq序号:占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。它的初始序号是随机的，相对序号/确认序号是和TCP会话的初始序号相关联的。该序号被用来跟踪该端发送的数据量。每一个包中都包含序号，在接收端则通过确认序号用来通知发送端数据成功接收。

（2）确认序号：ack序号，占32位，只有ACK标志位为1时（不要将确认序号ack与标志位中的ACK弄混了），确认序号才有效。确认方ack = 发起方seq +1，两端配对。

（3）位码即TCP标志位，有6种，具体含义如下：

SYN(synchronous建立连接) 发起一个新连接

ACK(acknowledgement 表示响应、确认) 确认序号有效

PSH(push表示有DATA数据传输) 接收方应尽快将这个报文交给应用层

FIN(finish关闭连接) 释放一个连接

RST(reset表示连接重置)

URG(urgent pointer紧急指针字段值有效)

## 三次握手： ##

分析的前提：安装wireshark抓包分析工具

抓取的数据包如下：

![aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjExNDQ0MjktMTEyNjUyMTgxMy5wbmc][]

从红框看出是一次完整的TCP建立链接的过程:  
1.客户端先向服务端80端口发送一个syn标志位，5774->80 seq=x  
2.服务端接收到请求，返回一个数据包syn标志位为1，ACK位置为客户端x+1,seq=y,通知客户端，80端口开放，为了保证数据传输可靠性，5774端口务必打开。  
3.客户端再一次向服务端发送一个数据包的ACK=y+1,Seq=x+1,5774->80，到此TCP链接建立完成。

以下为数据版各个字段：

![aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMTI1NTA5NDQtMTk3NzU5MDI3OC5wbmc][]

其中：16进制数据的ascii码解释，0000，0010,0020,0030就是16进制的地址。

左边的框框第一行是数据包整体概述，第二行是以太网这一层（链路层）的详细信息，最主要的是双方的mac地址，第三行是网络层（网际层）的详细信息，最主要的是双方的IP地址，第四行是传输层的详细信息，最主要的是双方的端口号。

每一层都有一个字段指向上一层，发包的时候会在数据上依次加上应用层、传输层、网络层、链路层的头部，但是对方收到数据包后是从最底层（链路层）开始层层剥去头部解包的，所以在每层上有一个字段指向上层表明上层的协议，对方就知道下一步该怎么解包。

![aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMTU0MzQ5MjktMTcxMTI2NDg4MC5wbmc][]

![aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMTU0NTc3ODgtMTEwNDE4MDg2MS5wbmc][]

由于建立TCP连接用不到应用层协议，所以传输层就没有相应的指明上层(应用层)的字段了。

下面更直观地感受一下，三次握手过程中标志位的变化情况，首先客户端发送的数据包syn位置1，然后服务器端回复的数据包syn位置1，ack位置1，最后客户端发送的数据包ack位置1.以下三幅图分别为TCP三次握手的数据包中传输层的标志位字段

![aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjA2MTEyNzItMTExMDQwMDY5MC5wbmc][]

![aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjA2MjM4OTctMTc0NzM3MjAzMi5wbmc][]

![aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjA2MzI1NTQtMTM4NjgxMzU1Ny5wbmc][]

**问题扩展：为什么不能用两次握手进行连接？**

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。  
       现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

## 四次挥手： ##

所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。中断连接端可以是Client端，也可以是Server端。

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

四次挥手分析图如下：

![aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjEzMjA1NjktNzc1MTYxNDQ3LnBuZw][]

从图可见：

1.客户端向服务端停止提出链接请求 5775->80 FIN =1  ACK =0 SEQ=0  
2.服务端接收到请求 ACK=1  80->5775  
3. 服务端向客户端提出停止连接请求，FIN = 1 5775->80  
4. 客户端收到，ACK = 1  80->5775

详细图解：

![70][]

(1)第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN\_WAIT\_1状态。

(2)第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE\_WAIT状态。

(3)第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST\_ACK状态。

(4)第四次挥手：Client收到FIN后，Client进入TIME\_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

**问题拓展：为什么建立连接是三次握手，而关闭连接却是四次挥手呢？**

答：这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

[aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjExNDQ0MjktMTEyNjUyMTgxMy5wbmc]: /images/20211201/f1343cd8bc334135a95f6e2b67986fc1.png
[aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMTI1NTA5NDQtMTk3NzU5MDI3OC5wbmc]: /images/20211201/2b7c7006b7e840cab560b3da664c2038.png
[aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMTU0MzQ5MjktMTcxMTI2NDg4MC5wbmc]: /images/20211201/6de8a8ece28941c9acd58dacb22be9b2.png
[aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMTU0NTc3ODgtMTEwNDE4MDg2MS5wbmc]: /images/20211201/ae7c9e3484774cb8a1d81cb429569d2d.png
[aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjA2MTEyNzItMTExMDQwMDY5MC5wbmc]: /images/20211201/646897ecb4b14ea9ba8774b6766dcfcf.png
[aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjA2MjM4OTctMTc0NzM3MjAzMi5wbmc]: /images/20211201/95847c0c0d6c4c5ea98975e1d0ec9a91.png
[aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjA2MzI1NTQtMTM4NjgxMzU1Ny5wbmc]: /images/20211201/fd584fab76aa48e9a096ff49259f3ec4.png
[aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNjgxODYxLzIwMTUxMC82ODE4NjEtMjAxNTEwMTIwMjEzMjA1NjktNzc1MTYxNDQ3LnBuZw]: /images/20211201/3eb00586e6114c3c82d69ebe9a777e04.png
[70]: /images/20211201/ba6a91995538474cbc775dcd0a08ba3b.png