Terminology - 3

Hyeseong·2021년 6월 14일

C&S

목록 보기

4/6

UDP Broadcast
오늘날 프로그래머가 다루는 기술 분야는 매우 다양하고, 실제 프로그래밍에 있어서 프로그래머가 저수준(수준이 낮다는 뜻이 아니라, 추상화가 덜 되었다는 의미로)의 기술 주제를 다루는 일도 드문 일이 되었다. 네트워크 프로그래밍의 경우에도 마찬가지여서 인터넷을 통해 데이터를 주고받거나 하는 작업에 소켓을 직접 사용해서 프로그래밍하는 경우는 흔치 않은 일이 되었고, HTTP 기반으로 하는 네트워크 프로그래밍이 유행하게 되었다. HTTP를 통한 네트워크 프로그래밍은 이해하기 쉽고, 이러한 프로그래밍 작업을 쉽게 해 주는 라이브러리 또한 도처에 널려 있는 것을 볼 수 있다.

그러다보니 TCP니 UDP니 하는 것을 다룰 일도 거의 없어졌고, 요즘에는 대부분의 응용 프로그래머가 네트워크에서의 데이터의 전송은 두 개의 특정 호스트가 1:1로 통신하는 것(=유니캐스트Unicast)이 기본적인 것이라고 인식하고 있는 것 같다. 그렇지만 이러한 1:1 통신은 TCP 프로토콜의 특징이며, 이는 HTTP 프로토콜이 TCP 프로토콜을 기반으로 하고 있기 때문에 TCP 프로토콜과 마찬가지의 특징을 갖고 있는 것 뿐이다.

혹시라도 UDP 프로토콜을 아직 다뤄보지 못한 프로그래머를 위해서 짧게 설명하자면, UDP에서는 유니캐스트 외에도 멀티캐스트(Multicast)와 브로드캐스트(Broadcast) 기능을 제공한다. 이는 그림으로 나타내면 다음과 같다:

