TCP와 UDP 중 어떤 통신 방식을 선택해야 하는가

TCP와 UDP 중 어떤 통신 방식을 선택해야 하는가#

1장 TCP와 UDP 중 어느 것이 더 좋은가#

1.1 정답은 데이터의 성격에 따라 달라진다#

새로운 주차관제 시스템을 구축한다고 가정해보겠습니다.

Network에는 다음 장비가 있습니다.

LPR Camera

Gate Controller

Parking Server

Payment Kiosk

Parking Sensor

관리 PC

이 장비들이 모두 같은 방식으로 통신해야 할까요?

그렇지 않습니다.

예를 들어:

결제 결과

와:

1초마다 전달되는 주차 센서 상태

는 중요도가 다릅니다.

결제 결과가 한 번 사라지면 업무 오류로 이어질 수 있습니다.

반면 1초마다 전송되는 센서 값 하나가 사라져도 바로 다음 값이 도착한다면 큰 문제가 아닐 수 있습니다.

따라서 TCP와 UDP를 선택할 때 첫 질문은:

어느 Protocol이 더 빠른가?

가 아닙니다.

다음 질문이 먼저입니다.

이 데이터가 사라져도 되는가?

순서가 바뀌어도 되는가?

늦게 도착한 데이터도 가치가 있는가?

같은 데이터가 두 번 도착해도 되는가?

한 명에게 보낼 것인가?

여러 장비에게 동시에 보낼 것인가?

이 질문에 대한 답이 Protocol 선택을 결정합니다.

2장 TCP와 UDP의 가장 큰 차이#

2.1 TCP는 신뢰성 있는 Byte Stream을 제공한다#

TCP는 다음 기능을 제공합니다.

Connection

Sequence Number

ACK

Retransmission

순서 복구

중복 처리

Flow Control

Congestion Control

Application 입장에서는 순서가 맞는 Byte Stream을 받을 수 있습니다.

개념적으로:

Application
↓
TCP
↓
신뢰성 있는 Byte Stream

입니다.

2.2 UDP는 Datagram을 독립적으로 전달한다#

UDP는 훨씬 단순합니다.

Application
↓
UDP Datagram
↓
IP
↓
Network

TCP처럼:

3-Way Handshake

Transport Layer ACK

자동 재전송

순서 복구

를 제공하지 않습니다.

대신 Application이 하나의 Datagram으로 보낸 Message 경계가 유지됩니다.

2.3 핵심 차이#

간단하게 비교하면 다음과 같습니다.

TCP
→ 연결 상태를 관리하며 신뢰성 있는 Byte Stream 제공

UDP
→ 독립적인 Datagram 전달

따라서 TCP와 UDP는 단순한:

안전한 Protocol
vs
빠른 Protocol

관계가 아닙니다.

3장 첫 번째 판단 기준 — 데이터가 사라져도 되는가#

3.1 손실을 허용할 수 없는 데이터#

예를 들어:

결제 승인

출차 정산 기록

설정 변경

장비 Firmware 전송

중요 업무 Event

같은 데이터는 손실됐을 때 문제가 큽니다.

이런 경우 TCP처럼 Transport Layer에서:

손실 감지
↓
재전송
↓
순서 복구

를 제공하는 방식이 유리할 수 있습니다.

3.2 일부 손실을 허용할 수 있는 데이터#

반대로 Sensor가 다음 상태를 계속 보내고 있다고 가정합니다.

10:00:01
Occupied

10:00:02
Occupied

10:00:03
Empty

10:00:04
Empty

10:00:02 하나가 사라져도 최신 상태가 계속 전달된다면 큰 문제가 아닐 수 있습니다.

이런 데이터에서는:

손실된 과거 데이터 복구

보다:

최신 데이터 빠르게 전달

이 더 중요할 수 있습니다.

이런 특성에서는 UDP가 적합한 경우가 있습니다.

4장 두 번째 판단 기준 — 늦게 도착한 데이터도 필요한가#

4.1 TCP는 손실된 데이터를 다시 전달하려고 한다#

TCP에서 Packet Loss가 발생하면 재전송이 일어날 수 있습니다.

즉:

Packet Loss
↓
복구
↓
Application에 순서대로 전달

합니다.

신뢰성이 중요한 업무에는 매우 유용합니다.

4.2 실시간 데이터에서는 오래된 데이터가 필요 없을 수 있다#

실시간 영상이나 음성을 생각해보겠습니다.

Frame 100
Frame 101
Frame 102
Frame 103

중 Frame 101이 손실됐다고 가정합니다.

이미 Frame 120을 보여주고 있는데 Frame 101이 늦게 도착한다고 해서 반드시 도움이 되는 것은 아닙니다.

이런 시스템에서는:

