3.3 비연결형 트랜스포트 : UDP

3.3 비연결형 트랜스포트 : UDP

이번 절에서는 UDP가 어떻게 동작하고 무엇을 하는지 자세히 살펴봅니다.

[RFC 768]에 정의된 UDP는 트랜스포트 계층 프로토콜이 할 수 있는 최소 기능으로 동작합니다. 그러니깐 UDP는 다중화/역다중화 기능과 간단한 오류 검사 기능을 제외하면 IP에 아무것도 추가하지 않는다는 말입니다. 그래서 애플리케이션 개발자가 TCP대신에 UDP를 선택한다면 애플리케이션은 거의 IP와 직접 통신하는 셈입니다. 

UDP는 (TCP와는 다르게) 세그먼트를 송신하기 전에 송신 트랜스포트 계층과 수신 트랜스포트 계층 사이에 핸드쉐이크(3-way handshake)를 사용하지 않는다는 점에 주의해야 합니다. 이런 이유로 UDP를 비연결형이라고 합니다. (TCP는 세그먼트를 송신하기 전에 상대방과 연결이 잘 되었는지 확인 후, ‘나 지금 보낸다!’ 라고 하고 보내는 반면에, UDP는 상대방과 연결이 잘 되든 말든 일단 보내고 보는 셈입니다.)

DNS가 일반적으로 UDP를 사용하는 애플리케이션 계층 프로토콜의 예입니다. DNS 질의(Query)를 생성할 때, DNS 질의 메시지를 작성하고 UDP에게 메시지를 넘겨줍니다. 목적지 쪽에서 동작하는 UDP와 송신 측 UDP는 어떠한 Handshake도 수행하지 않고 메시지에 헤더 필드만 추가한 후 최종 세그먼트를 네트워크 계층에 넘겨줍니다. 네트워크 계층은 UDP 세그먼트를 데이터그램으로 캡슐화하고 네임(name)서버에 데이터그램을 송신합니다. 이 때 질의하는 호스트(송신쪽)에서의 DNS 애플리케이션은 질의에 대한 응답을 기다립니다. 만약 질의 호스트가 응답을 수신하지 못하면, 질의를 다른 네임서버로 송신하거나 요청한 애플리케이션으로 응답할 수 없다는 것을 통보합니다.

왜 애플리케이션 개발자는 TCP보다 UDP 방식으로 애플리케이션을 개발하려고 하는지 궁금할 것입니다.  TCP가 신뢰적인 데이터 전송 서비스를 제공하지만, UDP는 그렇지 않으므로 TCP가 항상 더 좋을까요? 답은 ‘아니요’ 입니다. 왜냐하면 다음과 같은 이유때문에 UDP가 더 적합합니다.

• 애플리케이션 레벨이 데이터 송신에 대해서 정교한 제어를 할 수 있습니다.

UDP 하에서는 데이터를 UDP에게 전달되자 마자 UDP가 데이터를 세그먼트로 만들고, 즉시 그 세그먼트를 네트워크 계층으로 전달합니다. 이에 반해서 TCP는 혼잡제어 메커니즘(Congestion Control)을 가지고 있습니다. Congestion Control 기능은 호스트들 사이에 링크가 과도하게 혼잡해지면 TCP 송신자를 조절합니다. 또한 목적지가 세그먼트의 수신여부를 확인응답(ACK)할 때까지 총 시간이 얼마나 걸리든 상관없이 신뢰적인 전달을 보장하기 위해 세그먼트 재전송을 계속할 것입니다. 그러나 실시간(Real-time) 애플리케이션은 종종 최소전송률만을 요구하고, 지나치게 지연되는 세그먼트 전송을 원하지 않습니다. 또한 조금의 데이터 손실은 허용할 수 있으므로 TCP의 서비스 모델은 이들 애플리케이션의 요구와 맞지 않습니다. 

• 연결 설정이 없다.

나중에 논의하겠지만 TCP는 데이터전송을 시작하기 전에 3-way handshake를 사용하는 반면에 UDP는 형식적인 예비동작이 없습니다. 그러므로 UDP는 열결을 설정하기 위한 어떤 지연도 없습니다. 이것이 DNS가 왜 UDP에서 동작하는지에 대한 일반적인 이유입니다. DNS가 만일 TCP에서 동작한다면 많이 느려질 것입니다. 반면에 HTTP 문서로 된 웹페이지는 신뢰성이 중요하기 때문에 UDP보다 TCP를 사용합니다.

• 연결 상태가 없다.

TCP는 종단 시스템(End system)에서 연결 상태를 유지합니다. 이 연결상태는 수신버퍼, 송신버퍼, congestion control 파라미터, sequence number, ACK number 파라미터를 포함합니다. 이 정보들은 TCP의 신뢰적인 데이터 전송 서비스를 위해 필요한 것들입니다. 이에 반해 UDP는 연결상태를 유지하지 않으므로 이 파라미터 중의 어떤 것도 기록하지 않습니다. 그래서 일반적으로 특정 애플리케이션에 할당된 서버는 애플리케이션이 TCP보다 UDP에서 동작할 때 좀 더 많은 클라이언트를 수용할 수 있습니다.

