리눅스는 패킷 전송을 관리하고 조작하는 매우 다양한 도구들을 제공합니다. 많은 리눅스 커뮤니티에서 리눅스 상에서 패킷을 mangling 하고 방화벽(netfilter, 예전에는 ipchain) 을 만들어주는 툴들은 운영체제에서 돌아가는 수백개의 네트워크 서비스들 만큼이나 익숙합니다. 하지만 커뮤니티안에서는 조금, 리눅스 커뮤니티 밖에서는 더 조금만이 커널 2.2와 2.4에서 시작하고 발전된 트래픽 컨트롤 하위 시스템의 막강한 파워를 알고 있습니다.

이 하우투 문서를 통해 트래픽 관리의 개념과 일반적이고 전통적인 요소들, 리눅스에서의 트래픽 콘트롤 구현을 소개하고 몇가지 가이드라인을 제시하고자 합니다. 이 하우투 문서는 LARTC HOWTO의 개별 프로젝트에서 시작된 문서들과 오랫동안 LARTC의 메일링 리스트를 통해 주고밭은 토론들을 모으고 통합하여 결합한 문서입니다.

바로 당장 실험해보고 싶어하는 참을성 없는 영혼들은 HTB HOWTO나 LARTC HOWTO를 참고하는 것을 추천합니다.

이 하우투는 트래픽 컨트롤이라는 분야에 대한 소개나 리눅스 상에서 트래픽 컨트롤을 구현하는 툴에 대한 개요를 알고 싶어하는 네트웍 관리자나 어느 정도의 지식을 가지고 있는 일반 사용자를 대상으로 작성되었습니다.

이 문서를 읽는 독자들이 UNIX 개념이나 명령어에 친숙하고 IP 네트워킹에 대해 기본적인 지식이 있는 것으로 간주하고 문서를 작성하였습니다.

Users who wish to implement traffic control may require the ability to patch, compile and install a kernel or software package 1. For users with newer kernels (2.4.20+, see also Section 5.1), however, the ability to install and use software may be all that is required.

Broadly speaking, this HOWTO was written with a sophisticated user in mind, perhaps one who has already had experience with traffic control under Linux. I assume that the reader may have no prior traffic control experience.

This text was written in DocBook (version 4.2) with vim. All formatting has been applied by xsltproc based on DocBook XSL and LDP XSL stylesheets. Typeface formatting and display conventions are similar to most printed and electronically distributed technical documentation.

I strongly recommend to the eager reader making a first foray into the discipline of traffic control, to become only casually familiar with the tc command line utility, before concentrating on tcng. The tcng software package defines an entire language for describing traffic control structures. At first, this language may seem daunting, but mastery of these basics will quickly provide the user with a much wider ability to employ (and deploy) traffic control configurations than the direct use of tc would afford.

Where possible, I'll try to prefer describing the behaviour of the Linux traffic control system in an abstract manner, although in many cases I'll need to supply the syntax of one or the other common systems for defining these structures. I may not supply examples in both the tcng language and the tc command line, so the wise user will have some familiarity with both.

There is content yet missing from this HOWTO. In particular, the following items will be added at some point to this documentation.

A description and diagram of GRED, WRR, PRIO and CBQ.

A section of examples.

A section detailing the classifiers.

A section discussing the techniques for measuring traffic.

A section covering meters.

More details on tcng.

I welcome suggestions, corrections and feedback at <martin@linux-ip.net>. All errors and omissions are strictly my fault. Although I have made every effort to verify the factual correctness of the content presented herein, I cannot accept any responsibility for actions taken under the influence of this documentation.

This section will introduce traffic control and examine reasons for it, identify a few advantages and disadvantages and introduce key concepts used in traffic control. 이 장에서는 트래픽 컨트롤을 개념과 트래픽 컨트롤을 사용하는 이유, 장단점, 트래픽 컨트롤의 몇가지 중요한 개념들에 대해서 소개하겠습니다.