완벽한 복구

보다:

현재 데이터의 지연 최소화

가 더 중요할 수 있습니다.

그래서 실시간 Media에서는 UDP 기반 Protocol이 사용되는 경우가 많습니다.

5장 세 번째 판단 기준 — 순서가 반드시 중요한가#

5.1 TCP는 Byte 순서를 맞춰준다#

TCP는:

A
B
C

순서의 데이터를 Network에서:

A
C
B

순으로 받아도 Application에는 원래 Byte Stream 순서로 전달하도록 관리합니다.

5.2 UDP는 순서를 맞춰주지 않는다#

UDP Datagram을:

SEQ 100

SEQ 101

SEQ 102

순서로 보내도:

100
102
101

순으로 도착할 수 있습니다.

순서가 중요하다면 Application이:

Sequence Number

같은 정보를 Payload에 넣어 직접 처리해야 합니다.

5.3 순서가 항상 필요한 것은 아니다#

예를 들어 최신 온도만 필요하다면:

SEQ 101
20.1℃

SEQ 102
20.3℃

이후 늦게:

SEQ 100
19.9℃

가 도착했을 때 오히려 버리는 것이 적절할 수 있습니다.

따라서:

순서를 복구해야 하는가?

오래된 Message를 버려야 하는가?

도 선택 기준입니다.

6장 네 번째 판단 기준 — 중복 데이터를 어떻게 처리할 것인가#

6.1 TCP는 Byte Stream의 중복을 내부적으로 처리한다#

TCP Segment가 Network 상황 때문에 다시 전달되어도 TCP Stack은 Sequence Number를 이용해 중복 Byte를 Application에 반복 전달하지 않도록 관리합니다.

6.2 UDP에서는 Application이 중복을 처리해야 한다#

예를 들어 Gate 명령이 있습니다.

OPEN

ACK가 없어서 Server가 다시 보냈습니다.

OPEN
OPEN

두 Datagram 모두 Controller에 도착할 수 있습니다.

이때 Application이 아무 대책이 없다면 동일한 업무를 두 번 실행할 수 있습니다.

6.3 Message ID를 사용할 수 있다#

예:

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

Controller가:

CMD-10001

을 이미 처리했다면 다시 도착한 동일 Message를 중복 실행하지 않도록 설계할 수 있습니다.

이것이 UDP 기반 중요 명령에서 필요한 핵심 설계 중 하나입니다.

7장 다섯 번째 판단 기준 — Message 단위인가 Stream인가#

7.1 TCP는 Message 경계를 모른다#

Application이:

OPEN

과:

GATE01

을 따로 보내도 Receiver에서는:

OPENGATE01

로 읽힐 수 있습니다.

또는:

OP
ENG
ATE01

처럼 나뉠 수도 있습니다.

TCP는 Byte Stream이기 때문입니다.

따라서 Application Protocol에서:

Length

Delimiter

Header

등으로 Message 경계를 정의해야 합니다.

7.2 UDP는 Datagram 경계를 유지한다#

UDP에서는:

Datagram A
OPEN

Datagram B
GATE01

가 별개의 Datagram으로 처리됩니다.

따라서 독립적인 짧은 Message 중심 Protocol에서는 구조가 단순해질 수 있습니다.

하지만 이 장점과:

손실
중복
재정렬

문제는 별개입니다.

8장 여섯 번째 판단 기준 — Broadcast나 Multicast가 필요한가#

8.1 TCP는 기본적으로 Point-to-Point Connection이다#

TCP Connection은 기본적으로 특정 두 Endpoint 사이에 만들어집니다.

Client
⇄
Server

여러 장비에게 같은 데이터를 한 번에 보내는 Broadcast 용도로 TCP를 사용하는 구조는 아닙니다.

8.2 UDP는 Broadcast를 사용할 수 있다#

예를 들어 Device Discovery에서:

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

라는 Message를 같은 Broadcast Domain의 여러 장비에게 전송할 수 있습니다.

UDP가 이런 Discovery Protocol에서 많이 사용되는 이유 중 하나입니다.

8.3 Multicast가 필요하다면 UDP가 중요한 선택지가 된다#

예를 들어 하나의 영상 Stream을 여러 Monitor가 동시에 받아야 한다고 가정합니다.

Camera
   │
   ├→ Monitor A
   ├→ Monitor B
   └→ Monitor C

이런 경우 UDP Multicast 기반 구조를 사용할 수 있습니다.

TCP는 이런 IP Multicast 전달 구조를 일반적으로 제공하지 않습니다.

9장 TCP와 UDP의 Header 크기만 보고 선택하지 않는다#

UDP Header는 기본적으로 8Byte입니다.

TCP Header는 Option이 없는 기본 Header만 해도 20Byte입니다.

