UDP는 트랜스포트 게층 프로토콜이 할 수 있는 최소 기능으로 동작한다.UDP는 애플리케이션 프로세스로부터 메시지를 가져와서 다중화/역다중화 서비스에 대한 출발지 포트 번호 필드와 목적지 포트 번호 필드를 첨부하고 다른 두 필드들을 추가한 후에 최종 세그먼트를 네트워크 게층으로 넘겨준다. 네트워크 계층은 트랜스포트 계층 세그먼트를 IP 데이터그램으로 캡슐화하고, 세그먼트를 수신 호스트에게 "최선형" 전달 서비스로 전달한다.만약 세그먼트가 수신 호스트에 도착한다면, UDP는 세그먼트의 데이터를 해당하는 애플리케이션 프로세스로 전달하기 위해서 목적지 포트 번호를 사용한다. UDP는 세그먼트를 송신하기 전에 송신 트랜스포트 계층 개체들과 수신 트랜스포트 계층 개체들 사이에 핸드셰이크를 사용하지 않는다. 이런 이유로 UDP를 비연결형성이다.
DNS는 일반적으로 UDP를 사용하는 애플리케이션 계층 프로토콜의 예이다. 호스트에서 DNS 애플리케이션이 질의를 생성할 때, DNS 질의 메시지를 작성하고 UDP에게 메시지를 넘겨준다. 목적지 종단 시스템 상에서 동작하는 UDP 개체와 호스트 측 UDP는 어떠한 핸드셰이크도 수행하지 않고 메시지에 헤더 필드를 추가한 후에 최종 세그먼트를 네트워크 계층에 넘겨준다. 네트워크 계층은 UDP 세그먼트를 데이터그램으로 캡슐화하고 네임서버에 데이터그램을 송신한다. 이때, 질의 호스트에서 DNS애플리케이션은 질의에 대한 응답을 기다린다. 만약 질의 호스트
응답을 송신하지 못하면, 질의를 다른 네임 서버로 송신하거나 요청한 애플리케이션으로 응답을 수신할 수 없다는 것을 통보한다.
그러면 왜 TCP보다 UDP 방식으로 개발하고 싶어할까.
1. 무슨 데이터를 언제 보낼지에 대해 애플리케이션 레벨에서 더 정교한 제어가 가능하다. UDP하에서 APP 프로세스가 데이터를 UDP에게 전달하자마자 UDP는 즉시 데이터를 세그먼트로 만들고 네트워크 게층으로 전달한다. 하지만 TCP는 혼잡제어 매커니즘을 가지고 있다. 혼잡제어는 TCP 송신자를 조절한다. 그리고 확인응답할 때까지 세그먼트 재전송을 계속할 것이다. 실시간 애플리케이션은 종종 최소 전송률을 요구하고, 세그먼트 지연을 원하지 않기 때문에 TCP랑 맞지 않는다. 또한 기본 세그먼트 전달 외에 추가 기능을 구현할 수 있다.
2. 연결 설정이 없다. TCP는 세 방향 핸드셰이크를 사용한다. 하지만 UDP는 바로 전달박는다. 따라서 어떠한 지연도 없다. 만약 DNS가 TCP에서 동작하면 많이 느려질 것이다. HTTP 문서로 된 웹페이지는 신뢰성이 중요해서 TCP를 사용한다.
3. 연결 상태가 없다. TCP는 연결 상태를 유지한다. 연결 상태는 수신 버퍼 및 송신 버퍼, 혼잡제어 파라미터, 순서번호와 확인응답 번호 파라미터를 포함한다. 상태 정보는 TCP의 신뢰적인 데이터 전송 서비스를 구현하고 혼잡 제어를 제공하기 위해서 필요하다. UDP는 연결 상태를 유지하지 않기 때문에 필요없다. 그래서 일반적으로 TCP보다 UDP에서 동작하는 서버가 더 많은 클라이언트를 수용할 수 있다.
4. 작은 패킷 헤더 오버헤드이다. TCP가 세그먼트마다 20바이트의 헤더 오버헤드를 갖는 반면 UDP는 단지 8바이트의 오버헤드를 가진다.
몰론 혼잡제어나 신뢰성을 보장하지 않으면 빠르지만 결국 데이터를 손실할 확률이 있다는 뜻이 된다. 그리고 UDP도 신뢰적인 데이터 전송이 가능하다. 애플리케이션이 신뢰성을 애플리케이션 자체에서 제공한다면 신뢰적인 데이터 전송을 할 수 있다.
애플리케이션 데이터는 UDP 데이터그램의 데이터 필드에 위치한다. 예를 들면, DNS에 대한 데이터필드에는 질의 메시지나 응답 메시지를 포함한다. 스트리밍 오디오 앱은 오디오 샘플이 데이터 필드를 채운다. UDP 헤더는 2바이트씩 구성된 4개의 필드를 가진다. 포트 번호는 목적지 호스트가 목적지 종단 시스템에서 동작하는(역다중화 기능을 수행하는) 정확한 프로세스에게 애플리케이션 데이터를 넘기게 해 준다. 체크섬(checksum)은 세그먼트에 오류가 발생했는지를 검사하기 위해 수신 호스트에 의해서 사용된다. 사실 체크섬은 UDP 세그먼트 이외에 IP 헤더의 일부 필드도 계산한다.
체크섬을 사용하는 이유는 링크 게층 프로토콜(이더넷 프로토콜을 포함)이 오류 검사를 제공하는데, 왜 UDP가 체크섬을 제공하는지 궁금할 것이다. 이유는 출발지와 목적지 사이에 모든 링크가 오류 검사를 제공한다는 보장이 없기 때문이다. 링크 중에서 오류 검사를 제공하지 않는 프로토콜을 사용할 수도 있는 것이다. 세그먼트가 라우터의 메모리에 저장될 때 비트 오류가 들어오는 것이 가능하다. 주어진 링크 간의 신뢰성과 메모리의 오류 검사가 보장되지 않기 때문에, 종단간의 데이터 전송 서비스가 오류 검사를 제공한다면, UDP는 종단간의 트랜스포트 계층에서 오류 검사를 제공해야만 한다.
즉 체크섬을 사용하면 데이터가 변형되지 않았음은 보장하지만 순서대로 갔는지, 유실되었는지는 보장하지 않는다.
IP는 어떤 3-계층 프로토콜에서도 동작해야 하므로, 트랜스포트 계층은 안전장치로써 오류 검사를 제공한다. UDP는 오류 검사를 제공하지만 오류를 회복하기 위한 어떤 일도 하지 않는다. 즉
라우트 : 최단 경로
라우팅 : 최단 경로를 찾아 가는 과정
포워딩 : 패킷안에 포트번호로 라우터에 출력링크를 결정해 주는 행동
정리하면 다음과 같다.
구분 | TCP | UDP |
---|---|---|
혼잡, 흐름제어 | O | X |
순서보장 | O | X |
신뢰성(수신 여부확인) | O | X |
패킷 교환 방식 | 가상 회선 | 데이터그램 |
속도 느림 | 느리다 | 빠르다 |
사용처 | 연속성보다 신뢰성이 중요할 때(파일 전송, 이메일) | 신뢰성보다 연속성이 중요할 때(실시간 스트리밍, Multicast,DNS |
DNS 애플리케이션 클라이언트측에서 브라우저는 URL로부터 호스트 네임 ww.someschool.eud를 추출하고 그 호스트 네임을 DNS 애플리케이션의 클라이언트측에 넘긴다. 그리고 DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보낸다. 그러면 클라이언트는 호스트 네임에 대한 IP 주소를 가진 응답을 받게 된다. 브라우저가 DNS로부터 IP 주소를 받으면, 브라우저는 그 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.