1. 拥塞（congestion）
当过多的包在网络缓冲区中竞争某个相同链路时，队列会溢出丢包，当这种丢包成为普通事件时，则称网络发生拥塞。
简单概述就是对聚合带宽的需求超过了链路的可用容量。
1.1. 产生原因
宏观原因：网络资源分布不均匀，流量分布不均匀，
微观原因：报文聚合到达率大于路由器输出链路的带宽
1.2. 后果
- 多个包丢失，链路利用率低下
- 全网同步振荡，吞吐量下降
- 高排队延迟，拥塞崩溃
2. 拥塞控制
资源分配就是尽量合理的满足用户对网络资源的需求，但是总会有满足不了的情况
拥塞控制就是网络主机和路由器防止网络过载的情况采取的措施。这种措施可以是阻止几个用户使用网络，更好的方式是让全网都来减少流量，所以拥塞控制经常包含资源分配方法。
2.1. 资源分配和拥塞控制基本单位：数据流
流是在源目主机对之间，通过相同路由而发送的一系列包，在路由器中的资源分配中这是一个重要的抽象。
流过同一路由器，且具有若干相同头部特征的一系列数据包。这些特征是：源地址、目地址、源端口号、目端口号、协议类型、服务类型TOS、输入端逻辑接口等。
“通道”是端-端连通的一种抽象，“流”对网络路由器是可见的。
2.2. 拥塞控制与流量控制的区别
拥塞控制（congestion control）与全网有关，涉及多个端到端、主机、路由器等很多网络元素；目的是确保通信子网能够承载用户提交的通信
量，是一个全局问题，
流量控制（flow control）只与一对端到端的通信量有关，只涉及快速发送方与慢速接收方的问题，是局部问题，一般都是基于反馈进行控制的
要防止这两者的混淆，但它们有些机制是相同的
2.3. 解决拥塞：资源分配机制
解决拥塞本质上是更合理的资源分配：
1. 以路由器为中心与以主机为中心
2. 基于预留与基于反馈
3. 基于窗口与基于速率
2.3.1. R/H为中心的分配
以R为中心，链路算法(Link Algorithm). 在网络设备中(如路由器和交换机) 执行,作用是检测网络拥塞的发生,产生拥塞反馈信息，R决定何时转发包，决定丢掉哪个包，通知正产生网络流量的那些主机允许它们发送包的数目
以H为中心，源算法(Source Algorithm).源算法在主机和网络边缘设备中执行,作用是根据反馈信息调整发送速率端主机观察网络状态（多少个包成功通过了网络）并因而调整其行为
二者并不互斥，R中心的拥塞管理仍需要H执行R发送的建议消息，H中心的拥塞管理业需要R丢弃R溢出时那些包
2.3.1.1. 源拥塞控制算法-TCP层
源算法中使用最广泛的是TCP协议中的拥塞控制算法。TCP是目前在Internet中使用最广泛的传输协议.
下表给出拥塞控制源算法的简单描述
| 拥塞控制源算法 |
描述 |
| Tahoe-TCP |
慢启动、拥塞避免、快速重传-早期较为普遍采用版本 |
| Reno-TCP |
多一个：快速恢复 |
| NewReno-TCP |
引入了部分确认和全部确认的概念. |
| SACK-TCP |
规范了TCP中带选择的确认消息 |
| Vegas-TCP |
采用带宽估计,缩短了慢启动阶段的时间 |
2.3.1.2. 源算法测量网络是否拥塞的参数
缓冲区缺乏造成的丢包率；
平均队列长度；
超时重传包数目；
平均包延迟（RTT是重要指标）；
包延迟变化（Jitter）。
2.3.1.3. 路由器向源反馈方法
向负载发生源发送一个告警包；
包结构中保留一个位或域用来表示发生拥塞，一旦发生拥塞，路由器将所有的输出包置位，向邻居告警；
主机或路由器主动地、周期性地发送探测（probe），查询是否发生拥塞。
2.3.2. 基于预留与基于反馈
-
基于预留
建立流时，端主机请求网络给予一定的容量，每个R分配足够的资源（缓冲区或链路带宽的比例）来满足这一请求。问题：利用率？
如果由于资源的过量则R不能满足该请求而拒绝该流。这同打电话时碰到忙音一样？
-
基于反馈
端主机首先没有预留任何容量，而按照它们接收到的反馈来调整其发送。 调整或者是显式的，如拥塞R发送一个“请慢下来”消息到主机或
隐式的：如端主机根据外部可观察的网络行为，如包丢失率，来调整其发送率
2.3.2.1. 两种机制的比较
-
基于预留的系统总是意味着
以路由器为中心的资源分配机制：因每个R负责保持跟踪现在有多少容量被预留，并保障在其所做的预留内每个主机是活着的。
如果在作了预留后某主机发送数据快于它曾经所要求的，则该主机的包将是准备丢弃。R也将会拥塞
-
基于反馈的系统
可以既是以R为中心也可是以H为中心的机制。一般如果反馈是显式的，则R至少某种程度就被包括在资源分配模式里； 如果反馈是隐式的，则几乎所有的重担都落在端主机上，当R变成拥塞后就默默地丢包。
2.3.3. 基于窗口与基于速率
不论流控还是拥控，对发送者，都需要一个方法来表达：多少数据要传输？
用窗口大小来描述：如TCP：流控也可用窗口通告机制来预留缓冲空间，来支持资源分配
用速率大小来描述：用速率控制发送者行为，如接收方可说它可处理1Mbps的视频，而发送方则坚持这一速率
2.4. 资源分配评价标准
怎样评价资源分配机制的好坏
- 有效性
- 公平性
2.4.1. 资源分配的有效性（提高网络效率）
2个主要测量指标：
- 网络吞吐量（实际传输bps）
- 延迟
如果有方法，增加吞吐量，提高链路利用率，但是增加了R内队列长度，包平均延迟也变长了，并不是个很好的方法。
2.4.1.1. 网络能力
用吞吐率和延迟之比来描述资源分配模式的有效性，该比称为网络能力
Power = 吞吐率/延迟
Power是加速度量纲 bit/s^2
2.4.2. 资源分配的公平性
网络资源分配还要考虑公平性
定义公平性时又陷入什么是公平的困难
基于预约的资源分配机制显然导致了可控制的不公平
该机制可能通过预约使接收视频流在1Mbps，而相同链路中的FTP却只有10Kbps
一般公平原则（若没有明确要求）
当某条链路中存在几个流时，对接收每个流都应该有相等的带宽（平均主义）
3. 排队规则与流量整形
- 排队规则
不管其它资源分配机制是多么简单或复杂每个路由器都必须实现某些排队或调度规则，以便管理等待发送包的缓冲区（分配缓冲区资源）
- 排队算法
是带宽（包得到发送）和缓冲区的分配方法（包被丢弃），它还直接影响包经历的延迟
- 3个排队算法：FIFO、公平排队、加权公平排队
3.1. FIFO
首先到达的包首先发送
当R的缓冲空间满时，尾部的包就丢弃（tail drop）,不考虑包是否重要
FIFO和tail drop是不同的概念，前者是发送调度策略，后者是丢弃策略，但二者常捆绑在一起叫做FIFO
3.1.1. 优先排队
给每个包打上可携带的优先权标记，如IP服务类型TOS（DiffServ）。 R先发送其优先权高的包
这一方式离Best-effort delivery并不远
3.1.2. TOS（DiffServ）
在IPv4报文头部有个TOS域（8bit），IPv6有个Class域（8bit）
RFC791，RFC1122，RFC1349都定义过每个bit的含义； RFC1349废除了之前两个RFC的定义
RFC 2474又重新定义了TOS的前6个bit，称为DiffServ Code Point(DSCP)后两个bit留给Explicit Congestion Notification (ECN)
3.2. 公平排队
3.2.1. FIFO主要问题
不能区别不同的流，即不能按报文所属的流来区分。问题：
- 对在源端实现的拥塞控制算法没有帮助
- 由于存在非TCP应用，FIFO可能把端-端拥塞机制旁路掉
例如IP电话，这类应用能把自己的包洪泛到网上路由器，引起丢弃其他应用的包
- 大多数基于UDP对多媒体应用也会产生同样问题
3.2.2. 公平排队算法FQ
FQ主要思想：
为每个正在被路由器处理的流分别维护一个队列，路由器以轮循方式服务每个队列。
当一个流发送包太快，则其队列填满；当一个队列到达一个特定的长度，属于该队列的后继包就被丢掉，这样，任何源就不可能多占用其他流的网络容
量
FQ并不告诉源端任何有关路由器的状态，或并不限制源端发送怎样快
3.3. 加权公平排队WFQ
加权公平队列（Weighted Fair Queueing）
- 给排队流加权，R服务每个队列时每次发送多少比特，它直接控制每个流将得到多少链路带宽
- 简单FQ给每个队列权重是1，即每轮每个队列逻辑上仅1比特被传输->1/n
- WFQ:可让3个队列分别权重2:1:3则导致带宽分别是2/6:1/6:3/6
- WFQ中的流在使用中可能是“流量类型”，由TOS或DiffServ.来定义
3.4. 流量整形（Traffic Shaping）
3.4.1. 基本思想
造成拥塞的主要原因是网络流量通常是突发性的
强迫包以一种可预测的速率发送；
在ATM网中广泛使用。
3.4.2. 网络流监管的三准则
平均速率:100bps比6000bps的源约束要严格多,希望限制某个流的长期平均速率
峰值速率:网络可允许平均速率6000bps,希望限制其峰值速率<15000bps
突发长度:希望限制极短时间间隔内所能发送到网络的最大包数
3.4.3. 漏桶算法（The Leaky Bucket Algorithm）
将用户发出的不平滑的数据包流转变成网络中平滑的数据包流；
可用于固定包长的协议，如ATM；也可用于可变包长的协议，如IP，使用字节计数；
无论负载突发性如何，漏桶算法强迫输出按平均速率进行，不灵活,溢出时要丢包。
3.4.4. 令牌桶算法（The Token Bucket Algorithm）
漏桶算法不够灵活，因此加入令牌机制；
基本思想：漏桶存放令牌，每T秒产生一个令牌，令牌累积到超过漏桶上界时就不再增加。包传输之前必须获得一个令牌，传输之后删除该令牌；
3.4.4.1. 漏桶算法与令牌桶算法的区别
流量整形策略不同：漏桶算法不允许空闲主机积累发送权，以便以后发送大的突发数据；令牌桶算法允许，最大为桶的大小。
漏桶中存放的是数据包，桶满了丢弃数据包；令牌桶中存放的是令牌，桶满了丢弃令牌，不丢弃数据包没有令牌才丢弃数据包。