그래서:

UDP Header가 작다
→ UDP가 더 효율적이다

라고 말할 수는 있습니다.

하지만 실제 시스템에서는 Header 몇 Byte보다:

Packet Loss

Latency

Application 처리

암호화

Routing

MTU

재전송

Session 유지

같은 요소의 영향이 훨씬 클 수 있습니다.

따라서 Header 크기만으로 Protocol을 선택해서는 안 됩니다.

10장 UDP가 더 빠르다는 표현을 조심해야 한다#

10.1 UDP의 처리 구조가 단순한 것은 맞다#

UDP에는 TCP의:

Handshake

ACK

Retransmission

Flow Control

순서 복구

가 없습니다.

그래서 첫 Datagram을 보내기 전에 TCP와 같은 연결 절차가 필요하지 않습니다.

10.2 하지만 실제 응답 시간이 항상 더 짧은 것은 아니다#

UDP로 중요한 명령을 보내고 Application에서:

ACK 대기
↓
Timeout
↓
Retry
↓
중복 검사

를 모두 구현한다면 상황이 달라집니다.

결국:

Application Reliability Protocol

을 직접 만드는 셈이 될 수도 있습니다.

따라서 단순히:

Latency 중요
→ UDP

라고 결정하면 안 됩니다.

11장 LPR Camera에서는 무엇을 선택해야 할까#

11.1 LPR Camera Traffic도 하나가 아니다#

LPR Camera는 여러 종류의 데이터를 보낼 수 있습니다.

예:

실시간 Video Stream

차량번호 인식 결과

JPEG Snapshot

장비 상태

설정 API

각각 요구사항이 다릅니다.

11.2 실시간 Video Stream#

Video Streaming에서는 지연 특성 때문에 UDP 기반 RTP 등을 지원하는 경우가 있습니다.

반대로 Network 환경이나 제품 구성에 따라 TCP 기반 Streaming을 사용할 수도 있습니다.

따라서:

Camera
=
UDP

라고 보면 안 됩니다.

제조사가 제공하는 Streaming Protocol을 확인해야 합니다.

11.3 차량번호 인식 결과#

다음과 같은 결과라면:

{
  "plate": "12가3456",
  "time": "2026-09-24T10:31:05",
  "lane": "IN-01"
}

업무적으로 손실되면 안 될 수 있습니다.

이런 데이터는:

HTTP / HTTPS

TCP Socket

Message Queue

같은 신뢰성 있는 전달 구조가 적합할 수 있습니다.

11.4 JPEG Snapshot#

Snapshot 한 장이 반드시 저장되어야 한다면 TCP 기반 HTTP Upload 등을 사용할 수 있습니다.

반대로 실시간 영상 Stream의 Frame 하나라면 일부 손실을 허용하는 설계가 가능할 수 있습니다.

즉 같은 Camera에서도 Data Type별로 다른 Protocol을 사용할 수 있습니다.

12장 Gate OPEN 명령은 TCP가 정답일까#

12.1 TCP를 사용하면 Transport 전달 신뢰성은 높아진다#

예:

Server
↓
TCP
↓
Controller

TCP는 Byte Stream의 손실·순서를 관리합니다.

중요 명령에는 유리한 특성입니다.

12.2 하지만 TCP ACK가 Gate OPEN 완료를 보장하는 것은 아니다#

Server가:

OPEN

을 전송하고 TCP ACK를 받았다고 가정합니다.

이것은 기본적으로:

Controller의 TCP Stack까지
데이터가 도착했다.

는 의미입니다.

다음 과정은 별개입니다.

Application이 Command 읽음

Command 검증

Controller Logic 실행

Relay 출력

Motor 동작

Barrier Open Sensor 확인

따라서 TCP를 사용하더라도 중요한 제어는 Application 수준의 상태 확인이 필요합니다.

12.3 좋은 제어 Protocol은 업무 상태를 구분한다#

예:

CMD-10001 OPEN
        ↓
RECEIVED
        ↓
ACCEPTED
        ↓
STARTED
        ↓
COMPLETED

처럼 상태를 나눌 수 있습니다.

즉:

TCP 사용
=
Application ACK 불필요

가 아닙니다.

13장 UDP로 Gate 명령을 보내는 것도 가능하다#

제조사 Protocol이 UDP를 사용하도록 설계되어 있다면 UDP로 제어할 수도 있습니다.

그 경우 Application에서 다음을 고려해야 합니다.

Message ID

ACK

Timeout

Retry

중복 방지

명령 만료시간

실제 완료 상태

예:

Server

CMD=10001 OPEN
──────────────→

Controller

ACK=10001
←──────────────

Controller

COMPLETE=10001
←──────────────

