传输层
概述
- 运行在端系统上,分为发送端和接收端(通常既是发送端又是接收端)
- 为应用层提供端到端的传输
- 发送端:将从应用程序接受的报文划分为较小的块,加上运输层头部生成运输层报文
- 分为TCP UDP
- UDP是最简化的服务,只包括mux和demux
- TCP提供有序的、有保证的服务
- 与网络层的区别:
- 网络层将信息从一个主机运输到另一个,而运输层则是一个主机将到达的数据进行分发到应用;打包发送
socket套接字
- 套接字是一个软件抽象,用于表示一个应用程序进程与操作系统中的传输层之间交换网络消息的接口。
- 一个Socket由主机的IP地址和端口号组成,可以唯一地标识网络上的一个进程。在传输层使用的地址表示为
,通常称为套接字(Socket)。 - 套接字可以分为两种类型:UDP套接字和TCP套接字。
- UDP套接字的类型为SOCK_DGRAM,<来源端口、目的端口>,使用UDP协议提供数据传输服务,它是一种面向无连接的传输方式,不保证数据传输的可靠性和有序性。
- TCP套接字的类型为SOCK_STREAM,<来源端口、来源ip、目的端口、目的ip>,使用TCP协议提供数据传输服务,它是一种面向连接的传输方式,能够保证数据传输的可靠性和有序性,但会引入一定的传输延迟。
端口(四级地址)
- 16bits长度
- 用来区分一个主机上的不同应用
- 0-1023为保留端口,用于一些基础服务
- 软件与端口之间的关系由操作系统进行存储
- udp不管远程连接到谁,而tcp需要知道远程的信息
服务模型
- 进程间通信复用/去复用:区分开不同应用的信息(一个主机会受到属于不同应用的信息)
- mux(多路复用)合并发送端发出的不同应用的信息,并在网络层传输
- demux(多路分解)将合并的数据再分开
- 使用端口
- 提供了应用层共同使用的端到端服务(ip层服务不稳定可能发生各种问题,没有保障,传输层进行处理)
- 保证数据的可靠性和有序性,确保数据能够正确地传递到目的地,而且数据的顺序也得到维护。
- 还需要控制数据传输的速率,避免发送数据过快导致网络拥塞,或者发送数据过慢导致效率低下。
mux与demux
- 使用ip+port组合地址
- 每个IP数据报都包含源IP地址和目标IP地址。
- 每个IP数据报只能携带一个传输层协议的报文段。传输层协议的报文段包含源端口号和目标端口号。
udp
- 创建连接:
- 当创建一个UDP套接字时,该套接字会绑定到一个主机本地的端口号上。例如,在这段代码中,创建了一个端口号为12534的UDP套接字:
DatagramSocket mySocket1 = new DatagramSocket(12534);
- 在使用UDP套接字发送数据时,必须指定目标IP地址和目标端口号。
- 当创建一个UDP套接字时,该套接字会绑定到一个主机本地的端口号上。例如,在这段代码中,创建了一个端口号为12534的UDP套接字:
接收:
- 当主机收到一个UDP数据报时,会检查数据报中的目标端口号,并将该数据报转发到与该端口号相对应的套接字中。
- 对于来自不同ip/端口的数据,如果有相同的目标ip/端口则会被放入目标的同一个socket中。
- 仅依据目标端口进行合并
tcp
- CP套接字由四个值组成,称为4元组(4-tuple):源IP地址,源端口号,目标IP地址和目标端口号。
- demux:接收器使用这四个值来将数据段定向到相应的套接字
- 服务器主机可以支持许多同时存在的TCP套接字,每个套接字都由自己的4元组来识别。(源头ip/端口不同不合并)
- Web服务器为每个连接的客户端使用不同的套接字,因此对于每个请求,非持久化的HTTP将会有不同的套接字
可靠传输
- 手段
- 校验和:Checksums (to detect bit errors)
- 超时:Timers (to detect loss)
- ack:Acknowledgements (positive or negative)
- 序号:Sequence numbers (to deal with duplicates)
- packet corruption
- 校验,回复ack
- 但是ack也可能会出错!
- 无法判断是1还是2
- 因此给数据加上序号,表示是第几个数据包
- 窗口长度必须小于或等于序号空间大小的一半
- 校验,回复ack
- packet loss
- 发送者从发送时开始计时,超时没有答复后重新进行发送
- timeout时间长度要恰好,太短可能发生错误判断;太长会导致效率太低
- 发送者从发送时开始计时,超时没有答复后重新进行发送
停止&等待协议
效率:
- 效率极低,不能充分利用资源
- 发送者繁忙时间占总时长的比例
Pipelined(流水线)
- 一次发送多个包而不等待ack
- 效率计算
- 假设一次发送三个包
- 假设一次发送三个包
滑动窗口
- 滑动窗口长度为n,发送端在窗口中发送,接受端接收,两个窗口是相对独立的(可能不同步,如返回的ack正在传输中)
- 最多有n个未确认包在传输之中
-
- 窗口末尾是最后面的没有ack的包
带宽
- n太大超过网络带宽会产生丢包严重等问题
确认
- Cumulative ACKs:ack附带信息表示想要收到的下一个(滑动窗口中第一个元素)数据包
- Selective ACKs
- 对收到的每个包进行回复,提供更为精准的信息,但需要更为复杂的处理流程
- Cumulative ACKs:ack附带信息表示想要收到的下一个(滑动窗口中第一个元素)数据包
重发送(解决错误):
- Go-Back-N
- 当接收端只按照顺序接受时(会丢弃将来才应该到的后面的包)
- 接收端使用Cumulative ACKs
- 发送端只需要为一组数据包中的第一个设置定时器,如果这个包没有成功发送,那就重新发送所有的数据包(第一个数据包是否受到决定了滑动窗口能否向前移动)
Selective Repeat
- 复杂,对每个数据包都设置定时器
- 接受方受到一个不在滑动窗口(在前面)中的数据时也要重新发送ack,否则可能导致发送无法向前滑动 -
-
- 当错误率很高时gbn甚至不能完成传输
- sr常用于无线网络
- 没有确定的数据都要放在buffer里(内存/缓存)
- Go-Back-N
UDP
概述
- 尽力而为的服务
- 可能丢失
- 不一定按顺序到达
- 无连接的
- 发送者接收者之间不会握手
- 包头相对较小
- 用途
- 直播服务(不在乎丢包,注重实时性、流畅度)
- DNS
- SNMP
包头
- 构造伪首部用于计算校验和
- 源port可以省略(当不需要回复时)
checksum计算
- 发送端计算后放入checksum,接收端重新计算并比较是否相同
- checksum=0表示不需要进行校验确认
- 对报文段中所有16比特字的和进行加和
- 将溢出位加在末尾
- 最后对结果取反码得到checksum
TCP
概述
- 可靠性
- 一定把数据正确传到
- 丢失就重新传输
- 按顺序到达
- 字节流传输
- 机制
- checksum
- 序列号(偏移量)
- 使用缓存存储乱序的数据包
- 双方维护滑动窗口进行维护
- 使用累计确认法(发送n表示n之前的都收到了)
包头
- 32比特的序号字段和32比特的确认号字段。这些字段被TCP发送方和接收方用来实现可靠数据传输服务
- 16比特的接收窗口字段,该字段用于流量控制。该字段用于指示接收方愿意接受的字节数量。
- 4比特的首部长度字段,该字段指示了以32比特的字为单位的TCP首部长度。由于TCP选项字段的原因,TCP首都的长度是可变的。(通常, 选项字段为空,所以TCP首部的典型长度是20字节。)
- 可选与变长的选项字段(options ßeld) ,该字段用于发送方与接收方协商最大报文段长度(MSS)时,或在高速网络环境下用作窗口调节因子时使用。首部字段中还定义了一个时间戳选项。
- 6比特的标志字段,ACK比特用于指示确认字段中的值是有效的,即 该报文段包括一个对已被成功接收报文段的确认。RST、SYN和FIN比特用于连 接建立和拆除。在明确拥塞通告中使用了CWR和 ECE比特。(当PSH比特被置位时,就指示接收方应立即将数据交给上层。最后,URG比特用来指示报文段里存在着被发送端的上层实体置为"紧急"的数据。紧急数据的最后一个字节由16比特的紧急数据指针字段 指出。当紧急数据存在并给出指向紧急数据尾指针的时候,TCP必须通知接收端的上层实体。)(这两项实际中并不使用)
丢包与重传
sequence number(偏移量)
- 数据量达到一节或者超时时tcp执行发送(应用程序的数据是逐渐转交给tcp的)
- 长度
ack与序列号具体实现过程
当发送方发送一个数据包时,数据包的第一个字节会被标记为一个序列号X。如果数据包中有B个字节,则数据包中的字节序列为[X,X+1,X+2,… X+B-1]。当接收方接收到这个数据包时,它会发送一个ACK确认接收到了该数据包。如果在序列号X之前的所有数据都已经被接收方接收到,则ACK将确认接收到了序列号为X+B的下一个字节。如果接收方已经接收到了最高顺序的字节为Y,使得(Y +1)<X,则ACK将确认接收到Y + 1。即使这之前已经确认过了,仍会再次确认。
-
- 反复发送500告知发送方没有收到
- 因为TCP只确认该流中至第一个丢失字节为止的字节,所以TCP被称为提供累积确认
接收方收到重复ack时的处理
- 重复ack是出现数据包丢失的标志
- 当发送方发送一个数据包后,如果在一段时间内没有收到接收方的确认信息,则会进行重传。但是,TCP协议使用了一种更快的重传机制,即在接收到连续的k个重复的确认信息后,就会立即触发重传,而不是等待超时时间。在TCP中,通常将k设置为3。
如果等待一段时间后没有收到任何ack
- 那么从滑动窗口的第一个开始进行重传
- RTT:数据往返一次需要的时间(发送数据到接收确认所需要的时间),应该使timeout与RTT相近(SampleRTT:样本RTT,是指当前分组往返的时间;EstimatedRTT:估计的RTT,是指对SampleRTT进行平均计算得到的RTT值)
- 问题:如何区分ack的来源
在发送方进行重传之后,有两种选择:
- 在发送缺失的数据包之后,将滑动窗口向前移动与收到的重复确认信息数相同的距离。这种方法可以加速传输速度,但也可能出现错误。
- 在发送缺失的数据包之后,等待接收方发送确认信息,然后再将滑动窗口向前移动。这种方法会因为一个数据包的丢失而减慢传输速度。
RTO指数回避算法(超时重传时间,指在此时间内如果没有收到确认信息,就会触发超时重传机制)
不要使用从重传中获取的SampleRTT,因为这可能会导致估计的RTT偏高。重传的数据包可能会受到拥塞等其他网络问题的影响,从而导致RTT偏高。因此,我们只使用原始的、成功传输的数据包的SampleRTT。
EstimatedRTT = (1 - α) × EstimatedRTT + α × SampleRTT
其中,α = 0.125是平滑系数,表示对当前SampleRTT与上一次的EstimatedRTT进行平均的权重。这里我们假设初始的EstimatedRTT为0。
RTO的初始值为2倍的EstimatedRTT。算法采用指数退避机制,当RTO超时时(没有收到答复),将RTO加倍,直到达到一个最大(60s);收到了就对RTO进行重置
问题RTT会发生变化,不稳定
Jacobson/Karels algorithm
- SRTT(EstimatedRTT):平滑的往返时延,通常是通过对多次测量的SampleRTT进行加权平均得出的估计值。SRTT是用于计算RTO和DevRTT的重要参数。
- SERR (Smoothed Error):平滑误差,是估计的RTT和实际测量值之间的差异。SERR用于计算SDEV,以便更好地估计RTT的变异性。(SamplaeRTT-EstimatedRTT)即Deviation
- SDEV (Smoothed Deviation):平滑的偏差,是样本RTT与SRTT之间的差异的指数平均值。SDEV用于计算RTO,以便更好地调整重传超时时间,以适应网络中的变异性。即DevRTT
- 计算RTO:RTO是估计RTT加上4倍平均偏差的值,旨在提供足够的时间来等待确认信息的到达。
- 该算法的主要优点是它能够更准确地估计网络延迟和RTT的波动,从而提供更准确和可靠的RTO超时时间。同时,该算法还能够自适应地调整RTO超时时间,以适应网络的变化和波动。
例子
- 只要第二个报文段的ACK在新的超时发生以前到达,则第二个报文段将不会被重传。
- 只要第二个报文段的ACK在新的超时发生以前到达,则第二个报文段将不会被重传。
连接建立与控制
- 标志位
- 2-way握手
- a发送syn,b回复syn
- 丢失的syn包使用重传处理
- 问题:
- 可能会收到来自旧的会话的过时的数据包
- 问题解决:
- 对sn随机初始化(isn: initial sequence number)用于标识发送方发起连接的初始序列号
- 但过时的syn包还是会造成问题
- three-way:
- syn附带序号,确认序号正确(是对应的)再回复ack确认建立连接
- 过程
- 如果syn包发送失败,那么不会收到ack回复,并且发送者不知道接收者距离有多远,因此设置一个固定的超时时长(一般3s)
- SN是自己的编号,AN是对方的
- SN:序列号,用于标识TCP协议中每个数据包的唯一序列号。
- AN:确认号,用于标识收到的数据包的序列号。当接收方收到TCP数据包后,会向发送方发送一个ACK包,其中包含确认号,表明接收方已经成功接收了前面发送方发送的数据包。
- 双方会分别选择一个序号作为自己包序列序号的起点
连接断开
- 单边关闭
- 只关闭了a处的连接
- 如果b没有收到ack会重复发送fin
- a在回复ack后不会立即关闭,因为b可能收不到ack,需要重新进行发送
- 双边关闭
强制关闭
- 发送rst后对方不会进行回复,但如果对方继续发送data(表示没收到rst)则会重新发送rst
流量控制
- 滑动窗口回顾
- 发送方和接收方都会维护一个窗口,窗口的左边缘表示未确认的数据的开始位置,发送方维护的是还未收到确认的数据,接收方维护的是期望接收的数据的开始位置以及接收到的第一个缺失数据的位置。当发送方收到确认信息时,就知道接收方的窗口已经向前移动了。窗口的右边缘则是左边缘加上一个常数,这个常数只受传输层缓存大小的限制。
- 数据接收到并取走才滑动
- 流控:控制发送端发送的数据不会超过接收端的缓存能力
credit scheme
在发送ack同时在tcp包头中附加RWND,告诉发送方自己还有多少空闲的缓存,即还有多少空间可以接收数据。(总缓存大小减去已经使用的部分)(已使用的长度为最后一个接收到的减去最前面收到但还没有处理完成的长度)
总结:
- 发送方和接收方都会维护一个窗口,窗口的大小和位置会随着数据的发送和接收而变化。当发送方收到ACK确认信息时,窗口向前移动,表示之前发送的数据已经被接收方成功接收了。而当接收方消耗掉接收缓冲区中的数据时,窗口也会向前移动,表示接收方已经成功接收了之前发送的数据。
- 为了防止接收方缓存区溢出,接收方会告诉发送方当前接收缓存区的右边界位置,即还有多少空间可以接收数据。发送方会遵循这个位置,确保自己发送的数据不会超出接收方缓存区的限制,从而避免数据丢失的问题。
优点:
- ack与流量控制信号分开,避免二意性
- 头部
- AN表示已经接收到的数据的最大序列号(接收方已经成功接收的所有数据段的最后一个字节的序列号为AN-1,下一个期望接收的字节的序列号是AN)
- W表示接收方当前的窗口大小。(W表示接收方当前还有多少缓存空间可以用于接收数据,如果发送方想要继续发送数据,需要得到接收方的允许,发送窗口大小不能超过W。)
- 如果接收方B想要将窗口大小增加到k(k>j),而此时没有额外的数据到达,那么B可以发送一个ACK/CREDIT消息,其中AN=i,W=k,表示允许发送方在下一次发送数据时发送k个字节。
- 如果接收方B收到了一个包含m个字节数据的数据段(m<j),而此时不想要增加窗口大小,那么B可以发送一个ACK/CREDIT消息,其中AN=i+m,W=j-m,表示允许发送方在下一次发送数据时继续发送j-m个字节。
- 需要注意的是,如果ACK/CREDIT消息丢失了,那么对协议的影响很小,因为未来的ACK消息会重新同步协议。
- 如果发送方超时并重新发送数据段,那么它会触发一个新的ACK/CREDIT消息,从而重新调整窗口大小。
- 死锁问题:
- 接收方B首先向发送方A发送一个带有AN=i、W=0的数据段,表示关闭接收窗口。接着,B向A发送另一个数据段,其中AN=i,W=j,表示重新打开窗口,但这个数据段可能会丢失。此时,A认为窗口已经关闭,而B认为窗口已经打开,从而导致了死锁。
- 为了解决这种死锁情况,可以采用窗口定时器的方法。具体来说,当窗口定时器到期时,如果没有收到任何数据,则发送方A可以发送一些数据,例如重传之前的数据段。这样,即使接收方B发送的第二个数据段丢失了,发送方A仍然可以通过定时器来重新激活数据传输,从而避免了死锁。
拥塞控制
拥塞产生的原因与代价
- 当繁忙时会产生大量丢包与重传,即做大量无用功,进一步加重拥塞
让传输路径上的路由器发送速率大于接收速率,防止在传输过程中超出路由器缓存造成丢包
- 思路:根据拥塞状况调整滑动窗口的大小
- 主机可以通过不同的方式来推断当前网络的拥塞程度,并根据拥塞程度进行相应的调整。
- 另一方面,网络也可以向主机报告拥塞程度,并要求主机进行相应的调整。
- 还有一些策略是将以上两种策略结合起来,例如,主机可以根据自己的传输情况来推断网络的拥塞程度,并将这些信息反馈给网络,从而实现更加精细的拥塞控制。
- 在TCP连接中,每个连接都有一个窗口,它控制着可以同时发送的未确认数据包数量,从而影响发送速率。( 发送速率 ~Window/RTT)
- 如果窗口大小越大,就可以发送更多的数据包,从而提高发送速率;反之,如果窗口大小越小,就可以限制发送速率。通过动态调整窗口大小,可以实现流量控制和拥塞控制等功能,从而保证网络的可靠性和效率。
- 除了流量控制窗口(RWND),又增添拥塞窗口(CWND)表示可以在网络中发送而不会导致拥塞的字节数量(由发送方根据拥塞控制算法计算出来的)。
- Sender-side window = min {CWND, RWND}
- 实际上:RWND >> CWND
确定可用带宽
- 判断方式:
- 数据包往返时延(但是由于抖动很大,不可靠)
- 由路由器告诉终端发生了拥塞(太复杂了,不实际)
- 实际:使用数据包的丢失作为拥塞的标志(在广域网中使用,但移动网络中大量丢包造成了干扰)
- 丢包分类
- 收到连续ack:说明丢了个别包,问题不严重
- 超时没有收到ack:问题严重,出现严重拥塞
带宽动态调整
- 基本策略:
- 收到新的ack:加快发送速率
- 发现丢包:降低发送速率
- 在慢启动阶段,TCP会快速增加其拥塞窗口(CWND),以发现网络的可用带宽。(在第一次丢包之前会以指数速率快速增长)
- 初始时CWND=1,发送速率为MSS(数据包最大大小)/RTT(通过每收到一个ACK就把CWND+1),相当于每RTT翻一倍
- ssthresh最初会被初始化为一个很大的值
- 一旦达到了阈值(ssthresh)或发生拥塞丢包/重复ACK,TCP就会进入拥塞避免阶段。在这个阶段,TCP会以一种被称为加性增加和乘性减少(AIMD)的方式调整其CWND大小。简而言之,TCP在这个阶段会将CWND每RTT增加一个MSS(1/CWND,缓慢增加,即一个RTT加1),检测到3个连续重复ack时
ssthresh = CWND/2 CWND= ssthresh+3(收到3个重复ACK)
开始快速恢复(就是不到1,到CWND/2)(是较新版本TCP Reno所特有的,早期版本Tachoe会不区分丢包和冗余ACK,都会置1,进入慢启动)阶段,检测到丢包时ssthresh = CWND/2, CWND = 1
重新慢启动- tip:当出现ack冗余或者数据包丢失后,拥塞窗口长度会在下一轮回发生变化
- 如果在一轮回达到了sshresh,那么本轮回的长度就是sshresh,因为到达后会终止本回合开启下一回合!
- &&典:p41
AIMD原理(选择原因)
- 优势:效率&公平
- 可以找到带宽上限
- 动态调整带宽
- 公平分配带宽
- 其他可选:
- 绿线上:公平;红线上:效率;交叉点为最佳点(希望最终收敛到这一点)
- AIAD(常数加减)
- 不满足公平性
- MIMD(比例加减)
- 不满足公平性
- AIMD(常数加,比例减)
- MIAD(比例加常数减)
- 垃圾
带宽分配
改进-快速恢复(TCP Tahoe)
- 改进(TCP Tahoe)
- cwnd=10,接收方等待101,发送方为 [101, 102, 103,…, 110]
- 假设101丢失
- 直到重传的101被收到后窗口才能继续向前移动,因此会造成窗口阻塞问题
- 收到3个ack说明发送还在正常进行,不妨+3
- 在快速恢复阶段
- 直到收到新ack(包含缺失重传的那一个)再退出快速回复,并令CWND = ssthresh,进入拥塞避免
- 保证发生了单数据包拥塞后,还会继续向前发送
- &&
- cwnd=10,接收方等待101,发送方为 [101, 102, 103,…, 110]
理论分析
宏观模型
- 吞吐量
- 忽略慢启动指数增加阶段,因为这一阶段是很短的
- 假设在连接持续期间 RW几乎不变.那么 rcp 的传输 速率在 W/(2xRTT) W/RTT 之间变化(拥塞抑制阶段,每次加一个MSS)
- 故
-
- 平均发0.75w包/RTT,平均0.5wRTT发生一次丢包
- 当RTT不一致时TCP不是公平的
问题
高速传输问题
- &&
- 使用throughput公式计算,注意单位
- 解决
- 当越过上界时加快传输增加速度(乘性增加)
- 建立多条连接
Rate-based
- 避免震荡,直接计算出rate,发送数据
- 目的:速率与传统方式相同,但比较平稳,固定速率发送
移动网络丢包问题
- TCP在某些情况下可能会将数据包的丢失误认为是网络拥塞的结果,而实际上这些丢失可能是由于数据包损坏或其他非拥塞原因导致的。这种情况下,TCP会错误地将数据包的丢失解读为拥塞信号,从而触发拥塞控制算法中的拥塞避免机制,导致流量的速率被削减。
- 流量的吞吐量与丢包概率之间存在一个倒数的平方根关系。如果丢包概率增加,流量的吞吐量会下降。这个关系适用于所有类型的丢包,无论是由于拥塞引起的还是其他非拥塞原因引起的。
短数据问题
- 如果数据流比较短,可能无法充分加速,没有离开慢启动就结束了
- 如果包比较少可能无法启动快速重传,可能被误判为丢包
- 会增加短数据的延时,因为tcp总是想将缓存占满,因此数据包到达路由器后可能会经历漫长的延时等待
- 长数据支配短数据
欺骗问题
- 由于TCP是端算法,如果在操作系统修改CWDN的长度,会造成公平性的问题
- 一个传输开多个TCP连接抢占资源
路由器拥塞控制
思想
- 路由器告诉终端发生了拥塞:
- 解决误判、高排队延迟问题
- 路由器通知终端发送速率:
- 解决高速传输问题、短流问题
- 路由器保证传输公平性
抑制分组
- 拥塞路由器告诉发送源发生了拥塞丢包,使用ICMP进行通知
- 问题:
- 对路由器性能要求太大
- 反馈速度太慢
反压
- 逐层进行抑制分组,一层通知相邻的一层
警告位
- 在数据包的包头做一位标记,如果接收端发现head中有信号,则在返回的ACK中添加标志位提醒发送端,由此接收端不丢包也可以知道拥塞状态
精确拥塞通知
- 优点
- 不将数据包损坏误认为拥塞:ECN的优点之一是它可以通过在数据包中设置特殊的标志位来显式地通知接收方关于网络拥塞的情况。这样,TCP不会将数据包的损坏误认为是拥塞信号,而是通过相应的机制进行恢复和调整传输速率。
- 提前指示拥塞:ECN可以作为早期拥塞指示器,提供关于网络拥塞的信息。这可以帮助发送方避免等待传输超时来检测拥塞,从而减少传输的延迟。
- 易于增量部署:ECN的部署相对容易,特别是在今天的网络中,已经通过RFC 3168定义并使用IP头中的服务类型/差分服务代码点(ToS/DSCP)位来标识ECN。在数据中心环境中,ECN也很常见。
随机早期丢弃
- 防止出现同步波动问题
RED
- 在队列完全堆满之前就提前开始进行随即丢包,避免同时丢包
- 队列越长,丢包的概率越大
公平丢弃
- 为每个流提供独立queue,轮流传输,保证公平
&&MAX-MIN
- 不能直接平分,因为有的流很小,平分会造成浪费
- 如果需求小于直接平分的值,则直接满足,剩下的包再继续瓜分
- 无法直接实现:因为一个包必须一次性发送完成,无法轮流发送(不能拆分为逐字节发送)
Fair Queuing
使用算法进行模拟:
- 首先计算理想评分条件下每个数据包完成发送的时间,按照理论完成的先后依次进行发送
- WFQ带权重的公平
在实际中不一定是对单条TCP算作一个流(太多了),可以对一个更大范围的数据算作一个“流”(比如一个系楼)
与FIFO相比
优点:
- 避免欺骗,带宽分享不取决于往返时间(更加公平)
- 网络中的不同流(或连接)可以独立选择自己的速率调整方案或拥塞控制算法。
问题:
- 实现复杂度高
- 不能避免拥塞
- 虽然公平,但在这种情况下造成低效率
多媒体传输
音频传输
- 采样范围(频率范围)
- 采样频率(与模拟信号拟合程度)
视频传输
- 压缩:
- 空间压缩:同一图像不同位置(相邻)
- 时域压缩:不同帧相同信息压缩
- 压缩:
分类
流媒体:
服务器有完整视频,不需要下载整个文件,在线(在下载的同时)播放
-
- 服务器读取->发送->用户接收
- 正在播放的内容与正在接受的内容有一定不同(预先缓冲)
- 挑战
- 能否流畅播放(缓冲不用光)是用户最重视的
- 用户可能回看、快进等
- 网络时延、传输带宽不稳定
- 最初播放开始前先进行缓冲(储备)
- 在播放过程中buffer的量会反复波动
- 根据buffer进出速率关系
- 使用UDP传输
- 丢包没有很大影响,将丢包、异常处理交给应用层
- send rate = encoding rate = constant rate
- UDP may not go through firewalls
- 使用tcp+http
- 使用tcp拥塞控制机制,还可以更为方便的实现用户控制(播放、暂停)等功能
- DASH传输(HTTP基础上)
- 用于传输存储的数据
- 把大文件(视频)切分成好多小文件发送
- 将不同清晰度的文件分别切分发送,供用户选择
- 客户端根据网络带宽选择不同清晰度,实现自适应
- 客户端决定什么时候请求下一个文件,请求什么清晰度,从哪里请求,都交由用户决定
视频电话Voip:
- 注重延迟
- < 150 msec: good
- > 400 msec bad
- 数据包会丢失(1%-10%是可以接受的)、数据包有延迟
- 数据包丢失:如路由器缓存已满丢包
- 延迟丢包:数据包到达的太晚,即使到达了也要被丢弃(如>400ms)
- 使用超级节点帮助host建立连接
- 登陆后保持登录,内层与超级节点保持连接
- 因为数据包的传输实验可能发生抖动,因此也需要有播放延时(小于400ms)
流直播:
- 体育比赛啊
实时传输协议
RTP
- 在UDP之上,一种实时传输协议(传输实时音频视频等)
- RTP分组是封装在UDP内的
- 包含负载类型、序列号、时间等信息
- Timestamping(时间戳)注意与序列号区分
- 接收方使用时间戳来重构原始的时序信息。
- 协调不同流之间的同步,例如音频和视频的同步播放
- 时间戳的主要作用是在接收方进行数据恢复和播放时,保持正确的时序。通过时间戳,接收方可以根据数据包的采样时间来恢复和播放音视频数据,以确保音视频同步和正确的时序。
- 序列号
- 丢包检测:接收方可以通过比较接收到的数据包的序列号来检测是否有数据包丢失。如果接收方在连续的序列号中发现有缺失的序列号,就可以推断出存在丢包的情况。
- 恢复包序:在网络传输中,数据包可能会经历乱序的情况,即接收方可能以不同的顺序接收到数据包。通过序列号,接收方可以重新按照正确的顺序组装接收到的数据包,以保证数据的正确顺序。
- 负载类型中会标识数据包携带的数据类型、如音频视频等,以及用于指定有效负载格式以及编码/压缩方案。应用程序可以根据有效负载类型标识符来解释有效负载数据。
- RTP并不提供确保及时数据传递的机制。RTP封装仅在端系统可见,中间路由器看不到RTP封装。路由器对RTP数据包不做特殊处理,不提供额外的支持
RTCP
- 与RTP配合使用
- 用于源和端交换信息(双向,可以反馈信息)
- 用于传输关于RTP流的控制信息,如接收质量反馈、丢包统计、带宽估算和参与者信息等
服务
- QoS(服务质量)监测:
- 接收者向发送者反馈服务质量
- 发送者由此对传输进行调整
- 接收方可以确定拥塞是局部的、区域的还是全局的
- 源标识(接收者可以确定数据的来源)
- 媒体间同步(音画同步)
- 控制信息缩放:调整传输以适应网络状况,如调整传输方式、帧率等
- 限制控制流量:防止控制信息占用资源过多对正常传输造成影响
RTSP
- 与RTP配合使用
可以使用UDP也可以使用TCP,以ascii的格式发送命令
它允许客户端通过发送请求来控制流媒体服务器,如播放、暂停、快进、倒带和选择不同的音视频轨道等操作,可以用于控制实时流媒体的播放和交互。
SIP
- 在IP网络上实现软电话功能,可以在通话中更换编码方式、邀请加入
- 找到通话对象:都在代理处登记,通过代理寻找对方
- SIP主要用于会话的建立、修改和终止(而不是传输!),它处理会话的控制和信令。
格式
- user@host
通话建立
- 通过SIP地址确定被叫方(callee)的当前IP地址。
- 通知被叫方,告知其有人想要建立通话。
- 主叫方(caller)和被叫方商定媒体类型和编码,确定通话所使用的媒体格式和编码方式。
SIP地址必须转换为被叫方当前主机的IP地址(即将一个无法直接访问的内网地址转为为一个可以在公网访问到的地址)
- 注册服务器(Registrar):接受来自客户端(主叫方或被叫方)的注册请求,存储用户名对应的ip地址,可以用于查询
- 重定向服务器(Redirect):将指向被叫方的下一个跳转地址返回给主叫方,指示主叫方应该尝试另一个地址或服务器来完成通话建立。(不直接参与请求的传输)
- 代理服务器(Proxy):决定下一个跳转地址并将请求转发(作为中间人)。
- 主叫方(Caller):Bob@umass.edu,发起一个INVITE请求消息,发送给umass SIP代理。
- 代理(Proxy):umass代理将请求转发给upenn注册服务器。
- 注册服务器(Registrar):upenn服务器返回一个重定向响应,指示应该尝试Alice@eurecom.fr。
- 代理(Proxy):umass代理向eurecom注册服务器发送INVITE请求。
- 注册服务器(Registrar):eurecom注册服务器将INVITE请求转发给IP地址为197.87.54.21的Alice SIP代理。
- SIP响应:SIP代理和服务器之间进行一系列的请求和响应交互,包括接受INVITE请求、确认、会话建立等。
- 媒体传输:媒体直接在SIP代理之间传输,也就是Bob和Alice之间进行语音或视频通信的过程
通话管理
在通话过程中添加新的媒体流:允许在通话进行中添加额外的媒体流,例如添加一个新的音频或视频流。
在通话过程中更改编码方式:允许在通话进行中更改媒体数据的编码方式,以适应网络条件或其他需求。
- 邀请其他人、转接和保持通话:允许用户邀请其他人加入通话、将通话转接给其他人或将通话放置在保持状态。这些功能用于通话的管理和协调。
因特网质量控制QoS
整合服务架构ISA
- 把一组数据包定义为一个流
- 一组数据包具有相同的QoS参数(传输需求)
功能
- 路由算法:除了延迟外考虑更多的因素,如优先等级等
- 排队先后:优先级调度
- 丢包策略:选择性丢包
- 资源预留:为特定QoS的流预留资源(类似虚电路)
- RSVP
- Admission control:确定是否有足够的资源来满足请求的服务质量(QoS)下的数据流
- Traffic control database:流量控制数据库用于存储与流量控制相关的参数
- Management agent:管理代理通过修改流量控制数据库的内容来指导接纳控制模块设置策略。
RSPV预留过程
- 接收方(Receivers):接收方生成带有预留请求的RSVP消息,并将消息沿着上行传递给发送方。
- 请求的范围:预留请求传播的发送方主机集合。
- 每个中间路由器:RSVP模块将请求传递给接纳和策略控制模块,并执行检查。
- 维护每个流的软状态:为每个流维护软状态,定期进行更新。
缺点
- 设备要求高,复杂,成本高
- 不具有很好的弹性
- 不能很好的同时服务很多的流
差分服务DS
- 只提供几种服务分类,把数据分为不同类,对每一类的数据进行统一处理
- 从而减少状态,降低复杂度
- 对数据包打标记
- Use IPv4 header Type of Service or IPv6 Traffic Class field
- 作用域可控
- 可以单个ISP实施(通常),也可以共同实施
- 可以单个ISP实施(通常),也可以共同实施
内部路由
- 在域内一致解释DS代码:确保在特定网络域内对DS(差异化服务)代码点的一致解释。
- 基于代码点的简单处理机制:使用简单的机制根据代码点(类别)处理数据包。
- 分类器:根据DS代码点、源地址、目标地址、高层协议等对数据包进行区分。
- 队列管理:对数据包进行排队管理。
- Per Hop Behavior(PHB):根据代码点为数据包提供优先处理,不同的代码点会得到不同的待遇。
- 数据包丢弃规则:当缓冲区饱和时,规定了应丢弃哪些数据包。
边缘路由
- 对每个流进行流量管理:边缘路由器可以对每个数据流进行个别的流量管理。它可以标记和监管数据包,将其划分为符合要求的流量(in-profile)和不符合要求的流量(out-profile),标识分组。
- 内部路由器:边缘路由器将标记过的数据包传递给内部路由器。内部路由器根据边缘路由器的标记对数据包进行分类、缓冲和调度。它根据数据包的标记给予优先处理,更重视符合要求的数据包(in-profile)。
- 分类器(Classifier):将传入的数据包流分成不同的类别。
- 流量计(Meter):测量流量以符合预设的规格要求。
- 标记器(Marker):根据需要,通过重新标记代码点来进行流量管理。
- 塑形器(Shaper):使用令牌桶来塑造数据包流的流量。
- 丢弃器(Dropper):如果流量速率超过类别规格中指定的限制,丢弃数据包。
边缘路由器:对流分类打标记、对包数目等进行控制
- 根据in-profile and out-profile分类(是否在合同保证内)
- 常用控制
- 平均速率(Average Rate):指的是数据以恒定速率离开漏桶的速率。它表示单位时间内允许发送的平均数据量。例如,如果平均速率为100 Mbps,则漏桶每秒可以以平均100 Mbps的速率发送数据。(可以通过设置装填速度实现)
- 峰值速率(Peak Rate):表示漏桶允许的最大发送速率。峰值速率通常高于平均速率,并且可以在短时间内发送更多的数据。例如,如果峰值速率为200 Mbps,则漏桶可以在某些短时间段内以高达200 Mbps的速率发送数据。(可以通过设置通的容量和装填速度实现)
- 突发长度(Burst Size):指的是漏桶能够容纳的最大突发数据长度。突发长度与峰值速率相关,它定义了在突发情况下漏桶可以容纳的最大数据量。例如,如果突发长度为1 MB,则在突发发送数据时,漏桶最多可以容纳1 MB的数据。
- 在数据进入网络前进行控制、分类
- 漏桶策略
- 以恒定速率将数据放入网路,用缓冲区进行稳定
- 如果积累的数据超过了限制就进行丢包
- 以恒定速率将数据放入网路,用缓冲区进行稳定
- token桶
- 在边缘有一个”桶“里面装在用于提供特殊服务的token,装入速率r表示允许的最大(平均)速率,大小b表示可以爆发传输的最大数据量,没有token的意味着普通服务(低优先级),
- t时间内最多$$rt+b$$
- 发送队列$$3_7$$
- 设有n条流,参数$$b_i$$ $$r_i$$ 总带宽为R
- 流i至少有贡献链路带宽$$\frac{R*w_i}{\sum w_j}$$
- 漏桶+加权公平队列
- 数据包需要经过漏桶才能进入WFQ队列
- 当$$bi$$个分组被一次性加入到WFQ等待区域时具有最大时延$$d{max}=\frac{b_i}{R*\frac{w_i}{\sum w_j}}$$