2015.08.20

기고 | XMPP, CoAP, MQTT··· IoT용 실시간 프로토콜 둘러보기

Kurt Collins | InfoWorld

사물인터넷(IoT, Internet of Things) 활용 사례를 개발하는데 있어 실시간 커뮤니케이션 기술는 필수적인 요소다. 스마트폰이 거실의 전등과 커뮤니케이션 하는 상황을 상상한다면 이해하기 쉬울 것이다. 우리는 당연히 스마트폰의 스크린을 탭하는 그 순간 전등이 켜질 것이라 기대하고 있다.

실시간 커뮤니케이션 테크놀로지 개발을 설명할 때 빠지지 않고 언급되는 주제가 인스턴트 메시지다. 지금까지의 인스턴트 메신저들은 누구나 쉽게 이용할 수 있는 인터넷 연결형 실시간 커뮤니케이션 클라이언트들이었다. AOL IM, ICQ, 재버(Jabber) 등이 1990년대 실시간 커뮤니케이션을 지원한 인스턴트 메신저 클라이언트의 좋은 예다.

요즘에는 IoT 기기들 간 커뮤니케이션을 위한 프로토콜 개발이 이목을 집중시키고 있다. 이를 위해 인스턴트 메시징 솔루션을 만들면서 배웠던 교훈들을 다시 살펴보기도 한다.

참고로 오늘날 IoT 기기들에 쓰이는 주요 실시간 프로토콜들은 XMPP, CoAP, MQTT의 3가지다. 특히 XMPP의 경우 오픈 인스턴트 메신저 프로토콜인 재버로 처음 시작된 것이기도 하다.

XMPP
XMPP(eXtensible Messaging and Presence Protocol)는 2인 이상의 참여자 간에 구조적 데이터를 거의 실시간에 가깝게 교환할 수 있게 해주는 XML 기반 TCP 커뮤니케이션 프로토콜이다.

XMPP의 기능들 중에는 대화 참여자 정보를 보여주는 것과 연락처 리스트 관리 기능이 있다. 두 기능 모두 인스턴트 메시징을 위해 제작된 것이었지만 IoT에도 적용할 수 있다.

XML 재단과 XMPP자체의 열려 있는 성질 때문에 XMPP는 퍼블리TL/섭스크라이브 (publish/subscribe) 시스템에도 사용되고 있다. XMPP가 IoT 애플리케이션과 찰떡 궁합인 또 하나의 이유다.

IoT 커뮤니케이션 프로토콜로 XMPP를 사용하는 것에는 여러 가지 큰 장점이 있다. 우선 XMPP의 분산화된 성격이 큰 장점이다. XMPP의 작동 방식은 이메일과 비슷하다. CoAP나 MQTT처럼 하나의 중앙 서버나 브로커에 의지하기보다는 여러 트랜스퍼 에이전트(transfer agents)에 걸쳐 작동하는 것이 특징이다.

이메일과 마찬가지로 누구나 자신의 XMPP 서버를 운영할 수 있어 기기 제조업체나 API 오퍼레이터가 자신만의 기기 네트워크를 형성하고 관리할 수 있다. 또한 누구나 서버를 운영할 수 있기 때문에 보안이 요구되는 경우 내장 TLS 암호화를 사용해 회사 인트라넷에서 안전한 인증 프로토콜을 이용해 고립시킬 수 있다.

물론 XMPP에는 단점도 있다. 가장 큰 단점은 바로 엔드-투-엔드 암호화가 안 된다는 것이다. 물론 암호화가 굳이 필요하지 않은 경우도 있지만, 대부분 IoT 기기들은 암호화를 필요로 한다. 엔드-투-엔드 암호화가 안 된다는 것은 IoT 기기에 있어서는 큰 단점이 아닐 수 없다.

또 다른 단점은 QoS(Quality of Service)의 부재다. 메시지가 제대로 전달 되었는지 확실히 하는 것은 인스턴트 메시지를 보낼 때도 중요하지만 IoT에서는 더더욱 중요하다. 예를 들어 아침에 깨워달라는 메시지가 알람 시스템에 제대로 전달되지 않는다면 고대하던 휴가를 망쳐버릴 수도 있다.

