UDP는 왜 연결 없이 데이터를 보내는가

UDP는 왜 연결 없이 데이터를 보내는가#

1장 TCP가 있는데 왜 UDP를 사용할까#

1.1 연결 과정 없이 바로 데이터를 보내고 싶을 때#

주차관제 현장의 Gate Controller가 있다고 가정해보겠습니다.

장비 설명서에는 다음과 같이 적혀 있습니다.

Protocol : UDP
Port     : 4000

그리고 명령 형식은:

OPEN,ID=12345

입니다.

TCP를 공부한 직후라면 의문이 생깁니다.

TCP는 연결도 확인하고 손실된 데이터도 다시 보내는데 왜 굳이 UDP를 사용할까?

답은 UDP와 TCP의 목적이 다르기 때문입니다.

TCP는:

Connection 생성
↓
Sequence 관리
↓
ACK
↓
재전송
↓
Flow Control
↓
Congestion Control

과 같은 기능을 제공합니다.

UDP는 훨씬 단순합니다.

목적지 IP와 Port 결정
↓
Datagram 생성
↓
IP에 전달
↓
전송

즉 전송 전에 TCP와 같은 연결 상태를 만들지 않습니다.

1.2 UDP는 Connectionless Protocol이다#

UDP는 User Datagram Protocol의 약자입니다.

가장 중요한 특징 중 하나가 Connectionless입니다.

TCP에서는:

SYN
↓
SYN/ACK
↓
ACK
↓
Data

과정을 거칩니다.

UDP에서는:

Data
↓
전송

할 수 있습니다.

TCP처럼 상대방과 Connection을 먼저 확립하는 과정이 없습니다.

2장 Datagram은 무엇인가#

2.1 UDP는 Stream이 아니라 Datagram 단위로 동작한다#

TCP에서는 Application이 보낸 데이터를 Byte Stream으로 다룹니다.

UDP는 다릅니다.

Application이 한 번에 보낸 하나의 UDP Message는 하나의 Datagram 단위로 전달됩니다.

예를 들어:

sendto("OPEN")

하고:

sendto("GATE01")

을 각각 호출했다면 두 개의 Datagram이 만들어집니다.

개념적으로:

Datagram 1
OPEN

Datagram 2
GATE01

입니다.

2.2 TCP와 가장 큰 차이#

TCP에서는:

send("OPEN")
send("GATE01")

라고 두 번 보내도 Receiver에서는:

OPENGATE01

처럼 한 번에 읽힐 수도 있습니다.

반대로 나뉘어 들어올 수도 있습니다.

하지만 UDP는 Datagram 경계를 유지합니다.

UDP Datagram A
→ 하나의 Message

UDP Datagram B
→ 또 하나의 Message

따라서 Message 단위 Protocol을 구현하기 편한 면이 있습니다.

3장 UDP Header는 매우 단순하다#

3.1 UDP Header의 구조#

UDP Header는 8Byte입니다.

구조는 다음과 같습니다.

┌──────────────────────┐
│ Source Port     2Byte│
├──────────────────────┤
│ Destination Port 2Byte│
├──────────────────────┤
│ Length          2Byte│
├──────────────────────┤
│ Checksum        2Byte│
├──────────────────────┤
│ Payload              │
└──────────────────────┘

TCP Header에 비하면 매우 단순합니다.

3.2 Source Port#

송신 Application의 Port입니다.

예:

51024

환경에 따라 자동으로 할당되는 임시 Port일 수도 있고 Application이 특정 Port를 사용할 수도 있습니다.

3.3 Destination Port#

수신 Application이 기다리는 Port입니다.

예:

UDP 4000

장비 설명서에:

UDP Port 4000

이라고 적혀 있다면 일반적으로 이 Destination Port로 Datagram을 보내라는 의미입니다.

3.4 Length#

UDP Header와 Payload를 포함한 전체 UDP Datagram 길이를 나타냅니다.

3.5 Checksum#

전송 과정에서 UDP Header와 Data가 손상되었는지 검출하는 데 사용됩니다.

하지만 중요한 점이 있습니다.

Checksum은 손실된 Datagram을 다시 보내주는 기능이 아닙니다.

Checksum
→ 오류 검출

Retransmission
→ 제공하지 않음

으로 구분해야 합니다.

4장 UDP는 무엇을 보장하지 않는가#

UDP를 이해하려면 무엇을 해주는지보다 무엇을 해주지 않는지가 더 중요합니다.

4.1 전달 보장 없음#

Sender가 Datagram을 보냈다고 해서 Receiver가 반드시 받는 것은 아닙니다.

Sender
↓
UDP Datagram
↓
Network
↓
Packet Loss
↓
Receiver에 도착하지 않음

UDP 자체는 이를 다시 보내지 않습니다.

4.2 순서 보장 없음#

다음 순서로 보냈다고 가정합니다.

Datagram A

Datagram B

Datagram C

