[네트워크] Network | UDP의 특징, rdt 프로토콜의 발전, GBN과 SR 프로토콜의 장단점

 

왜 애플리케이션 개발자가 TCP 보다 UDP 방식으로 애플리케이션을 개발하려고 하는지 알아보자. 

 

애플리케이션 레벨이 데이터 송신에 대해서 정교한 제어를 할 수 있다는 특징이 있다. 애플리케이션 프로세스가 데이터를 UDP에게 전달하자마자 UDP는 데이터를 UDP 세그먼트로 만들고, 즉시 그 세그먼트를 네트워크 계층으로 전달한다. 이에 반해서 TCP는 혼잡 제어 메커니즘을 가지고 있다. 반면 UDP는 기본 세그먼트 전달 외에 필요한 어떤 추가 기능을 구현할 수 있다.

 

두 번째로 연결 설정이 없다는 것이다. TCP는 데이터 전송을 시작하기 전에 Handshake를 사용한다. 반면에 UDP는 형식적인 예비동작 없이 전송한다. 그러므로 UDP는 연결을 설정하기 위한 어떤 지연도 없다. 

 

세 번째로 연결 상태가 없다. TCP는 종단 시스템에서 연결 상태를 유지한다. 이에 반해 UDP는 연결 상태를 유지하지 않으며 파라미터 중의 어떤 것도 기록하지 않는다. 그래서 특정 애플리케이션에 할당된 서버는 TCP보다 UDP에서 동작할 때 더 많은 클라이언트를 수용할 수 있다.

 

 

 

UDP는 RIP 라우팅 테이블 갱신에 사용된다. 또한 UDP는 네트워크 관리 (SNMP) 데이터를 전달하는데 사용된다. 네트워크 관리 애플리케이션은 네트워크가 혼잡한 상태에 있을 때 자주 동작해야 하므로 이러한 경우에는 UDP가 TCP보다 좋다. 또한 DNS은 TCP의 연결 설정 지연을 피하기 위해서 UDP에서 동작한다. 또한 실시간 애플리케이션은 TCP 혼잡 제어가 나쁜 영향을 미친다. 그래서 해당 개발자들은 그들의 애플리케이션을 TCP 대신 UDP에서 동작하도록 만든다.

 

UDP는 애플리케이션 프로세스로부터 메시지를 가져와서 다중화 / 역다중화 서비스에 대한 출발지 포트 번호 필드와 목적지 포트 번호 필드를 첨부하고 다른 두 필드들을 추가한 후에 최종 세그먼트를 네트워크 계층으로 넘겨준다.

 

 

     UDP 체크섬은 오류 검출을 제공한다. 즉, 체크섬은 세그먼트가 출발지로부터 목적지로 이동했을 때 UDP 세그먼트 안의 비트에 대한 변경사항이 있는지 검사하는 것이다. 송신 측에서 UDP는 세그먼트 안에 있는 모든 16비트 워드 단위로 더하고 이에 대하여 다시 1의 보수를 수행하며, 덧셈 과정에서 발생하는 오버플로우는 wrap around를 한다.

 

 

각 비트들을 Bitwise 연산을 수행하고 발생한 Carry에 대해서는 보수를 취한다. 해당 sum을 구하게 된 상태에서 보수를 구하면 체크섬을 구할 수 있다. 수신자에서는 체크섬을 포함한 4개의 모든 16비트 워드들을 더한다. 만약 패킷에 어떤 오류도 있지 않다면 수신자에서의 합은 1111111111111111이 될 것이다. 만약 비트 중에서 하나라도 0이 있다면 패킷에 오류가 발생했을을 할 수 있다.

 

 

