IoT 네트워킹 (1) - IoT 프로토콜 - soo:bak
작성일 :
제약된 환경에서 어떻게 통신하는가
스마트홈, 산업 센서, 웨어러블 기기.
IoT(Internet of Things) 디바이스는 일반 컴퓨터와 다른 환경에서 동작합니다.
IoT 네트워킹의 특성
제한된 자원
IoT 디바이스는 자원이 제한되어 있습니다.
1
2
3
4
5
6
일반 서버 IoT 디바이스
─────────────────────────────────────────
CPU: GHz급 CPU: MHz급
RAM: GB급 RAM: KB~MB급
전력: 무제한 전력: 배터리 (수년)
연결: 상시 연결: 간헐적
HTTP 요청 헤더만 수백 바이트, TCP 핸드셰이크에도 여러 패킷이 필요합니다. 이는 수 KB 메모리의 센서에는 과도한 오버헤드입니다.
대규모 디바이스
수천, 수만 개의 디바이스가 연결됩니다.
1
2
3
4
5
6
7
8
9
10
11
스마트 공장:
┌─────────────────────────────────────────────────────┐
│ │
│ 센서1 ─┐ │
│ 센서2 ─┤ │
│ 센서3 ─┼─────► 게이트웨이 ─────► 클라우드 │
│ ... │ │
│ 센서N ─┘ │
│ │
│ N = 수천~수만 │
└─────────────────────────────────────────────────────┘
각 디바이스가 개별 연결을 유지하면 서버 부하가 큽니다.
간헐적 연결
디바이스가 항상 온라인이 아닙니다.
- 배터리 절약을 위한 슬립 모드
- 불안정한 무선 환경
- 이동하는 디바이스
프로토콜은 이런 상황을 처리할 수 있어야 합니다.
MQTT (Message Queuing Telemetry Transport)
MQTT의 탄생
1999년, IBM의 Andy Stanford-Clark과 Arlen Nipper가 개발했습니다.
목적: 석유 파이프라인 모니터링
위성 링크로 연결된 원격 센서.
대역폭이 비싸고 연결이 불안정한 환경이었기에 최소한의 오버헤드로 메시지를 전달해야 했습니다.
Publish/Subscribe 모델
MQTT는 Pub/Sub 패턴을 사용합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
┌──────────────────────────────────────────────────────────────┐
│ MQTT 브로커 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 토픽: sensors/temperature │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
▲ │
│ PUBLISH │ 전달
│ (25°C) ▼
┌───────────────┐ ┌───────────────┐
│ 센서 │ │ 구독자 │
│ (Publisher) │ │ (Subscriber) │
└───────────────┘ └───────────────┘
- Publisher: 토픽에 메시지 발행
- Subscriber: 토픽 구독
- Broker: 메시지 라우팅
Publisher와 Subscriber가 서로의 존재를 알 필요 없이 브로커만 바라보면 됩니다. 이러한 느슨한 결합(loose coupling)은 디바이스 추가와 제거를 자유롭게 하고, 시스템 확장성을 높여줍니다.
토픽 구조
토픽은 계층적 구조입니다.
1
2
3
4
5
6
7
8
home/livingroom/temperature
home/livingroom/humidity
home/bedroom/temperature
home/bedroom/light
와일드카드:
+ : 한 레벨 (home/+/temperature → livingroom, bedroom 모두)
# : 모든 하위 레벨 (home/# → home 아래 모든 토픽)
QoS 레벨
MQTT는 세 가지 서비스 품질 레벨을 제공합니다.
QoS 0: At most once
1
2
3
4
5
6
Publisher ─── PUBLISH ───► Broker
"보내고 잊기"
- 확인 없음
- 손실 가능
- 가장 빠름
센서 데이터처럼 약간의 손실이 허용되는 경우.
QoS 1: At least once
1
2
3
4
Publisher ─── PUBLISH ───► Broker
◄── PUBACK ─────
재전송 가능 → 중복 가능
메시지가 반드시 전달되어야 하지만 중복이 허용되는 경우.
QoS 2: Exactly once
1
2
3
4
5
6
Publisher ─── PUBLISH ───► Broker
◄── PUBREC ─────
─── PUBREL ───►
◄── PUBCOMP ────
4단계 핸드셰이크 → 정확히 한 번
금융 거래처럼 중복이 허용되지 않는 경우.
다만 4단계 핸드셰이크가 필요하여 오버헤드가 가장 큽니다.
영속 세션 (Persistent Session)
클라이언트가 오프라인일 때도 메시지를 보존합니다.
1
2
3
4
5
1. 클라이언트 A 연결 (cleanSession=false)
2. 토픽 구독
3. 클라이언트 A 오프라인
4. 메시지 발행됨 → 브로커가 보관
5. 클라이언트 A 재연결 → 보관된 메시지 수신
이 기능 덕분에 간헐적으로 연결되는 IoT 환경에서도 메시지 유실 없이 통신할 수 있습니다.
Last Will and Testament (LWT)
클라이언트가 비정상 종료될 때 유언 메시지를 발행합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
연결 시:
"내가 끊어지면 이 메시지를 발행해주세요"
┌───────────────┐
│ 센서 │
│ (연결 시) │ ─── Will: "sensors/status" = "offline"
└───────────────┘
│
X (비정상 종료)
│
▼
┌───────────────┐
│ 브로커 │ ─── PUBLISH "sensors/status" = "offline"
└───────────────┘
이를 통해 다른 시스템이 디바이스의 온라인/오프라인 상태를 실시간으로 파악할 수 있습니다.
MQTT 헤더 크기
1
2
3
4
5
6
7
8
MQTT 고정 헤더: 최소 2바이트
┌─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Type(4) │ DUP(1) │ QoS(2) │ Retain │ Remaining Length (1-4 bytes) │
└─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘
HTTP 헤더: 수백 바이트
MQTT 헤더: 2+ 바이트
이처럼 작은 오버헤드야말로 MQTT가 IoT 환경의 표준 프로토콜로 자리 잡은 핵심 이유입니다.
CoAP (Constrained Application Protocol)
RESTful for IoT
CoAP는 HTTP를 IoT에 맞게 경량화한 프로토콜입니다.
RFC 7252로 표준화되었습니다.
1
2
3
4
5
HTTP CoAP
─────────────────────────────────────
TCP 기반 UDP 기반
텍스트 헤더 바이너리 헤더
수백 바이트 헤더 4바이트 고정 헤더
CoAP 메시지 구조
1
2
3
4
5
6
7
8
9
10
11
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HTTP의 수백 바이트 헤더와 달리 단 4바이트의 고정 헤더만으로 통신합니다.
HTTP와의 대응
1
2
3
4
5
6
7
8
9
HTTP CoAP
─────────────────────────────────────
GET GET
POST POST
PUT PUT
DELETE DELETE
200 OK 2.05 Content
404 Not Found 4.04 Not Found
HTTP와 1:1 매핑이 가능하여 프록시를 통해 HTTP 서버와 자연스럽게 연동할 수 있습니다.
메시지 타입
1
2
3
4
5
6
7
8
9
10
CON (Confirmable):
클라이언트 ─── CON GET /temp ───► 서버
◄── ACK 2.05 Content ───
NON (Non-confirmable):
클라이언트 ─── NON GET /temp ───► 서버
(응답 없을 수 있음)
RST (Reset):
예상치 못한 메시지에 대한 응답
Observe 패턴
Observe는 리소스 변화를 감시합니다.
1
2
3
4
5
6
7
8
9
클라이언트 ─── GET /temp (Observe) ───► 서버
◄── 2.05 Content (25°C) ─────
│
│ (값 변경 시)
▼
◄── 2.05 Content (26°C) ─────
◄── 2.05 Content (27°C) ─────
HTTP 폴링 대신 푸시 방식
주기적인 폴링 없이도 리소스 변화를 즉시 감지할 수 있어 트래픽과 전력 소모를 크게 줄입니다.
블록 전송 (Block Transfer)
큰 데이터를 작은 블록으로 나눕니다.
1
2
3
4
5
큰 리소스 (10KB):
GET /firmware → Block1: 0-1023
→ Block2: 1024-2047
→ ...
→ Block10: 9216-10239
이 방식으로 UDP의 패킷 크기 제한을 극복하고 펌웨어 업데이트 같은 대용량 전송도 처리할 수 있습니다.
MQTT vs CoAP
아키텍처 차이
1
2
3
4
5
6
MQTT: CoAP:
┌─────────────────────┐ ┌─────────────────────┐
│ 클라이언트-브로커 │ │ 클라이언트-서버 │
│ Pub/Sub │ │ Request/Response │
│ 중앙 집중 │ │ 분산 │
└─────────────────────┘ └─────────────────────┘
특성 비교
| 항목 | MQTT | CoAP |
|---|---|---|
| 전송 | TCP | UDP |
| 패턴 | Pub/Sub | Request/Response |
| 헤더 | 2+ 바이트 | 4 바이트 |
| 신뢰성 | QoS 0/1/2 | CON/NON |
| 보안 | TLS | DTLS |
| 멀티캐스트 | 불가 | 가능 |
선택 기준
MQTT 선택:
- 많은 수신자에게 메시지 브로드캐스트
- 브로커 인프라가 있음
- 안정적인 TCP 연결 가능
- 이벤트 기반 시스템
CoAP 선택:
- RESTful 인터페이스 필요
- HTTP 프록시 연동
- 멀티캐스트 필요
- 매우 제한된 디바이스
저전력 무선
BLE (Bluetooth Low Energy)
BLE는 Bluetooth 4.0에서 도입되었습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
클래식 Bluetooth BLE
─────────────────────────────────────
연속 연결 간헐적 연결
mA급 전류 μA급 전류
음성, 스트리밍 센서, 비콘
BLE 토폴로지:
┌─────────────┐
│ Central │ (스마트폰)
└──────┬──────┘
│
┌───┴───┐
│ │
┌──▼──┐ ┌──▼──┐
│Peri.│ │Peri.│ (센서, 비콘)
└─────┘ └─────┘
스마트워치, 피트니스 트래커, 비콘 등에 널리 사용되고 있습니다.
GATT (Generic Attribute Profile)
BLE의 데이터 교환 방식입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
GATT 구조:
┌─────────────────────────────────────────────┐
│ Profile │
├─────────────────────────────────────────────┤
│ Service: Heart Rate │
│ ├── Characteristic: Heart Rate Measurement │
│ │ └── Value: 72 bpm │
│ └── Characteristic: Body Sensor Location │
│ └── Value: Chest │
├─────────────────────────────────────────────┤
│ Service: Battery │
│ └── Characteristic: Battery Level │
│ └── Value: 85% │
└─────────────────────────────────────────────┘
Zigbee
Zigbee는 IEEE 802.15.4 위에서 동작합니다.
1
2
3
4
5
6
7
8
9
10
11
Zigbee 네트워크 토폴로지:
Star: Mesh:
┌─C─┐ D─────D─────D
│ │ │ │ │
D D D─────C─────D
│ │ │ │ │
D D D─────D─────D
C: Coordinator
D: Device (Router 또는 End Device)
특성:
- 2.4GHz 주파수
- 메시 네트워킹
- 자가 복구 (self-healing)
- 홈 오토메이션에 널리 사용
Thread
Thread는 IP 기반의 저전력 메시 네트워크입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Thread 특징:
- IPv6 네이티브
- 6LoWPAN (IPv6 over 802.15.4)
- 메시 네트워킹
- 인터넷 직접 연결 가능
┌─────────────────────────────────────────────────────┐
│ Thread 네트워크 │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Router │──────│ Router │──────│ Router │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ ┌────▼────┐ ┌────▼────┐ ┌────▼────┐ │
│ │End Dev. │ │End Dev. │ │End Dev. │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
└───────────────────────┬─────────────────────────────┘
│
┌────▼────┐
│ Border │ ──── IPv6 인터넷
│ Router │
└─────────┘
Matter(스마트홈 표준)의 기반 프로토콜입니다.
정리: 제약이 혁신을 낳는다
IoT 프로토콜의 핵심:
| 프로토콜 | 특징 | 사용 사례 |
|---|---|---|
| MQTT | Pub/Sub, QoS | 대규모 센서 네트워크 |
| CoAP | RESTful, UDP | 제한된 디바이스 |
| BLE | 저전력, 근거리 | 웨어러블, 비콘 |
| Zigbee | 메시, 자가복구 | 홈 오토메이션 |
| Thread | IPv6, 메시 | Matter 스마트홈 |
제한된 환경이 오히려 혁신적인 경량 프로토콜을 탄생시켰고, 이 프로토콜들이 현재 수십억 개의 디바이스를 연결하고 있습니다.
Part 2에서는 LPWAN과 IoT 보안을 살펴봅니다.
관련 글