Chapter 14 User Datagram Protocol (UDP)

OBJECTIVES: UDP의 소개 및 TCP/IP 프로토콜 모음의 다른 프로토콜과의 관계를 설명한다. 프로세스 대 프로세스 통신, 초보적인 오류 제어, 다중화/역다중화, 그리고 큐잉(queuing) 등과 같은 UDP에서 제공하는 서비스를 설명한다. 옵션인 검사합을 계산하는 방법과 검사합을 계산하는 경우에 송신자가 패킷에 의사 헤더(pseudoheader)를 추가하는 이유에 대해 논의한다. 응용 프로그램이 UDP와 같은 단순한 프로토콜로부터 얻을 수 있는 장점을 설명한다. UDP를 구현하는 소프트웨어 패키지 구조를 설명한다.

Chapter Outline 14.1 Introduction 14.2 User Datagram 14.3 UDP Services 14.4 UDP Application 14.5 UDP Package

14-1 개요 그림 14.1은 TCP/IP 프로토콜 모음의 다른 프로토콜 및 계층과 UDP와의 관계를 보여준다. UDP는 TCP와 같이 응용 계층과 IP 계층 사이에 위치하며 응용 프로그램과 네트워크 동작 사이의 중개자 역할을 한다.

TCP/IP 프로토콜 그룹에서 UDP의 위치

UDP 전송 프로토콜 임무 프로세스-대-프로세스 통신 생성 : 포트번호 이용 최소한의 오류 제어 메커니즘 수행 프로세스로부터 데이터 단위를 받아 신뢰성 없는 전달 제공 비연결형, 신뢰성이 없는 전송 프로토콜 최소한의 오버헤드만 사용하는 간단한 프로토콜

14-2 USER DATAGRAM 사용자 데이터그램(user datagram)이라는 UDP 패킷은 8바이트의 고정 크기 헤더를 가진다. 그림 14.2는 사용자 데이터그램의 형식을 나타낸다.

사용자 데이터그램 형식

사용자 데이터그램 발신지 포트 번호(source port number) 발신지 호스트에서 수행되는 프로세스가 사용하는 포트 번호 목적지 포트 번호(destination port number) 목적지 호스트에서 수행되는 프로세스가 사용하는 포트 번호 길이(length) : 헤더와 데이터를 합한 전체 길이 검사합(checksum) : 오류 탐지에 사용

Example 14.1 다음은 16진수의 형식으로 UDP 헤더를 덤프한 것이다. a. 발신지 포트 번호는 얼마인가? b. 목적지 포트 번호는 얼마인가? c. 사용자 데이터그램의 총 길이는 얼마인가? d. 데이터의 길이는 얼마인가? e. 데이터의 전송 방향이 클라이언트에서 서버쪽으로 인가 아니면 반대의 방향인가? f. 클라이언트 프로세스는 무엇인가?

Example 14.2 Solution a. 발신지 포트 번호는 처음 네 자리 16진수(CB8416)이며, 10진수로 표현하면 52,100이다. b. 목적지 포트 번호는 두 번째 네 자리 16진수(000D16)이며, 10진수로 표현하면 13이다. c. 세 번째 네 자리 16진수(000D16)은 UDP 패킷의 전체 길이를 나타내며, 28바이트이다. d. 데이터의 길이는 패킷의 전체 길이에서 헤더의 길이를 뺀 것으로, 28 − 8 = 20바이트이다. e. 목적지 포트 번호가 13(잘 알려진 포트)이므로, 클라이언트로부터 서버로 패킷이 전송되었다. f. 클라이언트 프로세스는 Daytime(표 14.1 참조)이다.

14-3 UDP 서비스 13장에서 전송 계층 프로토콜에서 제공되는 일반적인 서비스에 대해서 살펴보았다. 이 절에는 이러한 일반적인 서비스 중에서 어떤 서비스가 UDP에 의해서 제공되는지 살펴보도록 하자.

UDP 서비스 프로세스 대 프로세스 통신 : IP 주소와 포트번호로 구성된 소켓 이용 비연결형 서비스: 각 사용자 데이터그램은 독립적 흐름 제어: 기능이 없고 윈도우 메커니즘도 없음 오류 제어: 검사합을 제외한 기능 없음 혼잡 제어: 기능 없음

Topics Discussed in the Section Process-to-Process Communication Connectionless Service Flow Control Error Control Congestion Control Encapsulation and Decapsulation Queuing Multiplexing and Demultiplexing Comparison between UDP and Generic Simple Protocol