신뢰적인 데이터 전송 연구에 대한 프레임워크를 보여준다. 상위 계층 개체에게 제공되는 서비스 추상화는 데이터가 전송될 수 있는 신뢰적인 채널의 신뢰적인 채널의 서비스 추상화다. 신뢰적인 채널에서는 전송된 데이터가 손상되거나 손실되지 않는다. 그리고 모든 데이터는 전송된 순서대로 전달된다. 이것은 TCP가 인터넷 애플리케이션에게 제공하는 서비스 모델이다. 이 작업은 신뢰적인 전송 프로토콜의 아래에 있는 계층이 신뢰적이지 않으므로 어려워진다. 예를 들어 TCP는 비신뢰적인 종단간 네트워크 계층 (IP)의 바로 상위에 구현된 신뢰적인 데이터 전송 프로토콜이다.

 

 

 

해당 그림은 데이터 전송 프로토콜에 대한 인터페이스를 나타낸다. 데이터 전송 프로토콜의 송신 측은 rdt_send() 호출에 의해서 위쪽으로부터 호출될 것이다. 수신 측에서는 상위 계층으로 전달될 데이터를 넘길 것이다. 수신 측에서 rdt_rcv()는 패킷이 채널의 수신 측으로부터 도착했을 때 호출된다. rdt 프로토콜이 상위 계층에 데이터를 전달하려고 할 때 deleiver_data()를 호출한다. 이제부터 프로토콜 데이터 단위에 대해 세그먼트보다는 패킷이라는 용어를 사용한다.

 

 

변화를 일으키는 사건은 변화를 표기하는 평행선 위에 나타낸다. 그리고 이벤트가 발생했을 때 취해지는 액션은 평행선 아래에 나타낸다. rdt의 송신 측은 rdt_send(data) 이벤트에 의해 상위 계층으로부터 데이터를 받아들이고 데이터를 포함한 패킷을 생선한다. (make_pkt) 실제로 rdt_send() 이벤트는 상위 계층 애플리케이션의 프로시저 호출에 의해서 발생한다.

 

수신 측에서 rdt는 rdt_rcv(packet) 이벤트에 의해 하위의 채널로부터 패킷을 수신하고, 패킷으로부터 데이터를 추출한 후 데이터를 상위 계층으로 전달한다. 이벤트는 하위 계층 프로토콜로부터의 프로시저 호출(rdt_rcv)에 의해서 발생한다.

 

 

 

 

하위 채널의 더 실질 모델은 패킷 안의 비트들이 하위 채널에서 손상되는 모델이다. 그러한 비트 오류는 패킷이 전송 또는 전파되거나 버퍼링될 때 네트워크의 물리적 구성 요소에서 일반적으로 발생한다. 제어메시지가 추가되는데 수신되었는지 또는 잘못 수신되어 반복이 필요한지를 수신자가 송신자에게 알려 줄 수 있게 한다.

 

하지만 rdt2.0은 잘 동작되는 것 같지만 치명적인 결함이 있다. ACK 또는 NAK 패킷이 손상될 수 있다는 가능성을 고려하지 않았다. 송신자 대 수신자 채널로 중복 패킷을 전송한다. 하지만 이것의 문제점은 ACK나 NAK가 송신자에게 정확하게 수신되었는 지를 알 수 없다는 것이다. 그러므로 도착하는 패킷이 새로운 데이터를 포함하고 있는 것인지, 아니면 재전송인지를 사전에 알 수 없다.

 

이에 대한 새로운 문제에 대한 간단한 해결책은 데이터 패킷에 새로운 필드를 추가하고 이 필드 안에 순서번호를 삽입하는 방식으로 데이터 패킷에 송신자가 번호를 붙이는 것이다.

 

 

프로토콜 rdt 2.1은 수신자로부터 송신자까지의 긍정 확인응답과 부정 확인응답을 모두 포함한다.

 

 

순서가 바뀐 패킷이 수신되면 수신자는 이미 전에 수신한 패킷에 대한 긍정 확인응답을 전송한다. 손상된 패킷이 수신되면 수신자는 부정 확인응답을 전송한다. NAK를 송신하는 것 대신에, 가장 최근에 정확하게 수신된 패킷에 대해 ACK를 송신함으로써 NAK를 송신한 것과 같은 효과를 얻을 수 있다.  같은 패킷에 대해 2 개의 ACK를 수신한 송신자는 수신자가 두 번 ACK한 패킷의 다음 패킷을 정확하게 수신하지 못했다는 것을 안다. 비트 오류를 갖는 채널을 위한 NAK 없는 신뢰적인 데이터 전송 프로토콜은 rdt 2.2에 해당한다.

 

 

