tc令牌桶限速心得

一、实验拓扑与实验现象

实验拓扑如图所示,在①号机上发送数据,③号机上接受数据,同时在④号机的eth1与eth2网口限制速率为115200kbps,命令如下

tc qdisc add dev eth1 root tbf rate 115200bps buffer 1600 limit  3000
tc qdisc add dev eth2 root tbf rate 115200bps buffer 1600 limit  3000

图1 实验拓扑

然后在④号机上使用ifstat查看网口状态,得到结果如下:

我们可以看到eth1的入口速率为144KB/s左右,而eth2的出口速率为112KB/s左右,那么还有32KB/s的速率哪里去了呢?

二、令牌桶在端口限速的原理

首先让我们了解下令牌桶限速的原理,如限速原理图如下(此图引自博文:令牌桶算法的应用 )

图2 使用令牌桶做端口限速的原理图

  图2展示是了linux系统中宽带管理的实现,需由端口发送的报文通过分类器分类以后,进入队列,这个队列的大小由上面tc tbf命令中的limit设定,若令牌桶中有这个报文大小的令牌,则将此报文发送出去,否则在缓存队列中等待,等待有足够多的令牌后在发送,若在这个过程中缓存队列溢出,则将导致部分报文被丢弃,这里值得注意的是发送报文是以包为单位发送的,但是令牌桶的实现是以字节为单位,而不是针对包进行的。

  每个到来的令牌从数据队列中收集一个数据包,然后从桶中被删除。这个算法关联到两个流上——令牌流和数据流,于是我们得到3种情景:

  1、数据流以等于令牌流的速率到达TBF。这种情况下,每个到来的数据包都能无延迟地通过队列。

  2、 数据流以小于令牌流的速度到达TBF。通过队列的数据包只消耗了一部分令牌,剩下的令牌会在桶里积累下来,直到桶被装满。剩下的    令牌可以在需要以高于令牌流速率发送数据流的时候消耗掉,这种情况下会发生突发传输。
  3、数据流以大于令牌流的速率到达TBF。这意味着桶里的令牌很快就会被耗尽。导致TBF中断一段时间,称为“越限”。如果数据包持续到    来,将发生丢包。

  

  最后一种情景非常重要,因为它可以用来对数据通过过滤器的速率进行整形。
  可见,令牌的积累可以导致越限的数据进行短时间的突发传输而不必丢包,但是持续越限的话会导致传输延迟直至丢包。

博客迁到个人博客网站:http://btdog.com.cn/index.php/home/article/detail/id/3.html

时间: 2024-07-29 04:45:11

tc令牌桶限速心得的相关文章

令牌桶过滤器(TBF)

令牌桶过滤器(TBF)是一个简单的队列规定,只允许不超过事先设定的速率到来的数据包通过,但可能允许短暂突发流量超过设定值. TBF很精确,对于网络和处理器的影响都比较小.如果对一个网卡限速,它应该成为第一选择. TBF的实现在于一个缓冲器(桶),不断地被一些叫做"令牌"的虚拟数据以特定速率填充(token rate).同最重要的参数就是它的大小,也就是它能够存储令牌的数量. 每个到来的令牌从数据队列中收集一个数据包,然后从桶中被删除.这个算法关联到两个流上----令牌流和数据流.于是由

理解流量监管和整形的关键算法—令牌桶