트래픽 컨트롤은 라우터에서 수신하거나 송신한 패킷들을 큐잉하는 시스템이나 메커니즘 집합에 붙여진 이름입니다. 이것은 수신 인터페이스에서 어떤 패킷을 어떤 속도로 받아들일지와 송신 인터페이스에서 어떤 패킷을 어떤 순서와 어떤 속도로 전송할지 결정하는 것을 포함하고 있습니다. 대부분의 경우 트래픽 컨트롤은 하나의 큐로 이루어져있습니다. 이 큐는 하드웨어가 할 수 있는 한 최대한 빨리 수신 패킷을 모으고 송신 패킷을 내보내도록 되어있습니다. FIFO(First In First Out)가 바로 이런 종류의 큐입니다.

리눅스의 디폴트 qdisc는 FIFO보다 약간 복잡한 pfifo-fast 입니다.

모든 종류의 소프트웨어에 큐를 사용하고 있습니다. 큐는 대기중인 작업이나 데이터를 관리하는 방법입니다. (Section 2.5 참고) 네트웍 링크는 일반적으로 데이터를 직렬로 차례차례(serialized fashon) 전달하기 때문에 처리 한계를 넘어서는 데이터 패킷을 처리하기 위해서 큐가 필요합니다.

데스크탑 장비와 웹서버가 인터넷으로 같은 업링크를 공유해서 사용하는 경우 사용 대역에 대한 경쟁이 발생하게 됩니다. 웹서버가 링크를 통해 데이터가 전달되는 것보다 빠르게 라우터의 송신 큐를 체울 수 도 있습니다. 이런 경우 어떤 시점 부터 라우터는 패킷을 버리게 됩니다. (큐가 가득 찼음) 이제 데스크탑 장비는 (그리고 작업중이던 사용자는) 패킷 손실과 전송 지연(high latency)을 겪게 됩니다. 느려터진 속도는 사용자를 소리지르게 만듭니다!! 이런 두가지 다른 종류의 어플리케이션을 위해 각각의 어플리케이션이 네트웍 자원을 더 잘 공유 하도록 내부의 큐를 사용할 수 있습니다.

Traffic control is the set of tools which allows the user to have granular control over these queues and the queuing mechanisms of a networked device. The power to rearrange traffic flows and packets with these tools is tremendous and can be complicated, but is no substitute for adequate bandwidth.

The term Quality of Service (QoS) is often used as a synonym for traffic control.

Packet-switched networks differ from circuit based networks in one very important regard. A packet-switched network itself is stateless. A circuit-based network (such as a telephone network) must hold state within the network. IP networks are stateless and packet-switched networks by design; in fact, this statelessness is one of the fundamental strengths of IP.

The weakness of this statelessness is the lack of differentiation between types of flows. In simplest terms, traffic control allows an administrator to queue packets differently based on attributes of the packet. It can even be used to simulate the behaviour of a circuit-based network. This introduces statefulness into the stateless network.

There are many practical reasons to consider traffic control, and many scenarios in which using traffic control makes sense. Below are some examples of common problems which can be solved or at least ameliorated with these tools.

The list below is not an exhaustive list of the sorts of solutions available to users of traffic control, but introduces the types of problems that can be solved by using traffic control to maximize the usability of a network connection.

일반적인 트래픽 컨트롤 방법들

전체 대역폭을 알려진 속도로 제한 : TBF, HTB 그외 하위 클래스들 특정 사용자나 서바스, 혹은 클라이언트에 대역폭을 제한 : HTB 클래스, classifying with a filter. traffic. 비대칭 링크에서 TCP 전송 속도를 최대화 : prioritize transmission of ACK packets, wondershaper. Reserve bandwidth for a particular application or user; HTB with children classes and classifying.

Prefer latency sensitive traffic; PRIO inside an HTB class.

Managed oversubscribed bandwidth; HTB with borrowing.

Allow equitable distribution of unreserved bandwidth; HTB with borrowing.

Ensure that a particular type of traffic is dropped; policer attached to a filter with a drop action.

Remember, too that sometimes, it is simply better to purchase more bandwidth. Traffic control does not solve all problems!