Network 상황에 따라 Receiver에서는:

A

C

B

처럼 도착할 가능성이 있습니다.

UDP는 원래 순서로 다시 정렬해 Application에 전달하는 기능을 제공하지 않습니다.

4.3 중복 제거 보장 없음#

Network 또는 Application의 재전송 구조에 따라 같은 Message가 두 번 도착할 수도 있습니다.

OPEN
OPEN

UDP 자체는:

이것은 아까 받은 Message와 같은 것이다.

라고 판단해 제거해주지 않습니다.

4.4 상대가 받았는지도 알 수 없다#

UDP Sender가:

sendto()

를 성공했다고 해서:

상대 Application이 받았다

는 뜻은 아닙니다.

일반적으로 Local OS가 Datagram을 전송 경로로 넘겼다는 정도로 이해해야 합니다.

5장 UDP가 단순하다고 항상 빠른 것은 아니다#

5.1 흔한 표현 — UDP가 TCP보다 빠르다#

입문 설명에서는 흔히:

TCP
느림

UDP
빠름

이라고 설명합니다.

하지만 지나치게 단순한 설명입니다.

UDP에는 TCP의:

Handshake

ACK

재전송

순서 복구

Flow Control

같은 기능이 없기 때문에 Protocol 자체의 처리 과정은 단순합니다.

그러나 실제 Application 성능은:

Network 상태

Packet 크기

Application 구현

Packet Loss

CPU

Socket Buffer

라우팅

QoS

등의 영향을 받습니다.

5.2 손실을 Application에서 모두 처리하면 오히려 복잡할 수 있다#

UDP 위에 다음 기능을 직접 만든다고 가정해보겠습니다.

Sequence Number

ACK

Retransmission

Timeout

Flow Control

그러면 Application 자체가 TCP와 비슷한 기능을 다시 구현하게 됩니다.

따라서:

빠르게 보내야 하니까 무조건 UDP

라는 판단은 적절하지 않습니다.

6장 TCP와 UDP를 비교해보자#

구분 TCP UDP
연결 Connection 기반 Connectionless
데이터 형태 Byte Stream Datagram
순서 보장 제공 제공하지 않음
재전송 제공 제공하지 않음
중복 처리 TCP 내부 처리 Application 책임
흐름 제어 있음 없음
혼잡 제어 있음 UDP 자체에는 없음
Broadcast 직접 사용하지 않음 가능
Multicast 일반적인 TCP 방식 아님 가능
대표 용도 Web·파일·API 등 DNS·실시간 Media·Discovery 등

중요한 것은 어느 쪽이 더 좋은 Protocol인가가 아닙니다.

Application이 어떤 특성을 필요로 하는가가 선택 기준입니다.

7장 UDP는 언제 유용할까#

7.1 손실보다 최신 정보가 중요한 경우#

예를 들어 센서가 다음 값을 계속 보내고 있다고 가정합니다.

10:00:00
Temperature 20.1

10:00:01
Temperature 20.2

10:00:02
Temperature 20.3

10:00:01의 Datagram 하나가 손실되었다고 해도 10:00:02의 최신 정보가 곧 도착합니다.

이런 Application에서는 오래된 값을 다시 받는 것이 크게 중요하지 않을 수도 있습니다.

7.2 실시간 Media#

Voice나 Video처럼 너무 늦은 Packet이 별 가치가 없는 Application에서는 UDP가 사용될 수 있습니다.

예:

현재 Video Frame
↓
100ms 뒤 다음 Frame
↓
1초 뒤 과거 Frame 재전송

이라면 과거 Frame을 뒤늦게 복구하는 것보다 현재 Stream을 계속 처리하는 것이 더 중요할 수 있습니다.

이 때문에 RTP 같은 실시간 Media Protocol이 UDP 위에서 동작하는 구성이 많이 사용됩니다.

7.3 Discovery#

장비를 찾는 Protocol에서도 UDP Broadcast나 Multicast가 활용될 수 있습니다.

예:

"이 Network에 Camera가 있습니까?"

같은 Discovery 요청을 여러 장비에게 전달하는 방식입니다.

8장 중요한 제어 명령에는 무엇을 더 고려해야 할까#

8.1 Gate OPEN 명령을 UDP로 보낸다면#

다음 Datagram을 보냈다고 가정합니다.

OPEN
ID=12345

Datagram이 사라지면:

Sender
OPEN 전송
↓
Packet Loss
↓
Gate
아무것도 받지 못함

이 될 수 있습니다.

8.2 무조건 두 번 보내면 해결될까#

단순히:

OPEN
OPEN

두 번 보내면 손실 확률을 줄일 수 있을 것처럼 보입니다.

하지만 두 Datagram이 모두 도착하면:

OPEN 처리
OPEN 처리

가 될 수 있습니다.

Application이 중복 처리를 제대로 하지 않는다면 더 큰 문제가 생길 수 있습니다.

