[김효곤 교수의 인터넷 프로토콜] 9. User Datagram Protocol(UDP)

17 May 2021 • Internet Protocol

User Datagram Protocol(UDP)

### 9.0 UDP 개관

  • 트랜스포트(4) 계층 프로토콜 중 두번째로 많이 사용됨 (ex - IPTV 중 실시간 방송)
    • 응용 프로세스간 통신을 지원하는 커널 내의 최상위 계층
      • 응용 프로그램들과 직접 맞닿는 위치에 있다.
        • 응용들은 트랜스포트와 인터페이스를 하고 있어서 이 중 어떤 트랜스포트 프로토콜을 사용할 것인지는 응용 계층의 특성에 따라 정해진다.
        • TCP와 UDP는 제공하는 서비스의 성질이 완전히 다르기 때문에, 응용이 이 중 어떤 서비스를 원하느냐에 따라 커널에서 소켓 인터페이스를 열 때 소켓의 종류가 정해진다.
      • 계단을 오르내리듯
    • IP 프로토콜 번호 17

  • 출발지 : DNS -(53)-> UDP -(17)-> IP -(0x0800) -> Ethernet -> 물리
  • 도착지 : 물리 -> Ethernet -(0x0800)-> IP -(17)-> UDP -(53)-> DNS
  • 출발지와 도착지를 제외한 라우터에서는 3계층까지만 왔다갔다 함

9.1 UDP 프로토콜 개요

  • TCP에 이어 2번째로 많이 사용되는 트랜스포트 프로토콜
  • 무연결(connectionless) 프로토콜 : 데이터를 주고받기 전에 connection을 해주지 않아도 됨
    • connection : 회선 연결처럼 물리적인 것x, 논리적인 개념 - ‘관리’
      • 잃어버린 패킷 관리, 전송 속도 관리 등
      • 데이터 전송의 제반 사항에 대해서 전송자와 수신자가 같은 이해를 갖도록 관리해줌
      • 유저 계층에서 내려온 데이터에 대해서 헤더만 8바이트 붙여서 IP에 밀어넣는 것이 다임
      • 무책임한 프로토콜
    • Multiplexing/demultiplexing 외에 해 주는 게 없다
      • Multiplexing : 출발지에서는 발신자의 포트 번호를 적어줌
      • Demultiplexing : 포트 번호를 확인하여 역방향으로 데이터를 보내주는 것
      • multiplexing demultiplexing이 없다면?
        • IP 에서 응용프로토콜로 점프를 해야한다. 중간다리가 없어지는 것. 트랜스포트 계층은 이 중간계단의 역할로서 필요하다.
    • Checksum : 선택 (IPv4) vs. 의무 (IPv6)
  • 용도
    • 실시간: 예) 인터넷 전화와 같이 interactive한 것, 스트리밍 X
      • deadline이 존재 : 특정 시간 안에 데이터의 전송이 완료되지 않으면 사용자가 delay를 느껴서 불편
      • headup line delay : TCP는 신뢰적인 전달을 목표로 하기 때문에 보내는 데이터가 확실히 전송되지 않으면 다음 데이터가 전송되지 않는다.
      • UDP는 데이터가 잘 전송되지 않았다면 죽이고 다음 데이터를 빨리 전송하는 편을 선택
    • 간단한 트랜잭션 : 예) DNS, DHCP, SNMP
      • 옛날에 설계된 응용 계층의 프로토콜들은 하나의 질문에 대해서 하나의 답변을 듣는 정도의 간단한 트랜잭션
      • TCP : TCP는 아무정보를 주고받지 않아도 연결(connection) 맺고 끊는데만 7개의 패킷을 주고 받으므로 이러한 간단한 트랜잭션에 대해서는 비효율적
    • 멀티캐스트/브로드캐스트 : 예) IPTV
      • TCP를 사용할 수 없는 경우 - TCP는 1:1 traffic 교환용 프로토콜이므로 멀티캐스트나 브로드캐스트는 TCP를 사용할 수가 없다.

Q : IP 프로토콜 번호가 정해지는 기준이 있나요? UDP는 두번째로 많이 쓰이는 데 17번이라서 궁금합니다. A : 17번이면 꽤 초기의 프로토콜이다. 예전에는 TCP와 UDP가 한덩어리의 프로토콜이었는데 분화되면서 이 순서에따라 일련번호가 붙은 것이다. IANA에 이 프로토콜 번호 정보들이 모두 관리되고 있다.

Q : 비디오 real time stream의 경우도 현재는 tcp 기반의 rtsp 프로토콜을 주로 쓴다고 본 것 같은데 tcp 속도가 많이 느린가요? A : RTSP는 데이터를 실어나르는 프로토콜이 아니라, 컨트롤 프로토콜이다. 스트리밍의 경우에는 초기에는 UDP를 사용했으나 요즘은 TCP를 사용한다. 버퍼를 사용하기 시작하면서. 네트워크 상황에 따라서 몰려들어오기도 하고 안들어오는 순간도 있는데 이를 조절하기 위해 버퍼를 사용한다. 흔히 착각하는 것이 TCP 속도가 느려서 사용되지 않는다고들 생각하는데, 아니다. TCP는 계속 재전송하려고 하니까 못쓰는 것이지 TCP가 UDP보다 속도가 느리진 않다.

