MQTT 이해하기

PUSH서버 연동이 필요한 프로젝트를 진행중이라 관련 정보를 정리해 보았습니다.

MQTT(Message Queuing Telemetry Transport) 란 텔레메트리 장치, 모바일 기기에 최적화된 라이트 메시징 프로토콜 입니다.
더 다양한 앱과 서비스의 등장으로 HTTP등의 기존 프로토콜만으로는 커뮤니케이션의 다양한 요구사항을 수용 할 수 없게 되었고, 제한된 통신 환경을 고려하여 디자인된 MQTT 프로토콜은 모바일 영역의 진화에 따라 최적의 프로토콜로 주목 받고 있습니다.

MQTT (MQ Telemetry Transport) 이해하기
MQTT (MQ Telemetry Transport) 이해하기
[MQTT 프로토콜 설계의 의도]
  • 프로토콜이 차지하는 모든 면의 리소스 점유(footprint)를 최소화
  • 느리고 품질이 낮은 네트워크의 장애와 단절에 대비
  • 클라이언트 애플리케이션 동작에 자원 활용이 극히 제한적임을 고려
  • 다수의 클라이언트 연결에 접합한 Publish/Subscribe 네트워크 채용
  • 신뢰성 있는 메시징을 위한 QoS(Quality of Service) 옵션 제공.
  • 개방형 표준 메시징 프로토콜을 지향 –  제 3자(3rd Party) 기기 제조업체와 소프트웨어 개발업체의
    용이한 도입, 적용을 유도