9장 UDP 명령에는 Message ID가 중요할 수 있다#

예를 들어 명령을 다음처럼 만들 수 있습니다.

{
  "messageId": "CMD-20260924-10001",
  "command": "OPEN",
  "gate": "GATE-01"
}

Receiver는 이미 처리한:

CMD-20260924-10001

을 기억하고 있다면 같은 Datagram이 다시 도착했을 때 중복 실행을 방지할 수 있습니다.

개념적으로:

첫 번째 명령
↓
Message ID 확인
↓
처리
↓
ID 저장

같은 명령 재수신
↓
이미 처리한 ID
↓
중복 실행 방지

입니다.

10장 Application ACK를 만들 수도 있다#

UDP 자체에는 TCP ACK 같은 전달 확인 기능이 없습니다.

하지만 Application Protocol에서 자체 ACK를 정의할 수 있습니다.

예:

Controller
OPEN CMD-1001
──────────────→ Gate

Gate
ACK CMD-1001
←──────────────

Sender가 일정 시간 안에 ACK를 받지 못하면 재전송하도록 설계할 수도 있습니다.

Command
↓
ACK 대기
↓
Timeout
↓
Retransmission

하지만 이렇게 만들기 시작하면:

Timeout

Retry Count

중복 처리

Message ID

순서

같은 Application Protocol 설계가 필요해집니다.

11장 TCP ACK와 UDP Application ACK는 다르다#

TCP에서는 Transport Layer가 ACK를 관리합니다.

UDP에서는 Application이 직접 ACK를 만든다면 그것은 Application Message입니다.

예:

UDP Payload

ACK,CMD-1001

UDP Header 자체에 TCP와 같은 ACK Flag가 있는 것이 아닙니다.

따라서:

UDP ACK

라는 표현을 사용할 때는:

UDP 위에서 Application이 구현한 ACK

인지 구분하는 것이 좋습니다.

12장 UDP에서 순서를 보장하고 싶다면#

UDP Header에는 TCP Sequence Number 같은 Field가 없습니다.

필요하다면 Application Payload에 Sequence Number를 넣을 수 있습니다.

예:

SEQ=1001,STATUS=OPEN

SEQ=1002,STATUS=CLOSING

SEQ=1003,STATUS=CLOSED

Receiver는:

1001
1003
1002

순서로 받더라도 Sequence를 보고 재정렬하거나 오래된 Message를 버릴 수 있습니다.

12.1 모든 Application에서 재정렬이 필요한 것은 아니다#

실시간 Sensor 데이터라면:

1001
1003
1002

에서 늦게 도착한 1002를 굳이 처리하지 않고 버리는 것이 더 적절할 수도 있습니다.

따라서 UDP 보완 로직은 업무 특성에 맞게 설계해야 합니다.

13장 UDP Broadcast는 무엇인가#

13.1 여러 장비에게 한 번에 보낼 수 있다#

IPv4에서는 UDP를 Broadcast Address로 보낼 수 있습니다.

예를 들어 특정 Subnet이:

192.168.10.0/24

이라면 Broadcast Address는:

192.168.10.255

입니다.

Application이 이 주소로 UDP Datagram을 보내면 해당 Broadcast Domain의 여러 장비가 받을 수 있습니다.

13.2 Broadcast와 Unknown Unicast Flooding은 다르다#

Switch에서 배운 내용과 연결해야 합니다.

Broadcast는 Packet 자체가 Broadcast Destination을 사용합니다.

반면 Unknown Unicast Flooding은:

특정 Destination MAC

을 가진 Frame인데 Switch가 그 위치를 모르기 때문에 여러 Port로 전달하는 것입니다.

두 현상을 혼동하면 안 됩니다.

14장 Router는 일반적으로 Broadcast Domain을 나눈다#

Broadcast는 기본적으로 같은 Broadcast Domain에서 동작합니다.

예:

VLAN 10
↓
Broadcast
↓
VLAN 10 장비

일반적인 Router는 이런 Layer 2 Broadcast를 다른 Network로 그대로 Forward하지 않습니다.

따라서:

장비 Discovery가 같은 VLAN에서는 되는데
다른 VLAN에서는 안 된다.

라는 상황은 충분히 발생할 수 있습니다.

15장 Multicast는 Broadcast와 다르다#

Broadcast는 같은 Broadcast Domain의 많은 장비를 대상으로 합니다.

Multicast는 특정 Group을 대상으로 합니다.

개념적으로:

Broadcast

Sender
 ├→ A
 ├→ B
 ├→ C
 └→ D

Multicast는:

Sender
 ├→ A  Group Member
 ├→ C  Group Member
 │
 B / D는 필요 없음

처럼 이해할 수 있습니다.

실제로 Switch에서는 IGMP Snooping 등을 활용해 Multicast Traffic 전달 범위를 관리할 수 있습니다.

16장 UDP Datagram이 Network를 이동하는 과정#

Application이 다음 데이터를 보낸다고 가정합니다.

