[컴퓨터 네트워크] 5. Performance (loss, delay, throughput)

패킷과 큐

하나의 라우터로 들어오는 패킷은 여러 종류가 있을 수 있다.

이때 라우터는 패킷을 들어오는 순서대로 처리하기 위해 큐에 패킷을 보관한다.

물리적으로는 라우터의 버퍼에 보관하는 것과 같다. (라우터도 일종의 컴퓨터라고 생각하면 된다.)

 

이 버퍼의 크기는 당연히 물리적으로 제한이 있다.

따라서 패킷이 전송되는데 걸리는 시간(transmission delay) 에 비해 라우터로 패킷이 들어오는 시간이 더 빠르다면 큐에는 전송을 기다리는 패킷들이 차곡차곡 쌓이게 된다. (queueing delay)

이때 패킷들이 가득차서 라우터의 버퍼 크기를 넘어서게 되면, 그때부터 도착하는 패킷들은 저장되지 못해 버려진다.

이를 Loss, 손실이 발생하였다고 표현한다.

 

Packet Delay

지금까지의 내용을 토대로 패킷하나가 목적지까지 전송되는데 걸리는 시간을 계산해보자.

이 시간은 아래와 같이 계산할 수 있다.

 

Packet Delay (Nodal Delay)

= process delay + queueing delay + transmission delay + propagation delay

 

process delay : 라우터 내에서 패킷을 처리하는 시간 (비트 에러 검사, output link 결정). microsec 미만의 빠른 시간

 

queueing delay : 패킷에 큐에 들어갔다가 전송될 차례가 될 때까지 기다리는 시간. 혼잡도에 따라 필요한 시간이 다르다.

 

transmission delay : 패킷의 모든 데이터가 링크에 들어가는 시간 (L = packet length / R = transmission rate )

 

propagation delay : 첫번째로 들어간 데이터가 처음으로 나오는데까지 걸리는 시간

(d = link length / s = propgation speed) 전파 속도는 link의 물리적 매체 종류에 따라 다르며, 광선이 제일 빠르다.

 

Example

요금소를 통과하는 10대의 자동차가 있다고 해보자.

요금소와 요금소 사이의 거리는 100km 이고, 요금소는 총 3개가 있다.

(각 자동차는 1bit를 의미하며, 10대의 자동차는 총 10-bit 패킷을 의미한다.)

 

1. 이때 요금소에서 자동차 한대의 요금을 계산하는데 12초의 시간이 걸리고, 자동차는 고속도로에 들어가자마자 시속 100km 의 속도로 달린다고 하자.

 

10대의 자동차가 현재 요금소를 지나 다음 요금소로 가는데 걸리는 시간은 아래와 같이 계산할 수 있다.

 

10대의 자동차가 모두 고속도로로 들어가는데 걸리는 시간 = 12초 * 10 = 120초 (=2분)

한 대의 자동차가 다음 톨게이트까지 가는데 걸리는 시간 = 60분

 

따라서 10대의 자동차가 모두 고속도로를 지나 마지막 차가 다음 요금소에 도차하는데 걸리는 시간은 62분이다.

---

2. 이번에는 요금소에서 자동차 한대의 요금을 계산하는데 1분의 시간이 걸리지만, 고속도로는 1000km/h 의 속도로 달린다고 해보자.

 

이 경우 모든 자동차가 다음 요금소에 도착할 때까지 필요한 시간은 아래와 같이 계산할 수 있다.

 

10대의 자동차가 모두 고속도로로 들어가는데 걸리는 시간 = 1분 * 10 = 10분

한대의 자동차가 다음 톨게이트까지 가는데 걸리는 시간 = 6분

 

따라서 총 16분의 시간이 필요하다.

한 가지 재미있는점은, 첫번째차가 목적지에 도착하는데 걸리는 시간이 7분이기 때문에,

첫번째 차가 도착해도 아직 요금소를 통과하지 못한 차가 3대나 남아있다는 것이다.

 

즉, 이 상황은 queueing delay가 propagation delay 보다 더 큰 상황이다.

---

Packet Queueing Delay

Queueing Delay는 아래와 같이 계산한다.

 

a = average packet arrival rate

L = packet length

R = link bandwidth (transmission rate)

 

L · a / R

 