• 작은 패킷 헤더 오베헤드

TCP가 세그먼트마다 20바이트의 헤더 오버헤드를 가지는 반면에 UDP는 단지 8바이트의 헤더 오버헤드를 가집니다. 

위 그림은 인기 있는 인터넷 애플리케이션과 그 애플리케이션들이 사용하는 트랜스포트 프로토콜의 목록을 나타냅니다. 

많은 중요한 애플리케이션은 TCP보다 UDP에서 동작합니다. RIP 라우팅 테이블 갱신에도 UDP가 사용됩니다. RIP 갱신(5분주기)은 주기적으로 전송되므로 손실된 갱신은 좀 더 최근의 갱신에 의해 교체될 수 있게 하여 손실되거나 시간이 지난 갱신은 필요없게 만듭니다. 네트워크 관리 애플리케이션 역시 네트워크가 혼잡한 상태에 있을 때 자주 동작해야 하므로 UDP가 좋습니다.

UDP 세그먼트 구조에 대해 설명하기 전에 애플리케이션이 UDP를 사용할 때도 신뢰적인 데이터 전송이 가능하다는 것에 주목합시다. 만약 애플리케이션 자체에서 신뢰성을 제공한다면 신뢰적인 데이터전송을 할 수 있습니다.(ACK 메커니즘, 재전송 메커니즘 추가 등). 그러나 애플리케이션 개발자가 좀 힘들어 하겠죠? 뭐 어찌되었든, 애플리케이션 프로세스들ㄴ TCP의 Congestion Control에 의해서 전송률 억제를 강요당하지 않고도 신뢰적으로 통신할 수 있습니다. 

3.3.1    UDP 세그먼트 구조

애플리케이션 데이터는 UDP 세그먼트의 data 필드에 위치합니다. 그러니깐 우리가 실질적으로 전송하고 싶은 내용들이 이곳에 위치합니다. 그 위에 위치한 4가지 필드들은 그저 주고받기 위한 최소한의 형식적인 필드라는 것 입니다. 정확히는 UDP 헤더는 2바이트씩 구성된 4개의 필드를 가진다고 할 수 있습니다. src , dst 포트넘버가 있고 헤더를 포함하는 UDP 세그먼트 길이(바이트단위)가 있고, 체크섬(checksum)이 있습니다. 체크섬은 세그먼트에 오류가 발생했는지를 검사하기 위해 수신 호스트에 의해서 사용됩니다. 

3.3.2    UDP 체크섬

UDP 체크섬은 오류 검출을 제공합니다. 즉, 체크섬은 세그먼트가 출발지로부터 목적지로 이동했을 때 UDP 세그먼트 안의 비트에 대한 변경사항이 있는지 검사하는 것 입니다. 

송신측에서 UDP는 세그먼트 안에 있는 모든 16비트 워드 단위로 더하고 이에 대하여 1의 보수를 수행하며, 덧셈과정에서 발생하는 오버플로우은 윤회식 자리올림(Wrap around)합니다. 이 결과는 UDP 세그먼트의 체크섬 필드에 삽입됩니다. 다음 슬라이드에서 간단한 예시를 봅시다.

2개의 16비트 워드를 더하면 오버플로우가 발생하고 이를 Wrap around 했습니다. 1의 보수(모든 0을 1로, 모든 1을 0으로)를 마지막에 해주면 체크섬이 됩니다. 수신자에서는 체크섬을 포함한 모든 16비트 워드를 더합니다. 만약 패킷에 어떤 오류도 있지 않다면, 수신자에서의 합은 1111 1111 1111 1111 이 될 것입니다. 만약 비트 중에서 하나라도 0이 있다면 패킷에 오류가 발생했음을 알 수 있습니다.

많은 링크계층 프로토콜(이더넷 프로토콜 포함)이 오류검사를 제공하는데, 굳이 왜 UDP가 체크섬을 제공하는지 궁금할 수도 있습니다. 그 이유는 모든 링크가 오류검사를 제공한다는 보장이 없기 때문입니다. 즉, 링크 중에서 하나가 오류검사를 제공하지 않는 프로토콜을 사용할 수도 있는 것입니다. 그러므로 주어진 링크 간의 신뢰성과 메모리 오류검사가 완벽히 보장되지 않기 때문에, 종단간의 데이터 전송 서비스가 오류검사를 제공한다면, UDP는 종단간의 트랜스포트 계층에서 오류검사를 제공해야만 합니다. 

UDP는 오류검사를 제공하지만, 오류를 회복하기 위한 어떤 일도 하지 않습니다. 일부 UDP구현에서는 손상된 세그먼트는 그냥 버리고, 다른 구현에서는 경고와 함께 손상된 세그먼트를 애플리케이션에서 넘겨주기도 합니다. 

이것으로 UDP에 대한 내용을 마칩니다. 

3.3 단원에서는 비연결형 트랜스포트 프로토콜인 UDP에 대해 알아보았습니다.

3.4 단원에서는 신뢰성 있는 데이터 저송의 원리에 대해 알아보겠습니다.