STATUS,GATE01,OPEN

처리 과정을 단순화하면:

Application Data
↓
UDP Header
↓
IP Header
↓
Ethernet Header
↓
Physical Signal

입니다.

Receiver에서는 반대로:

Physical Signal
↓
Ethernet
↓
IP
↓
UDP
↓
Application

으로 올라갑니다.

UDP 역시 Ethernet과 IP 위에서 동작하기 때문에 UDP 장애라고 해서 UDP만 봐서는 안 됩니다.

17장 UDP Socket은 Connectionless이지만 bind는 할 수 있다#

Server 역할의 Application이 UDP Port 4000을 받는다고 가정합니다.

UDP
0.0.0.0:4000

처럼 Socket을 특정 Local Port에 Bind하고 Datagram을 기다릴 수 있습니다.

이것은 TCP의 LISTEN Connection과는 개념이 다릅니다.

UDP에는 TCP 3-Way Handshake와 같은 Connection 확립 과정이 없습니다.

17.1 UDP에도 connect()를 사용할 수 있는 경우가 있다#

개발 관점에서 UDP Socket에도 운영체제 API의 connect()를 사용할 수 있습니다.

하지만 이것은 TCP처럼 Network상에서 3-Way Handshake를 생성해 Connection을 만드는 의미는 아닙니다.

Local Socket에 기본 Destination을 지정하고 특정 Peer Traffic만 받도록 하는 등 API 동작을 단순화하는 용도로 사용할 수 있습니다.

따라서:

UDP connect()
=
TCP Connection

으로 이해하면 안 됩니다.

18장 UDP Packet을 Capture해보자#

Linux에서는 시험망이나 허가된 환경에서:

tcpdump -n -i eth0 udp

처럼 UDP Traffic을 볼 수 있습니다.

특정 Port만 확인하려면:

tcpdump -n -i eth0 'udp port 4000'

처럼 사용할 수 있습니다.

18.1 실제로 확인할 정보#

Capture에서 우선 확인할 것은:

Source IP

Destination IP

Source Port

Destination Port

UDP Length

Payload

입니다.

TCP와 달리:

SYN

ACK Number

Sequence Number

FIN

같은 Field를 찾을 수 없습니다.

19장 netcat으로 UDP를 시험해보자#

격리된 시험망에서 Receiver를 준비할 수 있습니다.

환경의 nc 구현에 따라 Option이 다를 수 있지만 개념적으로:

nc -u -l 4000

처럼 UDP Port에서 데이터를 받을 수 있습니다.

Sender에서는:

printf 'TEST\n' | nc -u 192.168.10.50 4000

처럼 보낼 수 있습니다.

이때 Receiver에 데이터가 표시되지 않는다고 해서 Sender에게 자동으로:

전송 실패

가 알려지는 것은 아닙니다.

이 차이를 직접 경험하는 것이 UDP 이해에 도움이 됩니다.

20장 UDP Packet이 안 보일 때 어디부터 확인할까#

20.1 Sender에서 Datagram이 실제로 나가는가#

먼저 Sender Capture를 확인합니다.

Source IP
↓
Destination IP
↓
UDP Destination Port

가 맞는지 봅니다.

20.2 Receiver까지 도착하는가#

Sender에는 보이지만 Receiver에는 없다면:

VLAN

Routing

Firewall

ACL

VPN

NAT

등 중간 경로를 확인합니다.

20.3 Receiver에는 도착하지만 Application이 받지 못한다#

Receiver Capture에서는 Packet이 보입니다.

하지만 Application은:

No Data

라고 합니다.

이 경우:

잘못된 UDP Port

Application Bind Address

Socket Buffer

Application Processing

Protocol Format

등을 확인해야 합니다.

21장 UDP에는 TCP의 Connection Refused와 같은 흐름을 기대하면 안 된다#

TCP에서는 닫힌 Port로 SYN을 보내면 RST가 돌아오는 경우가 있습니다.

UDP에서는 다른 방식으로 오류가 전달될 수 있습니다.

예를 들어 환경에 따라 목적지 UDP Port가 열려 있지 않으면 ICMP 오류가 반환될 수도 있습니다.

하지만 Firewall이 Drop하거나 중간 경로 때문에 오류가 돌아오지 않는 경우도 있습니다.

따라서:

UDP 응답 없음

만으로:

Server Down

이라고 판단하면 안 됩니다.

22장 UDP와 NAT#

22.1 UDP에는 TCP Connection이 없지만 NAT는 상태를 만들 수 있다#

내부 장비가:

192.168.10.20:50000

에서 외부 Server:

203.0.113.20:4000

으로 UDP Datagram을 보낸다고 가정합니다.

NAT Gateway는 다음과 같은 Mapping을 일정 시간 관리할 수 있습니다.

192.168.10.20:50000
↓
Public-IP:62000