a 는 큐에 몇개의 패킷이 평균적으로 도착하는 지를 나타낸다.

L 은 도착한 패킷의 길이

R 은 대역폭이다.

 

L / R 은 transmission delay 이므로, 이 식은 transmission delay L/R 만큼 있는 상태에서 평균적으로 몇 개의 패킷이 큐로 들어오고 있는지를 계산한다.

 

a · L 은 단위 시간당 도착하는 총 bit 수이고, R 은 단위 시간당 한번에 빠져나갈 수 있는 비트의 수이다.

 

따라서 이 값이 0에 가까울 수록 queueing delay는 매우 적고, 1에 가까울 수록 queueing delay는 지수적으로 증가한다.

이 값이 1보다 크다면 queue에는 데이터가 무한히 쌓이게 되어 queueing delay는 무한대가 된다.

 

이 값을 trafifc intensity (밀집도) 라고 말한다.

 

언뜻 생각하면, R 값과 a · L 값이 같으면 그때까지는 delay가 없는 것 아니냐고 생각할 수 있다.

하지만 실제로는 들어온 bit가 어디로 나가야하는지 결정하는 process delay까지 고려해야 하기 때문에 기다리는 시간이 생긴다.

 

이를 확률적으로 증명한 것이 queueing 이론이다. 이 이론에 따르면 traffic intensity가 1에 가까워질 수록 Queueing Delay가 기하급수적으로 증가하는 것을 볼 수 있다.

따라서 만약 내가 회사의 네트워크 담당자라면 회사의 트래픽이 100일 때 최소한 130의 대역폭을 가진 네트워크를 설계해야 문제없이 서비스를 이용할 수 있다.

 

실제 인터넷 Delay 측정

지금까지 이야기한 이론과 달리, 실제 인터넷 지연 시간을 측정할 때는 traceroute 라는 프로그램을 사용한다.

이 프로그램은 source 컴퓨터와 destination 컴퓨터 사이의 지연 시간을 측정하는 프로그램이다.

이 프로그램은 말 그대로 어떤 라우터를 통과하여 목적지까지 가는지를 확인하므로 구체적인 패킷의 이동 경로를 알 수 있고, 각 경로마다 얼만큼의 딜레이가 걸리는지를 알 수 있으므로 네트워크가 느리다면 어디에서 병목현상이 발생하는지를 검출할 수 있다.

 

구체적인 작동 원리는 아래와 같다.

ICMP (Internet Control Message Protocol) 을 사용하여 3개의 패킷을 라우터로 보낸다.

이 3개 패킷이 라우터에 도착하는 시간의 평균값을 필요한 시간으로 계산한다.

 

패킷을 보낼 때는, 이 패킷이 유효한 시간을 의미하는 TTL 값을 패킷 헤더에 같이 담아 보낸다.

이 값은 '시간' 의 개념이 아닌 '홉 카운트'의 개념으로 유효 시간을 계산한다.

(홉은 라우터와 라우터 사이를 1 홉이라고 한다.)

그래서 라우터는 패킷을 받으면 이 패킷의 TTL 값을 1 감소시키고, 그 결과값이 0이라면 패킷을 다른 곳에 전송하지 않고 자신이 처리한 다음 버리게 된다.

 

원래 이 값은 목적지를 찾지 못한 패킷이 정처없이 떠돌면서 네트워크 상에 남아있는 것을 방지하기 위해 만들었다.

그런데 traceroute 프로그램은 이를 이용해서 라우터의 경로를 추적한다.

 

먼저 TTL = 1 인 값으로 목적지에 패킷을 전송한다.

그러면 이 패킷은 첫번째 라우터에 도착한 뒤, 다음 라우터로 가지 못하고 버려진다.

그러면 라우터는 다음 목적지로 패킷을 보내지 못하는 것을 '에러'로 간주하고 이 패킷을 전송한 Source 에게 에러를 알려준다. 이 에러 메세지에는 에러 메세지를 보낸 송신자 정보가 담겨있으므로, Source는 첫번째 라우터의 정보와 그 라우터에 데이터를 보내고 받기 까지의 시간을 알 수 있다.

 

이를 TTL = 2, TTL = 3 씩 계속 늘려가면서 목적지에 도착할 때까지 시도한다.

