为了账号安全,请及时绑定邮箱和手机立即绑定

为什么TCP建立连接协议是三次握手,而关闭连接却是四次握手呢?

2020.01.07 20:37 1961浏览

看到了一道面试题:“为什么TCP建立连接协议是三次握手,而关闭连接却是四次握手呢?为什么不能用两次握手进行连接?”,想想最近也到金三银四了,所以就查阅了相关资料,整理出来了这篇文章,希望对你们有所帮助。

TCP 连接

我们先来补一下基础什么是 TCP 协议?传输控制协议( Transmission Control Protocol, TCP )是种面向连接、确保数据在端到端间可靠传输的协议。面向连接是插在发送数据前,需要先建立一条虚拟的链路,然后让数据在这条链路上“流动”完成传输。

TCP 是可靠的,会尽自己最大的努力去完成数据传输,TCP 协议比较复杂,可以看下面这张 TCP 协议的报文头图片:

TCP 协议报文头格式

内容非常的丰富,跟我们今天要讨论的连接协议相关的就是中间那六个状态位: URG、ACK、PSH、RST、SYN、FIN ,都置为 1 表示有效,在这六个当中,我们主要关注重点关注 ACK、SYN、FIN 这三个。下面解释一下这三个状态位:

ACK:用于对收到的数据进行确认,所确认的数据由确认序列号表示。

SYN:用作建立连接时的同步信号

FIN:表示后面没有数据需要发送,通常意昧着所建立的连接需要关闭了。

好了,到这里,TCP 的基础知识我们就知道了,下面我们就来看看为什么
是三次握手,而不是四次或者两次
,为了让你更好的理解,我把知乎上一个高赞特别形象的比喻放在这里,希望对你有所帮助。

两次和四次都会出现问题,三次就刚刚好,希望这张图能够让你更好的理解为什么是三次握手。

我们已经知道了 TCP 协议是三次握手,为什么是三次握手呢?我们先来看看下面这张 TCP 协议建立连接的时序图。

TCP 协议三次握手时序图

总体来说就是呼叫、应答、回应,我们来详细的介绍每一步:

  • 第一步: A 机器向 B机器发出一个数据包并将 SYN 设置为 1 ,表示希望建立连接。这个包中的序列号假设是 X。
  • 第二步: B 机器收到 A机器发过来的数据包后,通过 SYN 得知这是一个建立连接的请求,于是发送一个响应包并将 SYN 、ACK 标记都置为 1。假设这个包中的序列号是 y ,而确认序列号必须是 x+l ,表示收到了 发过来的 SYN,TCP 中, SYN 被当作数据部分的一个字节。
  • 第三步: A 收到 的响应包后需进行确认,确认包中将 ACK ,并将确认序列号设置为 y+ ,表示收到了来自B 的 SYN

经过这三步之后,两台服务器就建立连接了,可以进行通信数据传输了。为什么要三次握手呢?主要是为了信息对等和防止出现请求超时导致脏连接。

第一是为了保证两台机器信息对等,确保两台机器都没有什么问题:

信息对称

只有三次握手之后才能够保证两台服务器都完全没有问题,各自具备发报和收报能力。

第二是防止出现请求超时导致脏连接,看下面这张图:

防止出现请求超时导致脏连接

为什么会出现脏连接?因为TTL 网络报文的生存时间往往都会超 TCP 请求超时时间,如果两次握手就可以创建连接 ,传输数据并释放连接后,第一个超时的连接请求才到达 B 机器的话,B 机器会以为是 A 创建新连接的请求,然后确认同意创建连接。因为 A 机器的状态不是 SYl_SENT ,所以直接丢弃了 B 的确认数据 ,以致最后只是 B 机器单方面创建连接完毕。

三次握手就可以解决这个问题,因为需要 A 服务器确认了才真正的建立了连接。

TCP 四次挥手

上面介绍了 TCP 协议连接,有连接就有断开,相对于三次连接,断开却需要四次挥手,怎么理解呢?先看下面这个场景:

A:B 啊,我不想玩了。

B:哦,你不想玩了啊,我知道了。

这个时候,还只是 A 不想玩了,也即 A 不会再发送数据,但是 B 能不能在 ACK 的时候,直接关闭呢?当然不可以了,很有可能 A 是发完了最后的数据就准备不玩了,但是 B 还没做完自己的事情,还是可以发送数据的,所以称为半关闭的状态

这个时候 A 可以选择不再接收数据了,也可以选择最后再接收一段数据,等待 B 也主动关闭。

B:A 啊,好吧,我也不玩了,拜拜。

A:好的,拜拜。

这就是一个完整的关闭连接,在这个关闭的过程中,一共说了四句话,我们也称之为四次挥手。跟建立连接一样,断开时也是用状态来表示,下面是断开的时序图:

状态时序图

我们结合上面的时序图和场景再来分析一下 TCP 断开过程。

当 A 说“不玩了”,A 就进入 FIN_WAIT_1 的状态,B 收到“A 不玩”的消息后,发送知道了,B 就进入 CLOSE_WAIT 的状态。

A 收到“B 说知道了”,就进入 FIN_WAIT_2 的状态,如果这个时候 B 直接跑路,则 A 将永远在这个状态。虽然 TCP 协议里面并没有对这个状态的处理,但是 Linux 有,可以调整 tcp_fin_timeout 这个参数,设置一个超时时间,最后 A 也会关闭的。

如果 B 没有跑路,发送了“B 也不玩了”的请求到达 A 时,A 发送“知道 B 也不玩了”的 ACK 后,从 FIN_WAIT_2 状态结束,按说 A 可以跑路了,但是最后的这个 ACK 万一 B 收不到呢?则 B 会重新发一个“B 不玩了”,这个时候 A 已经跑路了的话,B 就再也收不到 ACK 了,因而 TCP 协议要求 A 最后等待一段时间 TIME_WAIT,这个时间要足够长,长到如果 B 没收到 ACK 的话,“B 说不玩了”会重发的,A 会重新发一个 ACK 并且足够时间到达 B。

要求 A 等待 TIME_WAIT还有一个原因就是防止产生混乱,A 直接关闭了,但是这个时候 B是不知道的,可能在 A 关闭之前 B还发送了很多数据包,如果这时候 A 的端口被一个新的应用占用了的话,那么新的应用就会接收到上个连接中 B发送过来的数据包,这样就混乱了,虽然这个数据包是无效的,但是等待 TIME_WAIT 可以是一个双保险,因而也需要等足够长的时间,等到原来 B 发送的所有的包都死翘翘,再空出端口来。

以上就是 TCP 协议三次握手,四次挥手的原因,希望这篇文章对您的学习或者工作有所帮助,如果您觉得文章不错,还请您帮忙点个赞和转发,谢谢。

最后

目前互联网上很多大佬都有 TCP 协议相关文章,如有雷同,请多多包涵了。原创不易,码字不易,还希望大家多多支持。若文中有所错误之处,还望提出,谢谢。

平头哥的技术博文(id:pingtouge_java)
作者:平头哥,学会伺机而动,实现弯道超车

点击查看更多内容

本文首次发布于慕课网 ,转载请注明出处,谢谢合作

7人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消