When properly employed, traffic control should lead to more predictable usage of network resources and less volatile contention for these resources. The network then meets the goals of the traffic control configuration. Bulk download traffic can be allocated a reasonable amount of bandwidth even as higher priority interactive traffic is simultaneously serviced. Even low priority data transfer such as mail can be allocated bandwidth without tremendously affecting the other classes of traffic.

In a larger picture, if the traffic control configuration represents policy which has been communicated to the users, then users (and, by extension, applications) know what to expect from the network.

복잡성이 트래픽 컨트롤을 사용하는 경우에 가장 큰 단점이이다. Complexity is easily one of the most significant disadvantages of using traffic control. There are ways to become familiar with traffic control tools which ease the learning curve about traffic control and its mechanisms, but identifying a traffic control misconfiguration can be quite a challenge.

Traffic control when used appropriately can lead to more equitable distribution of network resources. It can just as easily be installed in an inappropriate manner leading to further and more divisive contention for resources.

The computing resources required on a router to support a traffic control scenario need to be capable of handling the increased cost of maintaining the traffic control structures. Fortunately, this is a small incremental cost, but can become more significant as the configuration grows in size and complexity.

For personal use, there's no training cost associated with the use of traffic control, but a company may find that purchasing more bandwidth is a simpler solution than employing traffic control. Training employees and ensuring depth of knowledge may be more costly than investing in more bandwidth.

Although traffic control on packet-switched networks covers a larger conceptual area, you can think of traffic control as a way to provide some of the statefulness of a circuit-based network to a packet-switched network.

큐는 모든 트래픽 컨트롤의 바탕이자 스케쥴링 밑에 있는 필수적인 개념 입니다. 큐는 액션이나 서비스를 기다리고 있는 한정된 수의 아이템을 담고 있는 장소(혹은 버퍼)입니다. 네트워킹에서 큐는 패킷들이 하드웨어에 의해 전송될때까지 대기하는 장소입니다. 가장 간단한 모델은 먼저 들어온 패킷이 먼저 전송되는 것입니다. 컴퓨터 네트워킹 체계에서(넓게는 컴퓨터 과학에서) 이러한 큐는 FIFO라고 알려져있습니다.

어떤 다른 메커니즘이 없다면 큐는 트래픽 컨트롤에 관한 어떠한 보장도 하지 않습니다. 큐는 오직 두개의 행동에만 관심이 있습니다. 큐에 들어온 것을 담는 것과 나간것은 삭제하는 것 입니다.

여러개의 큐를 이용해서 패킷을 지연시키고, 다시 배열하고, 버리고, 우선순위를 주는 메커니즘을 큐에 결합 할 수 있습니다. 이렇게 큐를 다른 메커니즘과 결합시킴으로써 큐는 더 흥미로워 질 수 있습니다.

상위 레이어 소프트웨어의 관점에서 패킷은 단순히 송신을 위해 큐에 넣어집니다. 그리고 큐에 넣어져있는 패킷이 어떤 순서나 규칙에 따라 전송이 되는지는 상위 레이어에게는 중요하지 않습니다. 그러므로 상위 레이어에게 전체 트래픽 컨트롤 시스템은 그저 한개의 큐로 보이게 됩니다. 트래픽 컨트롤 구조가 공개되고 보여지는 것은 현재 레이어의 내부를 들여다볼 때 뿐입니다.

흐름은 두개의 호스트 사이의 하나의 구분되는 연결이나 관리를 말합니다. 두 호스트간의 어떠한 특정한 패킷 묶음을 흐름이라고 할 수 있습니다. TCP 연결의 경우라면 출발지 IP와 port, 목적지 IP와 port를 가진 연결이 흐름을 나타내게 됩니다. UDP 연결되 비슷하게 정의될 수 있습니다.

자주 사용되는 트래픽 컨트롤 방법은 트래픽을 하나의 묶음으로 합쳐서 전송 할 수 있는 여러개의 흐름 클래스로 구분하는 것이다. 또 하나의 방법은 각각의 개별적인 흐름이 대역폭을 공평하게 나누어 사용하도록 하는 것이다.

