Simulate Network Latency and Packet Drop In Linux
In this article, we will understand how tc command in Linux can be used to simulate network slowness and how we can simulate packet corruption.
Join the DZone community and get the full member experience.
Join For FreeThere may be a scenario when you want to test an application when the network is slow(we also call it high network latency). Or you are reproducing a customer scenario(having high network latency) where some anomalous behavior is observed. In the Chrome browser, we can easily Simulate a slower network connection. This is very helpful when we are working with web applications. But we can also have non-web applications, like web-service applications, messaging brokers, etc. Also, the slowness simulated using Chrome dev tools is more from the client side.
In this article, we will understand how tc command in Linux can be used to simulate network slowness and how we can simulate packet corruption. I have followed a couple of articles on the web, and after testing the commands mentioned in the articles, I am sharing my experiences.
1. Run a basic HTTP application using the python utility. Then we can check the response time using the curl or ab utility.
$ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
# we can use curl with following syntax to get statistics for total response time.
$ curl -o /dev/null -s -w 'Establish Connection: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' http://localhost:8000/
Establish Connection: 0.000331s
TTFB: 0.002978s
Total: 0.003120s
# we can also use ab utility to understand statistics of a request. Here -n switch is used for number of request to be sent.
$ ab -n 1 http://localhost:8000/
This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software: SimpleHTTP/0.6
Server Hostname: localhost
Server Port: 8000
Document Path: /
Document Length: 2571 bytes
Concurrency Level: 1
Time taken for tests: 0.003 seconds
Complete requests: 1
Failed requests: 0
Total transferred: 2727 bytes
HTML transferred: 2571 bytes
Requests per second: 374.11 [#/sec] (mean)
Time per request: 2.673 [ms] (mean)
Time per request: 2.673 [ms] (mean, across all concurrent requests)
Transfer rate: 996.29 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 3 3 0.0 3 3
Waiting: 3 3 0.0 3 3
Total: 3 3 0.0 3 3
2. Now set a delay of two seconds and then again check the response time. Furthermore, we would see that the total response time is increased due to the delay we set.
#set a delay of 2 second for loopback interface.
$ sudo tc qdisc replace dev lo root netem delay 2000ms
# show the rule set
$ tc qdisc show dev lo
qdisc netem 8001: root refcnt 2 limit 1000 delay 2s
# we can use curl(or ab) with following syntax to get statistics for total response time.
$ curl -o /dev/null -s -w 'Establish Connection: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' http://localhost:8000/
Establish Connection: 4.000354s
TTFB: 8.002722s
Total: 8.002833s
cpandey@cpandey:~$ ab -n 1 http://localhost:8000/
This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software: SimpleHTTP/0.6
Server Hostname: localhost
Server Port: 8000
Document Path: /
Document Length: 2571 bytes
Concurrency Level: 1
Time taken for tests: 8.003 seconds
Complete requests: 1
Failed requests: 0
Total transferred: 2727 bytes
HTML transferred: 2571 bytes
Requests per second: 0.12 [#/sec] (mean)
Time per request: 8002.822 [ms] (mean)
Time per request: 8002.822 [ms] (mean, across all concurrent requests)
Transfer rate: 0.33 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 4000 4000 0.0 4000 4000
Processing: 4003 4003 0.0 4003 4003
Waiting: 4002 4002 0.0 4002 4002
Total: 8003 8003 0.0 8003 8003
3. Finally, delete the rule we had set earlier; this is important as we were simulating a slow network. This would slow down the complete interface and associated network traffic. Thus once we finish our testing, it is important to delete the rule which we have set.
$ sudo tc qdisc delete dev lo root
4. We can also simulate the corruption of packets as per the percentage set. As per my testing, I found that this also helps in simulating network latency. I observed that packets are being re-transmitted because TCP protocol ensures data is received correctly, no data is missing, and in order.
$ sudo tc qdisc replace dev lo root netem corrupt 50%
That's it; I hope you will find this article interesting and helpful. Thank you.
Opinions expressed by DZone contributors are their own.
Comments