멀티캐스트는 자신이 접속한 네트워크 내의 여러 호스트에게 패킷을 전송`하는 것
브로드캐스트는 자신이 접속한 네트워크 내의 모든 호스트에게 패킷을 전송하는 것이다. (이 글에서는 브로드캐스트를 다루고 있는데, 특별한 이유가 있어서기보다는 ... 멀티캐스트보다 브로드캐스트가 간단하기 때문이다)

실제 브로드캐스트로 UDP 패킷을 전송하기 위해서 유니캐스트와 다르게 작업해야 할 부분은 별로 없으며, 패킷을 전송할 IP 주소만 올바로 지정하면 된다. 단순한 상황을 하나 가정해보자. 만약 무선 공유기를 사용하고 있고, 무선 공유기에서 할당받은 IP가 192.168.0.4라고 가정하면, 단순히 192.168.0.255라는 IP 주소를 목적지로 UDP 패킷을 송신하면 된다. 그러면 위에 보인 브로드캐스트의 그림처럼, 해당 무선 공유기에 연결되어 있는 모든 네트워크 기기에 UDP 패킷이 전달된다.

UDP
Client와 Server가 서로 데이터를 주고 받을때 우리는 네트워크상의 수많은 약속(프로토콜)들을 지켜가면서 통신을 하고 있다. 우리가 주고 받는 데이터(패킷)들은 한번에 목적지로 가는 것이 아니라 우리가 잘 알고 있는 인터넷 5계층이나 OSI 7계층을 통과하여 전달된다. 이 포스팅에서는 전송 계층에서 사용하는 대표적인 프로토콜인 UDP에 대해서 알아보고자 한다.

UDP(User Datagram Protocol)

UDP(User Datagram Protocol)는 TCP와 함께 대표적인 전송 계층의 프로토콜이다. UDP의 특징은 TCP처럼 다양한 기능이 있는 것이 아니라 많은 기능을 과감히 생략한 단순함에 있다. UDP의 전송 방식은 너무 단순해서 서비스의 신뢰성이 낮고, 데이터그램 도착 순서가 바뀌거나, 중복되거나, 심지어 통보 없이 누락시키기도 한다. 따라서 UDP는 일반적으로 오류의 검사와 수정이 필요 없는 애플리케이션에서 사용한다고 본다.

패킷과 데이터그램 : 이 둘을 혼용해서 쓰기도 하지만 '패킷'은 일반적인 데이터 덩어리를 지칭한다면, '데이터그램'은 데이터를 전송하는 방식이 불안정하고 전송 실패에 대한 노티피케이션(notification)도 없는, 즉 신뢰할 수 없는 서비스를 통해 전달되는 패킷을 지칭한다. 따라서 UDP 패킷은 패킷보다는 데이터그램이라고 지칭하는 것이 옳다.

UDP의 사용

도메인 이름 서비스(DNS)
IPTV(와 이와 같은 스트리밍 미디어 서비스)
음성 인터넷 프로토콜(VoIP)
TFTP, RTSP, RIP, OSPF
NTP(Network Time Protocol)
IP 터널
많은 온라인 게임 (UDP가 multicast를 지원하므로 가능)

UDP는 브라우저와 인터넷 애플리케이션이 의존하고 있는 도메인 네임 시스템(DNS)에서 사용된다. 브라우저가 데이터 교환을 위해서는 DNS를 통해 컴퓨터의 IP 주소를 알아내야만 하는데, 인터넷에서 매번 요청하는 DNS 서비스에서 UDP에 의존하여 데이터를 전송하고 있었음에도,(물론 TCP라는 신뢰할 수 있는 전송 프로토콜이 있었기 때문이기도 하지만) 웹페이지나 웹 애플리케이션이 UDP를 데이터 전송 수단으로 잘 사용하지 않았었다. 최근 WebRTC(Web Real-Time Communication)가 등장하면서 UDP를 이용해 브라우저 내에서도 음성 통화나 화상 통화, 또는 P2P 통신과 같은 실시간 커뮤니케이션이 가능하게 되었고UDP도 이제 통용되는 브라우저 전송 수단이 되어 가고 있다.

UDP가 Null 프로토콜이라고 불리는 이유

UDP는 NULL 프로토콜이라고도 불린다. 그 이유는 무엇일까. 아래의 UDP 헤더의 구조를 살펴보면 총 8bytes(1bytes = 8bit)로 간단하게 구성되어 있다. 그런데 그마저도 발신지 포트와 체크섬 필드 모두 UDP에서는 선택 입력 필드이다. 아래에서 UDP의 특징에 대해 알아보겠지만 UDP는 네트워크의 혼잡 처리라던가, 패킷 손실에 대한 어떠한 처리도 하지 않는다. UDP가 하는 일이라곤 IP 위 계층에서 통신 호스트의 발신, 수신 애플리케이션 포트를 내장하여 '애플리케이션 다중처리'에 이용하는 것뿐이며, 모든 에러 탐지와 에러 복구가 그 위 계층 애플리케이션에서 이루어진다. 결국 프로토콜치고는 너무 하는 일이 없어서 Null 프로토콜이라고 부르는 것이다.

8Bytes( 출발지 포트, 도착지 포트, 길이, 체크섬 각각 16bits(2bytes)), https://en.wikipedia.org/wiki/User_Datagram_Protocol(wiki)

UDP 특징

메시지를 무사히 운반할 수 있다는 보장이 없음 (응답(Ack), 재전송, 타임아웃 없음)
메시지를 순서대로 운반할 수 없음 (패킷, 시퀀스 넘버, 재정렬, head-of-line(HOL) 블로킹 없음
커넥션 상태 트래킹 없음 (커넥션 성립 혹은 종료 매커니즘 없음)
혼잡 제어 없음 (내장된 클라이언트나 네트워크 피드백 메커니즘 없음)
UDP header, 8Bytes( 출발지 포트, 도착지 포트, 길이, 체크섬 각각 16bits(2bytes)), https://en.wikipedia.org/wiki/User_Datagram_Protocol (wiki)
TCP header, https://en.wikipedia.org/wiki/Transmission_Control_Protocol (wiki)

UDP와 TCP의 비교

Transmission Control Protocol is a connection-oriented protocol(연결형 프로토콜), which means that it requires handshaking to set up end-to-end-communications.
User Datagram Protocol is a simpler message based connectionless and unreliable protocol(비연결형 프로토콜).

TCP는 데이터를 주고 받을 양단 간에 먼저 연결(3-way handshaking)을 설정하고 양방향으로 데이터를 전송하지만, UDP는 따로 연결하지 않고 수신자가 데이터를 받을 준비를 확인하는 단계 없이 단방향으로 정보를 전송한다. TCP는 메시지의 수신을 확인하고 패킷이 유실되거나 수신지로부터 응답이 없을 경우에 데이터를 재전송하지만, UDP는 수신자가 메시지를 수신했는지 확인하지 않으며 따라서 데이터를 재전송하는 일이 없다. TCP에서는 메시지가 보내진 순서를 보장하기 위해서 해당 순서가 아닌 패킷의 경우 TCP 버퍼에 넣어 대기시킨 다음 순서에 맞는 패킷이 왔을 때 재조립하지만, UDP는 메시지 도착 순서를 예측할 수 없다.

TCP는 바이트 스트림 위주의 프로토콜이기 때문에 애플리케이션 메시지의 시작과 끝의 범위를 명시하지 않고 여러 패킷에 걸쳐 전송할 수 있다. 이를 위해 TCP에서는 커넥션의 양쪽 끝에 커넥션 상태를 지정하고 각 패킷에 전송번호를 부여해서, 패킷이 소실되었을 경우 패킷을 해당 순서에 따라 재전송 한다. 반면 UDP 데이터그램은 그 범위가 명확하다. 데이터그램 메시지 하나는 IP 패킷 하나에 완전히 포함되기 때문에, 애플리케이션이 패킷을 하나 읽을 때마다 메시지 전체가 수신된다. 데이터 그램은 TCP에서처럼 조각난(fragmented) 상태로 운반되는 경우는 없다.

UDP는 상태를 유지하지 않는 간단한 프로토콜이며, 다른 애플리케이션 포로토콜을 호출하여 작동시키는 데에 적절하다. 따라서 TCP보다 UDP의 속도가 일반적으로 빠르고 오버헤드가 적다. UDP는 사실상 거의 모든 프로토콜 동작에 관한 디자인 결정 사항을 위 계층의 애플리케이션에 위임했다고 볼 수 있다. UDP는 멀티캐스팅이 지원되어 단일 데이터그램 패킷이 매우 많은 사용자들에게 중복 없이 자동으로 라우팅 될 수 있다.


TCP(Trnsmisson Control Protocol)
인터넷 환경에서 기본으로 사용하는 연결형 서비스를 지원하는 전송 계층 프로토콜이다. 호스트 간 신뢰성 있는 데이터 전달과 흐름제어 및 혼잡 제어 등의 기능을 제공한다.

특징 

가상 회선 연결 방식, 연결형 서비스를 제공
높은 신뢰성 (Sequence Number, Ack Number를 통한 신뢰성 보장)
연결의 설정(3-way handshaking)과 해제(4-way handshaking)
데이터의 순서가 지켜짐
데이터 흐름 제어(수신자 버퍼 오버플로우 방지) 및 혼잡 제어(네트워크 내 패킷 수가 과도하게 증가하는 현상 방지)
전이중(Full-Duplex), 점대점(Point to Point) 서비스
데이터의 경계를 구분 안함
UDP (User Datagram Protocol)
비연결형 서비스를 지원하는 전송계층 프로토콜이다. 인터넷상에서 서로 정보를 주고받을 때 정보를 보내고 응답을 받지 않고 보내는 쪽에서 일방적으로 데이터를 전달하는 통신 프로토콜이다. 보내는 쪽에서는 받는 쪽이 데이터를 받았는지 받지 않았는지 확인할 수 없고, 또 확인할 필요도 없도록 만들어졌다.

특징

비연결형 (port만 확인하여 소켓을 식별하고 송수신, TCP의 hadnshaking 같은 연결 설정이 없음)
비신뢰성
패킷 오버헤드가 적어 네트워크 부하 감소 (전송 속도가 빠름)
데이터의 전송 순서가 바뀔 수 있음
오류검출 (헤더에 오류 검출 필드를 포함하여 무결성 검사)
데이터의 경계를 구분함
데이터의 정소 순서가 바뀔 수 있음
DNS, NFS, SNMP, RIP 등 사용

UDP와 네트워크 주소 변환기(NAT : Network Address translation)

NAT 도입 배경

IPv4의 주소의 길이, 주소 범위, 최대 고유 IP수

IPv4 주소의 길이는 32비트이므로, 제공할 수 있는 최대 고유 IP 수는 약 42억개 정도다. 90년대 초에 인터넷 호스트 수가 기하급수적으로 증가하면서, 모든 호스트에게 고유 IP 주소를 할당할 수 없음이 명백했다. 한정된 Public IP 주소의 고갈 문제를 해결하기 위해 1994년 중반에 제안되어 임시로 도입했던 방법이 바로 네트워크 주소 변환기 NAT(Network Address translation) 이다.

IP 네트워크 주소 변환기 (NAT)

NAT는 내부 네트워크에서 외부 네트워크로 통신을 할 때 IP를 변환하는 기술이다. 변환기 뒤에 있는 로컬 IP 주소 공간을 다른 네트워크가 재사용할 수 있게 하여 주소 부족 문제를 해결한다. 네트워크 끝에 NAT 기기를 설치해서, Private IP와 Port Number를 한 개 이상의 Public IP와 Port Number와 짝지어 관리한다. Private IP는 공유기에서 발급한 IP 주소이므로 외부에서는 이 Private IP로 바로 접근 할 수 없다. 외부에서는 Public IP와 Port Number를 통해 요청하고 위에 그림에서 보는 것처럼 NAT table에서 Public IP, Port Number와 짝을 이루는 Private IP, Port Number를 찾아 주소를 변환시키고 해당 주소로 패킷을 전달해준다.(private에서 public으로 요청할 때도 NAT table을 통해 변환한다).

같은 Private 네트워크에 존재하는 컴퓨터일 경우에는 같은 네트워크 안에 있기 때문에 NAT 없이 Private IP만으로도 통신이 가능하다.

NAT를 이용하는 목적 (필요성)

한정된 공인 IP 부족 문제 해결
외부로부터 내부방 보호

NAT를 이용하면 한정된 인터넷의 Public IP를 다수가 함께 사용함으로써 절약할 수 있다. 내부망에서는 Private(사설) IP를 사용하여 통신을 하고, 외부망과의 통신시에는 NAT를 거쳐 Public IP로 자동 변환된다. 공개된 인터넷망과 사설망 사이에 방화멱을 설치하여 외부 공격으로부터 내부 사용자들을 보호할 수 있다.

NAT는 앞서 말한 것처럼 임시로 도입된 방법이었다. 하지만 많은 기업들과 홈 프록시, 라우터, 보안기기, 방화벽, 그 밖의 수많은 하드웨어와 소프트웨어 기기들에게 보편적인 요소로 자리 잡았고, NAT 미들 장비는 더 이상 임시방편이 아니라, 인터넷 인프라에 없어서는 안 될 부분이 되었다.

NAT와 UDP 사이에 발생하는 문제들

Stateless한 UDP와 커넥션 상태에 따라 작동하는 NAT 간의 문제

UDP에서 NAT 변환 작업을 할 때 가장 큰 문제는 데이터 운반을 위해 라우팅 테이블을 관리해야 한다는 사실이다. 기본적으로 NAT 미들 장비는 커넥션 상태에 따라 작동하는데, 알다시피 (TCP처럼 연결을 위해 handshaking 하거나 연결 종료 절차가 있는게 아니라서) UDP는 커넥션(연결) 상태 정보를 가지고 있지 않다. 따라서 UDP의 데이터그램을 전송하려면 변환기가 상태가 없는 UDP의 흐름 상태를 알고 있어야 한다. 뿐만 아니라 변환기는 변환 레코드를 언제 버려야 하는지도 결정해야 한다. UDP는 커넥션 종료 시퀀스가 없어서 피어가 통보 없이 언제든 데이터그램 전송을 멈출 수 있다. 그래서 변환기는 UDP 라우팅 레코드를 일정 시간이 지나면 자동으로 폐기하는 방법을 사용한다. 결국 UDP에서 장기 세션을 유지하는 가장 좋은 방법은 양방향 킵-얼라이브 패킷을 도입하여 정기적으로 모든 NAT 기기의 변환 레코드 타이머를 리셋하는 것이다(타이머가 다되면 폐기될테니 킵-얼라이브 패킷을 보내 타이머를 다시 리셋해주는 것이다).

NAT와 TCP : TCP 프로토콜은 잘 정의된 핸드셰이크와 연결 종료 시퀀스를 따르기 때문에 변환 레코드를 언제 생성하고 지워야 하는지 적절한 시점에 신호를 준다. 하지만 실제로는 많은 NAT 기기가 TCP와 UDP 세션 모두에 비슷한 타임아웃 로직을 적용하고 있다. 결과적으로 TCP도 양방향 킵얼라이브 패킷이 필요한 경우가 생기는 것이다.

많은 애플리케이션이 UDP 커넥션 자체를 생성할 수 없다는 문제

많은 애플리케이션이 UDP 커넥션 자체를 생성할 수 없다는 문제가 있다. 내부 네트워크에서 상호작영을 시작하면서 변환을 수행하는 클라이언트 애플리케이션에게는 NAT의 동작 방식이 크게 문제되지는 않지만, VoIP, 게임 혹은 파일 공유 등 P2P 애플리케이션에서 이 문제가 발생한다. P2P는 애플리케이션이 서버와 클라이언트의 역할을 모두 수행해야만 양방향 커뮤니케이션이 가능한데 NAT가 존재하면 여러 문제가 발생한다. UDP와 NET의 어떤 점이 문제를 발생하게 할까.

문제 1. NAT 안쪽에 위치한 내부 클라이언트는 Private IP만 알고 자신의 Public IP를 모른다.

데이터 내부에서 자신의 Private IP를 쓴 경우에는 커넥션은 실패하게 된다. NET table을 사용한 완벽한 변환이 불가능할 수도 있다는 의미이다.

문제 2.외부에서 패킷이 도착하더라도 패킷에 목적지 Port number가 올바르게 명시되어 있어야 하고, NAT 테이블에 해당 Port number가 존재하지 않으면 Private IP에 전달되지 않고 소실된다. (매핑 데이터가 없어 인바운드 패킷이 소실됨)

NAT 기기는 Public IP 내부의 경로를 자동으로 파악할 수 없다 (Private IP와 Port number를 다 알고 있는게 아니라는 의미, 사설망을 설치할 때 미리 NET table을 생성해주는 것 같다). NAT 기기는 단순히 Net table에 있는 (Public IP, port)와 매칭되는 (Private IP, port)로 변환시켜 패킷을 전송해주는, 패킷 필터링 역할만 수행한다. 따라서 Net table에 port가 제대로 명시되어 있지 않으면 그냥 패킷을 버려버린다.

위의 문제를 해결하기 위해서 STUN, UTRN, ICE와 같은 프로토콜들이 존재하며, 실제로 이러한 프로토콜들을 결합하여 사용한다.

UDP를 보완하기 위한 프로토콜 - STUN, UTRN 그리고 ICE

STUN (Sesson Traversal Utilities for NAT)

STUN 서버에 요청해 Public IP, Port 반환하기

STUN 서버에 요청해 Public IP, Port 반환하기
STUN은 호스트 애플리케이션이 네트워크상의 NAT 기기를 발견하고 현재의 커넥션에 지정된 Public IP와 Port number를 알아낼 수 있게 하는 프로토콜이다. 이 프로토콜이 올바르게 동작하려면 공용 네트워크상에서 잘 알려진 제3의 STUN 서버의 도움을 받아야 한다. DNS 검색을 통해, 혹은 주소를 직접 지정해서 STUN 서버의 주소를 알아내자. STUN 서버에게 바인딩 요청을 보내면 현재의 Private IP, port의 Public IP, Port를 받을 수 있다. 이 프로토콜을 사용함으로써,

애플리케이션이 자신의 Public IP, port number를 얻을 수 있다.
STUN 서버에게 아웃바운드 바인딩 요청을 보낼 때, NAT table에 라우팅 값이 입력되므로 인바운드 패킷은 NET table에 해당 값이 없을 걱정 없이 Private IP에 데이터를 전달할 수 있다.
STUN 프로토콜이 킵-얼라이브 핑 역할을 해서 NAT 라우팅 타이머가 만기되어 table이 리셋되는 것을 막는다.

그러나 실제로는 STUN만으로는 모든 NAT 토폴로지와 네트워크 설정을 감당할 수 없다. UDP가 방화벽이나 다른 네트워크 기기에 의해 아예 막혀버릴 수도 있기 때문인데 TURN이 실패하였을 때의 대비책으로 TURN 프로토콜을 사용한다.

TURN(Traversal Using Relays around NAT)
TURN 프로토콜은 모든 것이 실패했을 때, UDP를 버리고 TCP로 전환(TURN)하는 기능을 한다. TURN은 'Relays(중계)'라는 개념이 매우 중요하다. TURN은 피어 간에 데이터를 왕복 운반하는 공용 중계(public relay)를 이용한다. 방법은 다음과 같다. 양쪽 클라이언트 모두 같은 TURN 서버에 할당 요청을 보내 커넥션을 시작한 후 권한 협상을 한다.협상이 완료되면 양쪽 호스트가 TURN 서버에 데이터를 보내고 TURN은 데이터 전달을 중계해줌으로써 서로 통신할 수 있게 해준다.

이 방식은 두 피어를 연결해주는 안정적인 방법이지만 더이상 P2P 통신이라고 할 수 없다. 또한 TURN 서버가 두 피어의 요청을 받아 중계해야 하기 때문에(양방향 중계) 상당한 부하를 받게 된다. 따라서 TURN은 다른 모든 연결이 실패했을 때의 대비책으로 사용하는게 바람직하다.

ICE(Interactive Connectivity Establishment)

ICE는 네트워크 참여자 간에 가장 효율적인 터널을 찾을 수 있는 프로토콜이다. ICE는 우선 연결 가능한 접속 경로들을 수집 한 후, 해당 경로에 패킷을 송수신 해서 각 경로에서 가장 품질이 우수한 것을 사용한다. ICE를 이용하면 직접 연결이 가능한 곳에서는 직접 연결을 수행하고, 직접 연결이 어려운 경우에는 STUN을 활용하고, 다른 모든 옵션이 실패했을 때는 TURN을 사용한다. 실제로 UDP 기반의 P2P 애플리케이션을 개발할 때에는 ICE, STUN, TURN을 모두 활용한 플랫폼 API, 혹은 제 3 라이브러리를 사용하는게 편리하다.