一、实验目的：

以“金庸梦“游戏的客户端连接服务器（10.1.230.41）、断开服务器为例，用wireshark抓包分析TCP协议的三次握手连接、四次握手断开，与计算机网络原理进行验证。
游戏客户端详见C#实现网游客户端与服务器的连接

二、TCP协议解析

1.连接建立
三次握手连接
在这里插入图片描述
三次握手过程分析：

（1）首先A向B发出连接请求报文段，这时首部中的同步位SYN=1。TCP规定，SYN报文段不能携带数据。这时，A进入SYN-SENT状态。
（2）B收到请求后，向A发送确认。在确认报文段中把SYN和ACK位都置为1。这时B进入SYN-RCVD状态。
（3）A收到B的确认后，还要向B给出确认。确认报文段的ACK置为1。这时，TCP连接已经建立，A进入ESTABLISHED 状态，当B收到A的确认后，也会进入 ESTABLISHED 状态。

第一次握手：客户 → 服务器（ACK = 0 ，SYN = 1）
第二次握手：服务器 → 客户（ACK = 1 ，SYN = 1）
第三次握手：客户 → 服务器（ACK = 1 ，SYN = 0）
2.连接释放
四次握手断开

四次握手（两个二次握手）过程分析：

（1）客户端 A 的 TCP 进程先向服务端发出连接释放报文段，并停止发送数据，主动关闭 TCP 连接,释放连接报文段中 FIN=1。这时，A进入 FIN—WAIT-1 (终止等待1)状态，等待 B 的确认。这是 TCP 连接释放的第一次挥手。
（2）B收到连接释放报文段后即发出确认释放连接的报文段，该报文段中，ACK=1。然后B进入CLOSE—WAIT(关闭等待)状态，此时TCP服务器进程应该通知上层的应用进程，因而A到B这个方向的连接就释放了，这时TCP处于半关闭状态，即A已经没有数据要发了，但B若发送数据，A仍要接受，也就是说从B到A这个方向的连接并没有关闭，这个状态可能会持续一些时间。这是TCP连接释放的第二次挥手。
（3）A收到B的确认后，就进入了FIN—WAIT(终止等待2)状态，等待B发出连接释放报文段，如果B已经没有要向A发送的数据了，其应用进程就通知TCP释放连接。这时B发出的链接释放报文段中，FIN=1。这时B进入LAST—ACK(最后确认)状态，等待A的确认，这是TCP连接的第三次挥手。
（4）A收到B的连接释放请求后，必须对此发出确认。确认报文段中，ACK=1，而后进入TIME—WAIT(时间等待)状态。二者都进入CLOSED状态后，连接就完全释放了，这是TCP连接的第四次挥手。

第一次握手：客户 → 服务器（ACK = 1 ，FIN = 1）
第二次握手：服务器 → 客户（ACK = 1 ，FIN = 0）
第三次握手：服务器 → 客户（ACK = 1 ，FIN = 1）
第四次握手：客户 → 服务器（ACK = 1 ，FIN = 0）

三、抓包分析三次握手连接

打开WireShark进行抓包后再打开游戏客户端
筛选tcp，很容易找到三次握手
在这里插入图片描述
第一次握手
客户 → 服务器（ACK = 0 ，SYN = 1）

第二次握手
服务器 → 客户（ACK = 1 ，SYN = 1）

第三次握手
客户 → 服务器（ACK = 1 ，SYN = 0）

四、抓包分析四次握手断开

按理来说WireShark可以抓取4次握手断开，但是我的TCP交互过程中出现了异常
在这里插入图片描述
此时重置位RESET值变为1了。
TCP异常终止的几种情况：

1.客户端尝试与服务器未对外提供服务的端口建立TCP连接，服务器将会直接向客户端发送reset报文。
2.客户端和服务器的某一方在交互的过程中发生异常（如程序崩溃等），该方系统将向对端发送TCP reset报文，告之对方释放相关的TCP连接。
3.接收端收到TCP报文，但是发现该TCP的报文，并不在其已建立的TCP连接列表内，则其直接向对端发送reset报文。
4.在交互的双方中的某一方长期未收到来自对方的确认报文，则其在超出一定的重传次数或时间后，会主动向对端发送reset报文释放该TCP连接。
5.有些应用开发者在设计应用系统时，会利用reset报文快速释放已经完成数据交互的TCP连接，以提高业务交互的效率。

由于我的TCP异常终止，这里借用同学的图。
第一次握手
客户 → 服务器（ACK = 1 ，FIN = 1）

第二次握手
服务器 → 客户（ACK = 1 ，FIN = 0）

第三次握手
服务器 → 客户（ACK = 1 ，FIN = 1）

第四次握手
客户 → 服务器（ACK = 1 ，FIN = 0）