CoAP
CoAP(Constrained Application Protocol)는 리소스 제약이 있는 기기들이 인터넷 상에서 TCP 대신 UDP를 사용해 커뮤니케이션 할 수 있도록 개발됐다. 개발자들은 전통적인 방식의 REST 기반 API를 사용하는 여느 기기와 마찬가지로 CoAP 기기를 다룰 수 있다. CoAP는 특히 인터넷을 통해 컨트롤 해야 하는 저출력 센서 및 기기와 커뮤니케이션 하는데 유용하다.

CoAP는 단순한 리퀘스트/리스펀스 프로토콜로(REST와 매우 비슷하다) 전통적인 클라이언트/서버 모델을 따르고 있다. 클라이언트는 GET, PUT, POST, DELETE 요청을 할 수 있다. CoAP 패킷은 비트필드(bitfields)를 이용해 메모리 효율을 극대화 하고 데이터 패킷을 온-디바이스로 트랜스포트 할 수 있을 정도로 작게 유지하기 위해 스트링~인티저(strings to integers) 매핑을 광범위하게 사용한다.

매우 작은 패킷 사이즈 외에 CoAP의 또 다른 장점은 바로 UDP의 사용이다. 데이터 그램을 사용하기 때문에 SMS같은 패킷 기반 테크놀로지보다 성능이 뛰어나다.

모든 CoAP 메시지는 ‘확인 가능’ 또는 ‘확인 불가능’으로 표시될 수 있어 애플리케이션 레벨의 QoS로 행동할 수 있다. SSL/TLS 암호화가 UDP에서는 불가능 하지만 CoAP는 TLS의 TCP버전과 비슷한 DTLS(Datagram Transport Layer Security)를 사용한다.

디폴트 암호화 레벨은 3,072-비트 RSA 키와 동등하다. 그럼에도 불구하고 CoAP는 10KB 정도의 아주 작은 램이 장착된 마이크로 컨트롤러에서 작동하도록 설계됐다.

CoAP의 단점 중 하나는 원-투-원 프로토콜이라는 점이다. 그룹 브로드캐스트를 가능하게 한 확장을 이용할 수도 있지만 브로드캐스트 기능은 원-투-원 프로토콜에 내재적인 것이 아니다. 게다가 더 큰 단점은 퍼블리시-섭스크라이브 메시지 큐의 부재다.




2015.08.20

기고 | XMPP, CoAP, MQTT··· IoT용 실시간 프로토콜 둘러보기

Kurt Collins | InfoWorld

사물인터넷(IoT, Internet of Things) 활용 사례를 개발하는데 있어 실시간 커뮤니케이션 기술는 필수적인 요소다. 스마트폰이 거실의 전등과 커뮤니케이션 하는 상황을 상상한다면 이해하기 쉬울 것이다. 우리는 당연히 스마트폰의 스크린을 탭하는 그 순간 전등이 켜질 것이라 기대하고 있다.

실시간 커뮤니케이션 테크놀로지 개발을 설명할 때 빠지지 않고 언급되는 주제가 인스턴트 메시지다. 지금까지의 인스턴트 메신저들은 누구나 쉽게 이용할 수 있는 인터넷 연결형 실시간 커뮤니케이션 클라이언트들이었다. AOL IM, ICQ, 재버(Jabber) 등이 1990년대 실시간 커뮤니케이션을 지원한 인스턴트 메신저 클라이언트의 좋은 예다.

요즘에는 IoT 기기들 간 커뮤니케이션을 위한 프로토콜 개발이 이목을 집중시키고 있다. 이를 위해 인스턴트 메시징 솔루션을 만들면서 배웠던 교훈들을 다시 살펴보기도 한다.

참고로 오늘날 IoT 기기들에 쓰이는 주요 실시간 프로토콜들은 XMPP, CoAP, MQTT의 3가지다. 특히 XMPP의 경우 오픈 인스턴트 메신저 프로토콜인 재버로 처음 시작된 것이기도 하다.

XMPP
XMPP(eXtensible Messaging and Presence Protocol)는 2인 이상의 참여자 간에 구조적 데이터를 거의 실시간에 가깝게 교환할 수 있게 해주는 XML 기반 TCP 커뮤니케이션 프로토콜이다.

XMPP의 기능들 중에는 대화 참여자 정보를 보여주는 것과 연락처 리스트 관리 기능이 있다. 두 기능 모두 인스턴트 메시징을 위해 제작된 것이었지만 IoT에도 적용할 수 있다.

