博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
NetWork——关于TCP协议的三次握手和四次挥手
阅读量:4045 次
发布时间:2019-05-24

本文共 1191 字,大约阅读时间需要 3 分钟。

0.  准备知识

1ACK TCP协议规定只有ACK=1时有效,也规定连接建立后所有发送的报文的ACK必须为1

2SYN,在连接建立时用来同步序号。当SYN=1ACK=0时,表明这是一个连接请求报文。对方若同意建立连接,则应在响应报文中使SYN=1ACK=1,因此SYN1就表示这是一个连接请求或连接接受报文

3FIN,用来释放一个连接。当 FIN = 1 时,表明此报文段的发送方的数据已经发送完毕,并要求释放连接

1.  三次握手和四次挥手示意图

1. 1 三次握手详细示意图

1)首先由Client发出请求连接即 SYN=1 ACK=0TCP规定SYN=1时不能携带数据,但要消耗一个序号,因此声明自己的序号是 seq=x

2)然后 Server 进行回复确认,即 SYN=1 ACK=1 seq=yack=x+1

3)再然后 Client 再进行一次确认,但不用SYN 了,这时即为 ACK=1seq=x+1 ack=y+1

1. 2  三次握手中的问题

1.3  四次挥手详细示意图

(1)当客户没有东西要发送时就要释放连接的时候(注意这里首先提出中断连接端可以是Client端,也可以是Server),客户端会发送一个FIN为1的没有数据的报文,进入FIN_WAIT状态,服务器收到后会给客户端一个确认,这时客户端那边不再发送数据信息(但仍可接收信息)。  

(2)客户端收到服务器的确认后进入等待状态,等待服务器请求释放连接 服务器数据发送完成后就向客户端请求连接释放(也是用FIN=1 表示,并且用ack = u+1(如图)), 客户端收到后回复一个确认信息,又要进入 TIME_WAIT 状态(等待2MSL 时间,最大报文生存时间)。服务器收到后关闭连接。

最后这里为什么还要等待呢?是防止最后一个ACK的丢失,服务器在超时后会重新发送FIN。如果客户端这时收到FIN就知道最后一个ACK丢失了,会重发。否则客户等待一段时间后依然没有收到回复,则证明Server端已正常关闭,那好,我客户端也可以关闭连接了。

1.4  最后是一些细节总结

(1)TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。

(2)服务器存在一个保活状态,即如果客户端突然故障死机了,那B那边的连接资源什么时候能释放呢? 

就是保活时间到了后,B会发送探测信息,以决定是否释放连接

(3)为什么连接的时候是三次握手,关闭的时候却是四次挥手?

关闭连接时,当Server端收到FIN报文时,很可能数据信息没有传完并不会立即关闭连接,所以只能先回复一个ACK报文(告诉Client端,"你发的FIN报文我收到了")。只有等到Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步挥手。

你可能感兴趣的文章
Yotta企业云盘更好地为教育行业服务
查看>>
Yotta企业云盘怎么帮助到能源化工行业
查看>>
企业云盘如何助力商业新发展
查看>>
医疗行业运用企业云盘可以带来什么样的提升
查看>>
教育数字智能化能为现有体系带来新的起点
查看>>
媒体广告业如何将内容资产进行高效地综合管理与利用
查看>>
能源化工要怎么管控核心数据
查看>>
媒体广告业如何运用云盘提升效率
查看>>
企业如何运用企业云盘进行数字化转型-实现新发展
查看>>
司法如何运用电子智能化加快现代化建设
查看>>
iSecret 1.1 正在审核中
查看>>
IOS开发的开源库
查看>>
IOS开发的开源库
查看>>
Jenkins - sonarqube 代码审查
查看>>
Jenkins + Docker + SpringCloud 微服务持续集成(一)
查看>>
Jenkins + Docker + SpringCloud 微服务持续集成 - 单机部署(二)
查看>>
Jenkins + Docker + SpringCloud 微服务持续集成 - 高可用集群部署(三)
查看>>
Golang struct 指针引用用法(声明入门篇)
查看>>
Linux 粘滞位 suid sgid
查看>>
C#控件集DotNetBar安装及破解
查看>>