TCP的三次握手和四次挥手的通俗化解释

TCP的三次握手和四次挥手

0-服务器进程在创建的时候就进入listen状态，随时准备接受客户端请求（前置）
1-首先客户端向服务器发送连接请求(SYN)，同时客户端主动进入syn_send（同步已发送）状态–半打开状态。
2-服务器接收到请求之后，进行自身确认请求+发出确认报文（syn+ack），这是两个动作合并成了一个，同时，服务器被动进入syn_rcvd（同步收到）状态–半打开状态。
3-客户端接收到服务器发出的确认报文之后，再一次向服务器发出确认链接报文（syn），此时客户端也进入estalished（已建立连接）状态；当服务器再次收到客户端的确认链接后进入established（已建立连接）状态，双方开始通信。

假如是两次握手：场景==》客户端发送了第一条请求因为网络延时滞留在网络节点中，这时候客户端迟迟没有收到服务器的确认报文，就会认为服务器没有收到请求，就会**重新**进行请求，然后服务器收到后进行确认回复，这时就完成了两次握手，完成连接，传输数据，然后关闭连接。这时，滞留在网络的节点中的请求在网络通畅后到达了服务器，之后服务器还是会进行确认回复，这样就再次完成两次握手，重新建立了连接。就会导致错误和浪费。
**为什么不是四次或者更多：**tcp协议建立连接，三次就能够最大程度上达到可靠连接了，多了也不会有什么实质性的进步，而且会影响性能。

1–客户端向服务器传输数据：客户端发送数据后，服务器接收到数据后要进行确认回复。无论如何，如果客户端没有收到确认回复，一段时间后，就会进行tcp重传。
- 发生重传就有可能服务器收到两次数据，这时候操作系统的网络内核模块就会自动进行去重。
**2–tcp链接是双工的：**双方都能主动发起数据传输，也都需要对方收到对方的确认。
**3–tcp窗口大小：**客户端可以一次性可以向服务器发送多条数据，服务器可以一次性接收完毕之后再进行批量回复–批量ack。但是也不能一次性传输太多数据，双方需要协商合适的发送和接受速率，这就是tcp窗口大小。
操作系统的网络内核模块会负责对数据包进行排序，到用户层时顺序就已经完全一致了。

**1–**客户端向服务器发送连接释放报文（fin），此时客户端进入了fin-wait-1（终止等待1）状态，进行第一次挥手。
2–服务器收到连接释放报文，再发出确认报文，此时服务器进入close-wait（关闭等待）状态，进行第二次挥手。tcp服务器就会通知应用进程，客户端向服务器的方向释放了。这时候，服务器进入半关闭状态，也就是客户端已经不发送数据往服务器了，但是服务器仍可以向客户端发送数据，客户端依旧得接受。
**3–**客户端收到确认报文后，客户端进入fin-wait-2（终止等待2）状态，等待服务器向客户端发送释放连接请求报文。在此期间需要接收服务器发送的最后的数据。
**4–**服务器发送完最后的数据后，就会发送连接释放报文，等待客户端的确认，进行第三次挥手。服务器进入last-ack（最后确认状态）。
**5–**客户端收到服务器的释放连接报文后，发出确认到服务器。客户端进入time-wait（时间等待）状态。此时客户端并没有进入closed状态，tcp链接也还没有释放，必须经过2个MSL（最长报文寿命）事件后，才会进入closed状态。
**6–**服务器端收到客户端的确认后，立即就会进入closed状态，结束tcp链接。

首先确保客户端发出的最后一个确认能够到达服务器，防止丢失造成错误，其次服务器能够在收不到客户端的最后一个释放连接确认时，再次发送释放连接报文，客户端收到后再次回应确认，同时重启2MSL计时器。
让此次链接的报文再2MSL的时间内全部消失，不会干扰新连接。

建立连接的时候，服务器是在listen状态下的，收到建立连接的请求后，将确认和发送链接请求一次性发送给客户端。
释放连接时，服务器收到客户端的释放连接报文后，就只是客户端不再向服务器发送数据了，但是服务器还是可以向客户端发送数据的，所以，服务器还会再一次发送释放连接给客户端同意关闭。这样就会将确认和同意释放分开，也就多了一步。