[컴퓨터 네트워크] 16. Transport Layer (2) : UDP

UDP

user datagram protocol

RFC 768 에 정의된 매우 오래된 프로토콜이다.

트랜스포트 계층이지만, 네트워크 계층에서 포트만 더해주기 때문에, 데이터그램이라는 네트워크 계층 전송단위를 그대로 사용하기도 한다.

네트워크 계층과 동일한 서비스 모델을 제공한다.

따라서 UDP 세그먼트는 중간에 유실되더라도 복구하거나 재전송하는 서비스는 없다.

send 순서와 receive 순서가 동일하다는 보장도 하지 않는다.

 

UDP 장점

1. connectionless

미리 연결을 설정할 필요가 없어서 오버헤드 시간이 절약된다

연결 설정이 없다는 말은, 같은 목적지로 보내는 같은 내용의 세그먼트도 모두 독립적으로 여긴다는 특징이 있다.

TCP와 달리 RTT 딜레이가 없다.

 

2. stateless

sender와 receiver 모두 connection state를 관리할 필요가 없다.

특히 서버 입장에서 다수의 트래픽이 몰려오는 상황이라면 TCP보다 UDP를 사용하는 것이 서버 성능 유지면에서 유리할 수 있다.

 

3. small header size

UDP는 데이터그램에 추가적으로 제어 정보가 들어가지 않기 때문에 TCP에 비해 헤더 사이즈가 작다.

 

4. no congestion control

네트워크 혼잡상황에서 TCP보다 빠르게 데이터를 보낼 수 있다.

TCP는 혼잡 상황이 발생하면, TCP를 따르는 데이터끼리는 서로 데이터를 조금씩만 보내자는 신사협정을 맺는다.

UDP는 이를 따르지 않기 때문에, 마치 갓길로 달리듯 빠르게 데이터를 보낼 수 있다.

 

 

UDP 활용

1. streaming multimedia application

TCP를 사용하는 어플리케이션도 있지만, 일부 데이터 손실은 감내할 수 있고, 대신 데이터의 전송률이 중요하다면 UDP를 사용하는 것이 유리하다.

 

2. DNS

DNS는 쿼리를 한번 보내고, 그에 대한 응답을 한번 받으면 끝나는 프로토콜이다.

따라서 연결을 설정해두고 계속 데이터를 주고받지 않으므로 UDP를 이용하여 구현한다.

 

3. SNMP (Simple Nework Management Protocol)

말 그대로 네트워크 관리를 위한 프로토콜이다.

네트워크의 어떤 상황을 물어보고 응답을 받는 프로토콜인데, DNS와 유사하게 한번 묻고 한번 응답받으면 끝나서 UDP를 사용하는 듯하다.

 

4. HTTP/3

이전 버전까지는 웹 오브젝의 loss가 있으면 안되기 때문에 TCP를 사용했었다.

HTTP/3은 역발상으로, UDP를 사용하여 빠르게 데이터를 받고, 대신 TCP가 제공하는 reliability, congestion control 기능을 어플리케이션에서 직접 구현하겠다는 아이디어를 사용한다.

 

 

Example

 

그림과 같이 SNMP 프로토콜을 사용하는 서버와 클라이언트가 있다고 하자.

 

UDP sender는 어플리케이션 메세지를 받아서 UDP segment 를 만든다.

그리고 UDP 세그먼트를 네트워크 계층에 넘긴다.

 

 

 

전송이 된 UDP 세그먼트는 네트워크 계층에서 트랜스포트 계층으로 올려보낸다.

UDP는 헤더에 있는 checksum을 확인하고, 어플리케이션 메세지를 추출해서 소켓을 통해 메세지를 어플리케이션에 보낸다.

 

 

이때 주고받는 UDP 세그먼트를 보면 위와 같다.

source port, destination port, length, checksum 4가지 정보가 UDP에서 추가하는 정보의 전부이다.

length는 어플리케이션 메세지의 데이터의 크기를 포함한 UDP 세그먼트의 크기를 의미한다.

그렇다면 checksum은 무엇일까?

 

 

UDP Checksum

UDP Checksum은 아주 약한 무결성(integrity) 확인 데이터이다.

매우 약하기 때문에 공격자가 데이터를 조작하더라도 체크섬의 무결성 확인은 쉽게 통과할 수 있다.

그래서 체크섬은 보안을 지키기 위한 것이 아니라, 전송 중간 노이즈에 의해 데이터가 변경되는 것을 감지하는 목적으로 사용한다.

 

무결성을 확인하는 방식은 말 그대로 합을 확인하는 것이다.

그래서 만약 원래 보내려는 값이 5, 6 이라서 합이 11이라면, 무결성을 확인할 때 받은 값의 합이 11인지만 본다.

그런데 만약 중간에 훼손된 값의 형태가 4, 7 이어도 합이 11이라서 무결성 검사를 통과한다.

따라서 이 검사는 크게 의미는 없다고 한다. 교수님도 만약 자신이 다시 UDP를 설계한다면 체크섬은 빼신다고..ㅋㅋ

 

구체적인 예시를 보자.

 

- sender

센더는 UDP 세그먼트를 16bit integer의 시퀀스로 간주한다.

즉, 2byte 씩 끊어서 이를 각각의 숫자로 생각하는 것이다.

그리고 이 숫자를 다 더해서 sum 을 구한다.

checksum은 sum 의 비트를 반전시켜서 (즉, 1의 보수를 구해서) 구한다.

 

- receiver

리시버는 동일한 방식으로 수신한 세그먼트의 체크섬을 직접 계산한다.

만약 계산한 값이 checksum 필드값과 다르다면 에러가 발생했다고 인지한다.

하지만 같게 나왔다고 해서 에러가 없음을 보장하는 것은 아니다.

(그럼 진짜 왜 쓰는걸까..)

 

 

구체적으로 구하는 과정은 위와 같다.

16bit 정수를 더한뒤, 마지막에 나오는 carry out 은 맨 뒤에 더해준다.

이렇게 구한 sum 을 bit flip 해서 checksum 을 구한다.

 

하지만 합을 구할 때 위처럼 더한 결과가 같은 수준에서 변화가 발생하면, checksum 으로 무결성을 확인할 수 없다.

그리고 다른 레이어에서 암호화를 적용한다음 데이터를 주고 받는 과정에서 이미 무결성을 확인해주고 있어서 UDP의 매우 취약한 체크섬을 별도로 제공할 이유는 사실 없다.