패킷 손실이 일어나는 경우는 어떻게 처리할 것인가? 송신자가 데이터 패킷을 전송하고 패킷 또는 수신자의 패킷에 대한 ACK를 손실했다고 가정하자. 어느 경우에나 송신자는 어떠한 응답도 없다. 만약 송신자가 패킷을 잃어버렸다는 것을 확신할 정도로 충분한 시간을 기다릴 수만 있다면, 데이터 패킷은 간단하게 재전송될 수 있다.

 

 

 

그렇다면 패킷을 손실했다는 것을 확신하기 위해 얼마나 오랫동안 기다려야 할까? 송신자는 적어도 송신자와 수신자 사이의 왕복시간 지연에 수신 측에서 패킷을 처리하는 데 필요한 시간을 더한 만큼 기다린다. 많은 네트워크에서는 이 최악의 최대 지연시간은 예측하기도조차 매우 어렵다. 더욱이, 이상적으로는 프로토콜이 패킷 손실을 가능한 한 빨리 복구해야 한다. 사건 기반의 재전송 메커니즘을 구현하기 위해, 주어진 시간이 경과된 후에 송신자를 중단할 수 있는 카운트다운 타이머가 필요하다.

 

해당 그림은 패킷이 손상되거나 손실될 수 있는 채널에서 데이터를 신뢰적으로 전송하는 프로토콜인 rdt 3.0 에 대한 송신자 FSM을 보여준다.

 

송신자의 관점에서 재전송은 만병통치약과 같다. 송신자는 데이터 패킷이 손실되었는지, ACK가 손실되었는지, 패킷 또는 ACK가 단순히 지나치게 지연된 것인지를 알지 못한다. 시간 기반의 재전송 매커니즘을 구현하기 위해, 주어진 시간이 경과된 후에 송신자를 중단할 수 있는 카운트다운 타이머가 필요하다.

 

(1) 매 패킷이 송신된 시간에 타이머를 시작함

(2) 타이머 인터럽트에 반응함

(3) 타이머를 멈춤

 

시간은 다이어그램의 위로부터 아래로 움직인다. 즉 패킷에 대한 수신 시간은 전송 지연과 전파 지연 때문에 패킷 전송 시간보다 더 늦다.

 

다음 그림에서 보이는 검은색 괄호는 타이머가 설정된 후에 타임 아웃된 시간을 가리킨다. 이 프로토콜의 좀 더 세세한 부분은 후반부에 나오므로 나중에 이어서 설명하도록 하겠다. 패킷의 순서번호가 0과 1이 번갈아 나타나므로, 프로토콜 rdt 3.0은 때때로 Alternating-bit 프로토콜이라고 부른다.

 

프로토콜 rdt 3.0은 기능적으로 정확한 프로토콜이다. 그러나 rdt 3.0의 핵심적인 성능 문제는 rdt 3.0 이 Stop-and-wait 프로토콜이라는 것이다. 미국의 서부와 동부에 각각 위치한 종단 호스트의 경우를 고려해보자. 두 종단 시스템 사이의 RTT는 대략 30msec 이다. 이것들이 1Gbps 전송률을 가진 채널에 의해서 연결되어 있다고 가정하자. 패킷당 1000 바이트 (8000bits) 의 패킷 크기를 가지고 1Gbps 링크로 패킷을 실제 전송하는데 걸리는 시간은 8 마이크로세컨드이다.

 

 

 

다음 그림처럼 전송 후 대기 프로토콜을 가지고 송신자가 t = 0 에서 데이터를 전송하기 시작한다면 8 (마이크로세컨드)에서 마지막 비트가 송신 측의 채널로 들어간다. 이제 패킷은 15msec 동안 대륙을 횡단하고 16.008 msec에서 수신측으로 마지막 비트가 도착한다. ACK 패킷은 전송 시간을 무시할 수 있을 만큼이고 수신자는 데이터 패킷의 마지막 비트가 수신되자 마자 ACK 패킷을 송신할 수 있다고 가정하자. 송신자 측에 ACK 패킷은 30.008 msec 후에 다시 받을 수 있다. 

 