검사합 계산을 위한 Pseudoheader

Example 14.2 그림 14.4는 7바이트만을 가지고 있는 매우 작은 사용자 데이터그램의 검사합 계산을 보여준다. 데이터의 바이트 수가 홀수이므로 검사합 계산을 위하여 패딩이 필요하다. 사용자 데이터그램이 IP에 전달될 때 패딩과 의사 헤더는 제거될 것이다. (부록 F 참조).

간단한 사용자 데이터그램을 위한 검사합 계산

Example 14.2 다음의 가상 상황에서 검사합으로 어떤 값이 전송되는가? b. 송신자는 검사합을 포함하기로 결정했지만, 검사합의 값이 모두 1이다. c. 송신자는 검사합을 포함하기로 결정했지만, 검사합의 값이 모두 0이다.

Example 14.3 Solution a. 검사합이 계산되지 않았다는 것을 알리기 위하여 검사합 필드의 값은 모두 0으로 설정된다. b. 송신자가 합에 보수를 취한 결과가 모두 0이면, 송신자를 전송하기 전에 결과 값에 다시 보수를 취한다. 즉, 검사합으로 전송되는 값은 모두 1이다. 두 번째 보수 연산은 a의 경우와의 혼돈을 피하기 위하여 필요하다. c. 합의 계산에 포함되는 모든 항목의 값이 0인 상황은 결코 일어날 수 없는 불가능한 경우이다. 의사 헤더의 필드들은 0이 아닌 값을 가지고 있다(부록 D 참조).

캡슐화(Encapsulation) 역캡슐화 (decapsulation)

UDP에서 큐(Queue)

다중화(Multiplexing)와 역다중화(demultiplexing)

Note UDP는 13장에서 설명한 비연결형 단순 프로토콜의 한 예이며, 오류 감지를 위해서 부가적인 검사합을 패킷에 포함한다는 것만 차이가 있다.

14-4 UDP 응용 비록 UDP가 신뢰성있는 전송 계층 프로토콜을 위하여 13장에서 언급한 어떠한 기준도 만족하지 않지만, UDP를 선호하는 응용들도 있다. 이것에 대한 이유는 어떤 서비스들은 신뢰성 서비스를 용납하지 않거나 선호하지 않는다는 것이다. 응용 설계자는 때때로 최적을 얻기 위하여 타협해야 하는 경우가 있다.

Topics Discussed in the Section UDP Features Typical Applications

Example 14.4 DNS(19장 참조)와 같은 클라이언트 서버 응용은 클라이언트가 짧은 요청을 서버에게 전송하고 서버로부터 빠른 응답을 수신하기를 원하기 때문에 UDP의 서비스를 이용한다. 요청과 응답은 각각 하나의 사용자 데이터그램에 들어갈 수 있다. 각각의 방향으로 단지 하나의 메시지만 교환되기 때문에, 비연결형 특징은 문제가 되지 않는다. 클라이언트나 서버는 메시지가 순서에 어긋나게 전달되는 것을 고민하지 않는다.

Example 14.5 전자 메일에서 사용되는 SMTP(23장 참조)와 같은 클라이언트 서버 응용은 사용자가 멀티미디어(즉, 이미지, 음성, 영상)를 포함하는 긴 e-mail 메시지를 전송할 수 있기 때문에 UDP의 서비스를 이용하지 않는다. 만일 응용이 UDP를 사용하고 메시지가 하나의 단일 사용자 데이터그램에 들어가지 않으면, 응용은 메시지를 여러 개의 사용자 데이터그램으로 쪼개야 한다. 여기에서 비연결형 서비스는 문제를 야기할 수 있다. 사용자 데이터그램은 순서에 어긋나게 수신자에 도착해서 배달될 수 있다. 수신측의 응용은 조각의 순서를 맞출 수 없다. 이것은 긴 메시지를 전송하는 응용 프로그램에게는 비연결형이 단점이 될 수 있다는 것을 의미한다. SMTP에서는 한 쪽에서 메시지를 전송하면, 그 메시지에 대한 응답을 빨리 받기를 기대하지 않는다(어떤 경우에는 응답을 요구하지 않기도 한다). 즉, 연결 지향 서비스 고유의 긴 지연은 SMTP에서는 중요한 문제는 아니다.