여러개의 경쟁적인 흐름들 속에서 대역폭을 공평하게 나누려고 할때 흐름은 중요해진다. 특히 어떤 어플리케이션이 많은 숫자의 흐름을 고의로 만들어낼때 더 그렇다.

shaping 매커니즘의 두가지 핵심 적인 내용은 토큰과 양동이의 개념과 밀접하게 연관이 있다.

디큐잉 속도를 조절하기 위해서 구현부는 매번 데이터가 큐에서 나갈때 나가는 패킷의 갯수 혹은 바이트를 셀 수 있어야한다. 비록 이것이 최대한 정확한 타이머와 측정 장치의 복잡한 사용을 필요로 하더라도. 트래픽 컨트롤에서 많이 사용하는 한가지 방법은 현재의 사용량과 시간을 계산하는 대신에 토큰을 사용하는 것이다. 토큰을 원하는 속도로 만들어내고 토큰이 사용가능한 시점에만 패킷이나 바이트를 디큐잉 한다.

놀이 공원에서 놀이기구를 타려고 기다리는 사람들과 큐잉의 유사점을 생각해보자. 고정된 트랙을 움직이는 카트를 상상해보자. 큐의 입구에 카트가 정해진 속도로 도착한다. 카트를 타기 위해서 모든 사람들은 빈 카트가 도착할때 까지 기다려야한다. 카트는 토큰을 비유되고 사람은 패킷에 비유된다. 이러한 방법은 전송률 제한 혹은 shaping 메커니즘이다. 특정한 기간동안 오직 정해진 숫자의 사람들만이 놀이기구를 탈 수 있다.

놀이기구 비유를 확장해서 생각해보자. 놀이 기구 앞의 빈 줄과 사람들을 태우려고 트랙에서 기다리고 있는 많은 숫자의 카트를 상상해보자. 많은 사람들이 한꺼번에 입장해서 놀이기구를 타려고 해도 빈 카트들이 기다리고 있으므로 한꺼번에 카트를 탈 수 있다. 여러대의 빈 카트가 양동이를 의미한다. 양동이는 기다릴 필요 없이 한꺼번에 다 사용할 수 있는 여러개의 토큰을 가지고 있다.

놀이 공원의 놀이기구 비유를 완성해보자. 카트(즉 토큰)이 도착했다. 카트는 정해진 속도로 도착하고 최대 양동이의 크기 만큼 대기하고 있을 수 있다. 그러므로 양동이는 정해진 속도로 토큰으로 체워진다. 그리고 토큰을 사용하지 않고 있으면 양동이가 가득 찬다. 토큰을 사용하면 양동이는 가득 차지 않는다. 양동이는 HTTP 처럼 일정하지 않게 몰려드는 트래픽을 수용 할 수 있는 핵심 개념이다. TBF qdisc는 shaper의 가장 일반적이고 고전적인 예이다. (TBF를 설명하고 있는 장에 토큰과 양동이 개념을 시각적으로 잘 나타내는 그림이 있다.) TBF는 속도 토큰을 만들고 토큰을 사용할 수 있는 경우에만 패킷을 전송한다. 토큰은 일반적인 shaping 개념이다.

토큰을 즉시 필요로 하지 않는 큐의 경우 토큰이 필요하게 될 때까지 토큰을 모을 수 있다. 토큰을 무한이 모으는 것은 shaping의 장점을 쓸모없게 만든다. 그러므로 정해진 갯수 까지만 토큰을 모은다. 이제 큐는 많은 수의 패킷과 바이트를 전송 할 수 있을만큼 토큰을 가지고 있다. 이 무형의 토큰은 무형의 양동이에 저장되어 있다. 그리고 모을 수 있는 토큰의 갯수는 양동이의 크기에 달려있다.

이것은 또한 토큰으로 체워진 양동이는 언제든지 사용 가능하다는 것을 의미한다. 매우 규칙적인 트래픽은 작은 양동이로도 관리할 수 있다. 불규칙적인 흐름을 줄이려는 목적이 아닌 이상 불규칙적인 트래픽은 큰 양동이가 필요하다.