TCP Connection은 아니지만 NAT 장비는 응답을 내부 장비로 돌려주기 위한 상태를 유지합니다.

22.2 UDP NAT Mapping은 일정 시간이 지나면 사라질 수 있다#

오랫동안 Traffic이 없다면 NAT 또는 Stateful Firewall의 UDP Session 정보가 제거될 수 있습니다.

그 후 외부 Server가 이전 Mapping으로 Datagram을 보내면 내부 장비까지 전달되지 않을 수 있습니다.

이 때문에 일부 UDP 기반 Application은:

Heartbeat

Keepalive Message

주기적 Registration

같은 Application 수준 기능을 사용하기도 합니다.

정확한 주기는 Network 장비와 Application 설계에 따라 달라집니다.

23장 UDP와 Firewall#

UDP Rule을 만들 때도 다음 항목을 정확하게 확인해야 합니다.

Source IP

Destination IP

UDP

Source Port

Destination Port

Direction

예를 들어:

Source
192.168.20.0/24

Destination
192.168.100.20

Protocol
UDP

Destination Port
4000

처럼 정의할 수 있습니다.

TCP Rule과 UDP Rule은 Protocol 자체가 다르기 때문에:

TCP 4000 허용

했다고:

UDP 4000

까지 자동으로 허용되는 것은 아닙니다.

24장 주차관제 사례 — UDP Gate 명령이 가끔 사라진다#

다음 구조를 가정합니다.

Parking Server
192.168.20.10

        ↓ UDP 4000

Gate Controller
192.168.20.30

Server는 다음 명령을 보냅니다.

CMD=OPEN
ID=10001

정상적으로는 Gate가 열립니다.

하지만 하루에 몇 번씩 열리지 않습니다.

24.1 먼저 Application을 재전송하기 전에 Network를 확인한다#

Server Capture:

CMD=10001
UDP Datagram
전송 O

Controller 측 Capture:

CMD=10001
없음

이라면 중간 Network를 확인합니다.

Switch Port

Error Counter

VLAN

Firewall

Packet Loss

Cable

등입니다.

24.2 Controller까지 Datagram이 도착한다면#

Controller Capture:

CMD=10001
수신 O

인데 Gate가 열리지 않았다면 UDP Transport보다 Application 이후를 확인해야 합니다.

Protocol Parsing

Command Validation

Controller Logic

Motor Interlock

Physical Sensor

입니다.

이전 TCP 글에서와 마찬가지로:

Packet 도착
≠
물리 동작 완료

입니다.

25장 Gate 제어에서는 Application ACK가 중요할 수 있다#

예를 들어:

Server
CMD=10001 OPEN
───────────────→ Controller

Controller가 명령을 정상적으로 해석했다면:

ACK=10001 RECEIVED

를 돌려줄 수 있습니다.

실제 Gate가 열린 뒤에는:

STATUS=10001 COMPLETED

같은 상태를 별도로 보내는 구조도 생각할 수 있습니다.

이를 구분하면:

Sent

Received

Accepted

Completed

상태를 명확하게 관리할 수 있습니다.

UDP를 사용한다고 이 업무 상태가 자동으로 만들어지는 것은 아닙니다.

Application Protocol 설계가 필요합니다.

26장 UDP 중복 전송은 멱등성을 고려해야 한다#

Controller가 ACK를 보내지 않아 Server가 명령을 재전송한다고 가정합니다.

CMD=10001 OPEN
↓
ACK 없음
↓
CMD=10001 OPEN 재전송

Controller는 동일한 Message ID라면:

이미 처리됨

이라고 판단할 수 있어야 합니다.

이런 성질을 Application에서 멱등성과 연결해서 설계할 수 있습니다.

즉 같은 명령이 여러 번 전달되어도 시스템 상태가 잘못 변하지 않도록 해야 합니다.

27장 Sensor 데이터와 제어 명령은 요구사항이 다르다#

같은 주차관제 Network라도 데이터 종류에 따라 Protocol 요구사항이 다릅니다.

27.1 주기적인 Sensor 상태#

10:00:01 Occupied

10:00:02 Occupied

10:00:03 Empty

중간 하나가 손실돼도 최신 값이 계속 전달된다면 UDP가 적합할 수 있습니다.

27.2 결제 결과#

Payment Approved

같은 중요한 업무 Event는 손실이나 중복 처리가 큰 문제를 만들 수 있습니다.

이런 경우:

TCP

Message Queue

Application ACK

Transaction ID

등 더 강한 전달·업무 처리 구조가 필요할 수 있습니다.

27.3 Gate OPEN#

Gate OPEN도 단순히:

실시간이니까 UDP

라고 판단하면 안 됩니다.

다음 질문이 더 중요합니다.

명령 손실을 허용할 수 있는가?

중복 실행은 안전한가?

ACK가 필요한가?

재시도 횟수는?

완료 상태를 확인해야 하는가?

Fail-safe 정책은 무엇인가?

이 기준으로 Protocol을 선택해야 합니다.

