我正在尝试使用 ubuntu 上的 tc 命令模拟来自源端口 7000 的 tcp 数据包的固定时间延迟。我使用的命令是:
sudo tc qdisc add dev eth1 root handle 1: prio
sudo tc qdisc add dev eth1 parent 1:1 handle 2: netem delay 3000ms
sudo tc filter add dev eth1 parent 1:0 protocol ip u32 match ip sport 7000 0xffff flowid 2:1
该过滤器似乎没有造成任何延迟,有人可以指出我哪里出错了吗?另外,有什么方法可以 ping 端口或执行相当于测试延迟的操作吗?
Thanks!
尝试这个:
sudo tc qdisc add dev eth1 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
sudo tc qdisc add dev eth1 parent 1:2 handle 20: netem delay 3000ms
sudo tc filter add dev eth1 parent 1:0 protocol ip u32 match ip sport 7000 0xffff flowid 1:2
解释:
- 将全零priomap添加到
prio
因此所有常规流量都流经单个频段。默认情况下prio
根据报文的DSCP值将流量分配到不同的频段。这意味着一些与您的过滤器不匹配的流量最终可能会与延迟的流量属于同一类别。
- 将 netem 分配给其中一个类 -
1:2
- 最后,添加您的过滤器,以便它分配流 ID
1:2
到匹配的数据包。这可能是你出错的地方。您需要将过滤器分配给1:2
of the classfulprio qdisc,而不是无阶级的 netem.
为了测试这个设置,我将过滤器更改为dport 80代替s端口 7000,并运行 wgetcheckip.amazonaws.com
,花费了 6 秒(TCP Syn 延迟 3 秒,HTTP GET 延迟 3 秒):
malt@ubuntu:~$ wget -O - checkip.amazonaws.com
--2016-10-23 06:21:42-- http://checkip.amazonaws.com/
Resolving checkip.amazonaws.com (checkip.amazonaws.com)... 75.101.161.183, 54.235.71.200, 107.20.206.176, ...
Connecting to checkip.amazonaws.com (checkip.amazonaws.com)|75.101.161.183|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10
Saving to: ‘STDOUT’
- 0%[ ] 0 --.-KB/s X.X.X.X
- 100%[===========================================================>] 10 --.-KB/s in 0s
2016-10-23 06:21:48 (3.58 MB/s) - written to stdout [10/10]
不过,与其他端口的连接(例如 443 - HTTPS、22 - SSH 等)要快得多。你也可以运行sudo tc -s qdisc show dev eth1
确保 netem 处理的数据包数量有意义。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)