UDP

Violet_Evgadn·2023년 4월 27일
0

네트워크

목록 보기
21/37

UDP

UDP 프로토콜의 활용 이유

지금까지 TCP 프로토콜에 대해 공부해 보았다.

하지만 모든 데이터를 TCP 프로토콜을 사용하여 송/수신하지는 않으며 UDP 프로토콜이라는 것도 활용한다.

UDP 프로토콜이 왜 필요한지를 알기 위해선 TCP 프로토콜이 상당히 복잡한 프로토콜이라는 것을 알고 있어야 한다.

TCP 프로토콜은 복잡한 원리를 사용함으로써 데이터를 확실하면서도 효율적으로 전달한다.

데이터가 확실히 전달되었는지 확인 메시지를 전달받고 정상적으로 도착하지 않았으면 누락된 패킷을 다시 보냄으로써 최대한 데이터 누락이 없도록 한다.

사실 TCP와 같은 복잡한 방식을 사용하지 않아도 데이터 송신 여부를 확실하게 확인하는 방법이 존재한다.

바로 데이터를 한 번에 전부 보낸 뒤 수신 측에서 그에 대한 처리 결과를 받는 것이다.

처리 결과가 정상적으로 도착했다면 데이터가 정상적으로 목적지에 도착했다는 의미이므로 그대로 통신을 종료하면 되고 만약 처리 결과가 도착하지 않았다면 데이터가 누락되었다는 의미이므로 데이터를 다시 보내면 될 것이다.

하지만 이렇게 전체 데이터를 보내는 방법은 매우 비효율적이다.

패킷은 담을 수 있는 데이터에 제한이 존재한다. 따라서 송신할 데이터 크기가 크다면 데이터를 분할하여 보내야 한다.

그런데 패킷 10개를 보냈을 때 1개만 소실되었을 경우 1개의 소실된 패킷 때문에 10개의 패킷을 다시 보내야 하는 상황이 발생한다.

따라서 TCP 프로토콜을 통해 어떤 패킷이 정상적으로 도착하지 않았는지 확인하고 소실된 패킷만 다시 보내 효율적으로 데이터를 송/수신하기 위하여 이런 복잡한 프로토콜을 사용하는 것이다.

하지만 반대로 말하자면 패킷 1개에 송신할 데이터를 모두 담을 수 있다면 TCP 보다 더 효율적인 방법이 존재한다는 것이다.

보낸 패킷이 1개밖에 없기 때문에 보낸 패킷 중 어떤 부분이 소실되었는지 확인할 필요가 없으며 소실되었을 경우 보낼 패킷이 단 1개밖에 존재하지 않으므로 어떤 패킷을 보내야 할지 판단할 필요도 없다.

또한 이런 경우에는 접속이나 연결을 끊기 위하여 제어용 패킷을 보낼 필요도 없으며(3-way handshake, 4-way handshake 과정이 필요 없음) 요청에 대한 처리 결과만 받으면 패킷이 정상적으로 도착했다는 의미를 가지므로 수신 확인 응답 패킷을 받을 필요도 없다.

이런 상황에서는 TCP 대신 UDP를 사용하는 것이다.

UDP 프로토콜을 활용하는 경우

대표적으로 음성 및 동영상 데이터를 보낼 때 UDP를 사용한다.

음성이나 영상 데이터는 정해진 시간 내에 데이터를 전해줘야 한다. 만약 데이터의 도착이 지연될 경우 음성이 끊기거나 영상이 멈추는 상황이 발생할 것이다.

만약 수신 확인 응답을 받고 만약 응답 메시지에서 오류가 발생되었음을 인지하면 패킷을 다시 보내는 TCP를 활용할 경우 응답 메시지를 읽는 시간 + 어떤 패킷을 다시 보내야 할지 판단하는 시간 등 재송신하는 과정에서 시간이 오래 걸릴 것이다.

이런 경우엔 요청을 다시 보내 누락된 데이터를 다시 받더라도 재생 타이밍이 맞지 않을 수 있다.

만약 재생 타이밍이 맞지 않다면 중간에 끊긴 소리나 영상을 원래대로 돌릴 수는 없기 때문에 데이터가 도착해도 쓸모가 없어진다.

음성이나 영상 같은 경우 데이터가 잠시 누락되어도 치명적인 문제가 되진 않는다.

음성이라면 "치직" 소리와 함께 잠시 소리가 끊기고 영상일 경우 잠깐 로딩 중 표시가 뜨거나 이미 로드해 왔던 영상을 보여주며 다시 요청을 보낼 시간을 벌 수도 있다.

따라서 UDP로 데이터를 보내는 쪽이 효율적인 것이다.

또한 DNS 서버에 도메인 명에 해당하는 IP 주소를 조회할 때도 UDP를 사용한다.

어차피 IP 주소를 조회할 때 필요한 데이터는 도메인명밖에 없고 나머진 헤더에 담긴 정보로 충분하다.

따라서 연결-연결 끊기 동작이 반복적으로 필요한 TCP 보다는 연결 과정을 생략하고 빠르게 IP 주소를 조회할 수 있는 UDP가 더 효율적이다.

만약 오류가 발생했다 하더라도 애플리케이션 측에서 도메인 명에 대응되는 IP 주소값이 오지 않았다는 것을 인지하고 다시 DNS 서버에 요청을 보내면 된다.

이렇게 보낼 데이터 크기가 매우 작거나, 데이터를 다시 보내도 쓸모가 없거나, 안정성보다는 속도가 필요한 경우 UDP를 사용하면 좋은 것이다.

UDP 헤더

  • 송신처 포트 번호 : 패킷을 송신한 측의 포트 번호
  • 수신처 포트 번호 : 패킷을 수신할 측의 포트 번호
  • 데이터 길이 : UDP 헤더 이후의 길이
  • 체크섬 : 오류 유무를 검사하기 위한 제어 정보
profile
혹시 틀린 내용이 있다면 언제든 말씀해주세요!

0개의 댓글