律所网站建设成品短视频app下载有哪些

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;