ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 10. IP 패킷 전송과 성능분석 기법
    전공공부/컴퓨터 네트워크 2020. 2. 28. 12:27
    728x90
    반응형

    목차

    1. IP 패킷 전방위 전송기법

    2. 네트워크 성능과 큐잉모델

    3. 큐잉분석과 네트워크 설계

     

    10.1 IP 패킷 전방위 전송기법

    10.1.1 패킷 전달 서비스

    네트워크 계층: 전송 측에서 목적지까지 패킷(데이터그램)이 거쳐가는데 이때 최적의 경로를 선택하는 '라우팅(routing)' 기능이 매우 중요하다

    네트워크 계층에서는 패킷의 전달이 중요 기능이라고 할 수 있다. 즉 물리적 네트워크에 의한 패킷의 처리 과정을 감독한다고 보면 된다. 패킷을 전달하는 방법은 직접 전달방식, 간접 전달방식으로 나뉜다.

     

    직접 전달방식: 패킷의 전송측과 최종 목적지가 동일한 네트워크에 있을경우 라우터를 거칠 필요 없이 직접 패킷을 전달할 수 있다.

     

    간접 전달방식: 패킷의 전송 측 호스트가 최종 목적지 호스트와 다른 네트워크일 경우 전달하는 방식이며 이때는 라우터를 거쳐 패킷을 전달하게 된다.

     

     

     

    10.1.2 전방위 전송기법

    전방위 전송 (forwarding): 최종 목적지로 전달되는 경로상에 패킷을 위치시킨다는 의미이다.

     

    라우팅: 전방위 전송이 원활하게 이루어지기 위한 라우팅 테이블의 생성으로 라우팅 테이블의 열(columm)에는 적어도 마스크, 네트워크 주소, 다음 홉, 인터페이스 등 4개의 항목이 필요하다. 

     

    하나의 호스트가 전송할 패킷을 가지거나, 라우터가 전방위 전송을 해야 하는 패킷을 수신한 경우 최종 목적지에 이르는 최적 경로를 찾기 위해 라우팅 테이블을 조사하게 되고 이를 최종 목적지 기반 전방위 전송기법이라 한다. 따라서 호스트나 라우터에서 라우팅 테이블이 반드시 필요해진다. 하지만 인터넷 환경에서는 라우팅 테이블에 들어가는 목록의 수가 너무 많아져 이에 대한 해결 방안이 필요했고 이에 따라 다음 홉 기법, 네트워크 특정 기법, 기정 라우팅 기법이 생겨났다.

     

    다음 홉 기법 (next-hop method)

    - 라우팅 테이블의 내용을 줄이는 기법으로, 테이블에는 전체 경로에 대한 정보 대신 다음 홉의 주소만 담겨 있어 라우팅에 들어간 메모리를 효과적으로 줄이는 방법이다. 하지만 라우팅 테이블마다 들어있는 항목들은 서로 일관성을 유지해야한다. 다음 그림을 보면 알 수 있듯이 다음 홉 기반 라우팅 테이블에는 다음 홉에 대한 정보만 들어있고 테이블 마다 최종 목적지까지 패킷이 잘 전달 될 수 있도록 서로 일관성이 유지되고 있다.

     

    네트워크-특정 기법(network-specific method)

    동일한 물리적 네트워크에 연결된 모든 목적지 호스트의 주소에 대한 모든 항목을 사용하는 것이 아니라, 목적지 네트워크의 주소 자체를 사용하여 하나의 항목으로 대체하는 방식이다. 다음 그림을 보자

    S호스트는 N1 네트워크에 연결되어 있고, A,B,C,D 각 호스트가 모두 N2 네트워크에 연결돼 있으므로 목적지가 A,B,C,D호스트로 설정된 경우 다음 홉은 모두 R1이 된다. 따라서 네트워크 특정 기법에 따라서 라우팅 테이블을 생성할때 목적지를 호스트 A,B,C,D를 다 쓸 필요 없이 목적지를 N2 네트워크로 설정하여 테이블의 항목을 하나로 줄일 수 있다.

     

    기정 라우팅 기법 (default routing method)

    말 그대로 라우터에 목적지가 정해져 있지 않은 다음 홉에 디폴트 값을 지정하는 방법이라고 생각하면 된다.

    다음 그림을 보자.

    A호스트에서 전송되는 패킷의 경로는 R1,R2로 구분되는 두 개의 라우터 중 하나가 되어야 한다. 만약 N2 네트워크에 연결된 호스트로 가는 패킷이라면 R1 라우터로 보내진다. 그 이외에는 모두 R2 라우터로 피킷이 전달되도록 지정할 수 있다. 라우팅 테이블에 특정 목적지에 대한 다음 홉을 설정하고 그 이외 목적지는 디폴트 값으로 R2로 설정하면 된다.

     

    10.1.3 전방위 전송 과정

    [그림 10-6] 처럼 네트워크가 구성되어 있다고 하자. R1 라우터를 중심으로 4개의 네트워크가 연결되어 있다. 

    175.50.65.200/26’ : 기정 라우터

    라우팅 테이블 작성 방법

    앞서 언급한것 처럼 라우팅 테이블의 열에는 적어도 마스크, 네트워크 주소, 다음 홉, 인터페이스 등 4개의 항목이 필요하다.

    작성할때는 테이블의 첫째줄부터 마스크의 N값이 큰 것부터 순서대로 작성한다. 여기서는 /26이 가장 큰값이 되므로 ‘175.50.65.192/26’으로 표현되는 네트워크가 R1라우터와 직접 연결되어 라우팅 테이블의 가장 위 항목에 표기된다. 다음 홉이 없을 때에는 굳이 하지 않아도 된다. 다음 홉이 없다는 뜻은 현재 홉을 거친 후부터는 동일한 서브넷에 들어와 있다는 것을 알아야 한다.

    테이블의 마지막 줄에는 인터넷에 연결되어 있는 라우터의 주소가 175.50.65.200/26’이므로 이것이 기정 라우터의 항목으로 들어가게 된다.

     

    [그림 10-6] 의 R1 라우터에 목적지 주소가 175.50.65.140’IP 패킷이 도착했을 때 

    - 첫 번째 마스크(/26)  IP 패킷의 목적지 주소인 ‘175.50.65.140’에 적용하면,

        그 결과는 ‘175.50.65.128’이 되는데, 이에 대응하는 네트워크 주소를 테이블에서 찾아보면‘175.50.65.192’ -> 대응하는 두 개의 주소가 서로 일치하지 않음

     

    - 두 번째 마스크(/25)IP 패킷의 목적지 주소인 ‘175.50.65.140’에 적용하면, 그 결과 ‘175.50.65.128’ -> 테이블상의 대응하는 네트워크 주소인 175.50.65.128과 일치한다.

     

    - 전방위 전송을 실행하기 위해서 필요한 다음 홉 주소를 테이블에서 찾아보면 테이블에는

        다음 홉 주소가 나타나 있지 않음 -> 직접연결이 되어 있기 때문에!

    - 마지막으로 인터페이스 번호 m0를 통해서 패킷의 전방위 전송(forwarding)이 이루어지게된다.

     

    10.2 네트워크 성능과 큐잉(queueing)모델

    10.2.1 큐잉분석 기법

    네트워크 성능분석 기법으로 네트워크 설계 시 노드 정보에 기초한 네트워크 자원의 효율적인 사용을 위해 만들어 졌고 자료구조의 queue 와 비슷한 방식(First In First Out)으로 패킷을 저장하고 전송하여 원할한 데이터 서비스 제공이 가능하도록 만들어진 방법이다.

     

    큐잉이론(queueing theory)

    -패킷이 도착하면 대기열에 일단 push가 되는데 이때 우선순위의 기준은 대기연의 도착과 대기 시간, 서버에 의한 서비스 등을 고려하여 대기열의 특성과 관련된 수학적분석을 통해 확률로 우선순위를 매기게 된다.

     

    즉 고려대상 항목으로: 고객의 도착과 그 다음 도착 사이 시간 (interarrival time), 확률밀도함수, 서비스 시간, 서버의 수, 큐에서의 처리규칙, 버퍼의 크기 등을 확률밀도 함수의 개념등 다양한 수학적 도구를 활용하여 우선순위를 부여한다.

     

    도착간 확률밀도함수는 도착 과정에 대한 특성을 결정

    도착간 밀도함수와 함께 서비스 시간 확률밀도함수도 큐잉시스템을 분석할 때 사용되는 중요한 속성이다.

    서비스를 제공하는 디바이스 서버가 다수인 경우 -> 멀티서버 큐잉 시스템이 된다.

     

    처리 규칙은 FIFO 또는 LIFO(Last In First Out) 등 으로 한다.

    버퍼크기는 일반적으로 큐잉시스템이 무한한 버퍼 크기를 가지고 있는 것은 아니기 때문에 서비스를 받지 못하는 경우가 발생할 수도 있다.

     

    10.2.2 단일서버에서의 큐잉모델

    큐잉모델의 속성을 고려한 가장 기본적인 모델이다.

    -> (버퍼), 서버, 도착간 시간(도착과 그 다음 도착 사이 시간), 서비스 시간, 큐에서의 처리규칙 등을 포함하고 있으며, 서버는 입력 데이터에 대한 서비스를 제공한다.

     

    입력 데이터 패킷을 데이터 아이템이라고 표현하며 서버는 아이템들에 대한 서비스를 수행한다.

     

    서버가 휴지(idle)상태에서 입력되면 그 아이템은 곧바로 서비스를 받게 되고, 서버가 사용 중 (busy)상태에서 입력되면 그 아이템은 큐에 들어가서 대기상태가 된다.

     

    만약 큐에서 버퍼의 용량이 무한하다면 버퍼의 용량초과로 인한 아이템 손실은 없고, 단지 아이템들이 처리되기 위해 필요한 시간 지연만 있게 된다. 

     

    이론적으로 단일 서버에서 적용될 수 있는 최대 입력률은 최대값(max) =1/Ts 로 정의된다.

    실제 시스템에서는 보통 최대 입력률 : 70~90%

     

    10.2.3 멀티서버 큐 모델과 다중 단일서버 모델

    멀티서버 큐 모델

    하나의 공통 큐와 N개 서버의 공유로 구성된 멀티서버 큐 모델 -> [그림 10-15(a)]

    N개의 서버 중에 휴지상태의 서버가 있다면, 아이템들은 그 서버로 전송되지만 휴지상태의 서버가 존재하지 않는다면 입력된 아이템은 큐를 형성하기 위해 버퍼로 전송된다.

     

    다중 단일서버 모델

    다중 단일서버 모델의 경우 -> [그림 10-15(b)] 단일서버 모델의 확장으로, 들어오는 데이터들은 각각의 큐에 저장되고 처리되기를 기다린다. 각 큐마다 우선순위를 제공할 수 있다는 점에서 단일 공통 큐를 갖는 멀티서버 큐 모델에 비해 다양한 분석이 가능하다. 

     

    10.3 큐잉분석과 네트워크 설계

    10.3.1 네트워크상의 서버에서 큐의 상태 분석

    [표 10-5] : 네트워크 시스템을 통한 실시간 서비스 제공 -> 실시간 서비스 제공을 위한 네트워크의 성능은 사용자의 서비스 요구에 대한 네트워크 시스템에서의 처리율 관계로 해석

    - 데이터가 초당 500개의 평균 요구량을 가지고 서버에 도착함

    - 서버는 1초에 1000개의 데이터를 처리할 수 있으므로, 서버의 처리율은 1000/초가 됨

     

    처음 0초에서 1초 사이

    - 88개의 데이터가 도착하였고, 서버의 초당 처리율이 1000개이므로 도착한 데이터 88개가 모두 처리되어 큐에는 어떠한 데이터도 없게 됨

     

    t=1(초)일 때

    - 입력 데이터=88, 출력 데이터=88, 큐 내의 데이터 길이는 0이 됨

     

    t=2(초)일 때

    -769개의 데이터가 서버에 도착했고, 서버의 초당 처리율이 1000개이므로 출력 역시 769개가 되며, 처리되지 못하고 큐에 남아있는 데이터가 없음

     

    t=3(초)일 때

    - 1627개의 데이터가 서버에 도착했고, 서버는 초당 1000개의 데이터를 처리하므로 1000개의 데이터만 처리

    - 나머지 627개의 데이터는 다음에 들어오는 데이터와 함께 처리되기 위해 서버의 버퍼에 축적됨

     

    t=4(초)일 때

    - 서버에 51개의 데이터가 들어오는데, 이 데이터는 이전 데이터가 입력되어 처리되지 못하고 버퍼에 저장된 데이터와 함께 처리 -> 출력값은 678개가 됨

    - 서버의 버퍼에 쌓이는 데이터의 양은 다시 0으로 되돌아감

     

    10.3.2 네트워크상의 서버에서 큐의 상태변화 -> [표 10-5]

     

    입력 평균값 : 입력되는 데이터의
    총 수를 더해서 50초로 나눈 값,
    즉 데이터의 입력에 대한 평균

     

    출력 평균값 : 서버에서 처리되어
    출력되는 데이터를 모두 더해서
    50
    초로 나눈 데이터의 출력 평균값

     

    큐의 버퍼에 대기하고 있다가
    서비스를 받은 데이터의 양에 대한
    평균은 43

        -> 서버에서 처리되지 못하고 버퍼에
    저장되었던 데이터의 양이 비교적
    적었음을 알려준다.

    728x90
    반응형

    댓글

Designed by Tistory.