linux流量控制(四)

用不同的SLA运行多个网站。
你有很多种方法实现这个。Apache的有些模块可以支持这个功能,但是我们会让你看看Linux如何处理这个问 题,并能够提供其它多种服务的。这些命令都是从Jamal Hadi 的演示中偷学来的。 比如说我们有两个顾客,需要http、ftp和音频流服务,我们需要向他们出售一定量的带宽。我们在服务器上这么做。
A顾客应该拥有最多2Mbps的带宽,B顾客则交了5M的钱。我们在服务器上分配不同的IP地址来区分它们。
# ip address add 188.177.166.1 dev eth0
# ip address add 188.177.166.2 dev eth0
给服务器赋予那些IP地址完全取决于你。当前所有的守护程序都支持这个特性。 我们首先往eth0上附加一个CBQ队列规定:
# tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit cell 8 avpkt 1000 /
  mpu 64
为我们的顾客创建类:
# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 10Mbit rate /
  2MBit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21
# tc class add dev eth0 parent 1:0 classid 1:2 cbq bandwidth 10Mbit rate /
  5Mbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21
然后为我们的客户添加过滤器:
##求助: Why this line, what does it do?, what is a divisor?:
##求助: A divisor has something to do with a hash table, and the number of
##       buckets - ahu
# tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 1
# tc filter add dev eth0 parent 1:0 prio 5 u32 match ip src 188.177.166.1
  flowid 1:1
# tc filter add dev eth0 parent 1:0 prio 5 u32 match ip src 188.177.166.2
  flowid 1:2   做完了。
求助: why no token bucket filter? is there a default pfifo_fast fallback somewhere?
15.2. 防护SYN洪水攻击
根 据Alexey的iproute文档和许多非正式的netfilter方法而设计。如果你使用这个脚本,请认真调整其中的数值以适应你的网络。 如果你需要保护整个网络,就不要考虑这个脚本了,它最适合于单机使用。 乎你需要很新版本的iproute2工具才能利用2.4.0的内核工作。
#! /bin/sh -x
# sample script on using the ingress capabilities
# this script shows how one can rate limit incoming SYNs
# Useful for TCP-SYN attack protection. You can use
# IPchains to have more powerful additions to the SYN (eg  
# in addition the subnet)
#path to various utilities;
#change to reflect yours.
TC=/sbin/tc
IP=/sbin/ip
IPTABLES=/sbin/iptables
INDEV=eth2
# tag all incoming SYN packets through $INDEV as mark value 1
############################################################  
$iptables -A PREROUTING -i $INDEV -t mangle -p tcp --syn /
  -j MARK --set-mark 1
########################################################
# install the ingress qdisc on the ingress interface
########################################################
$TC qdisc add dev $INDEV handle ffff: ingress
######################################################### SYN packets are 40 bytes (320 bits) so three SYNs equals
# 960 bits (approximately 1kbit); so we rate limit below
# the incoming SYNs to 3/sec (not very useful really; but
#serves to show the point - JHS
########################################################
$TC filter add dev $INDEV parent ffff: protocol ip prio 50 handle 1 fw /
police rate 1kbit burst 40 mtu 9k drop flowid :1
########################################################
echo "---- qdisc parameters Ingress  ----------"
$TC qdisc ls dev $INDEV
echo "---- Class parameters Ingress  ----------"
$TC class ls dev $INDEV
echo "---- filter parameters Ingress ----------"
$TC filter ls dev $INDEV parent ffff:
#deleting the ingress qdisc
#$TC qdisc del $INDEV ingress
15.3. 为防止DDoS而对ICMP限速
最 近一段,分布式拒绝服务攻击成了Internet上最让人讨厌的东西。通过对你的网络正确地设置过滤和限速可以避免成为攻击的目标和跳板。 你应该过滤你的网络,禁止非本地IP源地址的数据包离开网络,这可以阻止其它人向Internet上发送垃圾包。 限速就象以前所展示的那样。如果忘了,就是这张图:
[Internet] ---<E3、T3之类>--- [Linux路由器] --- [办公室+ISP]
                             eth1        eth0
