사용자 데이터그램 프로토콜

바이트 흐름과 다른 단위

UDP는 각각의 데이터그램을 구분하여 전달한다. TCP의 연속적인 바이트 스트림과 달리 메시지 경계가 있지만, 데이터그램이 도착하지 않거나 순서가 바뀔 수 있다.

응용 프로그램은 필요한 경우 누락과 중복을 감지하고 어떤 정보를 다시 보낼지 정해야 한다. UDP를 쓴다는 이유만으로 이런 처리가 자동으로 이루어지지는 않는다.

UDP 자체에는 TCP와 같은 연결 수립 협상과 전달 상태 관리가 없다. 그러나 프로그램은 상대 주소를 기억하거나 통신 상태를 유지할 수 있다.

운영체제의 UDP 소켓에 연결 함수를 사용하는 것도 프로토콜이 TCP처럼 바뀐다는 뜻은 아니다. API 사용 방식과 네트워크 프로토콜의 보장을 구분해야 한다.

실시간 정보에서는 이미 늦은 데이터를 재전송하는 것보다 새 정보를 전달하는 편이 유리할 수 있다. 반대로 모든 내용이 필요한 작업은 별도의 복구 절차가 필요하다.

UDP가 어떤 상황에서도 TCP보다 빠른 것은 아니다. 실제 지연은 손실과 혼잡, 응용 설계와 전송량에 좌우된다. 혼잡에 대한 책임 있는 제어 역시 필요하다.

UDP 위에 암호화와 연결 관리, 신뢰성 있는 스트림을 구현하는 프로토콜도 있다. QUIC은 이런 설계의 사례다. 기반이 UDP라고 상위 기능까지 모두 비신뢰적이라고 할 수는 없다.

큰 데이터그램과 경로의 전송 단위, 단편화 및 손실은 응용의 성능에 영향을 준다. 메시지의 크기와 전송 주기를 네트워크 조건에 맞게 정해야 한다.