이를 생각해보면 30.0008 msec 중 0.008 msec 동안만 데이터를 전송한 셈이다.송신자가 채널을 통해 실제적으로 분주하게 비트를 전송하는 데만 걸린 시간을 이용률(Utilization) 수식으로 정의한다면, 0.00027 에 해당하는 이용률을 가진다는 것을 알 수 있다.

 

해결책은 확인 응답을 기다리지 않고 여러 패킷을 전송하도록 허용하는 것이다.

 

 

이 사진의 경우 송신자가 3개의 패킷을 전송하도록 허용한다면 송신자의 이용률은 3배가 될 것이라는 것을 보여준다. 많은 전송 중인 송신자-수신자 패킷을 파이프라인에 채워 넣음으로써 나타낼 수 있다. 이 기술을 파이프 라이닝이라고 부른다.

 

 

GBN 프로토콜에서 송신자는 확인응답을 기다리지 않고 여러 패킷을 전송할 수 있다. 그러나 파이프라인에서 확인응답이 안 된 패킷의 최대 허용 수 N보다 크지 않아야 한다. 확인 응답이 안 된 가장 오래된 패킷의 순서번호를 base로 정의하고 사용되지 않은 가장 작은 순서번호를 nextseqnum으로 정의한다면 순서번호의 범위에서 총 4개의 구간을 확인할 수 있다.

초록색 구간 - 이미 전송 되고 확인응답된 패킷

노란색 구간 - 송신은 되었지만 아직 확인 응답되지 않은 패킷

파란색 구간 - 상위 계층으로부터 데이터가 도착하면 바로 전송할 수 있는 패킷

투명색 구간 - 파이프라인에서 확인응답이 안 된 패킷의 확인응답이 도착할 때까지 사용될 수 없다.

 

base와 nextseqnum 이라는 변수를 추가했다. 이 FSM을 Extended FSM이라고 부른다. 

 

- 상위로부터 호출

rdt_send()가 위로부터 호출되면, 송신자는 첫째로 윈도우가 가득 찼는지, 즉 N개의 아직 확인응답되지 않은 패킷이 있는 지를 확인한다. (아직 ACK를 받지 않은 패킷이 있는지를 확인하는 절차) 적절하게 변수들이 갱신된다.

- ACK의 수신

GBN 프로토콜에서 순서번호 n을 가진 패킷에 대한 확인응답은 누적확인 응답으로 인식된다.

 

수신자의 행동도 단순하다. 만약 순서번호 n을 가진 패킷이 오류 없이 순서대로 수신된다면, 수신자는 패킷 n에 대한 ACK를 송신하고 상위 계층에 패킷의 데이터 부분을 전달한다. 그 외의 경우에는 수신자는 그 패킷을 버리고 가장 최근에 제대로 수신된 순서의 패킷에 대한 ACK를 재전송한다.

 

GBN 프로토콜에서 수신자는 순서가 잘못된 패킷들을 버린다. 이것은 송신자 버퍼링을 간단하게 만들 수 있다. 그러므로 송신자는 윈도우 상위와 하위 경계와 이 윈도우 안에 있는 nextseqnum 위치를 유지해야 하는 반면에, 수신자가 유지해야 하는 것은 단지 다음 순서 패킷의 순서번호이다.

 

수신자에서 오류가 발생한 패킷을 수신했다고 의심되는 패킷만을 송신자가 다시 전송하므로 불필요한 재전송을 피한다. SR 수신자는 패킷의 순서와는 무관하게 손상 없이 수신된 패킷에 대한 확인응답을 할 것이다. 순서가 틀린 패킷은 분실된 패킷이 수신될 때까지 버퍼에 저장하고, 손실된 패킷이 수신된 시점에서 일련의 패킷을 순서대로 상위계층에 전달할 수 있다.