요약하자면 토큰은 정해진 속도로 만들어지고 양동이에 정해진 최대 갯수만큼 저장된다. 이것은 전송 트래픽을 smooting 하고 shaping 함으로써 불규칙적인 트래픽을 제어할 수 있게 해준다.

토큰과 양동이의 개념은 서로 밀접하게 연관되어 있고 둘다 TBF(클래스 없는 qdisc 중의 하나)와 HTB(class 사용하는 qdisc 중의 하나)에서 사용한다. tcng 언어에서 two- and three-color meters 의 사용은 의심할 여지 없이 토큰과 양동이 개념을 말한다.

네트웍을 가로질러 전달되는 데이터를 부르는 용어는 사용자가 관찰하는 레이어에따라 조금씩 달라진다. 이 문서는 패킷과 프레임이라는 단어를 명확한 기술적 구분없이 사용할 것이다. 비록 다음에서 두 용어를 대략 설명하긴 하지만.

프레임이라는 단어는 일반적으로 두번째 레이어(데이터 링크 레이어) 에서 다음 수신단으로 전달되는 데이터 단위를 뜻한다. 이더넷 인터페이스나 PPP 인터페이스, T1 인터페이스 모두 그들의 레이어 2 데이터 단위를 프레임이라고 부른다. 프레임은 실제로 트래픽 컨트롤이 적용되는 단위 이다.

반면 패킷은 layer 3 (네트워크 레이어)와 같은 더 상위 레이어의 개념이다. 이 문서에서는 조금 덜 정확한 단어이기는 하지만 패킷이라는 용어를 더 많이 사용한다.

shaper는 패킷을 원하는 속도로 지연 시킨다. 셰이핑(shaping)은 송신 큐에서 원하는 송신 속도를 유지하기 위해 패킷을 전송 전에 지연시키는 방법이다. 이것은 대역폭 제어를 원하는 사용자들의 가장 일반적인 요구사항 이다. 트래픽 컨트롤의 해결책으로써 패킷을 지연시키는 것은 모든 shaping 매커니즘을 non-work-conserving 매커니즘으로 만든다. 쉽게 말해서 패킷을 지연시키기위해서는 작업이 필요하다.

다시 말하면 non-work-conserving 큐잉 메커니즘이 shaping 함수를 구현한다. work-conserving 큐잉 매커니즘(예를들어PRIO)으로는 패킷을 지연시킬 수 없다.

shaper는 설정된 전송 속도(흔히 초당 패킷 수 혹은 초당 bit/byte 수로 측정)를 넘지 않도록 트래픽을 제한하거나 일정하게 분배하려고 한다.

scheduler는 전송 패킷을 정렬 혹은 재정렬한다. 스케쥴링은 특정한 큐의 수신단과 송신단 사이에 있는 패킷을 정렬 혹은 재정렬하는 메커니즘이다. 압도적으로 많은 수의 스케쥴러는 FIFO (First-in first-out) 스케쥴러이다. 패킷은 언제나 전송을 위해서 정렬되므로 넓은 관점에서 전송 큐에서의 어떤 트래픽 컨트롤 메커니즘도 스케쥴러라고 간주할 수 있다. 다른 일반적인 스케쥴링 메커니즘은 다양한 네트워크 조건에 따라 적절한 동작을 하고자 한다. fair queuing algorithm(예를들어 SFQ)은 특정한 클라이언트나 흐름이 네트워크 사용을 독점하는 것을 방지하려고 한다. round-robin algorithm (예를들어 WRR)은 각각의 클라이언트나 흐름이 번갈아 돌아가면서 패킷을 디큐하도록 한다. 다른 정교한 스케쥴링 알고리즘은 백본의 과부하를 방지하려고 하거나 (예를들어 GRED) 혹은 다른 스케쥴링 메커니즘을 개선한다. (예를들어 ESFQ)

Classifiers는 여러개의 큐로 트래픽을 구분하고 정리한다.