28장 UDP Broadcast가 많으면 Network에 부담을 줄 수 있다#

Broadcast Datagram은 같은 Broadcast Domain의 여러 장비가 처리해야 합니다.

장비가 많고 Broadcast가 과도하면:

Switch Traffic 증가

Endpoint CPU 처리 증가

불필요한 Packet 증가

등의 문제가 발생할 수 있습니다.

따라서 Discovery 목적으로 Broadcast를 사용하더라도 주기와 범위를 적절하게 제한해야 합니다.

29장 UDP Multicast 환경에서는 IGMP를 함께 본다#

IPv4 Multicast를 사용하는 환경에서는 Host의 Multicast Group Membership과 IGMP가 관련됩니다.

Switch에서 IGMP Snooping을 사용하면 필요하지 않은 Port로 Multicast Traffic이 무분별하게 Flooding되는 것을 줄일 수 있습니다.

구조를 단순화하면:

Video Sender
      ↓
Multicast
      ↓
Switch
 ├→ Subscriber A
 ├→ Subscriber B
 └→ 필요 없는 Port에는 제한

Network 규모가 커질수록 Multicast 설계는 단순 UDP Port 설정만으로 끝나지 않습니다.

30장 UDP Checksum을 과신하지 않는다#

Checksum이 맞았다는 것은 Datagram 내용이 전송 과정에서 오류 없이 전달되었을 가능성을 확인하는 데 사용됩니다.

하지만 Checksum은 다음을 해결하지 않습니다.

Packet Loss

Packet 순서

Packet 중복

Application 명령 성공

사용자 인증

따라서:

UDP Checksum 정상
=
업무 정상

이라고 판단하면 안 됩니다.

31장 UDP도 보안 기능을 기본 제공하지 않는다#

UDP 자체에는 Application Payload를 암호화하거나 Peer를 인증하는 기능이 없습니다.

평문 Protocol이라면 Packet Capture에서 내용을 볼 수 있을 수도 있습니다.

예:

OPEN,GATE01

CAR=12가3456

DEVICE=ENTRANCE01

민감한 정보가 포함된다면 별도의 보안 계층을 고려해야 합니다.

31.1 DTLS#

UDP 기반 Application에서 암호화와 인증이 필요한 경우 DTLS를 사용할 수 있는 환경이 있습니다.

개념적으로:

Application
↓
DTLS
↓
UDP
↓
IP

입니다.

단, 실제 장비가 DTLS를 지원하는지 확인해야 합니다.

31.2 Application 수준 보안#

장비가 DTLS를 지원하지 않는 경우에도 시스템 설계에 따라:

Message Authentication

Sequence Number

Nonce

Replay 방지

VPN

등을 검토할 수 있습니다.

단순히 UDP Port를 Firewall에서 열어놓는 것만으로 충분한 보안이 만들어지는 것은 아닙니다.

32장 UDP Spoofing을 고려해야 한다#

UDP에는 TCP 3-Way Handshake 같은 연결 확립 과정이 없습니다.

따라서 Source Address를 신뢰해 중요한 명령을 그대로 실행하도록 설계하면 위험할 수 있습니다.

예:

Source IP가 Server다
↓
OPEN 실행

만으로 인증하는 것은 충분하지 않을 수 있습니다.

중요한 제어 Protocol에는 적절한 인증과 무결성 검증이 필요합니다.

33장 UDP Packet Loss를 시험해보자#

격리된 Linux Test Network에서는 tc netem을 이용해 Network 품질을 변화시킬 수 있습니다.

예:

sudo tc qdisc add dev eth0 root netem delay 100ms loss 5%

이는 해당 Interface Traffic에 의도적으로 지연과 손실을 추가합니다.

실험 후에는:

sudo tc qdisc del dev eth0 root netem

으로 제거할 수 있습니다.

반드시 실제 운영 Network가 아닌 Lab 환경에서 사용해야 합니다.

33.1 무엇을 관찰해야 할까#

UDP Application에서는:

100개 송신
↓
몇 개 수신?

순서는 어떻게 변했는가?

Application ACK는 어떻게 동작하는가?

재시도는 몇 번 하는가?

중복은 어떻게 처리하는가?

를 확인합니다.

같은 조건에서 TCP도 시험하면 두 Protocol의 차이를 이해하기 쉽습니다.

34장 UDP Packet 재정렬도 시험할 수 있다#

Network에서는 Datagram의 도착 순서가 항상 송신 순서와 같다고 보장할 수 없습니다.

따라서 실시간 Telemetry나 제어 Protocol이라면 Payload에:

Sequence Number

Timestamp

Message ID

등을 포함할 필요가 있는지 검토할 수 있습니다.

예:

SEQ=102
TIME=10:00:02
STATUS=OPEN

Receiver는 늦게 도착한 오래된 상태를 구분할 수 있습니다.

35장 MTU와 UDP도 관계가 있다#

