UDP - 최소 기능의 트랜스포트 계층 프로토콜
- UDP는 트랜스포트 계층 프로토콜이 할 수 있는 최소 기능으로 동작한다.
- UDP가 제공하는 기능
- 다중화/역다중화
- 간단한 오류 검사 기능
- → IP에 아무것도 추가하지 않는다.
- UDP를 사용한다는 것은 거의 IP와 직접 통신하는 것과 같다.
데이터 전달 과정
- 애플리케이션 프로세스로부터 메시지를 가져와서 세그먼트를 생성하여 네트워크 계층으로 넘김
- 세그먼트의 구성
- 다중화/역다중화 서비스에 대한 출발지 포트 번호 필드와 목적지 포트 번호 필드
- 다른 2개의 필드
- 세그먼트의 구성
- 네트워크 계층은 세그먼트를 IP 데이터그램으로 캡슐화하고, 수신 호스트에게 전달하기 위해 최선을 다한다.
- 세그먼트가 수신 호스트에 도착
- UDP는 데이터 전달을 위해 목적지 포트 번호를 사용해 애플리케이션 프로세스를 찾는다.
- UDP는 세그먼트를 송신하기 전에 송신과 수신 계층 개체 간의 핸드셰이크를 하지 않는다.
→ UDP가 비연결형으로 불리는 이유
DNS
- DNS는 UDP를 사용하는 애플리케이션 계층 프로토콜
사용 과정
- DNS 애플리케이션의 질의를 생성할 때, DNS 질의 메시지를 작성하고 UDP에게 넘겨준다.
- 메시지에 헤더 필드를 추가한 후 최종 세그먼트를 네트워크 계층에게 넘겨준다.
- 목적지 종단 시스템에서 동작하는 UDP 개체 ↔ 호스트 UDP 사이에는 핸드셰이크 X
- 목적지 종단 시스템에서 동작하는 UDP 개체 ↔ 호스트 UDP 사이에는 핸드셰이크 X
- 네트워크 계층은 UDP 세그먼트를 데이터그램으로 캡슐화하고 네임 서버에 송신
- 이때, 질의 호스트에서의 DNS 애플리케이션은 질의에 대한 응답을 기다린다.
- 질의 호스트가 응답을 수신하지 못하는 경우
→ 질의를 다른 네임 서버로 송신하거나, 송신 애플리케이션에게 통보
- 질의 호스트가 응답을 수신하지 못하는 경우
- 이때, 질의 호스트에서의 DNS 애플리케이션은 질의에 대한 응답을 기다린다.
애플리케이션에 UDP가 선호되는 이유
- 애플리케이션은 UDP를 사용하고, UDP의 기본 세그먼트 전달 외에 필요한 추가 기능을 구현할 수 있다.
1. 무슨 데이터를 언제 보낼지에 대해 애플리케이션 레벨에서 더 정교한 제어
- 애플리케이션 프로세스가 데이터를 UDP에게 전달하자마자 즉시 네트워크 계층으로 전달
- UDP가 데이터를 UDP 세그먼트로 만든다.
- UDP가 데이터를 UDP 세그먼트로 만든다.
- TCP의 서비스 모델은 애플리케이션의 요구와는 맞지 않는다.
- 실시간 애플리케이션은 최소 전송률을 요구할 수도 있다.
- TCP는 혼잡 제어 메커니즘을 사용한다.
→ 목적지 호스트와 출발지 호스트 사이의 링크가 혼잡해지면 TCP 송신자를 제한
- TCP는 혼잡 제어 메커니즘을 사용한다.
- 실시간 애플리케이션은 지나치게 지연되는 세그먼트 전송을 원하지 않는다.
- TCP는 신뢰적인 전달을 사용
→ 시간에 관계없이 목적지가 세그먼트의 수신 여부를 확인 응답할 때까지 세그먼트를 재전송
- TCP는 신뢰적인 전달을 사용
- 실시간 애플리케이션은 최소 전송률을 요구할 수도 있다.
2. 연결 설정이 없음
- UDP는 공식적인 사전준비 없이 전송한다. → 연결을 설정하기 위한 어떤 지연이 없다.
- DNS가 TCP보다 UDP에서 동작하는 이유
- DNS가 TCP보다 UDP에서 동작하는 이유
- QUIC(Quick UDP Internet Connection) 프로토콜은 기본적으로 UDP 사용하고,
UDP 위에 애플리케이션 계층 프로토콜의 안정성을 구현- 웹 페이지는 신뢰성이 중요해서 원래 TCP 연결을 사용함
← But, TCP 연결 설정 지연으로 심각한 웹 문서 다운로드 지연 문제 발생
- 웹 페이지는 신뢰성이 중요해서 원래 TCP 연결을 사용함
3. 연결 상태가 없음
- UDP는 연결 상태를 유지하지 않으며 여러 파라미터에 어떤 것도 기록하지 않는다.
→ 특정 애플리케이션 전용 서버는 UDP로 동작할 때 더 많은 액티브 클라이언트 수용 가능
4. 작은 패킷 헤더 오버헤드
- TCP → 세그먼트마다 20바이트의 헤더 오버헤드
- UDP → 세그먼트마다 8바이트의 오버헤드
TCP와 UDP 중 어떤 걸 사용해야 할까
- 모든 애플리케이션은 TCP의 신뢰적인 데이터 전송 서비스가 필요하다.
- 예 : 전자메일, 원격 터미널 접속, 웹, TCP 상의 파일 전송 등
- 예 : 전자메일, 원격 터미널 접속, 웹, TCP 상의 파일 전송 등
- 최선 버전의 HTTP
→ UDP를 통해 실행되어 애플리케이션 계층에서 자체 오류 제어 및 혼잡 제어를 제공- But, 많은 중요한 애플리케이션은 TCP보다 UDP에서 동작함
- 예 : 네트워크 관리 데이터를 전달하는데 UDP를 사용
- 예 : 네트워크 관리 데이터를 전달하는데 UDP를 사용
- But, 많은 중요한 애플리케이션은 TCP보다 UDP에서 동작함
- 네트워크 관리 애플리케이션의 네트워크가 혼잡한 상태에 있는 경우
→ 자주 동작해야 하므로 이런 경우엔 TCP를 사용해야 함
멀티미디어 애플리케이션에서의 사용
- UDP와 TCP는 멀티미디어 애플리케이션에서 종종 사용됨
- 예 : 인터넷 전화, 실시간 비디오 회의, 저장된 오디오와 비디오의 스트리밍
- 예 : 인터넷 전화, 실시간 비디오 회의, 저장된 오디오와 비디오의 스트리밍
- 멀티미디어 애플리케이션에서는 적은 양의 패킷 손실은 허용한다.
→ 신뢰적인 데이터 전송이 애플리케이션 성능에 중요한 것만은 아님 - TCP 혼잡 제어는 실시간 애플리케이션들에게 나쁜 영향
→ 애플리케이션을 UDP에서 동작하도록 구현 - 패킷 손실률이 낮아야 하고, 보안 측면의 이유로 UDP 트래픽을 막는 기관도 있음
→ 이러한 기관은 TCP를 사용하여 스트리밍 매체를 전송
QUIC 프로토콜의 탄생 배경
- UDP는 혼잡 제어를 제공하지 않음 → 네트워크가 폭주 상태에 빠지는 것을 막을 수 없음
- UDP 송신자와 수신자 간의 높은 손실률을 초래
- TCP 세션의 혼잡이 발생할 수도 있음
- 다수가 높은 비트의 비디오 스트리밍 → 라우터에 많은 패킷 오버플로 발생
→ 대부분의 UDP 패킷이 목적지에 도착하지 못함 → UDP의 높은 손실률 발생
→ 손실률 감소를 위해 TCP 송신자들의 속도를 낮춤
- UDP 출발지를 포함한 모든 출발지가 적응 혼잡 제어를 수행하게 하는 프로토콜 개발
→ QUIC 탄생
- 애플리케이션이 신뢰성을 애플리케이션 자체에서 제공하는 경우 신뢰적 데이터 전송 가능
→ UDP를 사용할 때도 신뢰적 데이터 전송이 가능하다. - 애플리케이션 프로세스들은 TCP 혼잡 제어 메커니즘에 의해 전송률 억제를 강요당하지 않고,
신뢰적으로 통신할 수 있다.
- 애플리케이션이 신뢰성을 애플리케이션 자체에서 제공하는 경우 신뢰적 데이터 전송 가능
UDP 세그먼트 구조
- 애플리케이션 데이터는 UDP 데이터그램에 데이터 필드에 위치
- 예시
- DNS → 데이터 필드에 질의 메시지나 응답 메시지를 포함
- 스트리밍 오디오 애플리케이션 → 데이터 필드에 오디오 샘플을 채움
- 예시
- UDP 헤더는 2바이트씩 구성된 4개의 필드를 갖는다.
포트 번호
: 목적지 호스트가 목적지 종단 시스템에서 동작하는 프로세스에게 데이터를 넘기게 해 줌체크섬(checksum)
: 세그먼트에 오류가 발생했는지 검사하기 위해 수신 호스트가 사용- UDP 세그먼트 이외에 IP 헤더의 일부 필드도 계산
- UDP 세그먼트 이외에 IP 헤더의 일부 필드도 계산
길이 필드
: 헤더를 포함하는 UDP 세그먼트의 길이(바이트 단위)를 나타냄
UDP 체크섬
- 출발지에서 목적지로 이동했을 때, UDP 세그먼트 안의 비트에 대한 변경사항이 있는지 검사
체크섬 구성 방식
- 송신자 측에서 UDP는 안에 있는 모든 16비트 워드가 합산에 대해 다시 1의 보수를 수행한다.
- 만약 오버플로가 발생하면 윤회식 자리올림(wrap around)
- 만약 오버플로가 발생하면 윤회식 자리올림(wrap around)
- 다음과 같은 3개의 16비트 워드가 있다고 가정
- 0110011001100000
- 0101010101010101
- 1000111100001100
- 1의 보수 → 모든 0을 1로 변환하고, 모든 1을 0으로 변환하면 됨
- 1의 보수한 값이 체크섬이 됨
- 수신자에서 체크섬을 포함한 4개의 모든 16비트 워드가 더해짐
- 오류가 없는 경우 → 수신자의 합은 1111111111111111이 됨
- 오류가 있는 경우 → 수산자의 합의 비트 중 하나라도 0이 존재
UDP가 체크섬을 제공하는 이유
- 출발지와 목적지 사이의 모든 링크가 오류 검사를 제공한다는 보장이 없기 때문
→ 링크 중 하나가 오류 검사를 제공하지 않는 프로토콜을 사용할 수도 있다.
- 주어진 링크 간의 신뢰성과 메모리의 오류 검사가 보장되지 않고,
종단 간의 데이터 전송 서비스가 오류 검사를 제공해야 하는 경우
→ UDP가 종단 기반으로 트랜스포트 계층에서 오류 검사를 제공해야 함(종단과종단의 원칙
)종단과 종단의 원칙(end-end principle)
- 어떤 기능이 종단 기반으로 구현되어야 하므로, 하위 레벨에 있는 기능들은
상위 레벨에서 이들을 제공하는 비용과 비교했을 때 중복되거나 거의 가치가 없을 수 있다.
- 어떤 기능이 종단 기반으로 구현되어야 하므로, 하위 레벨에 있는 기능들은
- 주어진 링크 간의 신뢰성과 메모리의 오류 검사가 보장되지 않고,
- IP는 어떠한 2 계층 프로토콜에서도 동작해야 함 → 트랜스포트 계층은 안전장치로 오류 검사를 제공
- UDP는 오류 검사를 제공하지만, 오류를 회복하기 위한 어떤 일도 하지 않는다.
- 손상된 세그먼트를 버리기도 하고, 경고와 함께 손상된 세그먼트를 그대로 넘기기도 함