9.2 UDP 데이터그램 형식

  • 헤더의 복잡도는 프로토콜의 복잡도에 비례한다.
    • 포트 번호 두개 : multiplexing/demultiplexing을 위한 것
    • UDP 데이터그램의 길이
    • 체크섬 : IP는 헤더 체크섬은 IP 페이로드 부분을 책임지지 않기 때문에 존재하지만, optional이므로 UDP가 하지 않기로 선언한다면 하지 않는다.

  • 포트 번호 = 트랜스포트 계층의 “주소”
    • 0은 사용하지 않음
    • Private/Dynamic : 특별한 경우가 아니면 잘 사용되지 않는 영역
      • 황야나 벌판처럼 이 포트 번호를 사용하는 프로세스들이 없다.
      • 불법성이 있는 P2P, 트로이목마 해킹 프로그램들이 여기에 숨어서 활동한다고 한다.
      • 윈도우는 tracert를 할 때 ping과 같이 ICMP를 사용해서 구현하지만, 리눅스는 UDP를 사용한다. 포트 번호를 이 범위에서 한 서너개 골라서 TTL을 낮게 설정한 다음 패킷을 보낸다. 이 때, tracert의 중간 단계에서는 time exceed 에러가 발생되면서 중간 경로들을 하나씩 찾아내지만, 결국 도착지에 다다랐을 때에는 해당 포트 번호에 프로세스가 돌고 있지 않을 가능성이 크기 때문에, ICMP Port Unreachable 에러가 발생할 것이다. 따라서 송신측에서 ICMP Port Unreachable 에러를 받으면 패킷이 도착지에 도착했다고 인식한다.

9.2 UDP 데이터그램 형식

  • Well-known 포트 : 서버용(서비스 공급자용)
    • IANA에 등록 - 함부로 사용하면 안됨
    • 잘 알려진 서비스들을 위한 것: 예) DNS = 53
  • Registered 포트 : 다양한 프로세스들이 사용하는 것 클라이언트 프로그램
    • 소켓에 바인딩을 안할 경우, 커널에서 자체적으로 포트 번호를 할당해주는데, 이 범위 내에서 할당된다.
    • IANA에 등록
    • 클라이언트 사용 가능 : 예) ephemeral 포트
      • 클라이언트 프로그램에도 프로그램이 사용하는 인터페이스(커널쪽으로 TCP/UDP와 연결되기 위한 인터페이스로 소켓이 대표적임)와 연결될 때 사용하는 포트 번호도 이 범위에 해당한다.
      • ephemeral 포트 : 임시적으로 사용 ↔ 서버 포트 “영구적”
  • Private/dynamic 포트 : 특별한 경우가 아니면 잘 사용되지 않는 영역
    • 사용에 특별한 제약 없으나 많이 사용되지 않음
      • 이 포트 번호를 사용하는 프로세스들이 거의 없다.
    • P2P나 Trojan 등 불법성 프로그램이 사용
    • Linux traceroute : 윈도우는 tracert를 할 때 ping과 같이 ICMP를 사용해서 구현하지만, 리눅스는 UDP를 사용한다. 포트 번호를 이 범위에서 한 서너개 골라서 TTL을 낮게 설정한 다음 패킷을 보낸다. 이 때, tracert의 중간 단계에서는 time exceed 에러가 발생되면서 중간 경로들을 하나씩 찾아내지만, 결국 도착지에 다다랐을 때에는 해당 포트 번호에 프로세스가 돌고 있지 않을 가능성이 크기 때문에, ICMP Port Unreachable 에러가 발생할 것이다. 따라서 송신측에서 ICMP Port Unreachable 에러를 받으면 패킷이 도착지에 도착했다고 인식한다.

9.3 UDP 체크섬

  • UDP 데이터그램 전체 커버
  • IPv4 인터넷에서는 선택 사항
    • 아마도 미디어 (audio/video)를 위해?
      • 오디오나 비디오에 에러가 들어간다해도 살짝의 튐 정도만 생기는 정도로 큰 문제를 발생시키지 않기 때문으로 추측
    • sender가 체크섬을 하지 않기로 하면 receiver도 하면 안된다. 체크 여부를 확인하는 flag가 따로 없고, 다음과 같은 값이면 안하는 것으로 판단
      • 쓰지 않는 경우: checksum = 000….0
    • 쓰는데 하필이면 체크섬 계산한 값이 checksum=000…0인 경우 111…1로 바꾼다
      • 인터넷 체크섬은 1의 보수를 사용하는데, 이 관점에서 둘 다 0!

UDP Length가 중요하지 않은 이유?

