传输层服务
本章概述
1.传输层服务的基本理论和基本体制
- 多路复用/分用
- 可靠数据传输机制
- 流量控制机制
- 拥塞控制机制
2.Internet的传输层协议
- UDP:无连接传输服务
- TCP:面向连接的传输服务
- TCP拥塞控制
传输层服务概述
1.传输层服务和协议
- 传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制(指两个进程之间仿佛是直接连接的,它不需要关心两个进程间有多远的物理距离,经过多少路由器,使用了哪些物理层媒介,可以看成端到端的直接连接)
- 端系统运行传输层协议
- 发送方:将应用递交的消息分成一个或多个的Segment(报文段),并向下传给网络层
- 接收方:将接收方的segment组装成消息,并向上交给应用层
- 传输层可以为应用提供多种协议
- Internet上的TCP
- Internet上的UDP
2.传输层和网络层的区别
- 网络层:提供主机间的逻辑通信机制
- 传输层:提供应用进程间的逻辑通信机制
- 位于网络层之上
- 依赖于网络层服务
- 对网络层服务进行(可能的)增强
- 传输层提供的最基本的功能为多路复用/分用
- 类比:家庭——12个孩子给12个孩子写信
- 应用进程=孩子
- 应用消息=信封里的信
- 主机=房子
- 传输层协议=李雷和韩梅梅(李雷为李雷家的其他孩子寄信和韩梅梅为韩梅梅家的其他孩子寄信)
- 网络层协议=邮政服务
3.Internet传输层服务
- TCP提供可靠的、按序的交付服务
- 拥塞控制
- 流量控制
- 连接建立
- UDP提供不可靠的交付服务
- 基于“尽力而为”的网络层,没有做“可靠性方面的”扩展
- 只实现了传输层必要的服务,如:多路复用
- 两种服务均不保证延迟和带宽
4.多路复用和多路分用
- 使用复用/分用的原因:如果某层的一个协议对应直接上层的多个协议/实体,则需要复用和分用
- 接收端进行多路分用:传输层依据头部信息将收到的Segment交给正确的Socket(即不同的进程)
- 发送端进行多路复用:从多个Socket接收数据,为每块数据封装上头部信息,生成Segment,交给网络层
- 主机接收到IP数据报(datagram)
- 每个数据报携带源IP地址、目的IP地址
- 每个数据报携带一个传输层的段(segment)
- 每个段携带源端口号和目的端口号
- TCP/UDP段格式
- 主机收到Segment之后,传输层协议提取IP地址和端口号信息,将Segment导向相应的Socket
- TCP做更多处理
- 无连接分用
- 利用端口号创建Socket
- UDP的Socket用二元组标识(目的IP地址,目的端口号)
- 主机收到UDP段后(检查段中的目的端口号;将UDP段导向绑定在该端口号的Socket)
- 来自不同源IP地址和/或源端口号的IP数据包被导向同一个Socket
- 例:
- 面向连接的分用
- TCP的Socket用四元组标识(源IP地址,源端口号,目的IP地址,目的端口号)
- 接收端利用所有的四个值将Segment导向合适的Socket
- 服务器可能同时支持多个TCP Socket(每个Socket用自己的四元组标识)
- Web服务器为每个客户端开不同的Socket
- 例:
- TCP协议是一对一的,一个客户机进程对应一个服务器进程
- 多线程Web服务器(一个P4进程创建了三个线程,从而通过不同的线程维持多个TCP连接,为客户机提供服务)
5.UDP(User Datagram Protocol)协议
- 基于Internet IP 协议
- 多路复用/分用
- 简单的错误校验(在传输层做错误检测的原因:防止底层所有链路层中存在协议没有进行错误检测或存储转过过程中出错——端到端原则)
- "Best effort"服务模型,UDP段可能丢失或非按序到达
- 无连接
- UDP发送方和接收方之间不需要握手
- 每个UDP段的处理独立于其他段
- UDP存在的原因
- 无需建立连接(减少延迟)
- 实现简单:无需维护连接状态
- 头部开销少
- 没有拥塞控制:应用可以更好地控制发送时间和速率
- UDP的应用
- 常用于流媒体应用——容忍丢失,速率敏感
- UDP还用于——DNS,SMTP
- 在UDP上实现可靠数据传输可以通过——在应用层增加可靠性机制;应用待定的错误恢复机制
- UDP使用的报文段格式
- UDP校验和(checksum)
- 目的:检测UDP段在传输中是否发生错误(如位翻转)
- 发送方:将段的内容视为16位整数——》检验和计算:计算所有整数的和,进位加在和的后面,将得到的值按位取反,得到校验和——》发送方将校验和放入校验和字段
- 接收方:计算所收到的段的校验和,将其与校验和字段进行对比——不相等:检测出错误;相等:没有检测出错误(但可能有错误)
- 校验和计算示例(最高位进位加到和的最低位后,再按位取反):
6.可靠数据传输原理
- 可靠:不错(分组不会发生错误);不丢(分组在传输过程中不会丢失);不乱(分组顺序不会乱且能识别出重复分组)
- 可靠数据传输协议
- 可靠数据传输对应用层,传输层,链路层都很重要
- 网络top10问题
- 信道的不可靠特性决定了可靠数据传输(rdt)协议的复杂性
- 从提供的服务角度来看:传输层提供可靠的信道
- 从服务实现的角度来看:
- 可靠数据传输协议基本结构:接口 rdt_send():被上次应用调用,将数据交给rdt以发送给对方 udt_send():被rdt调用,在不可靠的信道上向接收方传输数据 rdt_rcv():当数据包到达接收方信道时被调用 deliver_data():被rdt调用,向上层应用交付数据
- 可靠数据传输协议
- 渐进地设计可靠数据传输协议的发送方和接收方
- 只考虑单向数据传输(但控制信息双向流动)
- 利用有穷状态机(FSM)刻画传输协议
- Rdt1.0:可靠信道上的可靠数据传输
- 底层信道完全可靠(不会发生错误;不会丢弃分组等)
- 发送方和接收方的FSM互相独立
- Rdt2.0:产生位错误的信道
- 底层信道可能翻转分组中的位(bit)——利用校验和检测位错误
- 恢复错误: 确认机制(ACK):接收方显示的告知发送方分组已正确接收 NAK:接收方显示地告知发送方分组有错误 发送方收到NAK后,重传分组
- 基于这种重传机制的rdt协议称为ARQ协议
- Rdt2.0中引入的新机制 *差错检测 *接收方反馈控制消息:ACK/NAK *重传
- FSM规约:
- 无错误场景
- 有错误场景
- 缺陷:当ACK/NAK消息发生错误/被破坏时,无法解决 解决方法:为ACK/NAK增加校验和,检错并纠错 发送方收到被破坏的ACK/NAK时不会知道发生了什么,添加额外的控制消息 如果ACK/NAK坏掉,发送方重传 不能简单的重传:产生重复分组(序列号:发送方给每个分组增加序列号;接收方丢弃重复分组)
- Rdt2.1——发送方应对ACK/NAK破坏
- 发送方的FSM
- 接收方的FSM
- Rdt2.1与Rdt2.0的区别: 发送方:1)为每个分组增加了序列号 2)两个序列号(0,1)就够用——由于采用停等协议 3)需要校验ACK/NCK消息是否发生错误 4)状态数翻倍——状态必须记住当前分组的序列号 接收方:1)需要判断分组是否是重复(当前所处状态提供了期望收到分组的序列号) 2)注意:接收方无法知道ACK/NAK是否被发送方正确收到
- Rdt2.2——无NAK的消息协议
- 与rdt2.1功能相同,但是只使用ACK
- 实现方法:接收方通过ACK告知最后一个被正确接收的分组;在ACK消息中显示地加入被确认分组的序列号
- 发送方收到重复ACK之后,采取与收到NAK消息相同的动作(重传当前分组)
- FSM片段
- Rdt3.0
- 在Rdt2.x时代,假设信道只会出现一种问题:发生位错误或丢失分组。但如果信道既发生错误,又丢失分组,那么:“校验和+序列号+ACK+重传"够用吗? 假如发送方发了一个分组,分组在到达接收方之前丢失了,发送方会一直等待,接收方无法处理。 如果发送方发的分组到达了接收方,但接收方发回的ACK丢失,发送方也会一直等待。 此时协议就无法工作,处于瘫痪状态。
- 解决方法:发送方等待”合理“时间—— 如果没有收到ACK,重传; 如果分组或ACK只是延迟而不是丢失(重传会产生重复,序列号机制能够处理;接收方需要ACK中显示告知所确定的分组) 定时器:解决合理时间的计时问题
- 发送方FSM 当发送方发出一个packet之后,启动定时器,进入等待ACK的状态。当等待时间超过合理时间时,发送方重传,重新启动定时器。如果packet正确发到接收方,接收方的ACK也正确的地到达发送方,则表示之前的packet顺利发送到接收方,然后重置定时器,转到状态1。
- 接收方FSM(自己补充) 因为rdt3.0和rdt2.2一样,没有ack,nak的区别,而且在传输中有序号 ,所以他们的FSM相同。
- 示例 讨论d中状态机如何解决后面的问题 rdt3.0中合理时间的设计是一个问题
- 性能 *Rdt3.0能够正确工作,但性能很差 *示例:1Gbps链路,15ms端到端传播延迟,1KB分组 发送方利用率:发送方发送时间 百分比 相当于: 在1Gbps链路上每30ms才发送一个分组—>33KB/sec 缺点:网络协议限制了物理资源的利用 ——软硬件的协同设计 *停等操作 ( 造成Rdt3.0性能差的主要原因)
7.滑动窗口协议
- 停等操作
- 流水线机制:提高资源利用率
- 流水线协议——允许发送方在接收到ACK之前连续发送多个分组(更大的序列号范围;发送方和/或接收方需要更大的存储空间以缓存分组)
- 滑动窗口协议(Sliding-window protocol)
- 窗口:允许使用的序列号范围(窗口尺寸为N:最多有N个等待确认的消息)
- 滑动窗口:随着协议的运行,窗口在序列号空间内向前滑动
- 滑动窗口协议:GBN,SR
- GBN协议(Go-Back-N协议)
- 分组头部包含k-bit序列号
- 窗口尺寸为N,最多允许N个分组未确认
- ACK(n):确认到序列号n(包含n)的分组均已被正确接收(可能收到重复的ACK)
- 为空的分组设置计时器(timer)
- 超时Timeout(n)事件:重传序列号大于等于n,还未收到ACK的所有分组(造成资源的浪费)
- 发送方扩展FSM:
- 接收方扩展FSM ACK机制:发送拥有最高序列的,已被正确接收的分组的ACK 可能产生重复ACK; 只需要记住唯一的expectedseqnum 乱序到达的分组: 直接丢弃-》接收方没有缓存 重新确认序列号最大的,按序到达的分组
- 示例:假设窗口大小为4
- 例题:
- 缺陷:重传时会重新传输大量重复的分组
- SR协议(Selective Repaet 协议)
- 接收方对每个分组单独进行确认——设置缓存机制,缓存乱序到达的分组
- 发送方只重传那些没收到ACK的分组——为每个分组设置定时器
- 发送方窗口——N个连续的序列号;限制已发送且未确认的分组
- 发送方/接收方窗口(无关联)
- 示例
- 困境 序列号:0,1,2,3 窗口尺寸:3 接收方不能区分下述两种不同的场景 解决方法:Ns+Nr<=2^(k)——其中k为序列号的位数;Ns为发送方窗口尺寸;Nr为接收方窗口尺寸