TCP为啥设定为三次握手(两个角度分析)
如果是4次，多了一次没啥意义还慢了，如果是两次握手逻辑可能存在下列问题：
(这两个方面也可以理解为握手过程中可能出现的问题)
不可靠
TCP协议是可靠的，那么建立的连接也需要确保是双向，可靠的; 根据连接过程分析，只有一方收到了另一方的ack确认报文，才能证明那一方的接收功能都正常。
举下面这个确认序号的例子说明 完整的接，收能力的重要性:
(这个抽象的接收功能，在下图握手过程中实际交换seq初始序号的过程中能体现)
第二次握手时，s端发完ack报文就默认进入establish建立成功状态，假设这个ack报文半路丢了呢？
c端压根就没有拿到ack也没有拿到s端的初始序号，显然这个链接是不可靠的！无法完成后续数据的交互；
产生无效链接浪费服务器资源
假定C端向S端发送了一个请求，但是该请求因为网络原因，在网路中逗留了一会儿，未及时送达。此时C将再次向S发送请求，Server接收到请求，发送确认包，完成连接并开始进行数据传输，直到数据传输完成后，断开连接。
之后，之前逗留的链接到了S端，这就尴尬了，S拿到syn请求，并回应了ACK应答，然后进入establish建立完成状态，这个链接无疑是不合法的，c端早已离去，剩下这个空连接，维持他消耗着S端的资源;
(c端:s端一般是n:1,如果存在上述问题，试想大量空连接有可能被维护，服务器资源会越来越吃紧从而导致更严重的问题)
TCP为啥四次挥手
客户端或服务器均可主动发起挥手动作,调用close()即可，为了方便理解，假设C端先发起，S端作为被动断开的一方;
其实我们三次握手的过程中的第二次，是将四次挥手中的中间两次合并优化了，那为啥TCP是四次挥手?其实这个说法有歧义，因为TCP多数情况下是4次挥手，但是也存在3次挥手的情况：
服务端有剩余数据需要发送–四次挥手(多数情况)
因为多数情况下，当c端主动与s端断开之后，s端不一定立即就与c端断开连接，可能还会有一些数据要发给c端，所以还会保持链接一段时间;
（当然TCP有保活机制，会通过设定时间间隔反复发送活性探测数据包，如果一段时间内没有响应或者一定的次数之后，就会断开这个链接释放资源）
服务端无剩余数据发送–捎带应答–四次变三次(少数情况)
在少数情况下，c端主动断开，s端恰巧也没啥要发的，也需要立即断开，那么TCP的捎带应答机制，就将四次挥手的中间两次进行合并，这时候四次挥手就变成了三次挥手;
四次挥手可能出现的问题
客户端或服务器均可主动发起挥手动作,调用close()即可，为了方便理解，假设C端先发起，S端作为被动断开的一方;
可能出现大量的TIME_WAIT
TIME_WAIT状态是C端收到了S端主动发送fin请求后，向S端发回了ACK确认断开报文之后出现的，需要保持2*MSL时间确保最后一个ACK报文能够到达S端，双方正常关闭; (设计成2*MSL的原因是确保响应ACK的传输时间和如果这个ACK丢失，S端重新发送FIN请求断开的时间)可见，msl一定是大于超时重传的时间的;
解决:文章来源：https://www.toymoban.com/news/detail-777890.html
一台主机出现大量的TIME_WAIT证明这台主机上发起大量的主动关闭连接(常见于一些爬虫服务器)
这时候我们应该调整TIME_WAIT的等待时间（linux centos当时测试默认是60s），或者开启套接字地址重用选项
(否则这个端口号就被占用了，这个主机其他的服务就用不了这个端口号了…Bind Error)
可能出现大量的CLOSE_WAIT
CLOSE_WAIT是S端同意C端的fin请求之后进入的状态，等待上层程序进一步处理（比如发送剩余数据）;
解决:
如果S端产生大量的CLOSE_WAIT，可能是内核断开连接后，S端忘记调用close，这就是我们程序员的疏忽了，写了个小bug;文章来源地址https://www.toymoban.com/news/detail-777890.html
到了这里，关于TCP为什么是三次握手和四次挥手以及可能出现的问题的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