XML 재단과 XMPP자체의 열려 있는 성질 때문에 XMPP는 퍼블리TL/섭스크라이브 (publish/subscribe) 시스템에도 사용되고 있다. XMPP가 IoT 애플리케이션과 찰떡 궁합인 또 하나의 이유다.

IoT 커뮤니케이션 프로토콜로 XMPP를 사용하는 것에는 여러 가지 큰 장점이 있다. 우선 XMPP의 분산화된 성격이 큰 장점이다. XMPP의 작동 방식은 이메일과 비슷하다. CoAP나 MQTT처럼 하나의 중앙 서버나 브로커에 의지하기보다는 여러 트랜스퍼 에이전트(transfer agents)에 걸쳐 작동하는 것이 특징이다.

이메일과 마찬가지로 누구나 자신의 XMPP 서버를 운영할 수 있어 기기 제조업체나 API 오퍼레이터가 자신만의 기기 네트워크를 형성하고 관리할 수 있다. 또한 누구나 서버를 운영할 수 있기 때문에 보안이 요구되는 경우 내장 TLS 암호화를 사용해 회사 인트라넷에서 안전한 인증 프로토콜을 이용해 고립시킬 수 있다.

물론 XMPP에는 단점도 있다. 가장 큰 단점은 바로 엔드-투-엔드 암호화가 안 된다는 것이다. 물론 암호화가 굳이 필요하지 않은 경우도 있지만, 대부분 IoT 기기들은 암호화를 필요로 한다. 엔드-투-엔드 암호화가 안 된다는 것은 IoT 기기에 있어서는 큰 단점이 아닐 수 없다.

또 다른 단점은 QoS(Quality of Service)의 부재다. 메시지가 제대로 전달 되었는지 확실히 하는 것은 인스턴트 메시지를 보낼 때도 중요하지만 IoT에서는 더더욱 중요하다. 예를 들어 아침에 깨워달라는 메시지가 알람 시스템에 제대로 전달되지 않는다면 고대하던 휴가를 망쳐버릴 수도 있다.

CoAP
CoAP(Constrained Application Protocol)는 리소스 제약이 있는 기기들이 인터넷 상에서 TCP 대신 UDP를 사용해 커뮤니케이션 할 수 있도록 개발됐다. 개발자들은 전통적인 방식의 REST 기반 API를 사용하는 여느 기기와 마찬가지로 CoAP 기기를 다룰 수 있다. CoAP는 특히 인터넷을 통해 컨트롤 해야 하는 저출력 센서 및 기기와 커뮤니케이션 하는데 유용하다.

CoAP는 단순한 리퀘스트/리스펀스 프로토콜로(REST와 매우 비슷하다) 전통적인 클라이언트/서버 모델을 따르고 있다. 클라이언트는 GET, PUT, POST, DELETE 요청을 할 수 있다. CoAP 패킷은 비트필드(bitfields)를 이용해 메모리 효율을 극대화 하고 데이터 패킷을 온-디바이스로 트랜스포트 할 수 있을 정도로 작게 유지하기 위해 스트링~인티저(strings to integers) 매핑을 광범위하게 사용한다.

매우 작은 패킷 사이즈 외에 CoAP의 또 다른 장점은 바로 UDP의 사용이다. 데이터 그램을 사용하기 때문에 SMS같은 패킷 기반 테크놀로지보다 성능이 뛰어나다.

모든 CoAP 메시지는 ‘확인 가능’ 또는 ‘확인 불가능’으로 표시될 수 있어 애플리케이션 레벨의 QoS로 행동할 수 있다. SSL/TLS 암호화가 UDP에서는 불가능 하지만 CoAP는 TLS의 TCP버전과 비슷한 DTLS(Datagram Transport Layer Security)를 사용한다.

디폴트 암호화 레벨은 3,072-비트 RSA 키와 동등하다. 그럼에도 불구하고 CoAP는 10KB 정도의 아주 작은 램이 장착된 마이크로 컨트롤러에서 작동하도록 설계됐다.

CoAP의 단점 중 하나는 원-투-원 프로토콜이라는 점이다. 그룹 브로드캐스트를 가능하게 한 확장을 이용할 수도 있지만 브로드캐스트 기능은 원-투-원 프로토콜에 내재적인 것이 아니다. 게다가 더 큰 단점은 퍼블리시-섭스크라이브 메시지 큐의 부재다.


X