이렇게 설계되어 있다면 UDP라고 해서 반드시 신뢰성이 낮은 업무 시스템이 되는 것은 아닙니다.

신뢰성 기능의 위치가 TCP가 아니라 Application에 있을 뿐입니다.

14장 Sensor 상태 전송에서는 UDP가 적합할 수 있다#

14.1 주기적인 상태 데이터#

주차면 Sensor가:

1초마다 상태 전송

한다고 가정합니다.

SEQ 100
EMPTY

SEQ 101
EMPTY

SEQ 102
OCCUPIED

SEQ 103
OCCUPIED

중 하나가 사라져도 다음 값이 곧 도착합니다.

이런 경우에는 UDP의 단순성이 유용할 수 있습니다.

14.2 단 Event는 다를 수 있다#

다음 Event는 성격이 다릅니다.

차량 진입

결제 완료

출차 완료

이벤트 하나가 영구적으로 사라지면 업무 데이터가 맞지 않을 수 있습니다.

따라서 같은 Sensor 장비라도:

실시간 상태

와:

업무 Event

를 다르게 설계할 수 있습니다.

15장 Heartbeat는 TCP와 UDP 모두 가능하다#

Heartbeat는:

상대 Application이 살아 있는가?

를 확인하기 위한 Application Message입니다.

예:

HEARTBEAT
DEVICE=GATE01
SEQ=5001

이 메시지는 TCP에서도 사용할 수 있고 UDP에서도 사용할 수 있습니다.

15.1 UDP Heartbeat#

일부 Packet이 손실돼도:

3회 연속 미수신
→ Offline

처럼 판단할 수 있습니다.

이런 구조에서는 UDP가 잘 맞을 수 있습니다.

15.2 TCP Connection만으로 Application 상태를 판단하지 않는다#

TCP Connection이:

ESTABLISHED

라고 해도 Application Process가 실제 업무를 처리하지 못하고 있을 수 있습니다.

따라서 중요한 시스템에서는 TCP에서도 Application Heartbeat를 별도로 사용할 수 있습니다.

16장 파일 전송에는 어떤 방식이 적합할까#

Firmware, Image File, Log Archive 등을 전송한다고 가정합니다.

파일 크기
500MB

이런 데이터는:

일부 Byte 손실 허용 불가

순서 중요

완전성 중요

합니다.

일반적으로 TCP 기반 Protocol을 사용하는 것이 구현하기 훨씬 편리합니다.

예:

HTTPS

SFTP

TCP 기반 전용 Protocol

등입니다.

UDP로 대용량 파일을 전송하려면 Application이 신뢰성 메커니즘을 별도로 설계해야 합니다.

17장 결제 데이터는 Transport Protocol만 보고 판단하면 안 된다#

Payment Kiosk와 Server가 통신한다고 하겠습니다.

중요한 것은 단순히:

TCP를 사용한다.

가 아닙니다.

다음까지 함께 봐야 합니다.

TLS

Authentication

Transaction ID

Retry 정책

Duplicate Transaction 방지

Server 처리 결과 확인

Audit Log

결제 Request를 TCP로 보냈다고 해서 결제가 한 번만 처리된다고 자동으로 보장되는 것은 아닙니다.

Network 오류 때문에 Client가 동일 Transaction을 다시 요청할 수도 있기 때문입니다.

18장 멱등성은 TCP와 UDP 모두에서 중요하다#

예를 들어 Client가 결제 요청을 보냈습니다.

PAYMENT
TX=ABC123

Server는 처리했는데 Response가 Network에서 사라졌습니다.

Client는 Timeout 후 다시 요청할 수 있습니다.

PAYMENT
TX=ABC123

TCP를 사용했다고 해도 새로운 Application Request가 다시 전송되는 상황은 발생할 수 있습니다.

따라서 Server는 Transaction ID 등을 이용해:

ABC123
이미 처리됨

을 판단할 수 있어야 합니다.

즉 중복 업무 처리 문제는 TCP만 선택한다고 사라지지 않습니다.

19장 Network가 불안정할 때 TCP와 UDP는 다르게 보인다#

19.1 TCP#

Packet Loss가 발생하면:

Loss
↓
Retransmission
↓
전송 지연 증가

가 나타날 수 있습니다.

Application에서는:

데이터는 결국 도착하지만
느려진다.

처럼 보일 수 있습니다.

19.2 UDP#

Packet Loss가 발생하면:

Loss
↓
해당 Datagram 사라짐

으로 나타납니다.

Application이 보완하지 않는다면 그대로 손실됩니다.

즉 불안정한 Network에서:

TCP
→ 지연 증가 형태로 나타날 수 있음

UDP
→ 데이터 손실 형태로 나타날 수 있음