Example 14.6 인터넷을 통하여 매우 큰 문서 파일을 다운받고 있다고 가정해보자. 이 경우에는 신뢰성 서비스를 제공하는 전송 계층을 사용해야 한다. 즉, 파일을 열었을 때 파일의 일부분이 손실되거나 훼손되는 것을 원하지 않는다. 파일의 일부분의 전달 사이에 발생하는 지연은 중요한 문제가 아니다. 단지 파일을 보기 전에 전체 파일이 구성되기만을 기다린다. 이 경우에는 UDP는 적합한 전송 계층이 아니다.

Example 14.7 컴퓨터를 통하여 실시간 스트림 영상을 본다고 가정해 보자. 이런 프로그램은 긴 파일로 간주되며, 여러 개의 작은 부분으로 나누어져서 실시간으로 방송된다. 메시지의 각 부분은 하나하나씩 전송된다. 전송 계층이 훼손되거나 손실된 프레임을 재전송하게 되면 전체 전송의 동기가 맞지 않게 된다. 시청자는 갑가지 빈 화면만 보게 될 것이고 두 번째 전송이 도착하기 전까지 기다려야 할 것이다. 이것을 참을 수는 없다. 그렇지만 화면의 각각의 조그만 부분이 하나의 단일 사용자 데이터그램으로 전송된다면, 수신 UDP는 훼손되거나 손실된 패킷을 그냥 무시하고 나머지를 응용 프로그램으로 전달한다. 화면의 일부분이 아주 잠깐 동안 공백이 되겠지만, 대부분의 시청자들은 알아차리지도 못한다. 그렇지만, 영상을 순서에 어긋나게 볼 수는 없기 때문에, UDP 상에서 동작하는 스트리밍 오디오, 영상, 그리고 음성 응용들은 순서에 어긋난 프레임들을 재-순서화하거나 버려야 한다.

UDP 대표적인 응용 단순 요청-응답 통신이 필요하고 흐름과 오류제어가 필요 없는 프로세스에 적합 내부에 흐름 및 오류제어가 있는 프로세스에 적합(예: TFTP) 멀티캐스팅에 적합한 전송 프로토콜 SNMP와 같은 관리 프로세스에 사용 RIP와 같은 경로 갱신 프로토콜에 사용 수신된 메시지 단편간 지연이 동일한 실시간 응용에 사용

14-5 UDP 패키지 UDP가 어떻게 UDP 패킷을 송신하고 수신하는지 설명하기 위하여 UDP 패키지의 간단한 버전을 보인다. UDP 패키지는 제어 블록 테이블, 입력 큐, 제어 블록 모듈, 입력 모듈, 출력 모듈의 다섯 개의 구성요소를 가지고 있다. 그림 14.8은 다섯 개의 구성요소와 이들 사이의 관계를 보여주고 있다.

Topics Discussed in the Section Control-Block Table Input Queues Control-Block Module Input Module Output Module

UDP 설계(design)

Example 14.8 처음 동작은 목적지 포트 번호가 52,012인 사용자 데이터그램이 도착하는 것이다. 입력 모듈은 이 포트 번호를 탐색하여 찾아낸다. 이 포트에는 큐 번호 38이 배당되어 있으므로 포트가 전에 이미 사용되었음을 알 수 있다. 입력 모듈은 데이터를 38번 큐에 보낸다. 제어 블록 테이블은 변하지 않는다.

Example 14.9 몇 초 후 프로세스가 시작된다. 이 프로세스는 운영체제에 포트 번호를 요청하고 52,014를 할당받는다. 프로세스는 자신의 ID(4,978)와 포트 번호를 제어 블록 모듈에 보내어 테이블 내에 엔트리를 생성한다. 모듈은 첫 번째의 FREE 엔트리를 취하여 수신된 정보를 입력한다. 이 목적지를 향한 사용자 데이터그램이 도착하지 않았으므로 이 시점에서 모듈은 큐를 배당하지는 않는다(표 14.6 참조).

Example 14.9 52,011 포트에 사용자 데이터그램이 도착한다. 입력 모듈은 테이블을 검사하여 이 목적지를 위한 큐가 아직 배당되지 않았음을 알게 된다. 이것은 이 패킷이 이 목적지로 온 첫 번째 사용자 데이터그램이기 때문이다. 모듈은 43번 큐를 생성한다(표 14.7 참조).

Example 14.9 몇 초 후 52,222 포트에 사용자 데이터그램이 도착한다. 입력 모듈이 테이블을 검사한 결과 이 목적지를 위한 엔트리를 발견하지 못한다. 사용자 데이터그램은 폐기되고 발신지에 “unreachable port” 메시지를 보낼 것을 ICMP에 요청한다.

알림 연습문제 풀이해서 Report로 다음주까지(일주일 후) 제출해 주세요!