다른 명령
편집 요약 없음 |
편집 요약 없음 |
||
| 13번째 줄: | 13번째 줄: | ||
* d<sub>trans</sub>는 '''패킷의''' '''모든 bits를 link로 전송하는데 걸리는 시간'''이다. 즉, 패킷의 크기가 L bit라고 하고 link의 전송 속도를 R bits/sec라고 하면 다음과 같이 계산된다. | * d<sub>trans</sub>는 '''패킷의''' '''모든 bits를 link로 전송하는데 걸리는 시간'''이다. 즉, 패킷의 크기가 L bit라고 하고 link의 전송 속도를 R bits/sec라고 하면 다음과 같이 계산된다. | ||
** <code>d<sub>trans</sub> = L/R</code> | ** <code>d<sub>trans</sub> = L/R</code> | ||
* d<sub>prop</sub>은 propagation delay라고 불리며, link에서 실제로 데이터가 이동하는 속력에 따른 지연을 | * d<sub>prop</sub>은 propagation delay라고 불리며, link에서 '''실제로 데이터가 이동하는 속력에 따른 지연을 의미'''한다. 통상적으로 데이터는 link에서 광속으로 이동하므로 해당 지연시간은 매우 짧아 종종 무시된다. 그럼에도 physical link의 길이를 d라고 하고, data의 속도<ref>propagation speed</ref>를 s라고 해 propagation delay을 구하면 다음과 같이 수식이 도출된다. | ||
** <code>d<sub>prop</sub> = d/s</code> | ** <code>d<sub>prop</sub> = d/s</code> | ||
| 39번째 줄: | 39번째 줄: | ||
==Queueing delay and loss== | ==Queueing delay and loss== | ||
Queueing delay의 중요한 특징 중 하나는 다른 세가지 지연과는 다르게 패킷마다 다르게 나타난다는 | '''Queueing delay의 중요한 특징 중 하나는 다른 세가지 지연과는 다르게 패킷마다 다르게 나타난다는 것'''이다. 예를 들어, 만약 10개의 패킷이 한꺼번에 비어 있는 대기열에 도착한다면, 첫 번째로 전송되는 패킷은 대기열 지연을 전혀 겪지 않는다. 하지만 마지막으로 전송된 패킷은 앞의 9개 패킷이 전송될 때까지 기다려 상당한 대기열 지연을 겪는다. | ||
queueing delay는 다음 요소들에 의해 결정된다. | queueing delay는 다음 요소들에 의해 결정된다. | ||
| 55번째 줄: | 55번째 줄: | ||
* <math>\frac{a \cdot L}{R} \le 1</math> | * <math>\frac{a \cdot L}{R} \le 1</math> | ||
** 각 패킷이 L/R초마다 하나씩 도착하는 경우<ref>a=R/L</ref>, 각 패킷이 도착할 때마다 대기열이 비어 있으므로, 대기열 지연은 0이다. | ** 각 패킷이 L/R초마다 하나씩 도착하는 경우<ref>a=R/L</ref>, 각 패킷이 도착할 때마다 대기열이 비어 있으므로, 대기열 지연은 0이다. | ||
** 패킷이 N개씩 주기적으로 도착하지만 이것이 (L/R)N 초마다 반복되는 경우는 첫 패킷의 queueing delay는 0이고, 두번째 패킷의 delay는 L/R이고, N번째 패킷의 dlelay는 (n-1)L/ | ** 패킷이 N개씩 주기적으로 도착하지만 이것이 (L/R)N 초마다 반복되는 경우는 첫 패킷의 queueing delay는 0이고, 두번째 패킷의 delay는 L/R이고, '''N번째 패킷의 dlelay는 (n-1)L/R'''이다. | ||
[[파일:Queueing delay graph.png|섬네일|300x300픽셀|Figure 2. Queueing delay as traffic intensity grows.]] | [[파일:Queueing delay graph.png|섬네일|300x300픽셀|Figure 2. Queueing delay as traffic intensity grows.]] | ||
하지만 실제로는 패킷은 주기적으로 도착하지 않고 무작위하게 도착하며 일정한 패턴을 따르지 않는다. 즉 단순히 L⋅a/RL⋅a/R 값만으로 대기열 지연을 완전히 설명할 수 없고 직관적으로 대기열 지연의 경향을 이해하는 데 사용할 수 있다. | 하지만 실제로는 패킷은 주기적으로 도착하지 않고 무작위하게 도착하며 일정한 패턴을 따르지 않는다. 즉 단순히 L⋅a/RL⋅a/R 값만으로 대기열 지연을 완전히 설명할 수 없고 직관적으로 대기열 지연의 경향을 이해하는 데 사용할 수 있다. | ||
| 63번째 줄: | 63번째 줄: | ||
** 순간적으로 arrival rate가 transmission rate를 초과하는 구간이 존재할 수 있다. 이 경우, queue가 점점 길어졌다가, 다시 줄어드는 패턴이 반복된다. | ** 순간적으로 arrival rate가 transmission rate를 초과하는 구간이 존재할 수 있다. 이 경우, queue가 점점 길어졌다가, 다시 줄어드는 패턴이 반복된다. | ||
** traffic intensity가 증가함에 따라 평균적으로 대기열 길이는 figure 2와 같이 점점 증가하게 된다. | ** traffic intensity가 증가함에 따라 평균적으로 대기열 길이는 figure 2와 같이 점점 증가하게 된다. | ||
또한 실제로는 queue의 크기가 | 또한 실제로는 '''queue의 크기가 유한하므로 traffic intensity가 1에 가까워지더라도 패킷 지연 시간이 실제로 무한대로 증가하지는 않는다.''' 대신, 패킷이 도착했을 때 대기열이 가득 차 있을 수 있다. 이 경우 패킷을 '''저장할 공간이 없으므로,''' 라우터는 해당 '''패킷을 drop'''한다.<ref>이때 drop되는 패킷은 다양한 기준에 의해서 선정된다. 예를 들면 가장 늦게 들어온 패킷이 drop되거나, 혹은 가장 낮은 priority를 지니는 패킷이 drop된다.</ref> 즉, 패킷이 손실된다(packet loss). 이렇게 '''패킷이 drop'''될 정도로 traffic intensity가 높은 상황을 '''traffic congestion'''이라고 한다. 이 경우 drop된 패킷은 다시 재전송된다. | ||
==Throughput== | ==Throughput== | ||
throughput이란 단위 시간 동안 네트워크를 통해 sender와 receiver 사이에서 전달된 데이터의 | throughput이란 '''단위 시간 동안 네트워크를 통해 sender와 receiver 사이에서 전달된 데이터의 양'''을 의미한다. 보통 단위로 bps(bit per second)를 사용한다. | ||
즉, sender가 receiver에 F bits크기의 file을 보내는데 T만큼의 전송시간이 걸렸다면 Throughput은 다음과 같이 계산된다. | 즉, sender가 receiver에 F bits크기의 file을 보내는데 T만큼의 전송시간이 걸렸다면 Throughput은 다음과 같이 계산된다. | ||
| 74번째 줄: | 74번째 줄: | ||
===bottleneck link=== | ===bottleneck link=== | ||
bottleneck link란 end-end path 내에서 end-end의 throughput을 결정짓는 | '''bottleneck link란 end-end path 내에서 end-end의 throughput을 결정짓는 link'''를 의미한다. 다음 예시를 통해 이를 더욱 잘 이해할 수 있다. | ||
[[파일:Bottleneck.png|섬네일|300x300픽셀| | [[파일:Bottleneck.png|섬네일|300x300픽셀|FIgure 3. Bottleneck link in simple network]] | ||
클라이언트와 서버가 라우터 하나와 두 개의 link를 통해 연결된 네트워크 내에서 서버에서 클라이언트로 파일을 전송하는 경우의 처리량을 분석해보자. 이때 R<sub>s</sub>는 서버에서 라우터까지의 link 속도에 해당하고, R<sub>c</sub>는 라우터에서 클라이언트까지의 link 속도를 의미한다. 이때, 네트워크 전체에서 서버에서 클라이언트로 전송되는 데이터만 있다고 가정하자. 이때 서버에서 클라이언트까지의 처리량은 다음의 특성을 통해 구할 수 있다. | 클라이언트와 서버가 라우터 하나와 두 개의 link를 통해 연결된 네트워크 내에서 서버에서 클라이언트로 파일을 전송하는 경우의 처리량을 분석해보자. 이때 R<sub>s</sub>는 서버에서 라우터까지의 link 속도에 해당하고, R<sub>c</sub>는 라우터에서 클라이언트까지의 link 속도를 의미한다. 이때, 네트워크 전체에서 서버에서 클라이언트로 전송되는 데이터만 있다고 가정하자. 이때 서버에서 클라이언트까지의 처리량은 다음의 특성을 통해 구할 수 있다. | ||
* 서버는 R<sub>s</sub> bps 이상의 속도로 데이터를 보낼 수 없다. | * 서버는 R<sub>s</sub> bps 이상의 속도로 데이터를 보낼 수 없다. | ||
| 84번째 줄: | 84번째 줄: | ||
* 반대로, Rc < Rs 라면, 라우터는 수신하는 데이터보다 느리게 전송해야 하므로 병목 현상이 발생한다. | * 반대로, Rc < Rs 라면, 라우터는 수신하는 데이터보다 느리게 전송해야 하므로 병목 현상이 발생한다. | ||
** throughput = R<sub>c</sub> | ** throughput = R<sub>c</sub> | ||
즉, 이 단순한 네트워크의 처리량은 min(R<sub>s</sub>, R<sub>c</sub>)가 된다. 즉, 네트워크의 bottleneck link의 전송 속도가 전체 처리량을 | [[파일:Bottlenet multi link.png|섬네일|250x250px|Figure 4. 공유 링크가 있는 network]] | ||
즉, 이 단순한 '''네트워크의 처리량은 min(R<sub>s</sub>, R<sub>c</sub>)'''가 된다. 즉, 네트워크의 '''bottleneck link의 전송 속도가 전체 처리량을 결정'''한다. | |||
이번에는 10개의 서버와 10개의 클라이언트가 인터넷 코어에 연결되어 있는 경우를 살펴보자. 이 예제에서는 10개의 다운로드가 동시에 진행되고 있으며, 네트워크의 다른 트래픽은 없다. 이때 R<sub>s</sub>는 서버에서 라우터까지의 link 속도에 해당하고, R<sub>c</sub>는 라우터에서 클라이언트까지의 link 속도를 의미한다. 또한 특정 공유 link의 속도가 R이며 이 공유 link는 10개의 다운로드가 모두 통과해야 하는 공통 경로이다. | 이번에는 10개의 서버와 10개의 클라이언트가 인터넷 코어에 연결되어 있는 경우를 살펴보자. 이 예제에서는 10개의 다운로드가 동시에 진행되고 있으며, 네트워크의 다른 트래픽은 없다. 이때 R<sub>s</sub>는 서버에서 라우터까지의 link 속도에 해당하고, R<sub>c</sub>는 라우터에서 클라이언트까지의 link 속도를 의미한다. 또한 특정 공유 link의 속도가 R이며 이 공유 link는 10개의 다운로드가 모두 통과해야 하는 공통 경로이다. | ||
* 각각의 연결에 대한 end-end throughput은 min(R<sub>s</sub>, R<sub>c</sub>, R/10)에 해당한다. | * 각각의 연결에 대한 end-end throughput은 min(R<sub>s</sub>, R<sub>c</sub>, R/10)에 해당한다. | ||
| 94번째 줄: | 95번째 줄: | ||
==각주== | ==각주== | ||
[[분류:컴퓨터 네트워크]] | [[분류:컴퓨터 네트워크]] | ||
<references /> | |||
2025년 4월 18일 (금) 14:17 기준 최신판
상위 문서: 컴퓨터 네트워크
개요
네트워크에서 성능을 측정하는 주요한 요소는 delay와 packet loss, 그리고 throughput이다.
Delay and loss in networks
이상적인 네트워크 통신에서는 데이터가 손실 없이 무제한으로 즉시 전송될 수 있어야 하지만, 실제로는 물리적 한계와 네트워크 제약으로 인해 현실적으로 불가능하다. 실제 네트워크에서는 처리량(throughput) 제한, 지연(delay) 발생, 패킷 손실(packet loss)이 발생한다. 이때 패킷이 source(src)에서 destination(dst)까지 이동에서는 다양한 유형의 delay(지연)가 발생하며, 이를 모두 합친 지연 시간을 total nodal delay라고 한다. total nodal delay를 구하는 수식은 다음과 같다.
[math]\displaystyle{ d_{nodal} = d_{proc} + d_{queue} + d_{trans} + d_{prop} }[/math]
다음은 위 delay들에 대한 설명이다.
- dproc은 processing delay라고 불리며, 패킷의 헤더와 error를 검사하고 이를 어느 link로 보낼지 등을 결정하는 데 걸리는 시간이다. 통상적으로 processing delay는 전체 지연시간 중에서 매우 작은 비중을 차지하기 때문에 종종 무시된다.
- dqueue delay는 queueing delay이라고 불리며, 패킷이 link로 전송되지 않고 라우터 내의 queue에 저장되어 있을때 발생한다. 이는 outbound link의 bandwidth가 해당 라우터 내로 진입하는 packet을 모두 동시에 송신하지 못할 만큼 크지 않을 때 발생한다.[1] 만약 queue가 비어있고 현재 전송 중인 다른 패킷이 없다면 dqueue delay는 0이다. 하지만 현재 traffic이 많고 이미 많은 패킷이 queue에서 대기하고 있다면 dqueue delay는 길어진다.
- dtrans는 패킷의 모든 bits를 link로 전송하는데 걸리는 시간이다. 즉, 패킷의 크기가 L bit라고 하고 link의 전송 속도를 R bits/sec라고 하면 다음과 같이 계산된다.
dtrans = L/R
- dprop은 propagation delay라고 불리며, link에서 실제로 데이터가 이동하는 속력에 따른 지연을 의미한다. 통상적으로 데이터는 link에서 광속으로 이동하므로 해당 지연시간은 매우 짧아 종종 무시된다. 그럼에도 physical link의 길이를 d라고 하고, data의 속도[2]를 s라고 해 propagation delay을 구하면 다음과 같이 수식이 도출된다.
dprop = d/s
first-byte delay란, 서버 응답 패킷의 맨 처음 바이트가 클라이언트에게 도착할 때까지의 지연 시간을 의미한다.
first-byte delay = propation delay + queueing delay + interface delay
Comparing transsmision delay and propagation delay
transsmision delay과 propagation delay는 구분하기 힘들지만 미묘한 차이를 가지고 있다. transsmision delay는 라우터가 패킷을 link에 밀어내는 데 걸리는 시간이며 이는 패킷의 길이와 link의 bandwidth에 의해서 결정된다. 즉, 두 라우터 사이의 거리와는 무관하다. 반면 propagation delay는 패킷의 bits가 두 라우터 사이에서 물리적으로 전송되는데 걸리는 시간이다. 이는 두 라우터 사이의 거리에 의해서 결정되며, 패킷의 크기나 link의 bandwidth와는 무관하다.
Caravan의 비유
위의 그림에서처럼 100km 간격으로 톨게이트가 있는 고속도로를 생각할 수 있다. 이때 톨게이트는 라우터, 고속도로는 link에 해당한다. 이때 다음상황을 가정하자.
- 이때 자동차는 고속도로에서 시속 100km의 속도로 이동(전파)한다.
- 즉, 자동차가 톨게이트를 떠날 때 즉시 시속 100km로 가속하여 다음 톨게이트까지 일정한 속도를 유지한다.
- 10대의 자동차가 일렬로 고정된 순서를 유지하며 이동한다.
- 여기서 각 자동차는 하나의 비트(bit), 전체 자동차 행렬(캐러밴, caravan)은 하나의 패킷(packet) 으로 비유할 수 있다.
- 각 톨게이트는 12초에 한 대의 자동차를 처리(전송) 한다.
- 첫 번째 자동차가 톨게이트에 도착하면, 뒤따르는 9대의 자동차가 도착하여 줄을 서기 전까지는 톨게이트에 진입하지 않는다.
- 즉, 전체 캐러밴(패킷)이 톨게이트에 도착하여 모두 저장된 후에야 출발 가능하다.
이때 전체 자동차 행렬이 두번째 톨게이트에 도착할 때까지 걸리는 시간은 톨게이트가 전체 캐러밴을 도로로 밀어내는 데 걸리는 시간과 톨게이트를 나온 자동차가 다음 톨게이트에 도착하는 데 걸리는 시간을 합하여 구할 수 있다. 즉, 다음과 같이 구해진다.
총 시간: 62분 톨게이트가 전체 캐러밴을 도로로 밀어내는 데 걸리는 시간(transmission delay): [math]\displaystyle{ \frac{10cars}{5car/min} = 2min }[/math] 톨게이트를 나온 자동차가 다음 톨게이트에 도착하는 데 걸리는 시간(propagation delay): [math]\displaystyle{ \frac{100km}{100km/h} = 60min }[/math]
자동차가 1000km/h로 더욱 빠르게 달린다면 propagation delay에 해당하는 시간은 6분에 불과하게 된다. 또한 톨게이트의 처리 속도가 1분에 1대의 차만을 처리한다고 가정하면 transmission delay에 해당하는 시간은 무려 10분이 된다. 이 경우, 첫번째 차가 출발하고 7분 후 첫 차는 두번째 톨게이트 앞에 도착하지만 세대의 차들은 여전히 첫번째 톨케이트도 통과하지 못한 상태이다. 이와 같은 상황은 패킷 교환 네트워크에서도 발생한다. 즉, 패킷의 첫 번째 비트가 다음 라우터에 도착했을 때, 여전히 많은 비트가 이전 라우터에서 전송되기를 기다리고 있을 수 있다.
Queueing delay and loss
Queueing delay의 중요한 특징 중 하나는 다른 세가지 지연과는 다르게 패킷마다 다르게 나타난다는 것이다. 예를 들어, 만약 10개의 패킷이 한꺼번에 비어 있는 대기열에 도착한다면, 첫 번째로 전송되는 패킷은 대기열 지연을 전혀 겪지 않는다. 하지만 마지막으로 전송된 패킷은 앞의 9개 패킷이 전송될 때까지 기다려 상당한 대기열 지연을 겪는다.
queueing delay는 다음 요소들에 의해 결정된다.
- a: queue에 packet이 평균적으로 도착하는 rate(packets/sec)
- L: 각 packet의 크기(bits)
- R: link bandwidth(bits/sec)
이때 traffic intensity는 다음과 같이 정의된다.
[math]\displaystyle{ traffic \,\, intensity = \frac{a \cdot L}{R} }[/math]
만약 queue가 매우 커서 사실상 무한한 수의 bits를 저장할 수 있다고 하면 [math]\displaystyle{ \frac{a \cdot L}{R} }[/math]값의 크기에 따라 queueing delay의 정도가 결정된다.
- [math]\displaystyle{ \frac{a \cdot L}{R} \gt 1 }[/math]
- 이는 대기열에 도착하는 비트의 평균 속도가 대기열에서 전송될 수 있는 비트 속도보다 크다는 것을 의미한다.
- 즉, 패킷이 도착하는 속도가 전송 속도보다 빠르므로 queue는 계속해서 증가하며, queueing delay또한 무한대로 커진다.
- [math]\displaystyle{ \frac{a \cdot L}{R} \le 1 }[/math]
- 각 패킷이 L/R초마다 하나씩 도착하는 경우[3], 각 패킷이 도착할 때마다 대기열이 비어 있으므로, 대기열 지연은 0이다.
- 패킷이 N개씩 주기적으로 도착하지만 이것이 (L/R)N 초마다 반복되는 경우는 첫 패킷의 queueing delay는 0이고, 두번째 패킷의 delay는 L/R이고, N번째 패킷의 dlelay는 (n-1)L/R이다.
하지만 실제로는 패킷은 주기적으로 도착하지 않고 무작위하게 도착하며 일정한 패턴을 따르지 않는다. 즉 단순히 L⋅a/RL⋅a/R 값만으로 대기열 지연을 완전히 설명할 수 없고 직관적으로 대기열 지연의 경향을 이해하는 데 사용할 수 있다.
- traffic intensity가 0에 가까울 때: 패킷이 도착하는 빈도가 낮기 때문에 대기열에 다른 패킷이 있을 가능성이 적다.
- 따라서 평균 대기열 지연은 거의 0에 가깝다.
- traffic intensity가 1에 가까울 때
- 순간적으로 arrival rate가 transmission rate를 초과하는 구간이 존재할 수 있다. 이 경우, queue가 점점 길어졌다가, 다시 줄어드는 패턴이 반복된다.
- traffic intensity가 증가함에 따라 평균적으로 대기열 길이는 figure 2와 같이 점점 증가하게 된다.
또한 실제로는 queue의 크기가 유한하므로 traffic intensity가 1에 가까워지더라도 패킷 지연 시간이 실제로 무한대로 증가하지는 않는다. 대신, 패킷이 도착했을 때 대기열이 가득 차 있을 수 있다. 이 경우 패킷을 저장할 공간이 없으므로, 라우터는 해당 패킷을 drop한다.[4] 즉, 패킷이 손실된다(packet loss). 이렇게 패킷이 drop될 정도로 traffic intensity가 높은 상황을 traffic congestion이라고 한다. 이 경우 drop된 패킷은 다시 재전송된다.
Throughput
throughput이란 단위 시간 동안 네트워크를 통해 sender와 receiver 사이에서 전달된 데이터의 양을 의미한다. 보통 단위로 bps(bit per second)를 사용한다. 즉, sender가 receiver에 F bits크기의 file을 보내는데 T만큼의 전송시간이 걸렸다면 Throughput은 다음과 같이 계산된다.
[math]\displaystyle{ throughput = \frac{F}{T} }[/math]
이때 throughput을 구할 때는 두가지 방식이 존재한다. intantaneous 방식은 랜덤한 시점에 해당 link의 throughput을 측정한다. average 방식은 장기간 동안 throughput을 측정하여 그 평균을 이용하여 구한다.
bottleneck link
bottleneck link란 end-end path 내에서 end-end의 throughput을 결정짓는 link를 의미한다. 다음 예시를 통해 이를 더욱 잘 이해할 수 있다.

클라이언트와 서버가 라우터 하나와 두 개의 link를 통해 연결된 네트워크 내에서 서버에서 클라이언트로 파일을 전송하는 경우의 처리량을 분석해보자. 이때 Rs는 서버에서 라우터까지의 link 속도에 해당하고, Rc는 라우터에서 클라이언트까지의 link 속도를 의미한다. 이때, 네트워크 전체에서 서버에서 클라이언트로 전송되는 데이터만 있다고 가정하자. 이때 서버에서 클라이언트까지의 처리량은 다음의 특성을 통해 구할 수 있다.
- 서버는 Rs bps 이상의 속도로 데이터를 보낼 수 없다.
- 라우터는 Rc bps 이상의 속도로 데이터를 전달할 수 없다.
따라서,
- 만약 Rs < Rc 라면, 서버가 밀어 넣는 데이터가 그대로 라우터를 통과하여 클라이언트에 도달하게 된다.
- throughput = Rs
- 반대로, Rc < Rs 라면, 라우터는 수신하는 데이터보다 느리게 전송해야 하므로 병목 현상이 발생한다.
- throughput = Rc
즉, 이 단순한 네트워크의 처리량은 min(Rs, Rc)가 된다. 즉, 네트워크의 bottleneck link의 전송 속도가 전체 처리량을 결정한다.
이번에는 10개의 서버와 10개의 클라이언트가 인터넷 코어에 연결되어 있는 경우를 살펴보자. 이 예제에서는 10개의 다운로드가 동시에 진행되고 있으며, 네트워크의 다른 트래픽은 없다. 이때 Rs는 서버에서 라우터까지의 link 속도에 해당하고, Rc는 라우터에서 클라이언트까지의 link 속도를 의미한다. 또한 특정 공유 link의 속도가 R이며 이 공유 link는 10개의 다운로드가 모두 통과해야 하는 공통 경로이다.
- 각각의 연결에 대한 end-end throughput은 min(Rs, Rc, R/10)에 해당한다.
- 예를 들어, Rs = 2 Mbps, Rc = 1 Mbps, R = 5 Mbps이라고 하자.
- 이때 min(Rs, Rc, R/10) = min(2Mbps, 1Mbps, 5Mbps/10) = 500kbps이므로 각각의 연결에 대한 throughput은 500kbps이다.
- 즉, bottleneck link는 공유 link R이다.