이라는 차이가 생길 수 있습니다.

20장 Head-of-Line Blocking도 이해해야 한다#

TCP는 Application에 순서가 맞는 Byte Stream을 제공합니다.

따라서 앞쪽 데이터가 손실되면 뒤쪽 데이터가 이미 도착했더라도 Application 전달이 지연될 수 있습니다.

개념적으로:

100
101 ← 손실
102 도착
103 도착

이라면:

101 복구

가 필요한 상황이 생길 수 있습니다.

이 특성은 신뢰성과 순서가 중요한 경우에는 필요하지만 매우 지연 민감한 실시간 Application에서는 부담이 될 수 있습니다.

21장 UDP라고 혼잡 제어를 무시해도 되는 것은 아니다#

UDP Protocol 자체에는 TCP와 같은 Congestion Control 메커니즘이 없습니다.

그렇다고 UDP Application이 Network 용량을 무시하고 마음대로 보내도 된다는 의미는 아닙니다.

예:

Camera 100대

각각 고속 UDP Stream

을 동시에 보내면 Network Queue가 가득 차고 Packet Loss가 급증할 수 있습니다.

UDP 기반 Application이나 상위 Protocol이 전송률을 적절하게 관리해야 합니다.

22장 큰 데이터에서는 MTU도 고려한다#

UDP Datagram이 매우 커지면 IP Fragmentation과 연결될 수 있습니다.

예:

UDP Payload
수만 Byte

를 하나의 Datagram으로 만든다고 생각해보겠습니다.

Network MTU보다 크다면 Fragmentation이 발생할 수 있습니다.

Fragment 일부가 손실되면 원래 Datagram 전체를 사용할 수 없게 될 수 있습니다.

따라서 큰 데이터를 UDP로 보낼 때는:

Datagram Size

Path MTU

Fragmentation

Application Chunking

을 고려해야 합니다.

TCP는 Byte Stream을 Segment 단위로 나누는 처리를 Transport Layer에서 담당한다는 차이가 있습니다.

23장 NAT 환경에서는 UDP 특성을 별도로 본다#

23.1 TCP NAT#

TCP에는 Connection 상태가 있기 때문에 Stateful Firewall이나 NAT 장비가 SYN·FIN·RST 등을 참고해 Session을 추적할 수 있습니다.

23.2 UDP NAT#

UDP는 Connectionless이지만 NAT 장비는 일정 시간:

내부 IP:Port
↕
외부 IP:Port

Mapping을 관리할 수 있습니다.

Traffic이 오랫동안 없으면 Mapping이 사라질 수 있습니다.

따라서 장시간 외부 Server와 UDP 통신해야 하는 장비에서는:

Heartbeat

Registration Refresh

Application Keepalive

등이 필요할 수 있습니다.

24장 방화벽에서는 TCP와 UDP를 정확하게 구분한다#

다음 두 Rule은 서로 다릅니다.

TCP 4000 Allow

과:

UDP 4000 Allow

Port Number가 같아도 Transport Protocol이 다릅니다.

따라서 장비 문서에:

Port 4000

만 적혀 있다면 정보가 부족합니다.

최소한:

TCP인가?

UDP인가?

Inbound인가?

Outbound인가?

누가 Client인가?

누가 Server인가?

까지 확인해야 합니다.

25장 TCP와 UDP 모두 보안을 자동으로 제공하지 않는다#

TCP를 사용한다고 Application Data가 암호화되는 것은 아닙니다.

UDP도 마찬가지입니다.

TCP 기반이라면:

TLS

를 사용할 수 있습니다.

UDP 기반이라면 환경에 따라:

DTLS

같은 보안 Protocol을 사용할 수 있습니다.

25.1 DTLS는 UDP에 TCP 신뢰성을 추가하는 기술은 아니다#

여기서 중요한 점이 있습니다.

DTLS의 주요 목적은 UDP 기반 통신에서:

암호화

인증

무결성 보호

를 제공하는 것입니다.

UDP Datagram의:

전달 보장

순서 보장

일반적인 TCP식 재전송

을 대신 제공하는 기술로 이해하면 안 됩니다.

전송 신뢰성은 Application이나 다른 상위 Protocol이 별도로 해결해야 할 수 있습니다.

26장 제조사가 정한 Protocol이 있다면 우선 확인한다#

실제 산업 장비에서는 사용자가 자유롭게 TCP와 UDP를 선택하지 못하는 경우가 많습니다.

예:

Camera Discovery
UDP 3702

Video
RTSP / RTP

Control API
HTTPS

장비 상태
Manufacturer Protocol

처럼 이미 Protocol이 정해져 있을 수 있습니다.

이 경우:

TCP가 더 좋아 보이니까 UDP 장비를 TCP로 바꾸자.