UDP Datagram이 지나치게 크면 IP Fragmentation 또는 Path MTU 문제와 연결될 수 있습니다.

특히 큰 UDP Datagram은 Fragment 하나만 손실되어도 원래 Datagram 전체를 사용할 수 없게 될 수 있습니다.

따라서 UDP Application을 설계할 때:

Payload 크기

Path MTU

Fragmentation

Tunnel / VPN Overhead

도 고려해야 합니다.

실시간 Network Protocol이 작은 Datagram을 선호하는 이유 중 하나이기도 합니다.

36장 UDP Socket Buffer가 가득 찰 수도 있다#

UDP는 Network Packet Loss만 문제가 되는 것이 아닙니다.

Receiver Host까지 Datagram이 도착했지만 Application이 충분히 빨리 읽지 못하면 Socket Receive Buffer가 부족해질 수 있습니다.

UDP Traffic
↓
Kernel Receive Buffer
↓
Application 처리 느림
↓
Buffer Full
↓
Datagram Drop

이 경우 Switch나 Cable은 정상인데 Application에서 Data Loss가 발생할 수도 있습니다.

36.1 Packet Capture와 Application Counter를 함께 본다#

예:

NIC Capture
1000 Datagram 수신

Application
930 Message 처리

라면 Host 내부의:

Socket Buffer

Application 처리 속도

CPU 부하

Thread Queue

등을 확인해야 합니다.

37장 UDP 장애를 진단하는 순서#

UDP 통신이 되지 않을 때는 다음 흐름이 유용합니다.

37.1 물리 계층#

Power

Cable

Link

Switch Port

37.2 Layer 2#

VLAN

MAC Address Table

37.3 Layer 3#

IP

Subnet

ARP / NDP

Gateway

Routing

37.4 UDP#

Source Port

Destination Port

Datagram이 실제 전송되는가?

Receiver까지 도착하는가?

37.5 Application#

Payload Format

Message ID

Sequence

Checksum

ACK Logic

Timeout

Retry

전체를 연결하면:

Link
↓
VLAN
↓
IP
↓
Routing
↓
UDP
↓
Application Protocol
↓
업무 처리

입니다.

38장 현장에서 증상별로 범위를 좁혀보자#

증상 우선 확인
Sender Capture에도 UDP 없음 Application·Socket·Routing
Sender에는 있고 Receiver에는 없음 VLAN·Routing·Firewall·Packet Loss
Receiver Capture에는 있고 Application은 못 받음 Port·Bind·Buffer·Application
일부 Datagram만 손실 Network 품질·Buffer·Application 부하
순서 뒤바뀜 Sequence 처리·Network Path
같은 명령 반복 수신 Retry·중복 처리·Message ID
Broadcast만 다른 VLAN에서 실패 Broadcast Domain·Routing 구조
Multicast 일부 장비만 실패 IGMP·IGMP Snooping·Group Membership
NAT 이후 응답 안 옴 NAT Mapping·Firewall Session Timeout

39장 UDP와 TCP를 선택할 때 보는 기준#

39.1 TCP가 적합할 가능성이 높은 경우#

데이터 손실이 허용되지 않음

순서가 중요함

파일 전송

API 통신

업무 Transaction

Application에서 전송 신뢰성을 직접 만들고 싶지 않음

39.2 UDP가 적합할 가능성이 높은 경우#

Message 단위 전송

일부 손실 허용

오래된 데이터보다 최신 데이터가 중요

Broadcast 필요

Multicast 필요

Application이 자체 Reliability를 관리

39.3 실제 선택은 요구사항으로 결정한다#

다음 질문을 먼저 하는 것이 좋습니다.

한 Packet 손실이 업무 장애인가?

순서가 반드시 필요한가?

중복 처리는 안전한가?

최신 데이터가 더 중요한가?

Broadcast / Multicast가 필요한가?

Application ACK를 구현할 것인가?

보안은 어떻게 적용할 것인가?

그 다음 TCP와 UDP를 선택해야 합니다.

40장 자주 발생하는 오해#

40.1 UDP는 무조건 TCP보다 빠르다?#

아닙니다.

Protocol Overhead는 작지만 실제 성능은 Network와 Application 구조에 따라 달라집니다.

40.2 실시간이면 무조건 UDP를 사용해야 한다?#

아닙니다.

손실 허용 여부, 지연 요구사항, Application Protocol 설계를 함께 봐야 합니다.

40.3 UDP는 Packet이 하나도 손실되지 않는다?#

아닙니다.

UDP는 전송 보장을 제공하지 않습니다.

40.4 UDP Checksum이 있으니 신뢰성이 보장된다?#

아닙니다.

Checksum은 오류 검출과 관련된 기능이며 재전송·순서·중복 처리를 제공하지 않습니다.

40.5 UDP는 Connectionless이므로 NAT와 무관하다?#

아닙니다.