UDP length는 UDP 전체 길이인데, 이 길이는 이미 IP 헤더에서 이미 짐작을 할 수가 있다. IP의 Total Length와 헤더 Length 가 있는데 이것을 뺀 길이가 IP 페이로드의 길이로 유추가되기 때문이다. 계층화 원칙에서 IP헤더가 떨어져나갔는데? 근데 그것은 계층화 원칙은 커널이라는 프로그램 안에 구현된 함수일 뿐이다. 즉, 어떤 계층에서든 IP헤더를 들여다 볼 수 있다는 뜻이다.

  • 체크섬 계산에 IP 헤더 일부 포함
    • “Pseudo-header” : UDP 헤더에 추가되는 것은 아님
      • UDP 데이터그램 위에 수도 헤더를 잠깐 씌운 후 전체를 계산한다.
      • TCP에서도 사용
  • Pseudo-header의 원래 목적은 주요 IP 필드 위조 방지
    • UDP 데이터그램 전체를 암호화해서 전달하려 했으나 NSA의 반대로 무산된 (어정쩡한) 결과
      • IP 헤더를 포함해서 암호화하여 변조했더라도 UDP 헤더에서 체크섬 검사할 때 이를 찾아낼 수 있도록
      • IPv6에서 UDP 체크섬이 의무화된 이유 – IP 헤더 체크섬이 없다
        • 오류가 이제 잘 발생하지 않고, 그나마도 데이터링크에서도 CRC가 잘 잡아주고 있었기 때문에 IP 헤더에서 체크섬을 안하기로 했으니, UDP에서 해주는 체크섬이 IP 헤더를 체크해주는 유일한 체크섬이 된 것이다.
        • 체크섬 여부를 선택할 수 있다는 것도 그닥 쓸모가 없었다.

9.4 UDP 데이터그램의 크기

  • UDP를 사용하는 초기 응용 프로토콜: 스스로 메시지 크기 제한
    • 예: DNS -> 512 바이트
    • IPv4에 연결되는 호스트가 지원해야 하는 최소 의무 지원 데이터그램 크기 = 576 바이트
      • 초기의 인터넷 상황을 반영한 값
      • 이때 576에서 IP 헤더 20바이트, UDP 헤더 8바이트를 빼면 548 바이트 정도 남는데, 이 어플리케이션 메시지가 이를 넘어가면 fragmentation이 일어날 수 있다. 그런데 UDP는 fragmentation의 연계를 지원해주지 않기 때문에 fragmentation이 일어나는 상황을 방지하도록 응용 프로토콜이 알아서 메시지 크기를 제한한 것
  • 최근의 인터넷 상황은 다름 : 576 바이트도 처리 못하는 호스트는 없음
    • 경로상의 모든 인터페이스가 지원 가능한 최소 IP 데이터그램 크기가 1500 바이트에 가까움
      • IPTV는 이 바이트를 꽉 채워서 보낸다.
    • 최근 응용 프로토콜들은 이러한 제한을 하지 않음
      • 예: IPTV (12강)
  • UDP는 IP fragmentation을 막기 위한 그 어떤 일도 하지 않음
    • TCP는 이것을 막기 위한 조치로 Path MTU Discovery를 시행하거나, ICMP 에러(Packet Too Big, Fragmentation needed but don’t-fragment bit set)가 나면, 그에 따라 패킷 사이즈를 줄이는 등의 조치를 취한다.
    • 응용 계층 프로토콜이 UDP용 소켓으로 만든 메시지에 8 바이트 UDP 헤더를 붙여 IP로 내리는게 UDP가 하는 모든 일
  • 페이로드가 없는 UDP 데이터그램?
    • Not illegal 에러가 아님
      • Windows, iOS -> 응용에 알리지도 않음
      • Linux, Android -> 알리지만 줄 데이터는 없음

Q : UDP는 packet loss가 큰 문제가 안되는 경우에만 사용되는 건가요? A : UDP를 선택하는 세 가지 케이스를 생각해보면 packet loss가 문제가 안되는 경우는 없지만 덜 문제가 되는 케이스가 실시간 응용 중 미디어 분야인 것이다. 그런데 multicast와 같은 것은 TCP를 사용할 수가 없으므로, 이것은 loss가 나도 괜찮아서 사용하는 경우는 아니다. 이 때에는 응용프로그램쪽에서 책임지고 packet loss를 책임져야한다.

Q : UDP 사용시 loss 여부는 다른 프로토콜을 이용해 아는건가요? A : 패킷 하나하나가 다른 패킷을 가리키지도 않으므로 어떤 패킷이 loss가 됐는지 이런 작업은 응용프로그램이 다 알아서 해야한다. 리니지가 개발되었을 때 UDP를 사용했던 적이 있었는 데 패킷 loss를 모두 프로그램이 직접 관리했어야했다. 결국 TCP로 바꿨다. reliability > 속도 라고 판단한 것이다.

 인터넷, 프로토콜, 그리고 계층화 원칙

Comments

Related Posts