라고 할 수 없습니다.

먼저 제조사가 제공하는:

Protocol Specification

SDK

API

Firmware 기능

보안 지원

을 확인해야 합니다.

27장 Protocol을 새로 설계한다면 먼저 요구사항을 적는다#

TCP와 UDP를 먼저 정하지 말고 요구사항부터 작성하는 것이 좋습니다.

예:

데이터 종류
Gate OPEN 명령

손실 허용
불가

중복 허용
불가

최대 허용 지연
500ms

완료 확인
필요

Broadcast
불필요

암호화
필요

이렇게 요구사항을 정리한 뒤 Protocol을 선택합니다.

28장 Gate 제어 Protocol을 설계해보자#

요구사항:

명령 손실 불가

중복 동작 불가

완료 확인 필요

라면 TCP를 사용한다고 하더라도 Application Protocol에 다음 정보가 필요할 수 있습니다.

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

Controller 응답:

{
  "messageId": "CMD-10001",
  "status": "accepted"
}

실제 동작 완료:

{
  "messageId": "CMD-10001",
  "status": "completed"
}

즉 TCP 선택과 업무 Protocol 설계는 별개의 문제입니다.

29장 Sensor Protocol을 설계해보자#

요구사항:

1초마다 측정

일부 Packet Loss 허용

오래된 값은 필요 없음

최신 상태 중요

이라면 UDP를 고려할 수 있습니다.

Payload:

{
  "sensorId": "P-001",
  "seq": 10321,
  "timestamp": "2026-09-24T10:31:20",
  "occupied": true
}

Receiver는:

Sequence Number

Timestamp

를 이용해 오래된 Datagram을 버릴 수 있습니다.

30장 Video 전송은 조금 더 복잡하다#

영상은 단순히:

TCP
vs
UDP

만 결정해서 끝나는 문제가 아닙니다.

실제 Camera System에서는:

RTSP

RTP

RTCP

HTTP

WebRTC

Manufacturer Protocol

등 여러 Protocol이 사용될 수 있습니다.

RTP 역시 구성에 따라 UDP와 함께 사용될 수 있고, 일부 환경에서는 TCP를 통한 전달 방식을 사용하기도 합니다.

따라서 Camera Traffic은 제품의 Streaming 방식 전체를 확인해야 합니다.

31장 TCP와 UDP 선택표#

요구사항 TCP 쪽이 유리한 경우 UDP 쪽이 유리한 경우
데이터 손실 허용하기 어려움 일부 허용 가능
순서 반드시 유지 Application에서 처리 가능
데이터 형태 Stream 독립 Message
늦은 데이터 받아야 함 가치가 낮을 수 있음
Broadcast 필요 없음 필요
Multicast 필요 없음 필요
신뢰성 구현 Transport Layer에 맡김 Application이 직접 구현 가능
실시간성 일부 지연 허용 최신 데이터 우선
대용량 파일 일반적으로 적합 별도 신뢰성 설계 필요
Device Discovery 일반적으로 부적합 적합한 경우 많음

이 표는 절대적인 규칙이 아니라 설계 방향을 결정하기 위한 기준입니다.

32장 주차관제 기능별 판단 예#

기능 우선 고려할 특성 가능한 선택
차량번호 인식 결과 손실 방지·업무 기록 TCP 기반 API 등
실시간 Camera Stream 지연·실시간성 UDP/RTP 또는 TCP 기반 Streaming
JPEG Snapshot Upload 완전한 데이터 전달 TCP/HTTPS 등
Gate 제어 명령 신뢰성·중복 방지·완료 확인 TCP 또는 신뢰성 보완 UDP
Parking Sensor 주기 상태 최신 상태 중요 UDP 고려 가능
결제 요청 업무 Transaction·보안 TCP/TLS 기반 구조
Device Discovery 여러 장비 검색 UDP Broadcast/Multicast 가능
Firmware Download 완전한 파일 전달 TCP 기반 Protocol

실제 장비에서는 제조사가 제공하는 Protocol 지원 범위가 우선됩니다.

33장 TCP를 선택한다고 모든 문제가 해결되지는 않는다#

TCP가 해결해주는 것은 Transport 수준입니다.

예를 들어 TCP는:

Byte 전달

순서

재전송

을 관리합니다.

하지만 다음은 Application 문제입니다.

같은 결제를 두 번 처리했는가?

OPEN 명령을 실제로 실행했는가?

Database 저장에 성공했는가?

장비가 물리적으로 열렸는가?

따라서 TCP 기반 시스템에서도:

Transaction ID

Message ID

Application ACK

업무 상태

Idempotency

가 필요할 수 있습니다.

34장 UDP를 선택한다고 신뢰성이 반드시 낮은 것도 아니다#