我们先进行预备设置:
# tc qdisc add dev eth0 root handle 10: cbq bandwidth 10Mbit avpkt 1000
# tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 10Mbit rate /
  10Mbit allot 1514 prio 5 maxburst 20 avpkt 1000
如 果你有一个100Mbps的网卡,调整这些数据。现在你需要决定允许多大的ICMP流量。你可以用tcpdump测量段时间,把结果写入一个文件,看一看 有多少ICMP数据包流经网络。别忘了适当延长监测时间! 如果没有条件进行测量,不妨就选择带宽的5%。设置我们的类:  
# tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 10Mbit rate /
  100Kbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 250 /
  bounded
限速为100Kbps。然后我们设置过滤器把ICMP数据包送给这个类:
# tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
  protocol 1 0xFF flowid 10:100
15.4. 为交互流量设置优先权
当 有很多上行和下行数据充斥了你的链路,而你正在使用telnet或者ssh维护一些系统的话,情况会很糟。器它的数据包会挡住你的按键数据包。有没有一种 方法,能让我们的交互数据包在大批数据传输中取得优先呢?Linux可以实现! 像以前一样,我们得处理量个方向的数据流。明显地,这在链路两端都是Linux
的时候非常有效——虽然其它的UNIX也能实现。问问你周围的 Solaris/BSD大拿们。 标准的pfifo_fast调度器有3个频道。0频道中的数据优先传输,然后才是1频道、2频道。关键就在于让我们的交互数据通过0频道! 我们改编自马上就要过期的ipchains HOWTO: 在IP头部有4个不常使用的bit,叫做TOS位。它们影响数据包的待遇,4个bit分别代表“最小延迟”、“最大吞吐”、“最大可靠”和“最小成本”。 同时只允许设置一位。Rob van Nieuwkerk——ipchains TOS-mangling代码的作者——这样说:
“最小延迟”对我来说特别重要。我在一个33k6的MODEM链路后面。Linux把数据包区分到3个队列
中。我在上行(Linux)路由器上为“交互”数据包打开它。这样我就可以在大批下在数据的同时得到可接受
的交互性能了。最通常的用发就是为设置telnet和ftp控制连接设置“最小延迟”,并为ftp数据连接设置“最大吞吐”。在你的上行路由器上如此实现:
# iptables -A PREROUTING -t mangle -p tcp --sport telnet /
  -j TOS --set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp --sport ftp /
  -j TOS --set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp --sport ftp-data /
  -j TOS --set-tos Maximize-Throughput
现在,所有从你的telnet/ftp主机到达你本机方向的数据流就设置好了。另外一个方向的设置似乎应该由你来设置,比如telnet、ssh等等都应自动在发出的数据包上做好TOS标记。你随时都可以用netfilter来实现。在你的本机上:
# iptables -A OUTPUT -t mangle -p tcp --dport telnet /
  -j TOS --set-tos Minimize-Delay
# iptables -A OUTPUT -t mangle -p tcp --dport ftp /
  -j TOS --set-tos Minimize-Delay
# iptables -A OUTPUT -t mangle -p tcp --dport ftp-data /
  -j TOS --set-tos Maximize-Throughput
15.5. 使用netfilter、iproute2和squid实现WEB透
明 代理 本节内容由读者Ram Narula(泰国)从Internet提交用于教学。  在Linux上实现这个功能的最正规方法可能是确认数据包的目标端口是80(web)后,使用 ipchains/iptables把它们路由到运行squid的服务器上。  有3种常规手段来实现,我们这里着重介绍第4种。  让网关路由器来路由 .你可以告诉路由器把目标端口是80的数据包发送到squid服务器上。 但是 这会给你的路由器增加负载,况且很多商业路由器根本就不支持。  使用4层交换器  4层交换器支持这个功能毫无问题。 但是
这种设备的价格 通常非常高。典型4层交换器的价格要超过一个典型路由器外加一个好Linux服务器的价格。让cache服务器做网关 你可以强迫所有的数据包都流经cache服务器。 但是这有相当风险,因为squid会占用很多CPU时间造成总体网络性能的下降,而且服务器本身的崩溃会造成所有人都无法上网。
Linux+NetFilter路由器 使用NetFilter的另一种技术,我们可以让Netfilter给去往80口的数据包
打上一个标记,然后用iproute2把打过标记的数据包路由给Squid服务器。  
|----------------|
|      实现    |
|----------------|