[주요 특징]
  • IBM과 Eurotech(Arcom)에 의해 1999년 최초 개발
  • 센서/장치 + 모바일 기기들의 연결을 위한 프로토콜
  • MQTT 프로토콜 오픈소스로 공개 (http://www.mqtt.org)
  • 단순하고 미니멀한 Pub/Sub 메시징 체제
    • 기업 경계 박의 Edge 네트워크 장치와 기업 내의 백엔드 애플리케이션 간 메시지 교환에 접합
    • 간편한 메시징을 위한 직관적 verb set(connect/disconnect publish/subscribe) 제공
  • 오버헤드를 최소화
    • 가장 작은 메시지 사이즈는 2byte: 가변길이 MQTT헤더 + 애플리케이션 Payload
    • Payload 데이터에 중립적: 별도의 다른 애플리케이션 헤더 불필요
    • 클라이언트 라이브러리: C버전은 30KB, Java 버전은 100KB 내외
  • Pub/Sub에 있어서 메시징 신뢰성을 위한 세가지 QoS(Quality of Service) 레벨 제공

    • 반드시 전달되어야하는 중요 메시지에 대한 전달 보장
    • QoS 0 : 한 번만 전달하고 전송 여부는 확인하지 않음.
    • QoS 1 : 적어도 한 번 이상 전송하고 전송 여부 확인. (전송 여부 확인 패킷이 유실되면 중복 메시지 발생 가능)
    • QoS 2 : 메시지 전송 핸드셰이킹을 통해 정확히 한 번만 전달. (신뢰할 수 있지만 성능 저하 발생)
  • 클라이언트와 서버간의 연결을 잃었을때 이를 보정하기 위한 자체 기능
    Last will and testament: 클라이언트가 예고 없이 연결을 잃을 경우 이벤트가 서버에서 발생,
  • 서버 측에서 연결의 유실 여부 인지
    Durable subscription: 서버에 클라이언트의 구독(subscription)정보 저장됨,
  • 세션 종료 후 재접속 시에도 재작업 없이 Pub/Sub유지
    Clean session 기능: 연결 해제 후 다시 연결되었을 때의 이전 세션 유지/삭제 선택
[이외 특징]
  • FB 메신져가 이걸 사용. 국내 통신사 PUSH 서버도 이걸 사용함.
  • 일단 FB가 쓰니, 동남아권 Telco에서 패킷 걸리는 문제는 없을듯
  • Qos 0,1,2로 해서, 2 의 경우 message delivery를 gurantee함
  • 저전력!! 모바일 환경에 이게 중요함.
  • XMPP에 비해서 훨씬 경량. (XMPP는 XML, MQTT는 byte로 보내는데, 2바이트부터 시작)
  • MQTT 서버를 라즈베리와 같은 임베디드 서버에도 넣을 수 있음. IOT용!! 즉 Things가 서버가 될 수 있다!!
  • 대부분 사용자 인증만 제공 (user id/password 방식) 이것도 대부분 서버들이 파일에 저장한다.
    (IDM이나 KEY 시스템과 연계 필요)
  • TLS/SSL은 지원. X.509 인증서를 이용한 양방향 인증도 지원
[MQTT over WebSocket]

Websocket은 TCP socket과 많이 닮았지만, 차이점도 있다.
그 차이점은 브라우저에서 서버로 양방향 커뮤니케이션 연결을 시도 한다는 점이다.
웹소켓이 위치하면서 웹브라우저에서 웹 어플리케이션을 위한 first class MQTT 지원이 가능해졌습니다.
여기엔 몇가지 옵션이 있습니다.

  1. IBM의 MQ 7.5가 Websocket을 지원하게 되었다.
  2. Mosquitto broker는 예제를 포함한 Javascript client를 가진다.
  3. HiveMQ MQTT broker는 네이티브 웹소켓 지원을 한다.
[원문]
[참고]

이메일 템플릿 만들기

본 가이드는 이메일 템플릿을 쉽게 제작 할 수  있는 서비스를 소개하고 유의 할 점들을 공유 합니다.
 
[이메일 템플릿 만들기를 도와주는 무료 서비스]
[작업시 유의사항]
  1. HTML작업시 Table 마크업! (기존 레이아웃 잡는 Block 요소 인식 못하는 이메일 클라이언트 서비스 때문)
  2. 스타일 시트를 별도 파일로 구성하면 인식 못하는 메일 서비스도 있기때문에 페이지내 포함하거나, Inline으로 작성한다.
  3. 작업후 서비스별 이메일 클라리언트의 랜덩링이 다르기 때문에 테스트 가능한 메일 서비스는 모두 테스트 한다.
  4. 메일별 결과 체크 리스트를 만들어서 브라우저별 서비스별 테스트 진행해야 한다.
[국내 필수 테스트 메일]
  • 다음, 네이버, 네이트, 구글, 아웃룩
[참고]

Mobile Safari 에서 Label 클릭이 안되는경우 해결방법.

https://bugreport.apple.com 에 리포팅된 버그이며, IOS 또는 iPhone4의 Safari버전에서 흔히 나타난다고 한다.
모바일에서 Label DOM 요소 클릭이 안될땐 빈 함수를 실행해주면 신기하게도 동작한다.

$('label').click(function() {});

최신버전의 Safari에서는 문제 없다.

[관련글]
http://stackoverflow.com/questions/7358781/tapping-on-label-in-mobile-safari

CORS 설정해도 IE에서 크로스 도메인간 요청 불가 원인.

[CORS 설정에도 IE9 요청 불가 콘솔 로그.]

JSONP를 사용하지 않아도 크로스 도메인간 데이터 송 수신을 가능하게 해주는 스펙이 CORS입니다.
하지만 CORS (Cross-Origin Resource Sharing) 는 XHR Level2에서 지원하는 스펙이기 때문에,
최신 파폭, 크롬, IE 10이상은 문제 없이 지원하지만, IE하위 버전에선 동작하지 않습니다.
제한적으로 IE에만 있는 XDomainRequest을 사용하는 방법을 소개하는 글도 있지만,
이 또한 IE 8, 9에만 제한되며, 그 이하 버전도 만족하려면 JSONP를 요청 응답을 사용해야 합니다.

관련글은 아래와 같습니다.

Summary of XHR2 CORS (or rather lack of) in Internet Explorer

  • IE 6, 7, 8, and 9 do not support XHR2 CORS. It is not possible to make generalized cross-domain requests in these browsers.
  • IE 8, 9 support an ActiveX control called XDomainRequest that only allows limited cross-domain requests compared to XHR2 CORS.
  • IE 10 supports XHR2 CORS.

[관련링크]
– https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/365