超详细且易于理解的三次握手四次挥手过程图解

底层流程图：

SYN: 表示连接请求 ACK: 表示确认 FIN: 表示关闭连接 seq:表示报文序号 ack: 表示确认序号

详细图解：

图解流程说明如下:

通信前：3次握手

3次握手：调用connect 双方都在准备资源（目的）

第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack (number )=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

关闭时：4次挥手

4次挥手–让双方都把资源给释放了（目的）

第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送。
解析：客户端调用close（）-关闭发送（这时操作系统会把包发给服务器），即客户端告诉服务器不会再给服务器发送任何数据，即应用程序不会发，不是操作系统不发

第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1。
解析：服务器会告诉客户端，服务器收到数据了（即发送的通道关闭了）

第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送。
解析：（还剩收数据的通道没关闭），服务器的操作系统收到你不发的信号时，会告诉你的应用程序说：客户端不会再发信息过来了，recv_date = new_socket.recv（）-（一般应用程序都会阻塞在这里）–>应用程序recv没有收到数据后会解堵塞，没有收到数据就调用执行new_socket_close(),即服务器告诉客户端我也不给你发数据了（即调用close），对于客户端来说，就是关闭接收的功能（看图片if…else处）
（蓝色的第三个箭头，是服务器调用close时才会有，如果没有调用close，这个箭头是不会发过去的，而第二个箭头是给客户端回复我收到你的数据包了，功能不一样，所以两个箭头不能合在一起）

第四次挥手：Client收到FIN后，接着发送一个ACK给Server，确认序号为收到序号+1。
解析：收到关闭的数据要求（即第4 个箭头）
Close一般是客户端先调用关闭，因为TCP为保证数据可靠信，收到一个数据，就要回复应答一下

问答题：

问：最后一次挥手（即蓝色的最后一次箭头），即客户端回复服务器，那客户端怎么知道服务器有没有收到呢？
答：
1.（客户端）谁先调用最后一次close，（客户端）谁就在那等待一段时间，即超时时间，如果没有收到客户端的回复，服务器过一段时间还会再发一次包过来。
2.（没有收到最后一次挥手情况）假如服务器因为特殊原因没有收到客户端发送过来的确认包。（前提不能释放资源）为了保证服务器能收到客户端的确认包，客户端会在这等待一段时间（等待2倍的2MSL，2-5分钟左右），
3.（客户端）先调用第一次close，谁就要发最后一次挥手，（客户端）谁的资源就会在你的电脑上保留2分钟，这段期间资源不能被释放，即你的端口不能被重复使用

问：端口被占用的解决办法
假如是服务器先调的用第一次close，服务器就要等待2分钟，等待期间不能重新绑定同一个端口（除非换端口），如果程序退出在运行，端口就会被占用（除非换端口运行或者用下面的解决办法）
答：
解决办法： 设置当服务器先close 即服务器端4次挥手之后资源能够立即释放，这样就保证了，下次运行程序时 可以立即绑定7788端口（即重复使用原端口）
server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

问：客户端调用close，为什么没有出现端口被占用的情况
**答：**因为客户端的端口是没有绑定的，服务器的端口是绑定了的，客户端的端口是随机的。

补充知识：
socket套接字是全双工的，有2个通道，一个是收数据，一个是发数据，即同时可以收发数据，一点影响都没有，通过多任务进程线程，实现同一个套接字的收发数据