Classifying is the mechanism by which packets are separated for different treatment, possibly different output queues. During the process of accepting, routing and transmitting a packet, a networking device can classify the packet a number of different ways. Classification can include marking the packet, which usually happens on the boundary of a network under a single administrative control or classification can occur on each hop individually.

The Linux model (see Section 4.3) allows for a packet to cascade across a series of classifiers in a traffic control structure and to be classified in conjunction with policers (see also Section 4.5).

Policers measure and limit traffic in a particular queue.

Policing, as an element of traffic control, is simply a mechanism by which traffic can be limited. Policing is most frequently used on the network border to ensure that a peer is not consuming more than its allocated bandwidth. A policer will accept traffic to a certain rate, and then perform an action on traffic exceeding this rate. A rather harsh solution is to drop the traffic, although the traffic could be reclassified instead of being dropped.

A policer is a yes/no question about the rate at which traffic is entering a queue. If the packet is about to enter a queue below a given rate, take one action (allow the enqueuing). If the packet is about to enter a queue above a given rate, take another action. Although the policer uses a token bucket mechanism internally, it does not have the capability to delay a packet as a shaping mechanism does.

Dropping discards an entire packet, flow or classification.

Dropping a packet is a mechanism by which a packet is discarded.

Marking is a mechanism by which the packet is altered.

Traffic control marking mechanisms install a DSCP on the packet itself, which is then used and respected by other routers inside an administrative domain (usually for DiffServ).

Table 1. Correlation between traffic control elements and Linux components

전통적 요소	리눅스 구성품
shaping	class가 shaping 을 제공한다.
scheduling	qdisc is는 scheduler이다. Scheduler는 FIFO처럼 간단한 것일 수도 있고 HTB 처럼 class나 qdisc를 포함하는 복잡한 것일 수도 있다.
classifying	필터는 classifer 에이전시를 통해서 classification 동작을 한다. 엄밀히 말해서 리눅스 classifier는 필터 바깥에 존재할 수 없다.
policing	policer는 리눅스 트래픽 컨트롤 구현에 filter의 한 부분으로서만 존재한다.
dropping	트래픽 drop은 drop action을 사용하는 policer가 적용된 필터를 필요로 한다.
marking	dsmark qdisc가 marking에 사용된다.

간단히 말하면 qdisc는 스케쥴러이다. (Section 3.2). 모든 송신 인터페이스는 어떤 종류의 스케쥴러를 필요로한다. 기본 스케쥴러는 FIFO이다. 리눅스 상에서 사용 가능한 다른 qdisc 는 스케쥴러의 큐에 들어오는 패킷을 스케쥴러의 규칙에 따라 재정렬한다.

qdisc는 리눅스 트래픽 컨트롤 구성의 핵심 요소이다. qdisc는 큐잉 규칙(queueing discipline)을 부르는 말이다.

classful qdisc는 클래스를 가지고 있다. 그리고 필터를 붙일 수 있는 핸들을 제공한다. 하위 클래스를 가지고 있지 않은 classful qdisc를 사용하는 것을 금지하지 않는다. 하지만 보통 이것은 이득없이 시스템의 자원을 소비하게 된다.

class 없는 qdisc는 클래스를 가지고 있지 않다. 또 필터를 붙이는 것도 불가능하다. The classless qdiscs can contain no classes, nor is it possible to attach filter to a classless qdisc. Because a classless qdisc contains no children of any kind, there is no utility to classifying. This means that no filter can be attached to a classless qdisc.

A source of terminology confusion is the usage of the terms root qdisc and ingress qdisc. These are not really queuing disciplines, but rather locations onto which traffic control structures can be attached for egress (outbound traffic) and ingress (inbound traffic).

Each interface contains both. The primary and more common is the egress qdisc, known as the root qdisc. It can contain any of the queuing disciplines (qdiscs) with potential classes and class structures. The overwhelming majority of documentation applies to the root qdisc and its children. Traffic transmitted on an interface traverses the egress or root qdisc.

