Linux uses TC to control network QoS (1)

TC is short for Linux traffic control. The principle is to use qdisc (queue Discipline) the filter mechanism and the filter mechanism exile different rule definitions into sub-qdisc of different classes (this is true for classful qdisc, and only one root qdisc for classless qdisc ). There is a lot of information about TC on the Internet. This article will not discuss the use of various TC qdisc, class, filter or different classful/classless classes, however, we only do some research on the htb + iptables/ebtables method.

Htb is an implementation of classful qdisc. latrc.org recommends using htb instead of CBQ as the configuration of classful qdisc. There are many methods to distinguish different streams in htb, such as u32 selector and classify, mark. Let's take a look at the example of lartc.org's famous document Linux advanced routing & Traffic Control howto.

# TC qdisc add Dev eth0 root handle 1: htb default 30

# TC class add Dev eth0 parent 1: classid :10 htb rate 5 Mbit burst 15 K

# TC class add Dev eth0 parent 1: classid :20 htb rate 3 Mbit Ceil 5 Mbit burst 15 K

# TC class add Dev eth0 parent 1: classid htb rate 500 kbit Ceil 1 Mbit burst 15 K

# TC qdisc add Dev eth0 parent :10 handle 10: SFQ perturb 10

# TC qdisc add Dev eth0 parent :20 handle 20: SFQ perturb 10

# TC qdisc add Dev eth0 parent :30 handle 30: SFQ perturb 10

In this example, the eth0 outbound traffic is divided into three types: Rate, Ceil bandwidth, and burst traffic. (For more information about the specific values, see the htb documentation. The default value is ), for each type of traffic, an SFQ sub-qdisc is used to ensure fairness. The reason for doing so is that the outbound traffic of many processes can be matched to classid, which is the public bandwidth of these processes. By using an SFQ, no process bandwidth is starved to death.

In this example, we use a u32 selector to differentiate traffic. We can see that HTTP traffic is divided into class, SMTP traffic is divided into class, and the rest are in default class, all processes share HTTP traffic in a fair manner

We can use the u32 match method to match different streams. Here we are not talking nonsense. I am interested in reading the document mentioned above. I personally think that although u32 match can match different protocols such as IP TCP ICMP and match such as IP segments and ports, it is not as flexible as iptables in the end, and u32 match is insensitive to Layer 2, this makes it more flexible and controllable to filter data using iptables/ebtables mark.

For example, TC + iptables is used to set QoS for the outbound packet of IP address 192.168.1.1. The BPS is limited to 2 Mbit, and the maximum bps to 5 Mbit is allowed.

# TC qdisc add Dev eth0 root handle 1: htb default 100

# TC class add Dev eth0 parent 1: classid :10 htb rate 2 Mbit Ceil 5 Mbit

# Iptables-T mangle-A postrouting-s 192.168.1.1-J classify -- Set-class :10

TC + iptables can only implement QoS for layer-3 traffic. For layer-2 traffic, only TC + ebtables can be used. The following example is used to limit the BPS of ARP packets.

# TC qdisc add Dev eth0 root handle 1: htb default 100

# TC class add Dev eth0 parent 1: classid :20 htb rate 1 kbit Ceil 5 kbit

# TC filter add Dev eth0 PRIO 32 protocol ARP handle 127 FW classid