NAT와 Stateful Firewall은 UDP Traffic에 대해서도 일정 시간 Mapping이나 Session 상태를 유지할 수 있습니다.

40.6 UDP는 Message 경계를 유지하는가?#

그렇습니다.

TCP의 Byte Stream과 달리 UDP는 Datagram 단위를 유지합니다.

다만 Network에서 Datagram 자체가 손실되거나 중복·재정렬될 수 있다는 점은 별개의 문제입니다.

41장 핵심 개념 한눈에 정리하기#

개념 의미
UDP Connectionless Transport Protocol
Datagram UDP의 독립적인 Message 단위
Source Port 송신 Application Port
Destination Port 수신 Application Port
Length UDP Header와 Payload 길이
Checksum Datagram 손상 검출
Packet Loss Datagram이 목적지까지 도착하지 않음
Reordering 송신 순서와 다른 순서로 도착
Duplicate 같은 Message가 반복 도착
Broadcast 같은 Broadcast Domain의 여러 장비 대상
Multicast 특정 Group 대상
Application ACK UDP 위에서 Application이 자체 구현하는 응답
Message ID 중복·응답 Matching 등에 활용
Sequence Number Application 수준 순서 관리에 활용 가능

42장 자기 점검#

42.1 UDP가 Connectionless라는 것은 무엇을 의미하는가#

TCP처럼 데이터를 보내기 전에 3-Way Handshake로 Connection 상태를 먼저 확립하지 않는다는 뜻입니다.

42.2 UDP는 데이터 순서를 보장하는가#

아닙니다.

순서가 필요하다면 Application에서 Sequence Number 등의 구조를 설계해야 합니다.

42.3 UDP로 Gate OPEN 명령을 보냈다면 전송 성공만으로 Gate가 열린 것을 확인할 수 있는가#

아닙니다.

UDP 전송 호출의 성공은 실제 장비의 수신이나 물리 동작 완료를 보장하지 않습니다.

Application ACK와 장비 상태 확인이 별도로 필요할 수 있습니다.

42.4 UDP Datagram을 두 번 보내면 더 안전한가#

단순 중복 전송만으로는 충분하지 않습니다.

두 Datagram 모두 도착할 수 있기 때문에 Message ID와 중복 처리 정책이 필요할 수 있습니다.

42.5 UDP와 TCP의 가장 중요한 데이터 처리 차이는 무엇인가#

TCP는 Application에 Byte Stream을 제공하지만 UDP는 Datagram이라는 Message 경계를 유지합니다.

43장 이 글을 마치며#

UDP는 TCP의 단순한 저가형 버전이 아닙니다.

두 Protocol은 출발점부터 다릅니다.

TCP는:

Connection
↓
Byte Stream
↓
Sequence
↓
ACK
↓
Retransmission
↓
Flow Control

을 제공합니다.

UDP는:

Datagram
↓
IP
↓
전송

이라는 훨씬 단순한 구조입니다.

따라서 UDP를 사용하면 Application이 더 많은 판단을 해야 할 수 있습니다.

손실돼도 되는가?

다시 보내야 하는가?

중복은 어떻게 처리하는가?

순서가 바뀌면 어떻게 할 것인가?

상대가 실제로 받았는지 확인할 것인가?

업무가 완료되었는지 어떻게 확인할 것인가?

주차관제 시스템에서 특히 중요한 제어 명령이라면 이 질문들이 매우 중요합니다.

예를 들어:

OPEN CMD-1001

을 보냈다면 단순히:

UDP Datagram 송신 완료

를 업무 완료라고 보면 안 됩니다.

보다 안전한 Application 설계라면:

Command Sent
↓
Application ACK
↓
Command Accepted
↓
Physical Action
↓
Completion Status

처럼 여러 상태를 구분할 수 있습니다.

UDP 장애를 분석할 때도:

Sender에서 Datagram이 나갔는가?
↓
Network를 통과했는가?
↓
Receiver까지 도착했는가?
↓
올바른 Port인가?
↓
Application이 읽었는가?
↓
Payload를 정상적으로 해석했는가?
↓
실제 업무 처리가 성공했는가?

순서로 살펴보는 것이 좋습니다.

특히 다음 네 가지를 기억하면 UDP의 핵심을 제대로 이해한 것입니다.

UDP는 TCP와 같은 Connection을 만들지 않습니다.

UDP는 Byte Stream이 아니라 Datagram 단위로 데이터를 전달합니다.

UDP 자체는 손실·순서·중복·재전송을 보장하지 않습니다.

신뢰성이 필요한 UDP 시스템에서는 Message ID·Sequence·ACK·Retry 같은 기능을 Application Protocol에서 별도로 설계해야 합니다.

결국 TCP와 UDP의 선택은 어느 것이 더 빠른가의 문제가 아닙니다. 어떤 데이터를 전달하고, 손실·지연·중복을 업무적으로 어떻게 처리해야 하는가의 문제입니다.

이 페이지의 목차