For traffic accepted on an interface, the ingress qdisc is traversed. With its limited utility, it allows no child class to be created, and only exists as an object onto which a filter can be attached. For practical purposes, the ingress qdisc is merely a convenient object onto which to attach a policer to limit the amount of traffic accepted on a network interface.

In short, you can do much more with an egress qdisc because it contains a real qdisc and the full power of the traffic control system. An ingress qdisc can only support a policer. The remainder of the documentation will concern itself with traffic control structures attached to the root qdisc unless otherwise specified.

Classes only exist inside a classful qdisc (e.g., HTB and CBQ). Classes are immensely flexible and can always contain either multiple children classes or a single child qdisc 1. There is no prohibition against a class containing a classful qdisc itself, which facilitates tremendously complex traffic control scenarios.

Any class can also have an arbitrary number of filters attached to it, which allows the selection of a child class or the use of a filter to reclassify or drop traffic entering a particular class.

A leaf class is a terminal class in a qdisc. It contains a qdisc (default FIFO) and will never contain a child class. Any class which contains a child class is an inner class (or root class) and not a leaf class.

The filter is the most complex component in the Linux traffic control system. The filter provides a convenient mechanism for gluing together several of the key elements of traffic control. The simplest and most obvious role of the filter is to classify (see Section 3.3) packets. Linux filters allow the user to classify packets into an output queue with either several different filters or a single filter.

A filter must contain a classifier phrase.

A filter may contain a policer phrase.

Filters can be attached either to classful qdiscs or to classes, however the enqueued packet always enters the root qdisc first. After the filter attached to the root qdisc has been traversed, the packet may be directed to any subclasses (which can have their own filters) where the packet may undergo further classification.

Filter objects, which can be manipulated using tc, can use several different classifying mechanisms, the most common of which is the u32 classifier. The u32 classifier allows the user to select packets based on attributes of the packet.

The classifiers are tools which can be used as part of a filter to identify characteristics of a packet or a packet's metadata. The Linux classfier object is a direct analogue to the basic operation and elemental mechanism of traffic control classifying.

This elemental mechanism is only used in Linux traffic control as part of a filter. A policer calls one action above and another action below the specified rate. Clever use of policers can simulate a three-color meter. See also Section 10.

Although both policing and shaping are basic elements of traffic control for limiting bandwidth usage a policer will never delay traffic. It can only perform an action based on specified criteria. See also Example 5.

This basic traffic control mechanism is only used in Linux traffic control as part of a policer. Any policer attached to any filter could have a drop action.

There are, however, places within the traffic control system where a packet may be dropped as a side effect. For example, a packet will be dropped if the scheduler employed uses this method to control flows as the GRED does.

Also, a shaper or scheduler which runs out of its allocated buffer space may have to drop a packet during a particularly bursty or overloaded period.

모든 클래스와 클래스 있는 qdisc는 트래픽 컨트롤 구조 안에서 유일한 identifier가 필요하다. 이 유일한 identifier를 핸들이라고 부른다. 핸들은 주번호와 부번호라고 불리는 두개의 숫자로 되어있다. 이 숫자들은 다음 규칙에 따라 사용자가 마음대로 할당할 수 있다.

클래스(class)와 큐잉규칙(qdisc)의 핸들에 번호 붙이기

주 번호 주번호는 커널로부터 자유롭게 붙일 수 있다. 사용자는 임의의 숫자를 사용할 수 있다. 하지만 같은 부모를 가진 트래픽 컨트롤의 모든 objects들은 하나의 주번호를 사용해야한다. 일반적으로는 root qdisc에 직접 붙은 object는 1부터 시작해서 숫자를 붙인다.

부 번호 This parameter unambiguously identifies the object as a qdisc if minor is 0. Any other value identifies the object as a class. All classes sharing a parent must have unique minor numbers.

The special handle ffff:0 is reserved for the ingress qdisc.

The handle is used as the target in classid and flowid phrases of tc filter statements. These handles are external identifiers for the objects, usable by userland applications. The kernel maintains internal identifiers for each object.