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一定是大于超时重传的时间的;
解决:
一台主机出现大量的TIME_WAIT证明这台主机上发起大量的主动关闭连接(常见于一些爬虫服务器)
这时候我们应该调整TIME_WAIT的期待时间（linux centos当时测试默认是60s），或者开启套接字地址重用选项
(否则这个端标语就被占用了，这个主机其他的服务就用不了这个端标语了…Bind Error)
大概出现大量的CLOSE_WAIT
CLOSE_WAIT是S端同意C端的fin哀求之后进入的状态，期待上层程序进一步处理（比如发送剩余数据）;
解决:
如果S端产生大量的CLOSE_WAIT，大概是内核断开连接后，S端忘记调用close，这就是我们程序员的疏忽了，写了个小bug;
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
