帮助文档
专业提供香港服务器、香港云服务器、香港高防服务器租用、香港云主机、台湾服务器、美国服务器、美国云服务器vps租用、韩国高防服务器租用、新加坡服务器、日本服务器租用 一站式全球网络解决方案提供商!专业运营维护IDC数据中心,提供高质量的服务器托管,服务器机房租用,服务器机柜租用,IDC机房机柜租用等服务,稳定、安全、高性能的云端计算服务,实时满足您的多样性业务需求。 香港大带宽稳定可靠,高级工程师提供基于服务器硬件、操作系统、网络、应用环境、安全的免费技术支持。
服务器资讯 / 香港服务器租用 / 香港VPS租用 / 香港云服务器 / 美国服务器租用 / 台湾服务器租用 / 日本服务器租用 / 官方公告 / 帮助文档
TCP为什么是三次握手和四次挥手以及可能出现的问题
发布时间:2024-03-10 08:26:49   分类:帮助文档
TCP为什么是三次握手和四次挥手以及可能出现的问题






目录
TCP为啥设定为三次握手(两个角度分析)不可靠产生无效链接浪费服务器资源
TCP为啥四次挥手服务端有剩余数据需要发送--四次挥手(多数情况)服务端无剩余数据发送--捎带应答--四次变三次(少数情况)
四次挥手可能出现的问题可能出现大量的TIME_WAIT可能出现大量的CLOSE_WAIT




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;




香港云服务器租用推荐
服务器租用资讯
·广东云服务有限公司怎么样
·广东云服务器怎么样
·广东锐讯网络有限公司怎么样
·广东佛山的蜗牛怎么那么大
·广东单位电话主机号怎么填写
·管家婆 花生壳怎么用
·官网域名过期要怎么办
·官网邮箱一般怎么命名
·官网网站被篡改怎么办
服务器租用推荐
·美国服务器租用
·台湾服务器租用
·香港云服务器租用
·香港裸金属服务器
·香港高防服务器租用
·香港服务器租用特价