一、三次握手

1.三次握手建立连接流程

在这里插入图片描述
三次握手流程：
（1）第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。

（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。

（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。

2.三次握手必要性

参考文章>>
确保能成功连接
1.假如一次握手
首先tcp是面向连接，一次握手肯定建立不了连接，因为客户机给服务器发出请求信息却没有得到回应，客户机是没法判定是否发送成功然后建立连接的。
2.假如两次握手
假设只有两次握手，比如图中的1，2步，当A想要建立连接时发送一个SYN，然后等待ACK，结果这个SYN因为网络问题没有及时到达B，所以A在一段时间内没收到ACK后，再发送第二个SYN，这次B顺利收到第二个请求，接着A也收到B发送来的ACK，这时A发送的第一个SYN经过一段时间也到了B，对于B来说这是一个新连接请求，然后B又为这个连接申请资源，返回ACK，然而这个SYN是个无效的请求，A只会承认它最后发的那个SYN的SYN+ACK，A收到B发来的第二个ACK实际是回应A的第一个SYN，所以A并不会理会它，而B却不知道，B会一直为这个连接维持着资源，造成资源的浪费。
3.假如三次握手
两次握手的问题在于服务器端不知道一个SYN是否是无效的，而三次握手机制因为客户端会给服务器回复第二次握手，也意味着服务器会等待客户端的第三次握手，与两次握手不同的是，服务器可以通过第三次握手来确认第一个连接请求是否有效，如果第三次握手迟迟不来，服务器便会认为这个SYN是无效的，释放相关资源。但这时有个问题就是客户端完成第二次握手便认为连接已建立，而第三次握手可能在传输中丢失，服务端会认为连接是无效的，这时如果Client端向Server写数据，Server端将以RST包响应，这时便感知到发生了错误。

4.三次握手中的错误处理方法

第一次握手A发送SYN传输失败，A,B都不会申请资源，连接失败。如果一段时间内发出多个SYN连接请求，那么A只会接受并回应第一个收到的SYN+ACK，忽略其他回应全部回应，B中多申请的资源也会释放。
第二次握手B发送SYN+ACK传输失败，A不会申请资源，B申请了资源，但收不到A的ACK，过一段时间释放资源。如果是收到了多个A的SYN请求，B都会回复SYN+ACK，但A只会进行一次连接，并回复最后一次握手的ACK。
第三次握手ACK传输失败，B没有收到ACK，释放资源，对于后序的A的传输数据返回RST。实际上B会因为没有收到A的ACK会多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到A的ACK，则释放资源，对A的数据传输返回RST。

四次挥手断开连接

四次挥手流程

在这里插入图片描述
主动连接，主动关闭：
主动发起连接请求—>另一端响应请求————>建立连接状态————>传输数据—————>发起关闭请求————>半连接状态——>另一端响应请求—>另一端发起关闭请求————>本端响应请求———>等待2MSL————>关闭状态。
被动连接，被动关闭：
被动接受连接请求————>建立连接状态————>传输数据————>被动接受关闭请求————>等待关闭状态（等待剩余数据发送完成）————>发起关闭请求————>接收到对方ACK——>关闭。