User Datagram Protocol
UDP 프로토콜
- L4 프로토콜 중 하나이다.
- L4의 SCTP는 멀티미디어를 위한 프로토콜이다.
(그러나 L4의 SCTP보다는 L5에 존재하는 멀티미디어 프로토콜이 더 많이 사용되는 추세이다.)
User Datagram (UDP Packet)
- UDP 패킷은 최대 65,535byte 크기로 생성될 수 있다.
- 헤더는 8byte 크기로 고정된다.
Source, Destination Port Number : Source와 Destination의 포트번호이다.
Total Length : Header와 Data의 크기의 합이다. (패킷의 크기)
Checksum : 패킷 전체에 대한 Checksum*으로, 선택사항이다.
* Checksum(검사합)
- 데이터의 정확성, 무결성을 위해 표시하는 값으로, 앞서 보낸 모든 데이터를 합한 값이다.
UDP Services
- UDP에서 제공하는 네트워크 서비스이다.
1. Process to Process Communication
- UDP는 포트 번호를 이용하여 프로세스 간 통신을 지원한다.
- 근래에 Echo, Discard, Users는 거의 사용되지 않는다.
- Domain은 네임 서비스에 접근하기 위해 빈번히 사용되는 포트번호이다.
- RPC는 분산 프로그램*에서 빈번히 사용된다.
- SNMP는 망 관리를 위해 빈번히 사용된다.
* 여기서, 분산 프로그램은 Network Boundary를 벗어나 다른 Machine의 Procedure를 Call하는 프로그램을 의미한다.
Checksum Calculation(첵섬 계산법)
- Checksum의 경우 필수적으로 사용되지 않는, 선택적인 필드이다.
- 일반적으로, Checksum은 위와 같은 UDP 패킷의 경우, Data가 16bits의 배수가 되도록 Padding을 삽입하고, Padding이 삽입된 Data의 길이를 저장한다.
- 그러나, UDP 패킷 헤더의 Checksum에는 Data의 길이에 Pseudo-Header의 길이까지 더한 값이 저장된다.
- Pseudo-Header의 8bit protocol은 패킷을 구성하는 프로토콜(TCP 혹은 UDP)을 구분한다.
- TCP에서도 마찬가지로 Checksum 계산 시, Pseudo-Header까지 더하게 된다.
- Total Length 값은 UDP 패킷과 Pseudo-Header에 동시에 포함되어 있다. (즉, 같은 값이다.)
Ex. Checksum calculation of a simple UDP user datagram
※ 본질적으로, L4 패킷에 L3 패킷의 정보가 저장되는 것은 Layering에 Violate하는 것이다.
2. Connectionless Service
- Transport Layer Service | 전송 계층 서비스 포스트에서 잘라오기!
3. Encapsulation and Decapsulation
- 패킷이 각 계층을 오갈 때마다, 헤더를 삽입/제거한다.
- 패킷을 송신할 때에는 헤더를 붙여서 패킷을 Encapsulation한다.
- 패킷을 수신할 때에는 헤더를 검사한 후, 떼어내서 패킷을 Decapsulation한다.
4. Queuing
- 대부분의 UDP Implementation에서 Outgoing Queue는 따로 구현하지 않는 추세이다.
- 즉, 메시지가 프로세스에 입력될 때에는 Queue를 통해 액세스되고, 프로세스에서 메시지가 나갈 때에는 Queue를 거치지 않는다.
5. Multiplexing and Demultiplexing
- L4에는 TCP Multiplexer와 UDP Multiplexer가 존재한다.
- UDP를 사용하는 여러 Application의 출력이 UDP MUX에서 Multiplexing이 되어 하나의 Entity로 출력된다.
- MUX에서는 송신자의 포트 번호를 MUX의 Control Signal로 사용한다.
- DeMUX에서는 목적지 포트 번호를 확인하여 해당 프로세스에게 메시지를 전달한다.
※ 마찬가지로, L3에서도 Demultiplexing을 통해 TCP DeMUX, UDP DeMUX를 적절히 선택하게 된다.
6. Comparison between UDP and Generic Simple Protocol
UDP Application
- UDP를 사용하는 Application을 의미한다.
Example 14.4 (TCP/IP Protocol Suite p.424)
- DNS는 일반적으로 UDP를 통해 구현된다. (그러나, TCP로 구현되기도 한다.) 클라이언트의 요청과 서버의 응답 패킷의 길이가 전반적으로 큰 편이 아니기 때문이다.
- 클라이언트는 Request를 하나의 User-Datagram으로 보내고, DNS Server는 Response 또한 하나의 User-Datagram으로 보낸다.
- 즉, 하나의 Request에 대한 Response는 하나이므로, 순서를 맞추어야 할 필요가 없다.
- UDP의 지향점인 Connectionless의 성질과 꼭 맞다.
- 단, UDP에서도 Request, Response 메시지가 전달되지 못하는 오류에 대한 최소한의 신뢰성 서비스*는 제공되어야 한다.
* UDP에서 제공하는 신뢰성 서비스 메커니즘
- 기본적으로, 아래 설명은 L5의 Application이 판단하고 수행하는 내용이다.
- 클라이언트는 Response를 자신이 보낸 Request 메시지에 대한 ACK로 간주한다.
- 제한시간동안, Response 메시지의 도착 여부에 대한 판단은 L5의 Application이 수행한다.
- Response 메시지가 수신되지 않으면, 클라이언트는 Response 메시지를 수 회 재전송한다.
- 클라이언트는 다수의 DNS 서버 주소를 저장하여, DNS 서버에 문제가 생겼을 경우에 대비한다.
Example 14.5 (TCP/IP Protocol Suite p.425)
- 이메일 프로그램의 경우, TCP로 구현하는 것이 바람직하다.
- 메일 내용에 대한 메시지가 Fragmentation되어 전송될 경우, 패킷을 순서대로 무결하게 재조립하는 것이 중요하기 때문이다.
- 또한, 신뢰성 서비스를 제공하는 TCP를 통해 이메일 프로그램을 보다 쉽게 구현할 수 있게 된다.
※ 일반적으로, TCP에서는 모든 신뢰성 서비스가 제공되어 무결한 패킷이 제공되기 때문에 Application 개발에 매우 용이한 환경을 제공한다.
Example 14.7 (TCP/IP Protocol Suite p.425)
- Internet Phone 프로그램(Real-Time Multimedia)에서 데이터의 송수신 과정은 아래와 같다.
- 인터넷 폰끼리 주고받는, Sampling된 Voice Data는 일정한 시간 간격을 두고 전송된다.
- 그러나, 주기적으로 전송하는 것이 순서대로 도착하는 것을 보장하지는 않는다.
- 따라서, 데이터를 수신하는 측에서 L5 헤더에 있는 순서 번호와 타이밍 정보를 이용하여 적절한 Buffering, Delaying을 수행하여 데이터를 순서에 맞게 Playback한다.
- 과도하게 늦게 도착한 메시지의 경우, 정상적인 Playback이 불가능하므로 폐기하게 된다.
- Playback 또한 일정한 시간 간격으로 재생되어야 할 것이다.
※ TCP에서는 오류, 흐름, 혼잡제어를 수행하기 때문에 전송속도가 느리다. 즉, TCP는 빠른 속도를 요구하는 실시간 멀티 미디어 프로그램 구현에 적합하지 않다.
UDP Package
- Input Module* : 각 포트에는 저마다의 Input Queue가 존재하여, Input Module은 도착한 패킷들의 목적지 포트 번호를 확인하여 적절한 Queue에 삽입한다.
- Output Module** : Process에서 생성된 패킷을 출력하는 단순한 구조로 구현된다.
- Control-Block Module*** : 시작된 프로세스로부터 P-ID와 포트번호를 넘겨받아 포트와 바인딩하고, 바인딩 정보를 Control Block Table****에 저장한다.
* Input Module 동작 예시
UDP_Input_Module (user_datagram) {
Look for the entry in the Control_Block_Table // 입력된 user_datagram의 목적지 포트 번호에 일치하는 엔트리가 있는지 검색한다.
if(Target entry is found) {
Check to see if a Queue is allocated
if(Queue is not allocated) // 아직 Incomming Queue가 할당되지 않았다면, 할당한다.
Allocate a Queue // 즉, 현재 User_datagram이 첫 입력값임을 의미한다.
Enqueue the data // 해당 Queue로 데이터를 삽입한다.
}
else { // 목적지 포트 번호에 해당되는 프로세스가 없는 경우
Ask ICMP to send an "Unreachable port" Message
Discard the user datagram
}
Return
} // End Module
** Output Module 동작 예시
UDP_Output_Module (Data) {
Create a user datagram // 데이터를 user_datagram으로 Encapsulation하여
Send the user datagram // 내보낸다
Return // Output Module은 구조가 간단하다.
}
*** Control-Block Module 동작 예시
UDP_Control_Block_Module (processID, portNumber) {
Search the table for a FREE entry
if (FREE entry is not found)
Delete one entry using a predefined policy // 보통, 오랫동안 쓰이지 않은 Entry를 비운다.
Create a new entry with the state IN-USE
Enter the process ID and the port number // 아직, Incomming Queue는 할당하지 않는다.
Return
} // End Module
**** Control Block Table 예시
- 첫 번째 엔트리는 2,345의 P-ID에 해당되는 프로세스가 34번 Incomming Queue에 연결된 52,010 포트에 바인딩되어 사용중에 있음을 의미한다.
- 두 번째 엔트리는 3,422의 P-ID에 해당되는 프로세스가 52,011 포트에 바인딩되어 있다. 아직까지 수신된 데이터가 없어 Incomming Queue는 할당받지 못했음을 의미한다.
- Incomming Queue는 P-ID와 포트 번호가 Control-Block에 등록되는 시점에는 Incomming Queue가 생성되지 않고,
해당 포트로 데이터가 하나라도 들어오는 순간, Incomming Queue를 생성하게 된다.
Example 14.7 (TCP/IP Protocol Suite p.425)
- 첫 번째 Activity는 52,012 포트번호를 가진 User-Datagram가 Input-Module로 입력되었다.
- Input Module은 해당 패킷에 대한 검색에 성공하여 38번 Queue로 전달했다. (즉, 해당 포트의 첫 번째 입력값은 아님을 의미한다.)
- 이 과정에서 Control-Block Table은 변하지 않는다.
Example 14.9 (TCP/IP Protocol Suite p.429)
- 일정 시간 경과 후, 프로세스가 새로 시작되었다.
- 이를 감지한 OS가 해당 프로세스에 포트번호 52,014를 할당했고, Process ID는 4,978로 확정되었다.
- 기존의 Control-Block Table에 이 프로세스의 정보가 반영되면 아래와 같이 수정된다.
Example 14.10 (TCP/IP Protocol Suite p.429)
- 일정 시간 경과 후, 포트 번호 52,011에 해당되는 User-Datagram이 도착하면 P-ID 3,422에 해당되는 엔트리에 새로운 Incomming Queue가 할당된다. (해당 User-Datagram이 첫 입력임을 의미한다.)
- 본 예시에서는 43번 Queue를 할당한다. 수정된 Control-Block Table은 아래와 같다.
Example 14.11 (TCP/IP Protocol Suite p.430)
- 일정 시간 경과 후, 포트 번호 52,222에 해당되는 User-Datagram이 도착했다.
- 포트 번호 52,222에 해당되는 프로세스가 Control-Block Table에 존재하지 않으므로, 해당 User-Datagram을 폐기하고, "ICMP Unreachable port" 메시지를 Source에게 전송한다.
Reference: TCP/IP Protocol Suite 4th Edition
(Behrouz A. Forouzan 저, McGraw-Hill, 2010)
Reference: Data Communications and Networking 5th Edition
(Behrouz A. Forouzan 저, McGraw-Hill, 2012)
User Datagram Protocol
UDP 프로토콜
- L4 프로토콜 중 하나이다.
- L4의 SCTP는 멀티미디어를 위한 프로토콜이다.
(그러나 L4의 SCTP보다는 L5에 존재하는 멀티미디어 프로토콜이 더 많이 사용되는 추세이다.)
User Datagram (UDP Packet)
- UDP 패킷은 최대 65,535byte 크기로 생성될 수 있다.
- 헤더는 8byte 크기로 고정된다.
Source, Destination Port Number : Source와 Destination의 포트번호이다.
Total Length : Header와 Data의 크기의 합이다. (패킷의 크기)
Checksum : 패킷 전체에 대한 Checksum*으로, 선택사항이다.
* Checksum(검사합)
- 데이터의 정확성, 무결성을 위해 표시하는 값으로, 앞서 보낸 모든 데이터를 합한 값이다.
UDP Services
- UDP에서 제공하는 네트워크 서비스이다.
1. Process to Process Communication
- UDP는 포트 번호를 이용하여 프로세스 간 통신을 지원한다.
- 근래에 Echo, Discard, Users는 거의 사용되지 않는다.
- Domain은 네임 서비스에 접근하기 위해 빈번히 사용되는 포트번호이다.
- RPC는 분산 프로그램*에서 빈번히 사용된다.
- SNMP는 망 관리를 위해 빈번히 사용된다.
* 여기서, 분산 프로그램은 Network Boundary를 벗어나 다른 Machine의 Procedure를 Call하는 프로그램을 의미한다.
Checksum Calculation(첵섬 계산법)
- Checksum의 경우 필수적으로 사용되지 않는, 선택적인 필드이다.
- 일반적으로, Checksum은 위와 같은 UDP 패킷의 경우, Data가 16bits의 배수가 되도록 Padding을 삽입하고, Padding이 삽입된 Data의 길이를 저장한다.
- 그러나, UDP 패킷 헤더의 Checksum에는 Data의 길이에 Pseudo-Header의 길이까지 더한 값이 저장된다.
- Pseudo-Header의 8bit protocol은 패킷을 구성하는 프로토콜(TCP 혹은 UDP)을 구분한다.
- TCP에서도 마찬가지로 Checksum 계산 시, Pseudo-Header까지 더하게 된다.
- Total Length 값은 UDP 패킷과 Pseudo-Header에 동시에 포함되어 있다. (즉, 같은 값이다.)
Ex. Checksum calculation of a simple UDP user datagram
※ 본질적으로, L4 패킷에 L3 패킷의 정보가 저장되는 것은 Layering에 Violate하는 것이다.
2. Connectionless Service
- Transport Layer Service | 전송 계층 서비스 포스트에서 잘라오기!
3. Encapsulation and Decapsulation
- 패킷이 각 계층을 오갈 때마다, 헤더를 삽입/제거한다.
- 패킷을 송신할 때에는 헤더를 붙여서 패킷을 Encapsulation한다.
- 패킷을 수신할 때에는 헤더를 검사한 후, 떼어내서 패킷을 Decapsulation한다.
4. Queuing
- 대부분의 UDP Implementation에서 Outgoing Queue는 따로 구현하지 않는 추세이다.
- 즉, 메시지가 프로세스에 입력될 때에는 Queue를 통해 액세스되고, 프로세스에서 메시지가 나갈 때에는 Queue를 거치지 않는다.
5. Multiplexing and Demultiplexing
- L4에는 TCP Multiplexer와 UDP Multiplexer가 존재한다.
- UDP를 사용하는 여러 Application의 출력이 UDP MUX에서 Multiplexing이 되어 하나의 Entity로 출력된다.
- MUX에서는 송신자의 포트 번호를 MUX의 Control Signal로 사용한다.
- DeMUX에서는 목적지 포트 번호를 확인하여 해당 프로세스에게 메시지를 전달한다.
※ 마찬가지로, L3에서도 Demultiplexing을 통해 TCP DeMUX, UDP DeMUX를 적절히 선택하게 된다.
6. Comparison between UDP and Generic Simple Protocol
UDP Application
- UDP를 사용하는 Application을 의미한다.
Example 14.4 (TCP/IP Protocol Suite p.424)
- DNS는 일반적으로 UDP를 통해 구현된다. (그러나, TCP로 구현되기도 한다.) 클라이언트의 요청과 서버의 응답 패킷의 길이가 전반적으로 큰 편이 아니기 때문이다.
- 클라이언트는 Request를 하나의 User-Datagram으로 보내고, DNS Server는 Response 또한 하나의 User-Datagram으로 보낸다.
- 즉, 하나의 Request에 대한 Response는 하나이므로, 순서를 맞추어야 할 필요가 없다.
- UDP의 지향점인 Connectionless의 성질과 꼭 맞다.
- 단, UDP에서도 Request, Response 메시지가 전달되지 못하는 오류에 대한 최소한의 신뢰성 서비스*는 제공되어야 한다.
* UDP에서 제공하는 신뢰성 서비스 메커니즘
- 기본적으로, 아래 설명은 L5의 Application이 판단하고 수행하는 내용이다.
- 클라이언트는 Response를 자신이 보낸 Request 메시지에 대한 ACK로 간주한다.
- 제한시간동안, Response 메시지의 도착 여부에 대한 판단은 L5의 Application이 수행한다.
- Response 메시지가 수신되지 않으면, 클라이언트는 Response 메시지를 수 회 재전송한다.
- 클라이언트는 다수의 DNS 서버 주소를 저장하여, DNS 서버에 문제가 생겼을 경우에 대비한다.
Example 14.5 (TCP/IP Protocol Suite p.425)
- 이메일 프로그램의 경우, TCP로 구현하는 것이 바람직하다.
- 메일 내용에 대한 메시지가 Fragmentation되어 전송될 경우, 패킷을 순서대로 무결하게 재조립하는 것이 중요하기 때문이다.
- 또한, 신뢰성 서비스를 제공하는 TCP를 통해 이메일 프로그램을 보다 쉽게 구현할 수 있게 된다.
※ 일반적으로, TCP에서는 모든 신뢰성 서비스가 제공되어 무결한 패킷이 제공되기 때문에 Application 개발에 매우 용이한 환경을 제공한다.
Example 14.7 (TCP/IP Protocol Suite p.425)
- Internet Phone 프로그램(Real-Time Multimedia)에서 데이터의 송수신 과정은 아래와 같다.
- 인터넷 폰끼리 주고받는, Sampling된 Voice Data는 일정한 시간 간격을 두고 전송된다.
- 그러나, 주기적으로 전송하는 것이 순서대로 도착하는 것을 보장하지는 않는다.
- 따라서, 데이터를 수신하는 측에서 L5 헤더에 있는 순서 번호와 타이밍 정보를 이용하여 적절한 Buffering, Delaying을 수행하여 데이터를 순서에 맞게 Playback한다.
- 과도하게 늦게 도착한 메시지의 경우, 정상적인 Playback이 불가능하므로 폐기하게 된다.
- Playback 또한 일정한 시간 간격으로 재생되어야 할 것이다.
※ TCP에서는 오류, 흐름, 혼잡제어를 수행하기 때문에 전송속도가 느리다. 즉, TCP는 빠른 속도를 요구하는 실시간 멀티 미디어 프로그램 구현에 적합하지 않다.
UDP Package
- Input Module* : 각 포트에는 저마다의 Input Queue가 존재하여, Input Module은 도착한 패킷들의 목적지 포트 번호를 확인하여 적절한 Queue에 삽입한다.
- Output Module** : Process에서 생성된 패킷을 출력하는 단순한 구조로 구현된다.
- Control-Block Module*** : 시작된 프로세스로부터 P-ID와 포트번호를 넘겨받아 포트와 바인딩하고, 바인딩 정보를 Control Block Table****에 저장한다.
* Input Module 동작 예시
UDP_Input_Module (user_datagram) {
Look for the entry in the Control_Block_Table // 입력된 user_datagram의 목적지 포트 번호에 일치하는 엔트리가 있는지 검색한다.
if(Target entry is found) {
Check to see if a Queue is allocated
if(Queue is not allocated) // 아직 Incomming Queue가 할당되지 않았다면, 할당한다.
Allocate a Queue // 즉, 현재 User_datagram이 첫 입력값임을 의미한다.
Enqueue the data // 해당 Queue로 데이터를 삽입한다.
}
else { // 목적지 포트 번호에 해당되는 프로세스가 없는 경우
Ask ICMP to send an "Unreachable port" Message
Discard the user datagram
}
Return
} // End Module
** Output Module 동작 예시
UDP_Output_Module (Data) {
Create a user datagram // 데이터를 user_datagram으로 Encapsulation하여
Send the user datagram // 내보낸다
Return // Output Module은 구조가 간단하다.
}
*** Control-Block Module 동작 예시
UDP_Control_Block_Module (processID, portNumber) {
Search the table for a FREE entry
if (FREE entry is not found)
Delete one entry using a predefined policy // 보통, 오랫동안 쓰이지 않은 Entry를 비운다.
Create a new entry with the state IN-USE
Enter the process ID and the port number // 아직, Incomming Queue는 할당하지 않는다.
Return
} // End Module
**** Control Block Table 예시
- 첫 번째 엔트리는 2,345의 P-ID에 해당되는 프로세스가 34번 Incomming Queue에 연결된 52,010 포트에 바인딩되어 사용중에 있음을 의미한다.
- 두 번째 엔트리는 3,422의 P-ID에 해당되는 프로세스가 52,011 포트에 바인딩되어 있다. 아직까지 수신된 데이터가 없어 Incomming Queue는 할당받지 못했음을 의미한다.
- Incomming Queue는 P-ID와 포트 번호가 Control-Block에 등록되는 시점에는 Incomming Queue가 생성되지 않고,
해당 포트로 데이터가 하나라도 들어오는 순간, Incomming Queue를 생성하게 된다.
Example 14.7 (TCP/IP Protocol Suite p.425)
- 첫 번째 Activity는 52,012 포트번호를 가진 User-Datagram가 Input-Module로 입력되었다.
- Input Module은 해당 패킷에 대한 검색에 성공하여 38번 Queue로 전달했다. (즉, 해당 포트의 첫 번째 입력값은 아님을 의미한다.)
- 이 과정에서 Control-Block Table은 변하지 않는다.
Example 14.9 (TCP/IP Protocol Suite p.429)
- 일정 시간 경과 후, 프로세스가 새로 시작되었다.
- 이를 감지한 OS가 해당 프로세스에 포트번호 52,014를 할당했고, Process ID는 4,978로 확정되었다.
- 기존의 Control-Block Table에 이 프로세스의 정보가 반영되면 아래와 같이 수정된다.
Example 14.10 (TCP/IP Protocol Suite p.429)
- 일정 시간 경과 후, 포트 번호 52,011에 해당되는 User-Datagram이 도착하면 P-ID 3,422에 해당되는 엔트리에 새로운 Incomming Queue가 할당된다. (해당 User-Datagram이 첫 입력임을 의미한다.)
- 본 예시에서는 43번 Queue를 할당한다. 수정된 Control-Block Table은 아래와 같다.
Example 14.11 (TCP/IP Protocol Suite p.430)
- 일정 시간 경과 후, 포트 번호 52,222에 해당되는 User-Datagram이 도착했다.
- 포트 번호 52,222에 해당되는 프로세스가 Control-Block Table에 존재하지 않으므로, 해당 User-Datagram을 폐기하고, "ICMP Unreachable port" 메시지를 Source에게 전송한다.
Reference: TCP/IP Protocol Suite 4th Edition
(Behrouz A. Forouzan 저, McGraw-Hill, 2010)
Reference: Data Communications and Networking 5th Edition
(Behrouz A. Forouzan 저, McGraw-Hill, 2012)