만약 TTL의 값이 딱 목적지에 도착할 만큼 설정되면, Destination은 TTL 값을 감소시킨 뒤 0이 된 것을 보고 자신에게 도착한 패킷이라고 확인해서 버리지 않고 수신한다. (즉, 에러가 발생하지 않는다!)

이 경우, source는 목적지 직전의 라우터까지의 정보만 알 수 있고, 목적지의 정보는 알 수 없는 문제가 있다.

따라서 강제로 에러를 발생시키기 위해 목적지 컴퓨터가 열지 않은 port 번호를 지정하여 전송한다.

이렇게 발생한 에러는 source 컴퓨터에게 전송되고, 이 시간을 반으로 나눠 destination 컴퓨터까지의 대략적인 전송 시간을 파악한다.

그리고 모든 중간 라우터까지의 전송시간을 파악하고 있기 때문에 임의 두 지점 사이의 전송시간도 계산할 수 있다.

 

Packet Loss

큐는 라우터라고 하는 장비의 한정된 저장공간(버퍼)으로 실제로 전송이 이루어질 link 앞단에 위치하고 있다.

라우터는 자신에게 들어온 패킷을 큐에 넣어두고 먼저 들어온대로 하나씩 처리하여 다시 목적지로 내보낸다.

그런데 만약 큐가 내보내는 데이터보다 큐에 들어오는 데이터가 더 많다면 큐에는 점점 데이터가 쌓여서 결국 꽉 찰 것이다.

이 상태에서는 새로 들어오는 패킷을 버릴 수 밖에 없어 lost, 손실이 발생한다.

이 경우 보통은 source 컴퓨터에서 재전송을 시도한다. (이전 노드가 재전송하는 것도 이론적으로 가능하지만, 보통 이전 노드는 라우터일텐데, 라우터가 자기가 보낸 패킷이 잘 도착했는지 신경쓰는 것은 효율적이지 않다. 보내고 잊는 것이 더 단순하고 성능이 좋다.)

또는 UDP 같은 프로토콜을 사용하는 경우, 재전송하지 않고, 보내지 못한 데이터는 무시하기도 한다. (동영상 스트리밍)

 

 

Throughput

스루풋은 우리가 성능을 체감하는 핵심 요소로, 단위 시간당 몇 bit 의 데이터가 전송되는지를 의미한다.

스루풋은 크게 2가지로 구분할 수 있다.

 

첫번재는 instantaneous, 특정 시점에서의 전송률이다.

두번째는 average, 전체 출발과 도착관점에서의 평균 스루풋이다.

 

보통은 평균을 낸 관점에서 많이 이야기한다.

 

예를 들어 서버가 클라이언트에게 데이터를 전송하는데, 중간에 라우터가 하나 있어 2개의 링크를 거친다고 하자.

서버에서 라우터까지의 링크는 Rs bit / s 의 전송률을 갖고 있고, 라우터에서 클라이언트까지의 링크는 Rc bit / s 의 전송률을 갖고 있다.

 

이때 만약 Rs < Rc 라면 많은 양의 데이터가 왔을 때 Rs 에서 병목현상이 발생할 수 밖에 없고, Rs가 전체 데이터 전송의 성능을 결정하는 핵심 요소가 될 것이다. 결국 이 전체 링크를 통해 보낼 수 있는 최대 전송량은 Rs 이기 때문이다.

 

만약 반대로 Rs > Rc 라면 많은 양의 데이터가 왔을 때 결국 Rc 를 넘어서는 양의 데이터를 보낼 수는 없으므로 이번엔 Rc가 성능을 결정하는 핵심요소, 병목현상이 발생하는 곳이 될 것이다.

 

이번엔 다른 경우를 생각해보자.

10개의 서버가 10개의 클라이언트에 각각 데이터를 보낸다고 하자.

이 때 중간에 R bit / s  의 큰 링크를 모든 서버가 공유하여 통과 해야 한다.

각 서버는 모두 Rs 의 동일한 링크를 가지고 있고, 큰 링크를 통과한 뒤에는 모두 Rc의 동일한 링크를 통해 클라이언트에 데이터를 전송한다.

 

이때 한번에 보낼 수 있는 데이터의 최대 비트값은 min ( Rs, Rc, R / 10) 이된다.

R 이라는 큰 링크를 최대 10개의 서버가 나눠서 사용할 수 있기 때문이다.