UDP 자체에는 신뢰성 기능이 없습니다.

하지만 Application Protocol에서:

Sequence

ACK

Retry

Message ID

FEC

Duplicate Detection

같은 기능을 설계할 수 있습니다.

따라서 잘 설계된 UDP 기반 Protocol은 특정 목적에서 높은 신뢰성을 제공할 수 있습니다.

다만 그만큼 Application 구현이 복잡해집니다.

35장 개발자가 Protocol을 선택할 때 묻는 질문#

Protocol을 결정하기 전에 다음 질문에 답해보는 것이 좋습니다.

35.1 손실#

Message 하나가 사라지면
업무 장애인가?

35.2 순서#

뒤늦게 도착한 Message를
처리해야 하는가?

35.3 중복#

같은 Message가 두 번 도착해도
안전한가?

35.4 지연#

100ms 늦는 것이 중요한가?

1초 늦어도 괜찮은가?

35.5 통신 대상#

1:1인가?

1:N인가?

35.6 복구#

손실됐을 때
누가 다시 보낼 것인가?

35.7 보안#

인증과 암호화가 필요한가?

이 질문에 먼저 답하면 TCP와 UDP 선택이 훨씬 쉬워집니다.

36장 장애가 발생했을 때 보는 방법도 다르다#

36.1 TCP#

확인 흐름:

SYN
↓
SYN/ACK
↓
ACK
↓
Sequence
↓
ACK
↓
Retransmission
↓
Window
↓
FIN / RST

입니다.

36.2 UDP#

UDP에는 이런 Connection 상태가 없습니다.

대신:

Sender에서 Datagram 발생?
↓
Receiver까지 도착?
↓
올바른 Port?
↓
Application이 수신?
↓
Sequence 누락?
↓
중복?
↓
Application ACK?

를 확인합니다.

따라서 Packet Capture를 읽는 방법 자체도 달라집니다.

37장 시험망에서 TCP와 UDP를 직접 비교해보자#

테스트 환경에서 같은 Message를 TCP와 UDP로 보내볼 수 있습니다.

예:

TEST-0001
TEST-0002
TEST-0003
...

그리고 Network에 의도적으로:

Latency

Packet Loss

Jitter

를 추가합니다.

관찰 항목은:

TCP Retransmission

TCP 지연 증가

UDP Message Loss

UDP Sequence 누락

Application 처리시간

입니다.

37.1 단순 평균 속도만 비교하지 않는다#

테스트 결과를:

TCP 20ms

UDP 10ms

라는 한 숫자로 비교해서는 부족합니다.

다음까지 보는 것이 좋습니다.

평균 Latency

최대 Latency

Jitter

Packet Loss

재전송률

처리 성공률

중복 처리

CPU 사용률

Application 요구사항과 연결해야 의미가 있습니다.

38장 Protocol 선택에서 보안도 포함한다#

어떤 Protocol을 선택하든 중요한 Network라면 다음을 봐야 합니다.

Authentication

Encryption

Integrity

Replay Protection

Access Control

Logging

예를 들어 중요한 Gate 명령을:

Source IP가 맞으니까 허용

하는 방식으로만 인증하면 충분하지 않을 수 있습니다.

Protocol 선택과 보안 설계는 함께 진행해야 합니다.

39장 현장에서 가장 위험한 선택 방식#

다음과 같은 이유만으로 Protocol을 선택하면 문제가 생길 가능성이 높습니다.

UDP가 빠르다니까 UDP

TCP가 안전하다니까 TCP

예전 장비가 UDP니까 UDP

포트가 적혀 있으니까 그대로 사용

대신 다음 순서가 좋습니다.

업무 요구사항
↓
손실 허용 여부
↓
지연 요구
↓
순서·중복 정책
↓
1:1 / 1:N
↓
보안 요구
↓
Network 환경
↓
장비 지원
↓
TCP / UDP 결정

40장 TCP와 UDP 중 선택하는 실무 흐름#

다음 흐름을 기준으로 판단할 수 있습니다.

이 데이터가 손실되면 안 되는가?
        │
        ├─ Yes
        │    ↓
        │  순서도 중요한가?
        │    ↓
        │  TCP 우선 검토
        │
        └─ No
             ↓
오래된 데이터보다 최신 데이터가 중요한가?
        │
        ├─ Yes
        │    ↓
        │  UDP 검토
        │
        └─ No
             ↓
Broadcast / Multicast가 필요한가?
        │
        ├─ Yes
        │    ↓
        │  UDP 검토
        │
        └─ No
             ↓
Application이 Reliability를 직접 구현할 이유가 있는가?
        │
        ├─ No → TCP 우선 검토
        │
        └─ Yes → UDP도 검토

