运输层TCP/UDP协议详解


前言

从通信和信息处理的角度看,运输层向它上面的应用层,提供通信服务,它属于面向通信的最高层,同时也是用户功能中的最低层.
①:俩台主机进行通信就是俩台主机中的应用进程互相通信.通信的真正端点并不是主机而是主机中的进程
②:运输层有一个很重要的功能是复用和分用
复用指的是:发送方不同的应用进程都可以使用同一个运输层协议传送数据
分用指的是:接收方运输层来剥去豹纹的首部能把这些数据正确交互目的的应用进程
③:运输层提供应用进程间端到端的逻辑通信
逻辑通信指:好像这种通信就是沿水平方向直接传送数据.
④:应该说明当运输层采用面向连接的TCP的协议时,尽管下面的网络是不可靠的,但是这种逻辑通信信道,相当于一条全双工的可靠信道
⑤:端口号:端口是各种协议进程和运输实体进行层间交互的一种地址
不同的操作系统实现端口的方式是不同的,所以端口号只有本地意义

在这里插入图片描述


在这里插入图片描述

一、用户数据报协议(UDP)

在这里插入图片描述

UDP的特点:

①无连接-发送数据前不需要建立链接

②不可靠传输-尽最大努力交付
③面向数据报-保留应用层,留下报文的边界
④全双工
⑤UDP没有拥塞控制
⑥UDP支持一对一,一对多,多对一和多对多的交互通信
⑦UDP首部开销小-只有8个字节

UDP的报文格式

①源端口:在需要对方回信时使用,不需要时全0
②目的端口:在终点交付报文时必须使用
③长度:UDP的用户数据报的长度,最小值是8(仅有首部)
④检验和:检测UDP数据报在传输中是否有错

在这里插入图片描述
注:当运输层从IP层收到UDP数据报时,就根据首部中的目的端口,把UDP数据报传送给对应的端口,上交给应用进程

在这里插入图片描述

二、TCP协议

TCP协议的特点

①面向连接-类似于打电话
②可靠传输
③面向字节流
④全双工
⑤TCP连接是点对点的-一条TCP连接只能有俩个端点
端点:Tcp连接 = {socket1 , socket2} = { (IP地址1 : 端口号1), (IP地址2 : 端口号2)}
套接字socket = (IP地址 : 端口号)

TCP报文格式的解释

在这里插入图片描述

①源端口:告诉对方你从哪里来
②目的端口:告诉别人你要去哪里
③序号:将TCP传输的字节流中的每一个字节都按序编号形成一个个分组
④确认号:期望收到对方下一个报文段的第一个数据字节的序号(这个是别人告诉你收到那些了分组了)
在这里插入图片描述

⑤数据偏移:指出TCP报文段的数据,距离TCP报文段的起始位置有多远.
⑥保留:字面意思就是保留一些,以防止其他情况
⑦一些特殊符号:告诉别人下面的状态是什么(要做什么)
⑧窗口:收方告诉你它最大一次性能接受多少数据
在这里插入图片描述

⑨检验和:双方防止东西丢了从而校验的手段
⑩紧急指针:让这个报加急发送,不走寻常路

解释一下:报文格式好像,你发送一个快递需要必填的信息,而整个发送流程才是TCP的其他机制比如三次握手等,这些机制就是基于这些首部实现的(好比快递发送出去,是由中转站再进一步的分链,这其中的一些特定想象被称为了机制)(机制是为了让我们更形象的去理解这个TCP的报头格式)

机制一:TCP的链接管理

三次握手

在这里插入图片描述
解释一下:SYN同步报文(作用,请求同步) . seq初始序号,ACK确认应答

用到了:①源端口②目的端口⑦一些特殊符号
形象比喻:

三次握手: 可以想象一个人去商店买东西,他要看到老板在,也要让老板知道他在这就是有链接(怎么体现出来呢?可以想象下面这个场景,
 男子走进商店叫了一声老板出来(客户端给服务器发送一个syn),老板回了一声,来了,同时往回走(服务器给客户端发送一个syn和ACK),男子收到老板的响应并回了一声嗯(客户端给服务器发送了一个ACK)
  这里说一下,ACK和SYN是什么,ACK是确认应答(好比,老板的来了),syn是同步(好比老板往回走),这里解释下为什么最后还要发送一次ACK(以上情况都是在看的见得情况下,如果老板和客人看不见呢?客人听到老板的响应声,是不是也得回应一声,然后在这之后再开始买东西
那么有人又要说了,你这明明是四次,为什么叫三次握手?那是因为,老板说来了,和往回走这俩个步骤是可以合并在一起的(这也是为什么2次握手不可靠(如果是俩次握手,老板会以为男子走掉了,从而这次链接失败),4次握手没必要的原因)

四次挥手

在这里插入图片描述
与三次握手同理,但是中间ACK和FIN发送时机不同,不能合并,ACK是收到报文就立马返回了,FIN是接收方关闭了链接才会发送

机制二:TCP的可靠传输

确认应答

实现可靠性的核心机制
用到了:③序号④确认号

TCP将每个字节的数据都进行了编号,即为序列号(解决收到重复数据问题)
而接送方发送的确认号:与发送方的序号无关,而是与收到发送方的数据最后一个字节的下一个字节的序号(这么说太TM抽象了:说人话就是:确认号就是表明:从开始的序号到这儿的确认号这里的数据都收到了)并索要确认号之后的数据(解决数据后发先至的问题)

首先要明白一个事情就是:并不是你发送过去什么数据,对方就立马接受完,TCP有一个缓冲区的,在缓冲区中检查数据全部收到之后,按序号排列,才会一次性写入内存或读取,从而确保应用程序读到的数据一定是有序的.如果这一切都没问题之后,接收方才会给发送一个确认应答

超时重传

只要发送方超过一定时间仍然没有收到确认,就认为刚才发送的数据丢失了,因此重传之前发送过的数据.(搭配超时计时器)

①发送方在发送一个分组后,必须暂时保留已发送的分组的副本,只有在收到确认才能清除
②分组与确认分组要进行编号(也就是序号和确认号)
③超时重传计时器的重传时间应该比数据传输的平均往返时间长

TCP提高效率的手段

滑动窗口-ARQ协议

发送方:一次性发送多个分组,然后每收到一个分组就将发送窗口往后移.
接收方:采用累积确认方式,对按序到达的最后一个分组发送确认,表示在这之前都已收到

在这里插入图片描述

流量控制

接收方根据自己的处理能力,反向约束发送方的传输速度,让其不要太快
接收缓冲区空间大小=>ACK应答报文的窗口大小
发送方的发送窗口不能超过接收方给出的接收窗口(这里的窗口指:字节)

当接收方不允许发送方在发送数据的时候,发送方就会每隔一段时间就发一个探测报文,让接收方给出现在的窗口值.

拥塞控制

衡量网络传输路径的处理能力
注:流量控制:指的是接收方能接受的能力
拥塞控制:指的是网络路径上的处理能力-理想状态是形成一种动态平衡

TCP的四种拥塞控制算法
1.慢开始:(指传输的报文少,不是增长速度慢)

2.拥塞控制
在达到初始门限制(ssthresh),发送报文开始变成线性增大.当发送方发现收到超时重传的请求时,就把门限值变成当前超时的一般,然后重新开始慢开始

3.快重传
当发送方发现这个报文丢了的时候,要立刻重传,而不是等超时计数器超时后再重传.
4.快恢复
当发送方收到三个重复确认时,就知道只是丢了个别报文段,于是不执行慢开始而是执行快恢复,将门限值和拥塞窗口都调整为当前的一半,在执行拥塞避免算法

在这里插入图片描述
在这里插入图片描述

延时应答与捎带应答

延时应答:接收方等待一段时间,等接收缓冲有了一部分空闲再去,给发送方发去接收窗口大小
捎带应答:将能一起发的报文一起发过去

面向字节流

粘包问题

当发送方A给接收方B连续发送多个应用层数据报之后,这些数据就都累积到B的接受缓冲区中,紧紧挨在一起,此时B就难以区分那个是一个完整的应用层数据报.
解决办法:①定义分割符
②约定长度:比如约定数据的前四个字节,表示整个数据报的差还能读

异常情况

①进程关闭 / 进程崩溃
进程没了,但是TCP建立的链接还在,所以仍然触发四次挥手,再结束
②主机关机(正常流程关机)
关机,会先杀死所有的用户进程,所以和①的情况一致,也会触发四次挥手,但是如果没挥手结束,对方的FIN发送过来,而主机关机的话,对方会重传一定的FIN,然后释放链接
③主机掉电
俩种情况:1对方是发送方:对方收不到ACK*超时重传),过一定时间就会重置链接,然后释放连接
2:对方是接收方:对方会不定时发送一个探测包,让咱们响应,如果多次没有响应,也就释放连接了

④网线断开
与③同理

总结

TCP与UDP的区别

①TCP的可靠传输效率低,UDP效率高,虽然TCP有着一系列提高效率的手段,但那只是止损
②应用场景不同,TCP可以用大多数场景,而对可靠性要求不高的情况下用的都是UDP
小知识:王者荣耀,LOL,绝地求是等用的都是UDP协议

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值