理解流量监管和整形的关键算法-令牌桶 无论是流量监管还是流量整形都提到一个超额流量的问题,而前面已经描述了监管和整形对超额流量的处理方式不同,监管丢弃或者重标记,流量整形是缓存,通过加大延迟的方式发送平滑的数据流量,那么网络设备怎么去确定这个超额流量,难道链路的带宽为512K,而此时用户以每秒768KB/s发送数据,使用768-512就256KB,难道超额的流量就是256KB吗?不是的,这样做是一种错误的理解,要确定用户的超额流量必须使用如下两种算法中的一种来确定,一种叫漏桶算法(leaky b

Guava-RateLimiter实现令牌桶控制接口限流方案

一.前言 限流的目的是通过对并发/一个时间窗口内的请求进行限速来达到保护系统的效果,一旦达到限制速率则可以拒绝服务.排队或等待.降级等处理. 二.常见限流方案   原理 优点 缺点 计数器法 在单位时间段内,对请求数进行计数,如果数量超过了单位时间的限制,则执行限流策略,当单位时间结束后,计数器清零,这个过程周而复始,就是计数器法. null 不能均衡限流,在一个单位时间的末尾和下一个单位时间的开始,很可能会有两个访问的峰值,导致系统崩溃.   漏桶算法                     

令牌桶-流量控制

作为后台服务,通常有一个处理极限PPS(packets per second),如果请求超过了这个处理能力,可能会出现“雪崩效应”,因此后台服务需要有过载保护机制. 1.有个简单的算法可以实现流量控制功能:设置一个单位时间(如1s, 1min)内的最大访问量,并维护一个单位时间里的计数器. 当访问请求到达时,先判断单位控制时间是否已经超时,如果已经超时,重置计数器为0; 否则,将计数器加1,并判断计数器的值是否超过最大访问量设置,如超过,则拒绝访问. 伪代码如下: 1 long timeStam

Golang令牌桶-频率限制

令牌桶算法 令牌桶算法一般用做频率限制.流量限制等,可能具体有单速双色.单速三色.双速三色等方法. 我们的具体需求是对API的调用的频率做限制,因此实现的是单速双色. package main import ( "errors" "fmt" "strconv" "sync" "time" ) const TOKEN_GRANULARITY = 1000 type MAP struct { lock sync

令牌桶算法限流

令牌桶算法最初来源于计算机网络.在网络传输数据时,为了防止网络拥塞,需限制流出网络的流量,使流量以比较均匀的速度向外发送.令牌桶算法就实现了这个功能,可控制发送到网络上数据的数目,并允许突发数据的发送. 1.https://blog.csdn.net/sunnyyoona/article/details/51228456 2.https://github.com/yangwenmai/ratelimit 3.https://juejin.im/post/5ab10045518825557005d

限流算法之漏桶算法、令牌桶算法

昨天CodeReview的时候看到同时使用RateLimiter这个类用作QPS访问限制.学习一下这个类. RateLimiter是Guava的concurrent包下的一个用于限制访问频率的类. 1.限流 每个API接口都是有访问上限的,当访问频率或者并发量超过其承受范围时候,我们就必须考虑限流来保证接口的可用性或者降级可用性.即接口也需要安装上保险丝,以防止非预期的请求对系统压力过大而引起的系统瘫痪. 通常的策略就是拒绝多余的访问,或者让多余的访问排队等待服务,或者引流. 如果要准确的控制Q

redis实现的简单令牌桶

这里给出的令牌桶是以redis单节点为中间件, 改成以redis集群为中间件应该也很简单. 不过, 这里的实现比较简单, 主要提供两个函数, 一个用于消费令牌, 一个用于添加令牌. 这里, 消费令牌和添加令牌都是通过lua来保证原子性. 消费令牌的代码如下 : // FetchToken 用来获取某个key的一个令牌 func (acc *Accessor) FetchToken(key string) (bool, error) { /* * KEYS[1] 表示特定的key, 这个key是当

coding++:Semaphore—RateLimiter-漏桶算法-令牌桶算法

java中对于生产者消费者模型,或者小米手机营销 1分钟卖多少台手机等都存在限流的思想在里面. 关于限流 目前存在两大类,从线程个数(jdk1.5 Semaphore)和RateLimiter速率(guava) Semaphore:从线程个数限流 RateLimiter:从速率限流  目前常见的算法是漏桶算法和令牌算法 令牌桶算法.相比漏桶算法而言区别在于,令牌桶是会去匀速的生成令牌,拿到令牌才能够进行处理,类似于匀速往桶里放令牌 漏桶算法是:生产者消费者模型,生产者往木桶里生产数据,消费者按照