[컴퓨터 네트워크]-Transport layer_UDP

 이번 장에서는 본격적으로 transport layer의 protocol 중 하나인 UDP에 대해서 알아보려고 한다. UDP는 TCP에 비해 간단하게 정리될 개념이긴 하지만, UDP가 어떻게 작동하는지, UDP는 왜 만들어졌는지, UDP는 어디에 쓰이는지 등에 대해서 고려하면서 정리해 볼 예정이다.

---

1. UDP란?

 UDP는 User Datagram Protocol의 줄임말이다. 사실 Datagram은 Network layer에서 쓰는 전송단위다. 즉, 3계층의 전송단윈데, 왜 4계층의 프로토콜 이름에 존재할까? 그 이유는 사실 UDP가 사용하는 데이터가 3계층의 Datagram과 큰 차이가 없기 때문이다. 

 

 그럼 UDP와 IP datagramd의 차이점은 무엇일까? 앞서 demultiplexing에서 봤듯이, IP datagram에 단지 목적지 port number만 추가해 놓은 것이 UDP의 segment이다.

 

 이렇듯, UDP를 쓰는 transport layer는 하위계층과 크게 다르지 않기 때문에, 최선의 노력을 통해 서비스를 제공하려고 하지만, 다음과 같은 문제가 존재한다.

• 데이터 loss
• 순서 없이 전송
• UDP sender와 receiver 간 연결 설정이 없다.
• 같은 client가 같은 server에 보내도 독립적으로 전송됨

 

 그렇다면 이런 단점이 존재하는 UDP를 왜 쓰는 것일까? 다음과 같은 이유가 있다.

• 연결 설정이 없어 RTT delay가 줄어든다.
• header size가 작다: TCP는 20byte 이상이 필요하지만, UDP는 8byte(=32bit)면 된다.
• 혼잡 제어가 없다: UDP는 혼잡 제어가 없어서 보낼 수 있을 때 무조건 보낸다(이러면 운 좋으면 혼잡상태라도 도착)

 

 UDP는 위와 같은 장점도 존재해 multimedia app이나 DNS(얘는 TCP로도 쓰임), SNMP, HTTP/3 등에서 사용된다. 그리고 만약, HTTP/3와 같이 신뢰성이 필요한 데이터 전송이 필요한 경우, application layer에서 구현한다. 혼잡제어도 application layer에서 구현한다.

---

2. UDP 과정

 UDP는 일단 sender와 receiver에서 하는 일이 다른데, 먼저 sender 쪽이 하는 일을 알아보자.

 

 -Sender

  먼저 sender는 다음과 같은 순서로 일을 처리한다.

1. application 계층으로부터 message를 전달받는다.
2. 목적지의 주소와 port번호를 결정하고, header fiedls에 값을 채워 넣는다
3. UDP segment를 만든다.
4. UDP segment를 Network 계층으로 전달한다.

 

  위 과정은 저번 글에서 언급했듯이, multiplexing과정이라고 볼 수 있다. 그리고, 위 그림은 UDP를 사용하는 transport계층이 헤더와 msg를 결합해 UDP segment를 만들고 network 계층에 전달한 모습이다.

 

-Receiver

 그렇다면 Receiver는 어떤 과정을 거칠까? UDP receiver는 다음과 같은 과정으로 이뤄진다.

1. Network 계층으로부터 UDP segment를 전달받는다.
2. Header field에 있는 checksum을 확인한다.
3. application에 전달할 msg를 header와 분리시킨다.
4. 메세지를 demultiplex한 뒤, 올바른 socket으로 전달한다.

 

 위와 같은 과정을 거쳐 올바른 socket을 통해 올바른 sender가 보낸 msg를 application process로 전달되게 한다. 위 그림은 최종적으로 application에 msg를 전달한 상태이다.

---

3. UDP segment & Checksum

 -UDP segment header

  그럼 이제, UDP segment가 정확히 어떻게 생겼는지 그림으로 살펴보자.

 

 위의 그림 중, application data는 message가 포함된 body 부분이고, UDP, 즉, transport layer의 프로토콜이 보고 판단하는 부분, Header는 source port #, dest port #, length, checksum 부분이다. 

 

 다시 정리하면 header에는 다음과 같은 값이 포함된다.

• source port #: 보낸이의 port 번호(4byte)
• destination port #: 도착지 port 번호(4byte)
• length: 헤더를 포함한 UDP segment 길이(4byte)
• checksum: 데이터가 변했는지 값을 확인하는 부분(4byte)

 이 중 checksum이 생소할 것이다. checksum이 무엇인지, 또 어떤 방식으로 이루어지는지 알아보려고 한다.

 

-Checksum

 기본적으로 checksum은 에러를 감지하기 위해 즉, 데이터가 변경됐는지에 대해 확인하려고 만들어진 방식이다. sender에서 이 값을 저장해서 보내주고, receiver에서 확인해야되는데 어떻게 이 과정이 이뤄지는 지 알아보자.

 

 먼저 sender는 header를 포함한 모든 UDP segment를 16bit로 다 쪼갠 뒤, 모든 값을 더한다. 그리고 segment header의 checksum field에 이 값을 저장한다. 

 

 그 다음, receiver에게 UDP segment가 전달됐다면, 받은 segment에 대해 checksum 계산 과정(모든 UDP segment를 16bit로 다 쪼갠 뒤, 모든 값을 더하는 과정)을 진행한다. 여기서 경우의 수가 2가지가 생기는데, 다음과 같다.

• checksum field에 있는 값과 받은 segment의 checksum과정이 같지 않다면, error가 발생한 것(data가 변한 것)
• 일치한다면, error가 검출되지 않는다.

 그렇지만, 이 checksum이 같다해도, error가 검출되지 않는 것이지, data가 변형이 일어나지 않았다는 것은 보장할 수 없다. 다음 예시를 살펴보자. 

 

 

 기본적으로, 다 더해준 뒤, carry값이 발생하면, 맨 뒤에 다시 1을 더해주고 sum을 구한다. 그 후, 1의 보수를 취하면 checksum을 구하는 과정이다. 즉, 위는 sum에서 1의 보수를 취해주면, checksum과 같기 때문에 error가 일어나지 않는다. 그렇지만, 다음 그림을 확인해보자.

 

 위와 같이, bit가 뒤바뀌었는데도, 값이 일치하며, checksum과 일치하기 때문에 error가 나지 않지만, 실제로는 값이 바뀌어서 error를 내야되는 상황이다. checksum 방식은 이런 오류에 대해서는 취약하다는 단점이 있다.

---

4. 정리

 UDP에 대해서 정리해봤는데, UDP는 최대한 노력해 서비스를 제공하려고 한다. 그렇지만 그 과정에서 segment들 일부가 손실될 수도 있고, 순서도 뒤죽박죽으로 전송될 수 있다는 단점이 존재한다. 

 

 그럼에도, 연결 설정이 필요없어 RTT시간이 발생하지 않고, 네트워크가 혼잡해도 데이터 전송을 제어하지 않기 때문에 데이터가 전송되어 도착할 수도 있다. 

 

 대표적으로 HTTP/3는 application layer쪽에서 많은 업무를 담당하기 때문에 구현하기 힘든 점도 있지만 위에서 언급한 장점들이 있기 때문에 UDP를 사용하고 있다.