Traffic Control 정리

네트워크는 환경은 다양하다.

개발당시 테스트했던 환경보다 대역폭이 좁을수도 있고.

처리 지연율이 낮을 수도 있다.

그렇기 때문에 실제 상황에서는

개발 테스트에서 일어나지 않았던 문제들이 발생 하기도 한다.

이러한 상황을 전부 고려할 수 없겠지만, 

실제 환경을 가정하여 네트워크성능을 측정하는것은 반드시 필요하다.

1. TC(Traffic Control)란? TC는 사용자로 하여금 네트워크의 Queue와 Queuing 매커니즘을 제어 할 수 있도록 하는 도구이다.

라우터에는 패킷을 수신 및 전송하는 대기열 처리 시스템과 매커니즘 경합이 있다. 

이것을 Traffic Control이라고 한다.

Traffic Control은 일반적으로 FIFO를 사용한다. (하나의 대기열에서 패킷을 수집하고 수집한 패킷을 대기열에서 제거한다)


TC는인터페이스의 패킷 Input와 Output에서 패킷의 송수신 속도와 순서를 결정 할 수 있다.

 

웹서버와 PC가 동일한 링크를 공유하는 경우 대역폭 경쟁이 발생 할 수 있다.

웹서버는 전송되는 것 보다 빠르게 출력 Queue를 채울 수 있다.

버퍼가 꽉차서 라우터가 패킷을 삭제하면

PC는(응용SW) Packet loss가 발생하고 전송지연이 길어지게 된다

이때 두 개의 클래스로 내부 대기열을 분리하면 두 개의 응용 프로그램이 원활하게 network 자원을 공유 할 수 있다.

 

정리하자면 TC는 사용자로 하여금 네트워크의 Queue와 Queuing 매커니즘을 제어 할 수 있도록 하는 도구이다.

(Qos와 traffic control은 동의어)

 

2. Traffic Control을 고려해야 하는 경우

- 총 대역폭 제한 TBF, HTB with child class

- 특정 사용자, 서비스 또는 client의 대역폭 제한 HTB classes / classifying with filter

- 비대칭 링크에서 TCP 처리량 극대화, ACK 패킷의 전송 우선순위 지정

- 네트워크 리소스를 보다 균등하게 분배 할 수 있다.


3. Queue란? 


큐는 스케쥴링의 핵심 개념이다.

처리되기를 기다리는 작업 혹은 서비스가 포함되어 있다.

네트워크에서 큐는 패킷이 HW(서비스)에 의해 전송되기를 기다리는 장소이다.

어떠한 메커니즘이 없으면, 큐는 트래픽 제어에 의해 아무것도 하지 않는다.

(어떠한 매커니즘이란, 패킷을 지연시키거나 재배열하거나 삭제 혹은 여러 대기열에서 패킷의 우선순위를 정하는 것.)


큐는 서브큐를 사용 할 수도 있지만 스케쥴링 작업을 복잡하게 한다.


#flow

flow는 호스트간 연결 또는 대화이다. TCP에서 연결개념, UDP도 비슷


TC매커니즘은 트래픽을 클래스로 집계하고 flow class도 트래픽을 분리합니다.(개개의 flow에 기초하여 균등하게 대역폭을 분할하기 위해)


4. 토큰, 버킷

큐에서 제어속도를 제어하기 위해 구현한 방법.

각 항목이 대기열에서 제외 될 때, 대기열에서 삭제 된 패킷수를 제한 할 수 있다.


하지만 타이머와 측정을 복잡하게 사용해서 재현해야 하기 때문에

현재 사용량과 시간을 계산하는 대신, TC에서 널리 사용하는 방법은

" 원하는 속도로 토큰을 생성, 토큰이 사용가능한 경우에만 패킷이나 바이트를 대기열에서 제외한다"

예를들면 일정시간마다 트랙을 출발하는 놀이기구를 생각해보자.

카트는 일정시간마다 대기열에 도차갛고, 사람들은 차례를 기다려야 한다.

이때 카트를 토큰으로 생각하고 사람을 패킷으로, 버킷을 사용가능한 카트에 비유를 하자면

버킷은 HTTP와 같이 burst traffic을 지원하는 개념이다.


토큰은 일정 비율로 생성되고 버킷의 상당수는 수집 될 수 있다.

이로써 burstry traffic을 처리 할 수 있고 원활한 네트워크 트래픽 처리를 도와준다.


#. 패킷/ 프레임

프레임은 실제로 트래픽 제어가 수행되는 단위이다.


#. shaping

shaper는 원하는 비율로 패킷을 지연시킨다.

(패킷이 출력 대기열에서 전송되기 전에 지연된다.)

shaper는 트래픽을 제한하거나 배분하여 구성된 속도(초당 패킷 비트/bytes)를 초과하지 않게 한다.

하지만 sideeffect로 오히려 burst traffic을 원활하게 처리 할수 있게된다.


패킷의 대기시간 제어

비율 혈성 매크니즘 - 토큰 및 버킷 매커니즘


#. 스케쥴러 

출력을 위해 패킷을 정렬/ 재정렬. FIFO 많이 씀

다른 스케쥴링 방식은 SFQ 가 있다. = 단일 client나 flow가 네트워크를 독점사용하지 않는다.

WRR = 각 flow나 client가 패킷을 큐에서 꺼내는 순서를 제공한다.


#.class

classifier는 트래픽을 queue에 정렬 분리한다.

서로다른 처리를 위해 패킷을 분리하는 매커니즘이다.

network device는 다른방식으로 패킷을 분류 할 수 있다.


#.policy

policy는 특정 queue의 트래픽을 측정하고 제한한다.

- 할당된 대역폭 보다 이상을 소비하지 않도록 제한한다.

- 특정 비율로 트래픽을 수용 한 후, 일정 비율을 초고화는 트래픽에 대해 정책에 따라 관리 할 수 있다(버리거나 reclassify)

- 주어진 속도(bandwidth) 초과 미만에 해당하는 패킷에 대해 어떤 action을 취할지 결정해야 한다.

< token bucket 메커니즘을 쓰지만 shaping처럼 패킷 지연 x >


#. qdisc

classful qdisc에는(class가 있는) class가 포함 될 수 있고 filter를 attach 할 수 있는 핸들을 제공한다.

- classless qdisc에는 class를 포함 할 수 없다. 필터를 ㄹ연결 할 수도 없다.


root qdisc / ingress qdisc는 실제로 queue가 아니라 출구(out bound traffic)와 입구(in bound traffic)에 대한 트래픽으 ㄹ제어 할 수 있는 것이다.


- 각 인터페이스에는 둘다 있다. 하지만 root를 많이 씀.


- 인터페이스에서 전송되는 트래픽은 egress나 root qdisc를 거친다

- ingress qdisc를 조작하려면 policer 쓰라.