호우동의 개발일지

Today :

article thumbnail

UDP - 최소 기능의 트랜스포트 계층 프로토콜

  • UDP는 트랜스포트 계층 프로토콜이 할 수 있는 최소 기능으로 동작한다.
  • UDP가 제공하는 기능
    • 다중화/역다중화
    • 간단한 오류 검사 기능
    • → IP에 아무것도 추가하지 않는다.

  • UDP를 사용한다는 것은 거의 IP와 직접 통신하는 것과 같다.

 


데이터 전달 과정

  1. 애플리케이션 프로세스로부터 메시지를 가져와서 세그먼트를 생성하여 네트워크 계층으로 넘김
    • 세그먼트의 구성
      • 다중화/역다중화 서비스에 대한 출발지 포트 번호 필드목적지 포트 번호 필드
      • 다른 2개의 필드

  2. 네트워크 계층은 세그먼트를 IP 데이터그램으로 캡슐화하고, 수신 호스트에게 전달하기 위해 최선을 다한다.
  3. 세그먼트가 수신 호스트에 도착
  4. UDP는 데이터 전달을 위해 목적지 포트 번호를 사용해 애플리케이션 프로세스를 찾는다.
  • UDP는 세그먼트를 송신하기 전에 송신과 수신 계층 개체 간의 핸드셰이크를 하지 않는다.
    → UDP가 비연결형으로 불리는 이유

 


DNS

  • DNS는 UDP를 사용하는 애플리케이션 계층 프로토콜

사용 과정

  1. DNS 애플리케이션의 질의를 생성할 때, DNS 질의 메시지를 작성하고 UDP에게 넘겨준다.
  2. 메시지에 헤더 필드를 추가한 후 최종 세그먼트를 네트워크 계층에게 넘겨준다.
    • 목적지 종단 시스템에서 동작하는 UDP 개체 ↔ 호스트 UDP 사이에는 핸드셰이크 X

  3. 네트워크 계층은 UDP 세그먼트를 데이터그램으로 캡슐화하고 네임 서버에 송신
    • 이때, 질의 호스트에서의 DNS 애플리케이션은 질의에 대한 응답을 기다린다.
      • 질의 호스트가 응답을 수신하지 못하는 경우
        → 질의를 다른 네임 서버로 송신하거나, 송신 애플리케이션에게 통보

 


애플리케이션에 UDP가 선호되는 이유

  • 애플리케이션은 UDP를 사용하고, UDP의 기본 세그먼트 전달 외에 필요한 추가 기능을 구현할 수 있다.

1. 무슨 데이터를 언제 보낼지에 대해 애플리케이션 레벨에서 더 정교한 제어

  • 애플리케이션 프로세스가 데이터를 UDP에게 전달하자마자 즉시 네트워크 계층으로 전달
    • UDP가 데이터를 UDP 세그먼트로 만든다.

  • TCP의 서비스 모델은 애플리케이션의 요구와는 맞지 않는다.
    • 실시간 애플리케이션은 최소 전송률을 요구할 수도 있다.
      • TCP는 혼잡 제어 메커니즘을 사용한다.
        → 목적지 호스트와 출발지 호스트 사이의 링크가 혼잡해지면 TCP 송신자를 제한

    • 실시간 애플리케이션은 지나치게 지연되는 세그먼트 전송을 원하지 않는다.
      • TCP는 신뢰적인 전달을 사용
        → 시간에 관계없이 목적지가 세그먼트의 수신 여부를 확인 응답할 때까지 세그먼트를 재전송

2. 연결 설정이 없음

  • UDP는 공식적인 사전준비 없이 전송한다. → 연결을 설정하기 위한 어떤 지연이 없다.
    • DNS가 TCP보다 UDP에서 동작하는 이유

  • QUIC(Quick UDP Internet Connection) 프로토콜은 기본적으로 UDP 사용하고,
    UDP 위에 애플리케이션 계층 프로토콜의 안정성을 구현
    • 웹 페이지는 신뢰성이 중요해서 원래 TCP 연결을 사용함
      ← But, TCP 연결 설정 지연으로 심각한 웹 문서 다운로드 지연 문제 발생

3. 연결 상태가 없음

  • UDP는 연결 상태를 유지하지 않으며 여러 파라미터에 어떤 것도 기록하지 않는다.
    → 특정 애플리케이션 전용 서버는 UDP로 동작할 때 더 많은 액티브 클라이언트 수용 가능

4. 작은 패킷 헤더 오버헤드

  • TCP → 세그먼트마다 20바이트의 헤더 오버헤드
  • UDP → 세그먼트마다 8바이트의 오버헤드

 