하지만 실제 산업 장비에서는 마지막에 반드시 하나를 더 확인합니다.

제조사가 무엇을 지원하는가?

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

판단 항목 TCP UDP
통신 형태 Connection 기반 Connectionless
데이터 모델 Byte Stream Datagram
전달 확인 TCP에서 처리 Application 필요
재전송 있음 없음
순서 복구 있음 없음
중복 Byte 처리 TCP에서 처리 Application 책임
Flow Control 있음 없음
Congestion Control 있음 UDP 자체에는 없음
Broadcast 일반적으로 사용하지 않음 가능
Multicast 일반적인 TCP 방식 아님 가능
Message 경계 없음 있음
Application 구현 부담 상대적으로 낮음 신뢰성 요구 시 증가

42장 자기 점검#

42.1 중요한 제어 명령이면 무조건 TCP를 사용해야 하는가#

반드시 그렇지는 않습니다.

TCP는 좋은 선택지가 될 수 있지만 제조사가 UDP 기반의 Application ACK·Retry·중복 방지 구조를 제공한다면 UDP로도 신뢰성 있는 시스템을 구성할 수 있습니다.

핵심은 Transport Protocol 이름이 아니라 업무적으로 필요한 전달 보장이 구현되어 있는가입니다.

42.2 실시간 데이터라면 무조건 UDP인가#

아닙니다.

일부 실시간 Application은 UDP가 적합하지만 Network 환경과 Application 요구사항에 따라 TCP 기반 전송도 사용할 수 있습니다.

42.3 TCP를 쓰면 중복 업무 처리가 없어지는가#

아닙니다.

TCP는 Byte Stream 중복을 처리하지만 Application Request 자체가 다시 발생할 수 있습니다.

Transaction ID와 Idempotency 같은 Application 설계가 필요할 수 있습니다.

42.4 UDP로 중요한 데이터를 보내려면 무엇이 필요할 수 있는가#

요구사항에 따라:

Message ID

Sequence Number

Application ACK

Timeout

Retry

Duplicate Detection

완료 상태 확인

등을 추가할 수 있습니다.

42.5 TCP와 UDP를 선택할 때 가장 먼저 물어야 할 질문은 무엇인가#

어느 것이 더 빠른가가 아니라:

이 데이터의 손실·지연·순서 변경·중복이 업무에 어떤 영향을 주는가?

를 먼저 확인해야 합니다.

43장 이 글을 마치며#

TCP와 UDP를 비교할 때 가장 흔한 설명은:

TCP
→ 느리지만 안전

UDP
→ 빠르지만 불안정

입니다.

입문 단계에서는 이해하기 쉽지만 실제 시스템을 설계하기에는 너무 단순한 설명입니다.

정확하게는 TCP가:

Connection

Byte Stream

Sequence

ACK

Retransmission

Flow Control

Congestion Control

을 Transport Layer에서 제공합니다.

UDP는:

Connectionless

Datagram

작은 Header

Broadcast

Multicast

같은 특성을 가지지만 손실·순서·중복 처리는 Application에 맡깁니다.

그래서 Protocol을 결정할 때는 다음과 같이 생각해야 합니다.

손실되면 안 되는가?
↓
순서가 중요한가?
↓
중복돼도 안전한가?
↓
늦은 데이터도 가치가 있는가?
↓
Message 단위가 필요한가?
↓
Broadcast / Multicast가 필요한가?
↓
Application이 Reliability를 구현할 것인가?
↓
보안은 어떻게 적용할 것인가?
↓
장비가 무엇을 지원하는가?

주차관제 시스템에 적용하면 더 명확합니다.

결제 Transaction
→ 신뢰성과 업무 중복 방지가 중요

차량번호 인식 결과
→ 손실 없이 Server에 남기는 것이 중요할 수 있음

Gate OPEN
→ 전달뿐 아니라 실제 완료 확인이 중요

Parking Sensor 상태
→ 최신 상태가 더 중요할 수 있음

실시간 Video
→ 지연과 손실의 균형이 중요

Device Discovery
→ Broadcast / Multicast가 필요할 수 있음

결국 TCP와 UDP를 선택하는 문제는 Network Protocol의 속도를 비교하는 문제가 아니라 업무 데이터의 의미를 정의하는 문제입니다.

그리고 가장 중요한 원칙은 이것입니다.

TCP를 선택했다고 업무 신뢰성이 자동으로 완성되는 것은 아니고, UDP를 선택했다고 신뢰성 있는 시스템을 만들 수 없는 것도 아닙니다.

Transport Layer가 어디까지 책임지고 Application이 어디서부터 책임질지를 명확하게 정하는 것이 좋은 Protocol 설계의 출발점입니다.

이 페이지의 목차