地址使用情况
10.0.0.1 naret (NetFilter 服务器)
10.0.0.2 silom (Squid 服务器)
10.0.0.3 donmuang (连接Internet的路由器)
10.0.0.4 kaosarn (网络上的其它服务器)
10.0.0.5 RAS 远程访问服务器
10.0.0.0/24 主网络
10.0.0.0/19 全体网络

|---------------|
|   网络结构  |
|---------------|

Internet
|
donmuang
|
------------hub/switch----------
|        |             |       |
naret   silom        kaosarn  RAS etc.
  
首 先,让naret成为除silom之外所有工作站的缺省网关,让所有的数据包都流经它。Silom的缺省网关是donmuang (10.0.0.3),否则就会造成web数据的环流。 (all servers on my network had 10.0.0.1 as the default gateway which was the former IP address of donmuang router so what I did was changed the IP address of donmuang to 10.0.0.3 and gave naret ip address of 10.0.0.1)  
Silom
-设置squid和ipchains  
在silom上设置好squid,保证它能支持透明缓冲/代理,缺省服务端口是3128,所以所有去网80口的数据流都应该重定向到它的3128口上。这可以用ipchains命令完成:
silom# ipchains -N allow1
silom# ipchains -A allow1 -p TCP -s 10.0.0.0/19 -d 0/0 80 -j REDIRECT 3128
silom# ipchains -I input -j allow1
或者,用netfilter来表达:  
silom# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
(注意:你可能还有其它条目)  
关于squid服务器的配置,请参考Squid常见问题网页: http://squid.nlanr.net)。 请确认这台服务器的IP转发已经打开,且缺省网关指向了路由器donmuang(不是NOT naret)。  
Naret
-----
-设置iptables和iproute2
-如果需要,禁止icmp REDIRECT消息
1. "Mark" 给去往80口的数据包打上标记“2”  
naret# iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 80 /
-j MARK --set-mark 2
        
2. 设置iproute2,把带有标记“2”的数据包路由到silom
naret# echo 202 www.out >> /etc/iproute2/rt_tables
naret# ip rule add fwmark 2 table www.out
naret# ip route add default via 10.0.0.2 dev eth0 table www.out
naret# ip route flush cache
如果donmuang和naret在同一个子网中,naret不应发出icmp重定向消息。
所以应该禁止icmp REDIRECT:
naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects
设置完成,检查配置:
在naret上:
naret# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       tcp  --  anywhere             anywhere           tcp dpt:www MARK set 0x2  

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

naret# ip rule ls
0:      from all lookup local  
32765:  from all fwmark        2 lookup www.out  
32766:  from all lookup main  
32767:  from all lookup default  