TCP와 UDP 중 어떤 걸 사용해야 할까

TCP와 UDP를 사용하는 애플리케이션 분류
TCP와 UDP를 사용하는 애플리케이션 분류

  • 모든 애플리케이션은 TCP의 신뢰적인 데이터 전송 서비스가 필요하다.
    • 예 : 전자메일, 원격 터미널 접속, 웹, TCP 상의 파일 전송 등

  • 최선 버전의 HTTP
    → UDP를 통해 실행되어 애플리케이션 계층에서 자체 오류 제어 및 혼잡 제어를 제공
    • But, 많은 중요한 애플리케이션은 TCP보다 UDP에서 동작함
      • 예 : 네트워크 관리 데이터를 전달하는데 UDP를 사용

  • 네트워크 관리 애플리케이션의 네트워크가 혼잡한 상태에 있는 경우
    → 자주 동작해야 하므로 이런 경우엔 TCP를 사용해야 함

멀티미디어 애플리케이션에서의 사용

  • UDP와 TCP는 멀티미디어 애플리케이션에서 종종 사용됨
    • 예 : 인터넷 전화, 실시간 비디오 회의, 저장된 오디오와 비디오의 스트리밍

  • 멀티미디어 애플리케이션에서는 적은 양의 패킷 손실은 허용한다.
    → 신뢰적인 데이터 전송이 애플리케이션 성능에 중요한 것만은 아님

  • TCP 혼잡 제어는 실시간 애플리케이션들에게 나쁜 영향
    → 애플리케이션을 UDP에서 동작하도록 구현

  • 패킷 손실률이 낮아야 하고, 보안 측면의 이유로 UDP 트래픽을 막는 기관도 있음
    → 이러한 기관은 TCP를 사용하여 스트리밍 매체를 전송

QUIC 프로토콜의 탄생 배경

  • UDP는 혼잡 제어를 제공하지 않음 → 네트워크가 폭주 상태에 빠지는 것을 막을 수 없음
    • UDP 송신자와 수신자 간의 높은 손실률을 초래
    • TCP 세션의 혼잡이 발생할 수도 있음
    • 다수가 높은 비트의 비디오 스트리밍 → 라우터에 많은 패킷 오버플로 발생
      → 대부분의 UDP 패킷이 목적지에 도착하지 못함 → UDP의 높은 손실률 발생
      → 손실률 감소를 위해 TCP 송신자들의 속도를 낮춤

  • UDP 출발지를 포함한 모든 출발지가 적응 혼잡 제어를 수행하게 하는 프로토콜 개발
    → QUIC 탄생
    • 애플리케이션이 신뢰성을 애플리케이션 자체에서 제공하는 경우 신뢰적 데이터 전송 가능
      → UDP를 사용할 때도 신뢰적 데이터 전송이 가능하다.

    • 애플리케이션 프로세스들은 TCP 혼잡 제어 메커니즘에 의해 전송률 억제를 강요당하지 않고,
      신뢰적으로 통신할 수 있다.

 

 


UDP 세그먼트 구조

UDP 세그먼트 구조

  • 애플리케이션 데이터는 UDP 데이터그램에 데이터 필드에 위치
    • 예시
      • DNS → 데이터 필드에 질의 메시지나 응답 메시지를 포함
      • 스트리밍 오디오 애플리케이션 → 데이터 필드에 오디오 샘플을 채움

  • UDP 헤더는 2바이트씩 구성된 4개의 필드를 갖는다.
  • 포트 번호 : 목적지 호스트가 목적지 종단 시스템에서 동작하는 프로세스에게 데이터를 넘기게 해 줌
  • 체크섬(checksum) : 세그먼트에 오류가 발생했는지 검사하기 위해 수신 호스트가 사용
    • UDP 세그먼트 이외에 IP 헤더의 일부 필드도 계산

  • 길이 필드 : 헤더를 포함하는 UDP 세그먼트의 길이(바이트 단위)를 나타냄

 

 


UDP 체크섬

  • 출발지에서 목적지로 이동했을 때, UDP 세그먼트 안의 비트에 대한 변경사항이 있는지 검사

체크섬 구성 방식

  • 송신자 측에서 UDP는 안에 있는 모든 16비트 워드가 합산에 대해 다시 1의 보수를 수행한다.
    • 만약 오버플로가 발생하면 윤회식 자리올림(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는 오류 검사를 제공하지만, 오류를 회복하기 위한 어떤 일도 하지 않는다.
    • 손상된 세그먼트를 버리기도 하고, 경고와 함께 손상된 세그먼트를 그대로 넘기기도 함