为什么TCP建立连接需要三次握手,断开却要四次挥手呢?

12 篇文章 9 订阅
11 篇文章 1 订阅

首先,我们可以先看一下TCP是如何建立的?

一、TCP建立过程:

1、TCP的三次握手:

三次握手

第一次握手:客服端向服务器发送请求(syn=1包),seq=x,进入SYN_SENT状态,等待服务器的确认。
第二次握手:服务器收到了syn包,并且确认收到客服端发送的请求(ack+1),同时服务器也发送一个请求包(syn+ack包),seq=y,此时服务器进入SYN_RECV状态。
第三次握手:客户端收到服务器的SYN+ACK包(SYN+ACK包)后向服务器发送确认包(ACK+1),之后进入ESTABLISHED(此时TCP连接成功,完成三次握手)。

2、 同时打开(相当于四次握手建立):

同时打开连接是指通信的双方在接收到对方的SYN包之前,都进行了主动打开的操作并发出了自己的SYN包。由于一个四元组(源IP、源端口、目的IP、目的端口)标识一个TCP连接,一个TCP连接要同时打开需要通信的双方知晓对方的IP和端口信息才行,这种场景在实际情况中很少发生。同时打开的流程如下图:
在这里插入图片描述

二、TCP连接的断开过程:

1、TCP的四次挥手:

在这里插入图片描述

1、Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
2、Server收到FIN后,发送一个ACK给Client,确认序号为u +
1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。
3、Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
4、Client收到FIN后,Client进入TIME_WAIT状态(主动关闭方才会进入该状态),接着发送一个ACK给Server,确认序号为w

  • 1,Server进入CLOSED状态,完成四次挥手。
2、 同时关闭连接:

同时关闭连接跟同时打开连接基本相似。
在这里插入图片描述
三、 常见问题

  1. 为什么要三次握手建立连接? TCP连接是可靠的双工通信,在连接建立阶段必须确认双向通信都是OK的。理论上来讲这需要至少四次交互:

1、Client发送SYN
2、Server响应ACK
3、Server发送SYN
4、Client响应ACK(如果没有这一步,Server无法知道Client能否收到自己的消息)
@1、2两步让Client知道自己和Server之间的双向通信是OK的,3、4两步让Server知道自己和Client之间的双向通信是OK的。实际应用中,2、3两步合并了,所以最终就只有三次握手。
@三次握手还可以解决网络中延迟的重复分组问题。假设TCP连接建立过程只有两次握手:
1、Client发送SYN
2、Server响应ACK
如果出现下面的情况,服务端就会出问题:
3、Client发送SYN Client端超时未收到Server的ACK,重发SYN Server端收到Client重发的SYN,响应ACK
4、Client收到ACK后,和Server正常数据交互,然后关闭连接
5、 Client第一次发送的SYN并未丢失,而是由于网络延迟,现在才到达Server端
6、 Server发送ACK(Server认为TCP连接已建立)
7、Client收到Server的ACK,由于Client认为自己并未请求连接,所以会忽略该ACK(不同于SYN,ACK报文不需要回复)
8、这时Server认为连接已经建立,一直等待客户端数据;客户端却根本不知道有这么一条连接

  1. 为什么要四次挥手断开连接
    @ TCP连接是全双工的,因此每个方向都必须单独进行关闭:当一方完成它的数据发送任务后就发送一个FIN来终止这个方向的连接,对端收到后回复一个ACK报文,这样双向就需要四次交互。
    @ Client主动关闭的情况下,Server收到Client的FIN报文时,仅仅表示Client没有数据发送给Server了;但Server可能还有数据要发送给Client,所以Server可能并不会立即关闭SOCKET,而是先回复一个ACK报文,告诉Client“你发的FIN报文我收到了”。只有等到Server所有的报文都发送完了,才发送FIN报文。也就是说,被动关闭方的ACK和FIN报文多数情况下都是分开发送的,所以需要四次交互。

  2. 为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态
    @ 为了保证主动关闭方发送的最后一个ACK报文能够到达被动关闭方。因为这个ACK有可能无法到达对端,这样对端会重发FIN报文,这时候主动关闭方需要重发ACK。
    @ 保证本连接的所有报文在网络上消失。如果没有这个机制,可能会对新连接产生干扰。举例如下:
    1、A和B正常建立TCP连接,数据传输,然后断开连接。但是由于网络传输原因,A发给B的seq为100的报文滞留在了网络上。
    2、 A和B再次建立连接,所用IP和端口与1中相同,二者数据传输过程中,B正好请求A发送seq为100的数据,这时1中滞留的报文到达B,TCP认为该报文合法,就接收了这个报文。

总结:

前面讲这么多,都是废话,三次建立就好比打电话(我的另一篇文章有写)
说白了,三次握手之前还没建立关系,不存在数据是传输,当然可以把客户端发送的请求和回复合并一起发过去啦。

四次挥手还是打电话(结束通话那一刻的恋恋不舍):
张三:先不跟你说了,我这边有事,
李四:好的(表面上我同意的你挂电话,但是我还要说完我没说的)
说完后…
李四:可以结束通话了。
张三:好的(四次挥手结束)
四次的目的完全就是为了确保把未传输完的数据传输过去,以免造成丢包问题。

而在TCP同时连接跟断开就好比是两个对的人(对的人指的是符合四元组,他们找的都是他们希望的那个)异口同声的说你们要在一起:
张三:我们在一起吧!(同时)
李四:我们在一起吧!(同时)
接着又一起异口同声的说了句:
张三:好啊!
李四:好啊!
也是同时说,但是我们要是知道,这种情况的出现的概率是非常小的,小的不能再小。

  • 10
    点赞
  • 50
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

混子不当

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值