naret# ip route list table www.out
default via 203.114.224.8 dev eth0  
naret# ip route   
10.0.0.1 dev eth0  scope link  
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link  
default via 10.0.0.3 dev eth0
(make sure silom belongs to one of the above lines, in this case
it's the line with 10.0.0.0/24)

|------|
|-结束-|
|------|

15.5.1. 实现之后的数据流图
|----------------------------------------------|
|Traffic flow diagram after implementation|
|----------------------------------------------|

INTERNET
//
||
//
-----------------donmuang router---------------------
//                                      //         ||
||                                      ||         ||
||                                      //         ||
naret                                  silom      ||
*destination port 80 traffic=========>(cache)||
//                                      ||         ||
||                                      //         //
//===================================kaosarn, RAS, etc.
请注意网络是非对称的,输出的路径多了一跳。
Here is run down for packet traversing the network from kaosarn
to and from the Internet.
For web/http traffic:
kaosarn http request->naret->silom->donmuang->internet
http replies from Internet->donmuang->silom->kaosarn
For non-web/http requests(eg. telnet):
kaosarn outgoing data->naret->donmuang->internet
incoming data from Internet->donmuang->kaosarn
15.6. 与PMTU发现有关的“基于路由的MTU设置”  
在 传输大量数据的时候,使用大一些的数据包会让Internet表现好些。每个数据包都意味着一次路由判断,如果要发送1M字节的文件,即使让包处于最大尺 寸的话只需要大约700个包,而让包尽量小的话则需要4000个包。 然而,不是Internet的所有部分都能支持每个数据包1460字节负载。因此,为了
优化连接,就得检测一下,找到数据包最大的合适尺寸。 这个过程就叫“沿途MTU发现”,MTU意思是“最大传输单位”。 如果一个路由器发现一个数据包太大而无法在一个数据包中传输,而且数据包标
明 了“不可分片”,就会返回一个ICMP消息,报告说不得不丢弃这个包。发包的主机根据这个提示就会减小发包尺寸,反复几次之后,就能够找到一个连接沿特定 路径传输时最优的包尺寸。 但是好景不长,因为Internet被一帮竭尽全力破坏通信的臭流氓们发现了。然后导致网管们被误导去通过阻挡或限制ICMP流量的方法来增加他们 Internet服务的安全性和坚固性。 现在的情况就是“沿途MTU发现”工作得越来越不好了甚至在某些路由器上失败,以至于TCP/IP会话在一段时间之后奇怪地中止。 虽然我不能证明,但是我曾经有两个运行Alteon Acedirectors的曾经站点有这个问题,也许有人能提供更多线索说明为什么发生。
15.6.1. 解决方案
当 你碰到被这个问题困扰的网站,可以手工地禁止沿途MTU发现功能。Koos van den Hout写到(经简单编辑): 下列问题:因为我的专线只有33k6,我设置了ppp的MTU值是296,但是我无法影响对端的队列。设置为296后,击健的响应时间比较合理。 在我这一端,是一个运行了Linux的伪装路由器。
最近,我把服务器和路由器分开了,所以绝大多数应用程序挪到了路由器的外面。 然后麻烦了,我无法登录到irc里。可怕!经过研究发现我已经连接到了irc上,但是没有从irc那里收到motd。我检查了可能出错的地方,注意到以前 我的MTU是1500时,连接某些web服务器没有问题,但设置为296后不行了,应该是与MTU相关的问题。因为irc服务器阻挡几乎每种它不直接需要 的流量,也包括icmp。
我试图向一个web服务器的操作员证明这就是引起问题的原因,但他们不愿意解决问题。 所以我不得不保证输出伪装过的数据包的时候使用比外部链路更低的MTU。但是我又希望本地以太网使用普通的MTU(为了nfs之类服务)。
解决方案:
ip route add default via 10.0.0.1 mtu 296
(10.0.0.1是缺省网关,伪装路由器的内网地址) 一般而言,可以通过设置特定的路由器来抑制PMTU发现。比如,如果只有某些子网由这个问题,那么:
ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000
15.7. 与PMTU发现有关的MSS箝位(给ADSL,cable,PPPoE和PPtP用户)
象 上面解释的那样,PMTU发现不再像以前那样有效了。所以如果你知道网络中某一跳的MTU比较小(<1500),你不能指望通过PMTU发现来解 决。 除了MTU之外,还有令一个方式来控制最大包尺寸,所谓的MSS(Maximum Segment Size,最大段尺寸)。这是SYN数据包中的一个TCP选项。 最近的Linux内核和一些PPPoE驱动程序(最显眼的是出色的Roaring Penguin)引入了“MSS箝位”特性。
它的好处在于,设置了MSS的值就等于明确地告诉对方“不要向我发送大于这个数值的数据包”。这完全不需要ICMP协议的参与。 它的坏处是,它明显是一种hack——通过改变数据包破坏了“端到端”原则。
知道了这些,我们在很多地方使用这个窍门,向符咒一样灵。 这个功能至少需要iptables-1.2.1a和Linux
2.4.3才行。基本命令行是:
# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu
它为你的链路计算出合适的MSS值。如果你足够勇敢,或者是高手,你也可以这样做:
# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128
它设置了发送SYN的数据包的MSS为128。如果你有小数据包的VoIP应用,而巨大的http数据包导致了语音的不连续,就可以这样设置。
15.8. 终极的流量控制:低延迟、高速上/下载
Note: This script has recently been upgraded and previously only worked for Linux
clients in your network! So you might want to update if you have Windows machines
or Macs in your network and noticed that they were not able to download faster while
others were uploading.
我试图打造圣杯: 让交互数据包保持较低的延迟时间
也就是说上载或下载文件不会打扰SSH/telnet等。这是最重要的,即使是200ms的延迟也会感觉很差。
上载或下载期间有合理的速率用于网页浏览 即使http属于一种大量数据传输,也不应受其它传输影响太大。 保证上载不会影响下载
上载数据流会影响下载的速率,这是相当普遍的现象。 只要花费一点点带宽就可以实现它们。之所以上载流、下载流和ssh之间要互相伤害,是因为像Cable或者DSL Modem这样的家用设备中的队列太大。  
下面一节进一步解释了造成延迟的原因和如何缓解。如果你对魔术的咒语不感兴趣,完全可以不看它,直接参考脚本那一节。
15.8.1. 为什么缺省设置不让人满意
ISP们知道人们评价他们的时候要看看下载的速度。除了可用带宽之外,丢包因为会严重地牵制TCP/IP效率而极大地影响下载速度。大队列有助于改善丢包,进而提高下载速度。所以ISP们都配置成大队列。
然而,大队列会破坏交互性。一次击键行为首先要在上行流队列中排队(可能长达数秒!)才能到达对端主机。回显的时候,数据包还要回来,所以还要在你ISP的下行流队列中排队,你的本端显示器才有显示。
这 个HOWTO教你如何用多种方法重组和处理队列,但是,并不是所有的队列配置我们都有权访问。你的ISP的队列肯定是无法配置的。上行流可能存在于你的 cable modem或DSL设备中,你也许可以配置,也许不可以配置。绝大多数不能配置。 那怎么办呢?既然无法控制那些队列,那就除去它们,让数据包在我们的Linux路由器内排队。幸运的是,这是可能的。 限制上载速率 把上载速率限制在比可用带宽稍小一些的位置上,于是你的MODEM中就不会形成队列了。也就是说,队列转移到你的Linux路由器中了。
限制 下载速率  这带点欺骗的味道,因为我们实际上不能控制Internet 向我们发包的速率。但我们可以丢掉那些太快到来的数据包,不让他们导致TCP/IP的速率低于我们期望的速率。因为我们不希望轻易地丢弃数据包,所以我们 要配置“burst”来容纳突发传输。 在做完了这些之后,我们就排除了下行队列(除了偶尔的突发),并让上行队列存在于我们的Linux路由器中,以便施展Linux非凡的能力。 剩下的事情就是保证交互数据包永远排在上行队列的最前面。为了保证上行数据流不会伤害下行流,我们还要把ACK数据包排在队列前面。这就是当发生大批量数 据流的时候,双向传输均受到严重影响的原因。因为下行数据的ACK必须同上行流进行竞争,并在处理过程中被延迟。 为了进一步配置,我们使用一个高质量的ADSL连接(荷兰的xs4all)得出了如下测量结果:
基准延迟:
round-trip min/avg/max = 14.4/17.1/21.7 ms
不进行流量控制,下载数据:
round-trip min/avg/max = 560.9/573.6/586.4 ms
不进行流量控制,上载数据:
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms
进行流量控制,220kbit/s上行:
round-trip min/avg/max = 15.7/51.8/79.9 ms
进行流量控制,850kbit/s下行:
round-trip min/avg/max = 20.4/46.9/74.0 ms
上载数据时,下载得到约80%的带宽。当上行流达到90%时,延迟一下子到850 ms,也能说明问题。
这 个脚本的期望效果极大地取决于你的实际上行速率。当你满速率上载的你击键的那个数据包前面总会有一个数据包。这就是你能够达到的上行延迟限——MTU除以 上行速率。典型值会比它稍高一些。要达到更好效果,可低MTU! 然后是两个版本的脚本一个是使用Devik的HTB,另一个是使用Linux内部的CBQ。都已经过测试,正常工作。
15.8.2. 实际的脚本(CBQ)
适用于所有内核。我们在CBQ的内部放置2个随机公平队列,以保证多个吐量数据流之间不会互相淹没。
下行流使用带有令牌桶过滤器的tc过滤器进行管制。 你可以往脚本中“tc class add .. classid 1:20”那一行添加“bounded”进行改如果你降低了MTU,同时也得降低allot和avpkt!
#!/bin/bash  
# The Ultimate Setup For Your Internet Connection At Home
# Set the following values to somewhat less than your actual download
# and uplink speed. In kilobits
DOWNLINK=800
UPLINK=220
DEV=ppp0
# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### uplink
# install root CBQ
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit  
# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
# main class
tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit allot 1500 prio 5 bounded isolated  
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit allot 1600 prio 1 avpkt 1000
# bulk and default class 1:20 - gets slightly less traffic,  
#  and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit allot 1600 prio 2 avpkt 1000
# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# start filters
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff  flowid 1:10
# ICMP (ip protocol 1) in the interactive class 1:10 so we  
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 match ip protocol 1 0xff flowid 1:10
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 12 u32 /
   match ip protocol 6 0xff  match u8 0x05 0x0f at 0  match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10
# rest is 'non-interactive' ie 'bulk' and ends up in 1:20
tc filter add dev $DEV parent 1: protocol ip prio 13 u32  match ip dst 0.0.0.0/0 flowid 1:20
########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent  
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src /
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
如果你希望这个脚本在ppp连接时执行,就把它拷贝成/etc/ppp/ip-up.d.如果在最后两行报错,请更新你的tc工具!
15.8.3. 实际的脚本(HTB)
下面的脚本通过HTB完成那些功能,参见相关章节。你真的值得为它打个补丁!
#!/bin/bash
# The Ultimate Setup For Your Internet Connection At Home  
# Set the following values to somewhat less than your actual download
# and uplink speed. In kilobits
DOWNLINK=800
UPLINK=220
DEV=ppp0
# clean existing down- and uplink qdiscs, hide errors
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
###### uplink
# install root HTB, point default traffic to 1:20:
tc qdisc add dev $DEV root handle 1: htb default 20
# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit  burst 6k prio 1
# bulk & default class 1:20 - gets slightly less traffic,  
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit burst 6k prio 2
# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff  flowid 1:10
# ICMP (ip protocol 1) in the interactive class 1:10 so we  
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:10
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
   tc filter add dev $DEV parent 1: protocol ip prio 10 u32 /
   match ip protocol 6 0xff /
   match u8 0x05 0x0f at 0 /
   match u16 0x0000 0xffc0 at 2 /
   match u8 0x10 0xff at 33 /
   flowid 1:10
# rest is 'non-interactive' ie 'bulk' and ends up in 1:20
########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent  
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src /
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
如果你希望这个脚本在ppp连接时执行,就把它拷贝成/etc/ppp/ip-up.d。 如果在最后两行报错,请更新你的tc工具! 
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Linux令牌桶流量控制是一种网络流量控制机制,用于限制进入或离开系统的数据包速率。它基于一个令牌桶模型,在这个模型中,一个固定数量的令牌以固定速率被添加到令牌桶中。每当有一个数据包到达时,系统将从令牌桶中取出一个令牌,只有当令牌桶中有足够的令牌时才允许数据包通过。如果令牌桶中没有足够的令牌,那么数据包就会被丢弃或延迟。 通过配置Linux内核参数和使用工具如tc(Traffic Control),可以实现令牌桶流量控制。以下是一些关键步骤: 1. 启用Linux内核的Traffic Control子系统。这可以通过加载“sch_htb”模块实现。 ``` $ modprobe sch_htb ``` 2. 使用tc命令创建一个类别(class)和队列(qdisc)来实现流量控制。例如,以下命令将创建一个带宽为1mbps、延迟为10ms的队列。 ``` $ tc qdisc add dev eth0 root handle 1: htb default 1 $ tc class add dev eth0 parent 1: classid 1:1 htb rate 1mbit ceil 1mbit $ tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 10ms ``` 3. 根据需求,可以添加过滤规则(filter)以便仅对特定的流量应用流量控制。例如,以下命令将对源IP为192.168.0.1的流量应用限制。 ``` $ tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip src 192.168.0.1 flowid 1:1 ``` 通过以上步骤,你可以实现针对特定网络接口、IP地址或其他条件的流量控制。你可以根据具体需求进行调整和配置,以满足你的流量控制需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值