traffic_shaping_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
traffic_shaping
上传于||文档简介
&&常​用​的​几​种​流​量​整​形​算​法
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩5页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢4061人阅读
Web/Net（26）
文章来源：
UDP主要丢包原因及具体问题分析
一、主要丢包原因
1、接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。
2、发送的包巨大丢包：虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。
3、发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4、发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。
5、局域网内不丢包，公网上丢包。这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法： 要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。
二、具体问题分析
1.发送频率过高导致丢包
很多人会不理解发送速度过快为什么会产生丢包，原因就是UDP的SendTo不会造成线程阻塞，也就是说，UDP的SentTo不会像TCP中的SendTo那样，直到数据完全发送才会return回调用函数，它不保证当执行下一条语句时数据是否被发送。（SendTo方法是异步的）这样，如果要发送的数据过多或者过大，那么在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对“过快”的解释，作者这样说：“A few packets a sec hundreds or thousands
may be an issue.”（一秒钟几个数据包不算什么，但是一秒钟成百上千的数据包就不好办了）。 要解决接收方丢包的问题很简单，首先要保证程序执行后马上开始监听（如果数据包不确定什么时候发过来的话），其次，要在收到一个数据包后最短的时间内重新回到监听状态，其间要尽量避免复杂的操作（比较好的解决办法是使用多线程回调机制）。
2.报文过大丢包
至于报文过大的问题，可以通过控制报文大小来解决，使得每个报文的长度小于MTU。以太网的MTU通常是1500 bytes，其他一些诸如拨号连接的网络MTU值为1280 bytes，如果使用speaking这样很难得到MTU的网络，那么最好将报文长度控制在1280 bytes以下。
3.发送方丢包
发送方丢包：内部缓冲区（internal buffers）已满，并且发送速度过快（即发送两个报文之间的间隔过短）； &接收方丢包：Socket未开始监听； &虽然UDP的报文长度最大可以达到64 kb，但是当报文过大时，稳定性会大大减弱。这是因为当报文过大时会被分割，使得每个分割块（翻译可能有误差，原文是fragmentation）的长度小于MTU，然后分别发送，并在接收方重新组合（reassemble），但是如果其中一个报文丢失，那么其他已收到的报文都无法返回给程序，也就无法得到完整的数据了。
-------------------------
我们是后一个包丢掉了
最近在做一个项目,在这之前,做了个验证程序.
发现客户端连续发来字节的包,服务器端出现了丢包现象.
纠其原因,是服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了.
有没有成熟的解决方案来解决这个问题.
我用过sleep(1),暂时解决这个问题,但是这不是根本解决办法,如果数据量大而多,网络情况不太好的话,还是有可能丢失.
你试着用阻塞模式吧...
select...我开始的时候好像也遇到过..不过改为阻塞模式后就没这个问题了...
采用回包机制,每个发包必须收到回包后再发下一个
UDP丢包是正常现象，因为它是不安全的。
丢包的原因我想并不是“服务端在还未完全处理掉数据,客户端已经数据发送完毕且关闭了”，而是服务器端的socket接收缓存满了(udp没有流量控制，因此发送速度比接收速度快，很容易出现这种情况)，然后系统就会将后来收到的包丢弃。你可以尝试用setsockopt()将接收缓存(SO_RCVBUF)加大看看能不能解决问题。
服务端采用多线程pthread接包处理
UDP是无连接的，面向消息的数据传输协议，与TCP相比，有两个致命的缺点，一是数据包容易丢失，二是数据包无序。
要实现文件的可靠传输，就必须在上层对数据丢包和乱序作特殊处理，必须要有要有丢包重发机制和超时机制。
常见的可靠传输算法有模拟TCP协议，重发请求（ARQ）协议，它又可分为连续ARQ协议、选择重发ARQ协议、滑动窗口协议等等。
如果只是小规模程序，也可以自己实现丢包处理，原理基本上就是给文件分块，每个数据包的头部添加一个唯一标识序号的ID值，当接收的包头部ID不是期望中的ID号，则判定丢包，将丢包ID发回服务端，服务器端接到丢包响应则重发丢失的数据包。
模拟TCP协议也相对简单，3次握手的思想对丢包处理很有帮助。
udp是不安全的，如果不加任何控制，不仅会丢失包，还可能收到包的顺序和发送包的顺序不一样。这个必须在自己程序中加以控制才行。
收到包后，要返回一个应答，如果发送端在一定时间内没有收到应答，则要重发。
UDP本来存在丢包现象,现在的解决方案暂时考虑双方增加握手.
这样做起来,就是UDP协议里面加上了TCP的实现方法.
程序中采用的是pthread处理,丢包率时大时小,不稳定可靠
我感觉原因可能有两个，一个是客户端发送过快，网络状况不好或者超过服务器接收速度，就会丢包。
第二个原因是服务器收到包后，还要进行一些处理，而这段时间客户端发送的包没有去收，造成丢包。
解决方法，一个是客户端降低发送速度，可以等待回包，或者加一些延迟。
二是，服务器部分单独开一个线程，去接收UDP数据，存放在一个缓冲区中，又另外的线程去处理收到的数据，尽量减少因为处理数据延时造成的丢包。
有两种方法解决楼主的问题：
方法一：重新设计一下协议，增加接收确认超时重发。（推荐）
方法二：在接收方，将通信和处理分开，增加个应用缓冲区；如果有需要增加接收socket的系统缓冲区。（本方法不能从根本解决问题，只能改善）
网络丢包，是再正常不过的了。
既然用UDP，就要接受丢包的现实，否则请用TCP。
如果必须使用UDP，而且丢包又是不能接受的，只好自己实现确认和重传，说白了，就是自己实现TCP（当然是部分和有限的简单实现）。
UDP是而向无连接的，用户在实施UDP编程时，必须制定上层的协议，包括流控制，简单的超时和重传机制，如果不要求是实时数据，我想TCP可能会更适合你！
-------------------------
1：什么是丢包率？&
你的电脑向目标发送一个数据包，如果对方没有收到.就叫丢包.&
比如你发10个，它只收到9个. 那么丢包率就是 10%&
数据在网络中是被分成一各个个数据报传输的,每个数据报中有表示数据信息和提供数据路由的桢.而数据报在一般介质中传播是总有一小部分由于两个终端的距离过大会丢失,而大部分数据包会到达目的终端.所谓网络丢包率是数据包丢失部分与所传数据包总数的比值.正常传输时网络丢包率应该控制在一定范围内.
2：什么是吞吐量？
网络中的数据是由一个个数据包组成，防火墙对每个数据包的处理要耗费资源。吞吐量是指在没有帧丢失的情况下，设备能够接受的最大速率。其测试方法是：在测试中以一定速率发送一定数量的帧，并计算待测设备传输的帧，如果发送的帧与接收的帧数量相等，那么就将发送速率提高并重新测试；如果接收帧少于发送帧则降低发送速率重新测试，直至得出最终结果。吞吐量测试结果以比特/秒或字节/秒表示。
吞吐量和报文转发率是关系防火墙应用的主要指标，一般采用FDT(Full Duplex Throughput)来衡量，指64字节数据包的全双工吞吐量，该指标既包括吞吐量指标也涵盖了报文转发率指标。&
随着Internet的日益普及，内部网用户访问Internet的需求在不断增加，一些企业也需要对外提供诸如WWW页面浏览、FTP文件传输、DNS域名解析等服务，这些因素会导致网络流量的急剧增加，而防火墙作为内外网之间的唯一数据通道，如果吞吐量太小，就会成为网络瓶颈，给整个网络的传输效率带来负面影响。因此，考察防火墙的吞吐能力有助于我们更好的评价其性能表现。这也是测量防火墙性能的重要指标。
吞吐量的大小主要由防火墙内网卡，及程序算法的效率决定，尤其是程序算法，会使防火墙系统进行大量运算，通信量大打折扣。因此，大多数防火墙虽号称100M防火墙，由于其算法依靠软件实现，通信量远远没有达到100M,实际只有10M-20M。纯硬件防火墙，由于采用硬件进行运算，因此吞吐量可以达到线性90-95M,是真正的100M防火墙。
对于中小型企业来讲，选择吞吐量为百兆级的防火墙即可满足需要，而对于电信、金融、保险等大公司大企业部门就需要采用吞吐量千兆级的防火墙产品。
3：检测丢包率
下载一个世纪前线，在百度可以找到，很小的程序。
NetIQ Chariot &一款网络应用软件性能测试工具
网络吞吐量测试,
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：954391次
积分：8317
积分：8317
排名：第1826名
原创：137篇
转载：240篇
评论：103条
(1)(2)(4)(1)(2)(5)(5)(31)(22)(21)(8)(20)(24)(31)(22)(19)(1)(10)(13)(34)(7)(8)(6)(8)(15)(22)(9)(23)(2) 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
以太网专线业务参数说明
下载积分：1000
内容提示：以太网专线业务参数说明
文档格式：DOCX|
浏览次数：7|
上传日期： 15:58:43|
文档星级：
该用户还上传了这些文档
以太网专线业务参数说明
官方公共微信TCP/UDP丢包（转）
这个丢包不是网卡级别的丢包，在每个网卡中也会显示丢失的包的数据。这个一般是由于网卡在中断处理中需要通过skbuff来存储新来的包。此时是直接通过内存管理接口申请结构，此时这个地方并没有办法做限制，因为此时的中断处理程序并不理解上层的协议，更不用说进程或者是socket这些逻辑概念。所以当网卡收到数据之后就分配一个包结构，此时分配失败就认为是丢掉一个包，计入网卡的报文统计中。
TCP和UDP是传输层协议，所以它们的丢包一般是主动丢弃，并且它参考了更加详细的控制信息。这里我们最为关注的有两个，对于udp来说，一般是由于一个UDP能够占有的系统资源达到限量；不能让一个服务耗光系统中所有的资源；对于TCP来说，它除了有socket限制之外，对于侦听的套接口，它同样还需要有一个运行多少个连接存在的问题，不可能让一个套接口三次握手过多的连接而用户态不执行accept。
二、UDP丢包
UDP丢包主要存在于接收端无法及时处理对方发送的数据，这些数据以报文的形式在系统中暂时存储，但是如果这些未接受的报文太多，操作系统就会将新到来的报文丢掉，从而避免一个套接口对整个系统资源耗光。
这个逻辑和思路都比较简单，也是因为UDP本身是一个相对比较简单的传输控制协议。这里大致看一下相关代码
__udp4_lib_rcv---&&&udp_queue_rcv_skb
&&& if ((rc =
sock_queue_rcv_skb(sk,skb)) & 0) {
&&& if (rc ==
UDP_INC_STATS_BH(UDP_MIB_RCVBUFERRORS,
up-&pcflag);
而接收函数中处理为
int sock_queue_rcv_skb(struct sock *sk, struct sk_buff
&&& int err =
(atomic_read(&sk-&sk_rmem_alloc) +
skb-&truesize &=
&&&&(unsigned)sk-&sk_rcvbuf)&{
这里如果达到一个套接口的限量，则返回错误，上层记录到UDP丢包状态中，这个状态可以通过/proc/net/snmp文件查看，例如我的系统
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors
SndbufErrors
Udp: 672 0 0 670 0 0
这个功能在2.6.17--2.6.21之间的一个版本添加，小于2.6.17的版本一定没有。
三、TCP丢包
1、三次握手时丢包
这个主要是由用户的listen的backlog参数决定的一个信息。其中的backlog表示可以有多少个连接完成三次握手而不执行accept，如果大于该值，则三次握手不能完成，这是一个准确值。相对来说还有个大概值，这个值也是根据backlog参数计算得到，只是按照2的幂数取整了，例如backlog为5，该值可能为8.它用来控制一个套接口可以同时最多接收多少个连接请求，这个请求准确的说是第一次握手，这个数值其实是和accept的限量是独立的。极端情况下，以listen参数为5说明，第一次握手可以有8个完成，而三次握手可以有5个。
①、listen之backlog参数处理
inet_listen --&&&sk-&sk_max_ack_backlog&=
这里的数值是对于完成三次握手而没有被accept的连接的限制。
inet_csk_listen_start---&&reqsk_queue_alloc
(lopt-&max_qlen_log = 3;
(1 && lopt-&max_qlen_log) & nr_table_
lopt-&max_qlen_log++);
该数值限制的是第一次握手的回应数量。
②、第一次握手处理
int tcp_v4_conn_request(struct sock *sk, struct sk_buff
(inet_csk_reqsk_queue_is_full(sk) && !isn) {这里判断listen中可以完成第一次握手的数量，如果大于限量，丢掉报文。
#ifdef CONFIG_SYN_COOKIES
(sysctl_tcp_syncookies) {
&&& want_cookie
(sk_acceptq_is_full(sk) &&&inet_csk_reqsk_queue_young(sk)&&
1)这里的young表示系统中还没有被重传的sync回应套接口。
&&& return
这里的连接丢掉并没有记录任何信息，所以我们并不知道系统拒绝了多少三次握手的第一次请求。
③、第三次握手回应时丢包
struct sock *tcp_v4_syn_recv_sock(struct sock *sk, struct sk_buff
& struct request_sock *req,
& struct dst_entry *dst)
&&& struct
inet_request_sock *
&&& struct
inet_sock *
&&& struct
tcp_sock *
&&& struct sock
#ifdef CONFIG_TCP_MD5SIG
&&& struct
tcp_md5sig_key *
(sk_acceptq_is_full(sk))
exit_overflow:
NET_INC_STATS_BH(LINUX_MIB_LISTENOVERFLOWS);
NET_INC_STATS_BH(LINUX_MIB_LISTENDROPS);
此时该信息有记录，可以通过/proc/net/snmp查看该信息。
2、缓冲区满时丢包
tcp_data_queue
&&& if (eaten
queue_and_out:
&&& if (eaten
(atomic_read(&sk-&sk_rmem_alloc) &
sk-&sk_rcvbuf&||&&同样是检测了一个套接口的接收缓存数量，超过限量尝试整理出存储空间，如果失败丢弃报文。
!sk_stream_rmem_schedule(sk, skb))) {
(tcp_prune_queue(sk) & 0 ||
!sk_stream_rmem_schedule(sk, skb))
sk_stream_set_owner_r(skb, sk);
__skb_queue_tail(&sk-&sk_receive_queue, skb);
__kfree_skb(skb);
这里并没有记录，所以超过缓冲区的丢包不会记录。但是TCP有自己的流量控制和重传机制，所以丢包并不是问题。
3、限量的设置
这些限制可以通过set_sockopt接口来修改。
.ctl_name&&& =
NET_CORE_WMEM_DEFAULT,
.procname&&& =
"wmem_default",
&sysctl_wmem_default,
.maxlen&&&
sizeof(int),
.proc_handler&&&
= &proc_dointvec
.ctl_name&&& =
NET_CORE_RMEM_DEFAULT,
.procname&&& =
"rmem_default",
&sysctl_rmem_default,
.maxlen&&&
sizeof(int),
.proc_handler&&&
= &proc_dointvec
proc文件系统中也可以修改这些接口
[tsecer@Harry template]$ cat
/proc/sys/net/core/rmem_default&
[tsecer@Harry template]$ cat
/proc/sys/net/core/wmem_default&
[tsecer@Harry template]$
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。导读：GTS与CAR是在IP层实现的，3令牌桶实现，上面介绍了RFC中定义的令牌桶技术原理以及其在IPQoS中的应用，令牌桶究竟是怎么实现的？令牌桶中的令牌是怎么添加的？报文的处理流程又是什么样的？，3.1单速率三色标记算法的实现，目前业界有两种方式，可以由一个桶实现，这种实现方式完全按照令牌桶的定义来实现，所以放入一个相同的桶实现，也可以由两个桶实现(图4下)，即C桶和E桶分开实现，令牌桶的添加完
2.3 在端口限速中的应用
端口限速(LR)[4](如图3所示)也用于出方向，但不同于GTS的是：第一，GTS与CAR是在IP层实现的，所以对于不经过IP层处理的报文不起作用，而LR则能够限制在物理接口上通过的所有报文；第二，LR不但能够对超过流量限制的报文进行缓存，并且可以利用QoS丰富的队列如优先级队列(PQ)、自定义队列(CQ)、加权公平对列(WFQ)等来缓存报文。
3 令牌桶实现
上面介绍了RFC中定义的令牌桶技术原理以及其在IP QoS中的应用，但是在实际应用中，令牌桶究竟是怎么实现的？令牌桶中的令牌是怎么添加的？报文的处理流程又是什么样的？下面就简单谈一谈令牌桶在业界的实现方式[5]。
3.1 单速率三色标记算法的实现
3.1.1 桶的构成
在令牌桶的构成上，目前业界有两种方式，如图4所示。
可以由一个桶实现，即C桶是E桶中的一部分(图4上)，最终桶的容量是由EBS决定的。不管有没有突发流量，EBS不能为0，必须大于或等于CBS。这种实现方式完全按照令牌桶的定义来实现，因为CBS和EBS都是令牌桶的参数，所以放入一个相同的桶实现，通过突发计数器来进行区分。也可以由两个桶实现(图4下)，即C桶和E桶分开实现。如果不允许有突发流量，EBS则设置成0。
3.1.2 令牌添加
令牌桶的添加完全依照RFC规定实现，按照恒定的速率CIR添加。即每隔1/CIR时间添加一个令牌，添加顺序为先添加C桶再添加E桶，当令牌桶添加满的时候，再产生的令牌就会被丢弃。
实际中比较常见的有两种实现方式：(1)周期性的添加，如图5所示，添加的时间间隔就是令牌桶的容量与添加速率的比值：T c=CBS/CIR，每次添加的令牌数为CBS 个；(2)一次性添加，只有当令牌桶中没有令牌时才添加令牌，如图6所示，添加令牌的数量是△t×CIR(△t是当前时间与上次添加令牌的时间之差)，且是一次添加完毕，并不是按照一定速率添加。
3.1.3 报文处理流程
一般的报文处理方法如图7所示：当报文到来后，直接与桶中的令牌数相比较，如果有足够的令牌就转发，如果没有足够的令牌则丢弃或缓存。这种令牌桶处理方式在突发流量的处理上没有优势，也就是说当存在较大的突发流量时，令牌桶可能会由于没有足够令牌无法处理报文，而且在没有突发流量且报文到达速率较大时，报文处理流程也不连续，有时会因为令牌数量不足而造成丢包。
为解决这种无谓的丢包问题，目前业界采用了一种借贷机制的报文处理方法，如图8所示。当报文到来后，只要令牌桶中有令牌，无论数量是否足够，都可以转发报文。当令牌数量小于报文长度时，就可以欠债转发，即转发后令牌桶中令牌数目为负；当下次添加令牌的时候，先还清所欠债务，再继续转发报文。这种处理方法较前者在处理突发报文时有优势，能够保证报文发送的连续性。
3.1.4 实现方式比较
假设令牌桶的总容量为1 000 kb，CIR为125 kb/s，报文到达的速率为200 kb/s，报文长度为125 kB (1 000 kb)。
方式一：周期性添加令牌，只有当令牌数足够时才转发报文。添加令牌的周期为8 s，而转发一条报文的时间为5 s。
方式二：一次性添加令牌，当令牌数不足时采用借债机制。转发一条报文的时间是5 s，但是添加令牌的时间是不一定的，每次添加令牌的数目为CIR×△t。
图9至图11是对这两种方式的令牌桶中令牌数、报文转发速率和令牌添加过程的比较。
分析数据的处理流程得出以下结论：
(1) 数据包丢弃率：方式二的丢包率远小于方式一。
方式一中，由于令牌添加周期与报文发送周期的不一致，导致第6 s到第8 s由于没有令牌不能转发报文。而第8 s到第16 s虽然在不断添加令牌，但令牌数不足以转发一个报文，所以仍旧无法转发报文，那在这一段时间内到达的报文将被丢弃掉。在前16s的时间内丢包率达到了10/16≈62.5%，由于添加令牌和发送报文的时间都是固定的，所以整个发送过程中的丢包率也为62.5%。
方式二中，第5 s第一条报文发送结束令牌被消耗光，但第6 s又立即加入了550 kb令牌，虽不够转发一条报文，但可以采用借债机制，直到第10 s第二条报文发送结束，累计欠债250 kb。这时若有报文到达，就不能继续欠债，而要注入新的令牌才能继续转发。直到第15 s第三条报文发送完毕由于一次添加令牌不够还清所欠令牌，所以造成了短暂的丢包现象，而在前17s内丢包率仅为1/17≈5.9%。
(2) 突发流量处理：方式二在突发流量处理方面优于方式一。
由图10可知，对方式一来说，由于令牌桶总的容量只有1 000 kb，发送完每条报文后桶中剩余令牌数都为0。此时若有突发流量，则报文必然被丢弃。而方式二令牌数可为负，当突发报文到达时即使令牌数不足仍可通过欠债方式现将报文转发出去，后续再偿还债务。
(3) 大小包混合时：方式一可能会造成大包始终得不到转发，而方式二则不会。
如果发送一长度大于1 000 kb的报文，方式一中则始终会由于令牌不足而丢弃报文，方式二则可以通过借债方式现转发报文后偿还债务。
(4) 数据流发送过程平缓程度：方式二数据处理的时间较长，所以趋势明显比方式一平缓。
3.2 双速率三色算法的实现
3.2.1 桶的构成
双速率三色算法的实现，目前业界的实现基本上完全依照RFC的规定，用两个令牌桶来实现，两个令牌桶的容量不同，第一个是CBS，第二个是PBS。
3.2.2 令牌添加
双速率三色标记算法中两桶添加令牌的速率不同，CBS桶添加令牌的速率是CIR，PBS桶添加令牌的速率则是PIR。添加令牌时先添加CBS桶，CBS桶填满后再添加PBS桶。
3.2.3 报文处理流程
当发送连续流量时，先看报文速率是否超过PIR：当报文速率大于PIR时，超过PBS部分流量无法得到令牌，被标记为红色报文；未超过PBS而从PBS桶中获取令牌的报文标记为黄色报文；从CBS桶中获取令牌的报文被标记为绿色报文。当报文速率小于PIR，大于CIR时，报文不会得不到令牌，但会超过CBS部分报文将从PBS桶中获取令牌，被标记为黄色报文；其他报文将从CBS桶中取令牌，被标记为绿色报文；当报文速率小于CIR时，报文所需令牌数不会超过CBS，所以只会被标记为绿色报文。
当发送突发报文时，若突发流量大于PBS，则超出部分统计为红色报文；当突发流量大于CBS，但小于PBS时，则超过CBS部分标记为黄色报文；当突发流量小于CBS时，全部标记为绿色报文。
在流量控制中，用户可针对不同颜色的报文设定不同行为，如；允许通过、丢弃、或重新标记优先级等。
3.3 单速率三色算法与双速率三色算法的比较
单、双速率三色标记算法的比较如表1所示。
单速率三色标记算法采用单桶或双桶结构，令牌添加方式和报文处理流程比较简单；双速率三色记算法采用双桶结构，令牌添加方式和报文处理流程相对复杂。前者关注报文尺上的突发，后者关注速率上的突发，两者各有优点。
包含总结汇报、旅游景点、文档下载、党团工作、资格考试、教学研究、办公文档、IT计算机、出国留学以及QoS技术中令牌桶算法实现方式比较等内容。本文共3页
相关内容搜索