1流量控制的概念.docx
- 文档编号:27264719
- 上传时间:2023-06-28
- 格式:DOCX
- 页数:40
- 大小:119.24KB
1流量控制的概念.docx
《1流量控制的概念.docx》由会员分享,可在线阅读,更多相关《1流量控制的概念.docx(40页珍藏版)》请在冰豆网上搜索。
1流量控制的概念
1.流量控制的概念
分组交换和电路交换的一个重要不同之点在于,电路交换是立即损失制,即如果路由选择时没有空闲的中继电路可供选择,该呼叫建立就告失败。
因此,只要根据预测话务量配备足够多的中继电路,就能保证呼叫不阻塞。
其流量控制只是在交换机处理机过负荷时才起作用,控制功能也较简单,主要是限制用户的发话话务量。
分组交换则不同,它是时延损失制,只要传输链路不全部阻断,路由选择总能选到一条链路,由于用户终端发送数据的时间和数量具有随机性,网络中各节点交换机的存储容量和各条线路的传输容量(速率)总是有限的,如果链路上待传送的分组过多,就会造成传送时延的增加,引起网络性能的下降,严重时甚至会使网络崩溃。
这就需要采取流量控制来实现数据流量的平滑均匀,提高网络的吞吐能力和可靠性。
因此,流量控制是分组交换网的一项必不可少的重要功能,其控制机理也相当复杂。
具体说来,分组交换中的流量控制有以下3方面的作用:
(1)防止因过载导致网络吞吐量下降和传送时延的增加
(2)避免死锁
(3)公平分配网络资源
X.25协议的第三层着重于传输过程中的流量控制,流控通过滑动窗口算法来实现,对通过接口的每一个逻辑信道使用独立的“窗口”流量控制机构,X.25协议的第二层,也具有流量控制功能,也是通过滑动窗口来实现的,但它是对整个接口进行流量控制的。
2.OSI与TCPIP模型一
谈到网络不能不谈OSI参考模型,虽然OSI参考模型的实际应用意义不是很大,但其的确对于理解网络协议内部的运作很有帮助,也为我们学习网络协议提供了一个很好的参考。
在现实网络世界里,TCP/IP协议栈获得了更为广泛的应用。
1.1 OSI参考模型的分层结构
OSI参考模型(OSI/RM)的全称是开放系统互连参考模型(OpenSystemInterconnectionReferenceModel,OSI/RM),它是由国际标准化组织(InternationalStandardOrganization,ISO)提出的一个网络系统互连模型。
OSI参考模型采用分层结构,如图1-1所示。
图1-1 OSI参考模型
在这个OSI七层模型中,每一层都为其上一层提供服务、并为其上一层提供一个访问接口或界面。
不同主机之间的相同层次称为对等层。
如主机A中的表示层和主机B中的表示层互为对等层、主机A中的会话层和主机B中的会话层互为对等层等。
对等层之间互相通信需要遵守一定的规则,如通信的内容、通信的方式,我们将其称为协议(Protocol)。
我们将某个主机上运行的某种协议的集合称为协议栈。
主机正是利用这个协议栈来接收和发送数据的。
OSI参考模型通过将协议栈划分为不同的层次,可以简化问题的分析、处理过程以及网络系统设计的复杂性。
OSI参考模型的提出是为了解决不同厂商、不同结构的网络产品之间互连时遇到的不兼容性问题。
但是该模型的复杂性阻碍了其在计算机网络领域的实际应用。
与此对照,后面我们将要学习的TCP/IP参考模型,获得了非常广泛的应用。
实际上,也是目前因特网范围内运行的唯一一种协议。
1.2 OSI参考模型中各层的作用
在OSI参考模型中,从下至上,每一层完成不同的、目标明确的功能。
1、物理层(PhysicalLayer)
物理层规定了激活、维持、关闭通信端点之间的机械特性、电气特性、功能特性以及过程特性。
该层为上层协议提供了一个传输数据的物理媒体。
在这一层,数据的单位称为比特(bit)。
属于物理层定义的典型规范代表包括:
EIA/TIARS-232、EIA/TIARS-449、V.35、RJ-45等。
2、数据链路层(DataLinkLayer)
数据链路层在不可靠的物理介质上提供可靠的传输。
该层的作用包括:
物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。
在这一层,数据的单位称为帧(frame)。
数据链路层协议的代表包括:
SDLC、HDLC、PPP、STP、帧中继等。
3、网络层(NetworkLayer)
网络层负责对子网间的数据包进行路由选择。
此外,网络层还可以实现拥塞控制、网际互连等功能。
在这一层,数据的单位称为数据包(packet)。
网络层协议的代表包括:
IP、IPX、RIP、OSPF等。
4、传输层(TransportLayer)
传输层是第一个端到端,即主机到主机的层次。
传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。
此外,传输层还要处理端到端的差错控制和流量控制问题。
在这一层,数据的单位称为数据段(segment)。
传输层协议的代表包括:
TCP、UDP、SPX等。
5、会话层(SessionLayer)
会话层管理主机之间的会话进程,即负责建立、管理、终止进程之间的会话。
会话层还利用在数据中插入校验点来实现数据的同步。
会话层协议的代表包括:
NetBIOS、ZIP(AppleTalk区域信息协议)等。
6、表示层(PresentationLayer)
表示层对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机的应用程序理解。
表示层的数据转换包括数据的加密、压缩、格式转换等。
表示层协议的代表包括:
ASCII、ASN.1、JPEG、MPEG等。
7、应用层(ApplicationLayer)
应用层为操作系统或网络应用程序提供访问网络服务的接口。
应用层协议的代表包括:
Telnet、FTP、HTTP、SNMP等。
1.3 OSI参考模型中的数据封装过程
图1-2 OSI参考模型中的数据封装过程
如图1-2所示,在OSI参考模型中,当一台主机需要传送用户的数据(DATA)时,数据首先通过应用层的接口进入应用层。
在应用层,用户的数据被加上应用层的报头(ApplicationHeader,AH),形成应用层协议数据单元(ProtocolDataUnit,PDU),然后被递交到下一层-表示层。
表示层并不"关心"上层-应用层的数据格式而是把整个应用层递交的数据包看成是一个整体进行封装,即加上表示层的报头(PresentationHeader,PH)。
然后,递交到下层-会话层。
同样,会话层、传输层、网络层、数据链路层也都要分别给上层递交下来的数据加上自己的报头。
它们是:
会话层报头(SessionHeader,SH)、传输层报头(TransportHeader,TH)、网络层报头(NetworkHeader,NH)和数据链路层报头(DatalinkHeader,DH)。
其中,数据链路层还要给网络层递交的数据加上数据链路层报尾(DatalinkTermination,DT)形成最终的一帧数据。
当一帧数据通过物理层传送到目标主机的物理层时,该主机的物理层把它递交到上层-数据链路层。
数据链路层负责去掉数据帧的帧头部DH和尾部DT(同时还进行数据校验)。
如果数据没有出错,则递交到上层-网络层。
同样,网络层、传输层、会话层、表示层、应用层也要做类似的工作。
最终,原始数据被递交到目标主机的具体应用程序中。
2 TCP/IP参考模型
ISO制定的OSI参考模型的过于庞大、复杂招致了许多批评。
与此对照,由技术人员自己开发的TCP/IP协议栈获得了更为广泛的应用。
如图2-1所示,是TCP/IP参考模型和OSI参考模型的对比示意图。
图2-1 TCP/IP参考模型
2.1 TCP/IP参考模型的层次结构
TCP/IP协议栈是美国国防部高级研究计划局计算机网(AdvancedResearchProjectsAgencyNetwork,ARPANET)和其后继因特网使用的参考模型。
ARPANET是由美国国防部(U.S.DepartmentofDefense,DoD)赞助的研究网络。
最初,它只连接了美国境内的四所大学。
随后的几年中,它通过租用的电话线连接了数百所大学和政府部门。
最终ARPANET发展成为全球规模最大的互连网络-因特网。
最初的ARPANET于1990年永久性地关闭。
TCP/IP参考模型分为四个层次:
应用层、传输层、网络互连层和主机到网络层。
图2-2 TCP/IP参考模型的层次结构
在TCP/IP参考模型中,去掉了OSI参考模型中的会话层和表示层(这两层的功能被合并到应用层实现)。
同时将OSI参考模型中的数据链路层和物理层合并为主机到网络层。
下面,分别介绍各层的主要功能。
1、主机到网络层
实际上TCP/IP参考模型没有真正描述这一层的实现,只是要求能够提供给其上层-网络互连层一个访问接口,以便在其上传递IP分组。
由于这一层次未被定义,所以其具体的实现方法将随着网络类型的不同而不同。
2、网络互连层
网络互连层是整个TCP/IP协议栈的核心。
它的功能是把分组发往目标网络或主机。
同时,为了尽快地发送分组,可能需要沿不同的路径同时进行分组传递。
因此,分组到达的顺序和发送的顺序可能不同,这就需要上层必须对分组进行排序。
网络互连层定义了分组格式和协议,即IP协议(InternetProtocol)。
网络互连层除了需要完成路由的功能外,也可以完成将不同类型的网络(异构网)互连的任务。
除此之外,网络互连层还需要完成拥塞控制的功能。
3、传输层
在TCP/IP模型中,传输层的功能是使源端主机和目标端主机上的对等实体可以进行会话。
在传输层定义了两种服务质量不同的协议。
即:
传输控制协议TCP(transmissioncontrolprotocol)和用户数据报协议UDP(userdatagramprotocol)。
TCP协议是一个面向连接的、可靠的协议。
它将一台主机发出的字节流无差错地发往互联网上的其他主机。
在发送端,它负责把上层传送下来的字节流分成报文段并传递给下层。
在接收端,它负责把收到的报文进行重组后递交给上层。
TCP协议还要处理端到端的流量控制,以避免缓慢接收的接收方没有足够的缓冲区接收发送方发送的大量数据。
UDP协议是一个不可靠的、无连接协议,主要适用于不需要对报文进行排序和流量控制的场合。
4、应用层
TCP/IP模型将OSI参考模型中的会话层和表示层的功能合并到应用层实现。
应用层面向不同的网络应用引入了不同的应用层协议。
其中,有基于TCP协议的,如文件传输协议(FileTransferProtocol,FTP)、虚拟终端协议(TELNET)、超文本链接协议(HyperTextTransferProtocol,HTTP),也有基于UDP协议的
3.流量控制的理解
m0n0提供的流量管理软件为ipfw,我们并不需要了解该软件的机理,所以了解该软件并不妨碍我们对流量控制的理解。
通过对自动化生成的队列和管道,我们可以简单的发现一个共同点,就是“队列共用管道,且该管道队列权值和为100”。
通过实践总结和理论分析,我们对于“管道”和“队列”会有如下认识
“管道”就是一个网络带宽划分的模型,一个网络的带宽可以划分为任意个管道。
管道是逻辑的而不是物理,所以管道在数值上叠加没有实际意义。
管道具有独立性,一个管道在逻辑上是独立的,不会和任何其他的管道叠加。
"队列"就是“管道”内TCP/IP数据包转发机制的模型,一个管道内充满了队列永不停息。
队列在管道中的逻辑行为只有2种,就是upload和download,但是这两种行为只是逻辑上的相对意义,你定义了两种行为的其中之一,另一个行为才会存在。
比如定义了“上”的方向,自然就有了“下”的方向,反过来亦然。
对于队列组建方式m0n0提供的非常灵活,有三个影响队列的参数是权重,延时,slot长度。
首先讲队列的slot概念。
slots是单个队列的长度,这个可以任意设定,主要取决于你的CPU和网卡的处理能力,当然还有你的内存。
原则上理解,单个队列越长,处理起来效率就会越低,CPU占用越高,内存使用越大,但是网速肯定会提高,因为潜在的缩短了TCP/IP包流通的时间。
单位长度TCP/IP流通时间=(单队列组建+单队列转发+单队列处理+延时)*队列总数
其中括号中的时间数值受到单个队列长度影响较小,所以,队列总数成为影响时间的关键。
由于数据流永远存在的,所以,slots值一旦确定,m0n0就会自动填充当前队列到达slot值,然后再建立下一个队列,长度依然是slots值。
对于单个队列的每个数据槽按何种次序填充则依据权重进行分配,例如:
某个管道内队列定义了5个A权重50,B权重20,C权重15,D权重10,E权重5。
队列slots=100,那么权重50的A数据包会自动填充100单位的前50个单位,从51位开始填充权重为20的B数据包,从71位开始填充权重为15的C数据包,到达队列的86位开始填充权重为10的D数据包,最后填充E数据包直到长度实现100。
然后依次建立下一个队列。
简单的排列顺序:
100=50+20+15+10+5。
也就是说,管道内的数据包依据流量规则被打上标签以后,根据权重自动组成队列。
这样,权重高的数据被优先传输,并且占用更大的管道带宽,权重最低的数据被最后处理,并占用最低的管道带宽。
延时就不用说了,上面的公式可以看得出延时的作用,这个主要用于网络非常拥堵的状况,人为的架设信号灯提供CPU更长的分时处理机会。
到这里,我们虽然理解了管道,队列,但是队列和管道究竟如何设计?
这是一个难点,这是因为,队列规则的最终生成其实是整个流量管理模型设计最后的产物,也就是说,你必须在写出流量规则以前要明白你要建立什么规则,需要几个管道,管道如何使用这3个问题。
这是至顶向下的设计,然而WebGUI却要先写队列再写规则,造成了理解的困难。
了解这些后我们基本上会把注意力集中在管道,队列,规则的设计上。
以下是就是三种流量控制的管理思路:
1.针对上网行为的流量控制设计
2.针对特定应用的流量控制设计
3.针对网络协议的流量控制设计
流控精灵就是采用1方式,分别建立上传和下载两种行为的管道,然后细分上传和下载的具体行为,以此来达到控制流量的目的。
优点是,思路清晰,结构明朗,配置简单。
缺点是,胡子头发一把抓,对于未知因素的控制缺乏应变。
往往需要了解更多的网络行为才能满足需要,工作量巨大。
针对网络特定应用的流量控制设计,这是比较灵活的也是有效的设计思路,针对需要控制的网络应用进行流量控制。
优点是,配置简单,效果明显,特别是针对服务器访问的控制非常有意义,缺点是,必须了解具体应用的网络特征,比如端口号或者ip地址等等,对于可变端口的p2p软件无能为力。
针对网络协议的流量控制,对于单个协议建立管道队列,例如TCP协议管道,UDP协议管道等等。
优点是,思路简洁,配置简单,效果明显,对于复杂网络环境非常有效。
缺点是,网络速度过于均衡,对于单个应用的优先需要手动添加规则,例如UDPQQ上传。
否则,会影响用户的网络感受。
技巧和提示:
1。
TCP的上传和下载的权值比例可以为1:
4~1:
2,影响用户感受的是下载速度,例如网页下载速度,游戏对象的更新速度。
2。
上传的权值如果太低会导致游戏服务器与用户通讯频繁短线,例如UDP上传权值为5的时候浩方会经常短线,改为15就正常了。
3。
UDP带宽尽量给的够小,通常与TCP的带宽比例为TCP:
UDP=3:
1这样可以有效的控制p2p软件的泛滥。
4。
LAN的流量规则也很有用,但是会增加LAN网卡的负荷,可酌情使用。
5。
从防火墙角度来看进/出观点如下:
PC->LAN->WAN-> LAN口:
进,WAN口:
出
PC<-LAN<-WAN<- LAN口:
出,WAN口:
进
4.TCP/IP互联网上的拥塞控制
拥塞控制在复杂的网络中公认的问题。
我们发现,国防部的网间网协议(IP),
一种纯数据报协议,和传输控制协议(TCP),一种传输层协议,当把它们一起使
用时容易遭受不寻常的拥塞问题,这是由在传输层和数据报层之间的相互作用而
引起的。
特别的,IP网关对于被我们称为“拥塞崩溃”的现象而言是脆弱的,
特别是当这种网关连到大范围的不同带宽的网络上的时候。
我们研究了防止拥塞
崩溃的方案。
由于这些协议在基于ARPANETIMP技术的网络上使用频繁,这些问题没有得
到普遍的认识。
基于ARPANETIMP的网络通常有一致的带宽和完全相同的交换节
点,并且容量很大。
对大多数TCP/IP主机和网络而言,盈余的容量以及IMP系
统控制主机传输量的能力已足以处理拥塞。
然而,随着最近ARPANET分成两个互
连的网络以及连到ARPANET上的具有不同特性的其他网络的增长,IMP系统良性
特性中的可靠性已不足以允许主机迅速而可靠的通信。
为了使网络成功的运转,
必须改善拥塞控制。
福特航空航天及通信股份有限公司,和它的总公司,福特汽车公司,经营着如
今实际存在的唯一一家私有的TCP/IP长距离网络。
这个网络与四个网点相连(一
个在Michigan,两个在Galifornia,另一个在England),它们中的一些还有大规
模的本地网。
这个网络交叉连接在ARPANET上但却使用它自己的长距离线路。
福
特公司各网点之间通过私人租赁线路进行传输,包括一条专用的横渡大西洋的卫
星通讯线路。
所有的交换节点都是没有点到点流量控制的纯IP报交换,并且所
有主机运行的软件都是由福特公司或它的子公司编写或者经他们大量修改的软
件。
这个网络上的链接带宽变化很大,从1200到10,000,000bps。
通常,我
们已经没有能力购买昂贵的ARPANET那样的额外的长距离带宽,而且我们的长距
离链接在高峰时期是超负荷的。
几秒的传输时间在我们的网络里是如此的平常。
由于我们的纯数据报定向,负荷过重和带宽的大范围变化,我们不得不去解决
ARPANET/MILNET组织才刚开始认识到的问题。
我们的网络对主机的TCP实现的
次最优性能很敏感,包括与我们的网络连接或断开。
我们力图检查在不同条件下
的TCP性能,并且已经解决了一些TCP普遍存在的问题。
在这里我们提出了两个
问题及其解决办法。
许多TCP实现有这些问题;如果对于某个给定的TCP实现,
经过ARPANET/MILNET网关的吞吐量比经过一个单一的网络糟,那么很可能这个
TCP实现存在这些问题中的一个或两个。
拥塞崩溃
在我们开始讨论这两个具体问题及其解决办法之前,描述一下当这些问题没
有解决时会发生什么是妥当的。
在负载较重的带有端到端重发机制的纯数据报网
络中,当交换节点拥塞时,网络上的往返时间增加,在网络上传输的数据报的数
量也增加了。
这在轻负载下是正常的.只要在传输中仅有每个数据报的一个拷贝,
拥塞就在控制之中。
一旦还没递送成功的数据报开始重传,潜在的严重问题就可
能会出现。
主机TCP的实现预期在增加的时间间隔内多次重传数据报,直到重传间隔
的某个时间上限已到。
通常,这个机制足以防止严重的拥塞问题。
虽然有更好的
自适应主机重传算法,但是网络上的意外负载能使往返时间的增长速度比发送方
估计的往返时间的更新更快。
当一个新的大量数据传输时,这样的负载就产生了,
这样的文件传输开始填充一个大的窗口。
如果这个往返时间超过了所有主机的最
大重传间隔,那么主机将开始向网络产生越来越多的同一数据报的副本。
这时,
这个网络有了严重问题。
最终在交换节点中所有可获得的缓冲将饱和,于是必须
丢失数据报。
这时,被传送的这个数据报的往返时间到达它的最大值。
主机多次
发送每个报文,最终每个报文的某个拷贝到达它的目的地。
这就是拥塞崩溃。
这个状态是稳定的。
一旦到达饱和点,如果选择包丢弃算法良好,网络将继
续运行在性能降低了的状态下。
在这种状态下,每个包被传输几次,吞吐量将降
低到正常情况的几分之一。
我们实验性地迫使我们的网络处于这样的状态并且观
察它的稳定性。
往返时间可能变得很大以致于由于主机超时造成连接中断。
拥塞崩溃和不正常的拥塞通常不出现在ARPANET/MILNET系统中,因为这
些网络有足够大的超额容量。
只要连接不经过IP网关,增强的主机流量控制机
制通常能防止拥塞崩溃,特别是自从针对和纯ARPANET网情况相关的时间常量
很好地调整了TCP实现以来。
然而,当TCP运行在ARPANET/MILNET上数据
报在网关被丢弃时,除了ICMP的源抑制报文外,没有什么基本的机制来防止拥
塞崩溃。
一些运行不好的主机通过它们自身使网关拥塞并阻止其他主机通过是没
价值的。
我们已经在ARPANET上的某些主机上(我们已私下与这些主机的管理
员交流过)重复观察到这个问题。
给网关添加额外的内存不能解决这个问题。
添加的内存越多,在数据报被丢
弃之前往返时间变得越长。
这样,拥塞崩溃的发生将被延迟,但当崩溃发生时,
网络中的更大的数据报分片将被复制,吞吐量将变得更糟。
两个问题
和TCP实现的技术有关的两个关键问题已经被观察到;我们称它们为短数
据报问题和源抑制问题。
第二个问题正由几个实现方案着手解决,第一个问题通
常被(不正确地)认为已经被解决了。
我们发现,一旦短数据报问题解决,源抑
制问题就变得更加容易处理。
因此,我们首先提出短数据报问题及其解决方案。
短数据报问题
这里有一个与短数据报相关的具体问题。
当TCP用来传输来自键盘的单字
符信息时,典型的结果是为了传输一个字节的有用数据传输了41个字节的数据
报(1个字节的数据,40个字节的头文件)。
这4000%的开销是令人讨厌的,但
在轻负载的网络里是可以容忍的。
然而,在负荷过重的网络中,由这个开销引起
的拥塞能导致数据报的丢失和重传,以及在交换节点和网关中由于拥塞而造成传
输时间过大。
事实上,吞吐量可能降低以致于TCP连接被异常中断。
这个典型的问题在20世纪60年代下半期在Tymnet网络中第一次被提出并
被广泛认识。
那里所采用的解决办法是强行对每单位时间里所产生的数据报的数
量给定一个限制。
这个限制是通过对短数据报延迟一个短的时间(200-500ms)
后再传输来实施的,以期可以在定时器到时之前另一个或两个字符到来并附加在
同一个数据报中。
为了增加用户的可接受性,一个附加的特性是当一个控制字符
(比如回车字符)到来时,禁止时间延迟。
这个技术已经在NCPTelnet,X.25PADs和TCPTelnet中使用。
它的优点是
易于理解和不难实现。
它的缺点是很难给出一个使每个人满意的时限。
一个在
10Mbps以太网上提供高速应答服务的时限太短以致于不能防止在有5秒往返时
间的高负荷的网络上的拥塞崩溃;相反,处理高负荷的网络的时限太长又会给以
太网的用户造成挫折感。
短数据报的解决方案
显然,一个自适应的方法是不难想到的。
我们期望为自适应交互包的时限提
出一个建议方案,这个时限是在TCP所观察到的往返时间延迟的基础上的。
然而
虽然这样一个机制确实能被实现,但它是不必要的。
我们发现了一个简单且优化
的解决方案。
这个解决方案是,如果任何先前在连接上传输的数据仍没有被确认,那么来
自用户的输出数据到来时,禁止传输TCP数据段。
这个限制是无条件的,没有定
时器,不需要测试收到的数据的大小,不需要其他条件。
典型的实现只需要TCP
程序中的一两行程序。
乍看,这个解决方案好象意味着TCP行为的剧烈改变。
但并非如此。
最终它
很好地工作。
让我们看看为什么是这样。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 流量 控制 概念