计算机网络 3. 传输层 2021-05-27 浏览量 538 暂无评论 [TOC] ## 课程主要内容 - 多路复用解复用(聚合主机数据-区分进程数据) - 可靠数据传输(RDT)※ - 流量控制 - 拥塞控制 - ### 3.1 概述和传输层服务(21:42) 提供的服务:远程的进程到进程间的以报文(Message)为逻辑通信 传输层加强网络层的服务品质,但不是所有服务品质都是可以加强的 ### 3.2 多路复用和解复用(19:01) 为什么叫复用呢?就是一个TCP/UDP实体上面进行着许多进程的信息交换 发送方主机多路复用:从多个套接字接受来自多个进程的报文,根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装(传输层封装端口号,网络层封装IP) ### 3.3 无连接传输UDP(17:04) UDP:用户数据报协议 头部开销小 校验和:EDC(差错检测编码),检测不出残存错误(错了,但是校验和却通过了) 发送方:将整个数据报D(包括伪头部,头部,数据部分)分成数个16比特整数,将这些整数相加,进位时回滚(就是把进位挪到末尾),最终的和取反码即为校验和(EDC), 接收方:将接收到的D和EDC全分16位加起来,若校验范围(D)+校验和(EDC)=1111111111111111,则通过校验 ### 3.4 可靠数据传输(rdt)原理(2:20:15) 由udt变为rdt 只考虑单向数据传输,但控制信息是双向流动的 使用有限状态机(FSM)来描述发送方和接收方 FSM:状态1到状态2(经过什么事件和动作--边) RDT 1.0: 下层的信道是可靠的,只进行封装解封装 - 不出错 - 不丢失 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210606210238753.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) **RDT 2.0:** ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210606210355599.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) 缺陷:既然发送的Packet可能出错,那ACK和NAK也可能出错,在RDT 2.1中更新了,为Packet编号,发送方发P0,接收方成功接收到了P0,发回ACK,然后又接受到了P0,说明刚刚的ACK发回途中出错了,再发ACK **RDT 2.2:** 无NAK的协议 对ACK编号,便于流水线。比如我现在在等ACK1,但返回来个ACK0,答非所问,那不就是出错了吗。就像我们你她好看吗?你说她很温柔。 **RDT 3.0** 假设:下层提供的信号可能丢失 发送完后启动超时定时器,如果到时间还没等到想等的人,那重发 超时定时器的设置很重要 缺点:如果链路容量比较大,那一次发一个PDU不能充分利用链路的传输能力 **流水线协议/管道化协议(pipline)** :一次发送多个分组 分为两种: 1. 回退N步协议(GBN) 2. 选择性重发协议(SR) **滑动窗口协议(SW)** 1. SW = 1, RW = 1,rdt3.0 2. SW > 1, RW = 1,GBN 3. SW > 1, RW > 1,SR **发送缓冲区:** 在内存中,存放已发送,但未经确认的分组 **发送缓冲区的大小** :一次最多可以发送多少个未经确认的分组 **发送窗口:** 每发送一个分组,前言前移一个单位;每收到老分组的确认,后沿移动一个单位 发送缓冲区和发送窗口有何区别? 是不是可以这么理解:我想发一个分组,先把它放到发送缓冲区中等待发送,发送窗口实施发送 **接收窗口:** GBN: 窗口大小为1,并且罩在0号分组上,意思是指现在只接收0号分组,其他分组来了就丢弃,然后给出收到的最高分组的ACK确认(累计确认),超时定时器启动,从发送窗口的后沿重新发送 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210612204450998.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) 疑问: 虽然可以流水线式地同时发送多个分组,但接收窗口是一个个移动的,那速度会变快吗?会的,因为接收窗口的移动不需要传输,直接软件实现 SR: 窗口大小大于1(非累计确认) 每个分组都都一个超时定时器 1. 收到的分组位于后沿,则给出后沿分组的ACK确认,接收窗口向前移动 2. 收到的分组不位于后沿,但在接收窗口范围内,则给出该分组的ACK确认,窗口不动 3. 收到的分组不位于接收窗口范围内,接收窗口复位? ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210612205445744.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) 疑问: 1. 接收方怎么事先知道要接收哪些分组呢? 2. 如果后沿的分组迟迟不来呢?-> 后沿对应分组的超时计时器启动超时重传 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210612210120300.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) 对于SR,如果窗口大小大于$2^{n-1}$,在一批流水ACK返回失败时,接收窗口移动后,却包含了需要重新发送的分组,导致程序以为这是符合逻辑的,区分不出这是异常情况。 ### 3.5 面向连接的传输TCP(1:33:51) 应用层向下交付字节流,传输层将大的字节流按最大报文段(MSS)分成多个组,加上TCP头部形成多个报文段,报文段的body部分第一个字节即为每个分组在整个字节流中的偏移量,后面是每个分组的内容。 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210612215008609.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) 序号(按最大报文段编号):报文段的首字节在字节流的编号 确认号:表明已收到该序号之前的所有字节段,期望从另一方收到的下一个字节的序号 **可靠数据传输** 通过字节流的序号和确认号来告诉对方传输的信息位于字节流的哪部分 疑问: 为什么不每次传输的时候告知报文段在字节流中的起始、终止位置,而要告诉对方:我这次是从哪开始的,你下次又是从哪开始的?因为通常字节流中包含多个需要传送的报文段,这些报文段共同组成所需信息,确认号意味着此序号之前的报文段已经传送完毕,下次希望对方从哪开始传。 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210613101251124.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) **TCP发送方(简化版)** 首先指定我从哪开始发,我想要你从哪开始发 疑问: 为什么不从固定的序号开始发,而是每次都要指定呢?为了防止滞留在网络中的段对传输造成影响,老的数据对新的数据可能产生影响?是的,比如上次连接关闭前仍有数据滞留在网络中,下次连接又使用了相同的端口建立连接,这时会把滞留的数据当成新的数据接收,所以在3握手建立TCP连接时,要随机选择初始序号,或者用时钟的低32位。 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210614102517312.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) ![在这里插入图片描述](https://img-blog.csdnimg.cn/2021061410583230.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) **TCP流量控制** 通过反馈将接收方的剩余空间(buffer)告诉发送方。 捎带作用。 **TCP连接管理** 正式交换数据前,建立连接。 同意建立连接 同意连接参数 Q:为什么2次握手建立连接不总是可行的? 1. 变化的延迟(连接请求的段没有丢,但可能超时,滞留在网络中,过会又到达,而由于超时定时器的作用,在没有收到确认之前,又发送了请求,过会又到达,第一次服务器同意,第二次服务器也同意,这样服务器维护了半连接,把旧数据当成新数据接接收资源浪费。疑问:为什么不将第二次丢弃呢?因为无法分辨?) 2. 由于丢失造成的重传 3. 报文乱序 4. 相互看不到对方 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210614110602118.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) 第3次握手通常和数据传递放在一起。 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210614154624794.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) 疑问: 客户端怎么辨别虚假的连接?为什么服务器不能辨别? **TCP关闭连接** 对称释放,并不完美 一边一边拆除:客户端告诉服务器要拆除连接,服务器说好的,但服务器向客户端的连接还存在,仍要拆除。-> 两军问题 最后用一定定时器,在这期间确实没有数据交换,则真正关闭连接。 ### 3.6 拥塞控制(32:06) 太多的数据需要网络传输,超过了网络的处理能力。 表现:分组丢失(路由器缓冲区溢出);分组经历比较长的延迟(在路由器的队列中排队) 拥塞原因: 1. 进入的速率$\lambda_{in}$接近链路带宽R时,延迟增大; 2. 路由器的缓冲是有限的; 3. 分组丢失时,发送端要重传,此时应用层的输入=应用层的输出,传输层的输入大于应用层的输入,因为要包括重传; 控制方法: 1. 网络辅助,网络反馈信息给终端; 2. 端到端 ,TCP如此,自身判断是否拥塞。 实际: ATM网络,信元,轻载 ### 3.7 TCP拥塞控制(45:59) 端到端的拥塞控制,小型网络用网络设备反馈更好。 简化网络核心。 - 路由器的负担较轻; - 端系统根据自身得到的信息,判断是否拥塞 **如何判断:** - 超时(拥塞) - 原因1:网络拥塞(概率大) - 原因2:出错被丢弃(会造成误判,但概率小,不影响总体控制方向) - 有关某个段的3次重复ACK(轻微拥塞) **如何调节发送方向网络中注入的速率:** $rate=\frac{Cong Win}{RTT}$,CongWin是动态的,是感知到的网络拥塞程度的函数 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210615200648965.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210615200912591.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210615214236923.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NzkyOTU5,size_16,color_FFFFFF,t_70) 赞赏 微信支付 支付宝支付