TCP与UDP协议(三次握手四次挥手)

简介TCP和UDP

TCP、UDP都属于传输层,是传输协议
TCP基于连接,UDP基于非连接
TCP:在不稳定的信道上建立稳定的连接
在这里插入图片描述
UDP(写信):是不可靠通信,邮件发出后无法判断对方是否接收到,内容是否完整,顺序是否正常等等。
TCP(打电话):可靠的通信,必须对方接通才可以互相对话,到最后挂断。

一、TCP

1.1 TCP的三次握手

在这里插入图片描述
建立连接的过程:

  1. 当客户端向服务端发起连接时,会先发一包syn包连接请求数据,进行询问,能否建立连接。
  2. 如果服务端同意连接,则回复一包syn+ack包。
  3. 客户端收到之后回复一包ack包,连接建立

举个例子:(假设客户端为A,服务端为B)
A:是B吗?我要和你说个事,听得到吗?
B:好的,你听到我说话吗?
A:我也听得到。

问题来了:为啥是三次握手而不是两次呢?

本质是为了互相确认对方的序列号。
大家也可以想想如果是前两次握手就建立了链接,无需A再次发送ack给B,其实B这边无法知道A是否可以接受信息的。第一次握手表示A可以发出信息,第二次则表示B可以接收消息和发消息。所以必须要求第三次握手,确保在不可靠的通信中实现可靠的通信。
举个握手两次翻车的例子: 例如A第一次发送syc1包,出现网络波动导致滞留,A再次发送syc2包,正常建立连接,这个时候网络正常,syc1包发送到B,B误以为建立新的连接,导致B这边以为有两个连接,而A这边只有一个连接,导致最终状态不一致。(如果这个时候有第三次A确认,就不会出现这个情况了)

1.2建立连接后的通信过程(丢包与乱序问题)

在这里插入图片描述
首先有一个发送缓冲区,数据序列是从0开始递增,A发送给B的报文中有起始序列号和长度以及内容,B接收到后会发送一个ACK就是刚刚发送的序列号加长度,确保数据不丢包,如果不一致,B可以则根据实际收到的计算丢失的序列号起点要求A重发即可。

1.3四次挥手

在这里插入图片描述
过程描述:

  1. A需要向服务端发起一包fin包,表示要关闭连接,自己进入终止等待1状态,这是第一次挥手。
  2. B 收到fin包,发送一包ack包,表示自己进入了关闭等待状态,客户端进入终止等待2状态,这是第二次挥手
  3. B此时还可以发送未发送的数据,而客户端还可以接收数据,待服务端发送完数据之后,发送一包fin包,进入最后确认状态。这是第三次挥手。
  4. A收到之后回复ack包,进入超时等待状态,经过超时时间后关闭连接,而服务端收到ack包后,立即关闭连接。这是第四次挥手

举个生活中的例子:
A:打完球了吗,饭做好了。
B:知道了,最后一个回家球!
B:进了,回家的路上。
A:OK。

问题来了:为什么要四次挥手?

由于 TCP 的半关闭(half-close)特性,任何一方都可以在数据传送结束后,发出连接关闭的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接关闭通知,对方确认后就完全关闭了TCP连接。
通俗的来说,两次挥手就可以释放一端到另一端的 TCP 连接,完全释放连接一共需要四次挥手。

二、UDP

在这里插入图片描述
特点:

  • 建立于非链接,将数据包封装一下,即可发出
  • 性能损耗少,CPU、内存占用远小于TCP,稳定性弱于TCP
  • TCP适合传输文件、发送文件、浏览网页,UDP适合域名查询、语音通话、视频,以及隧道网络:VPN等

举个例子:
在这里插入图片描述
左边兄弟把盘子中的韭菜扔出去了就不管了,不管对方是否接收到,韭菜是否散了等等。

此文章是基于B站视频而记录
视频地址:视频讲解更清晰

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值