使用tc模拟特定端口上的网络延迟 [英] Simulate network latency on specific port using tc

查看:1073
本文介绍了使用tc模拟特定端口上的网络延迟的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试使用ubuntu上的tc命令来模拟来自源端口7000的tcp数据包的固定时间延迟.我正在使用的命令是:

I'm trying to simulate a fixed time latency on tcp packets coming from source port 7000 using the tc command on ubuntu. The commands I'm using are:

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端口或执行等效的操作来测试延迟?

There doesn't appear to be any delay caused by this filter, could someone please point out where I'm going wrong? Also, is there any way I can ping a port or do something equivalent to test the latency?

谢谢!

推荐答案

尝试一下:

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值将流量分配到不同的频段
    • 这意味着某些与您的过滤器不匹配的流量可能会与延迟的流量归为同一类
      • I've added the all zeros priomap to prio so all regular traffic will flow through a single band
        • by default, prio assigns traffic to different band according to the DSCP value of the packet
        • This means that some traffic that doesn't match your filter might end up in the same class as the delayed traffic
          • 这可能是您出问题的地方
          • 您需要将过滤器分配给 classful prio qdisc的1:2,而不是 classless netem.
          • This is probably where you went wrong
          • You need to assign the filter to 1:2 of the classful prio qdisc, not the classless netem.

          要对其进行测试,我将过滤器更改为 d 端口 80 ,而不是 s 端口7000,并连接到checkip.amazonaws.com 6秒(TCP Syn延迟3秒,HTTP GET延迟3秒):

          To test it, I changed the filter to dport 80 instead of sport 7000, and connecting to checkip.amazonaws.com took me 6 seconds (3 second delay for the TCP Syn, 3 second delay for the HTTP GET):

          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处理的数据包数量合理.

          Connections to other ports though (e.g. 443 - HTTPS, 22 - SSH, etc) were much quicker. You can also run sudo tc -s qdisc show dev eth1 to make sure that the number of packets handled by netem makes sense.

          这篇关于使用tc模拟特定端口上的网络延迟的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