웹 MQTT 협정에 대한 검색, 표준의 공식 해석을 복제하지 않습니다 여기에 설명하기 너무 많이있을 것입니다. 우리가 실제 전투의 관점에서 이해이 섹션에서는 인기 MQTT 계약과 원칙의 구현의 역할은 무엇인가, 당신은 신속하게 이해할 수있는 말은 MQTT 계약을 목표로하고있다. 이 글을 무시하세요, 매우 능숙 MQTT의 MQTT의 의미를 이해하기 쉽게 보이는 표준 설명을 많이 할 수 있지만.
상황이 프로젝트 요구 사항의 인터넷은 종종 "제한된 환경"입니다. 그 의미를 무엇을, 인기 속담 네트워크가 불안정한 대역폭이 작은 일 수있다이다, 속도도 상대적으로 낮다,이 경우 매우 낮은 하드웨어 MCU의 성능 요구 사항이 안정적으로 정보를 전송하는 네트워크로 할 수 있습니다. 그렇지 않으면 쓸모가 없다, 여기에서 우리는 앞서 언급 짧은 명령 문제가 오면 보여야하는데, 그리고 우리는 개발자가 쉽게 우리가 먼저 작업 환경의 요구 사항을 충족해야 좋은 유지할 수 있습니다 생각하는지, 프로젝트는 성공적으로 착륙 할 수있다 .
전 첫 번째 N 년 동안 일을 프로젝트를 수행하려고하는, 하드웨어 제어를 사용하여 HTTP 프로토콜 하드웨어 장치 정보를보고 할 많은 (사실, 어떤 사람들은 여전히 사용) 프로젝트 구현의 결과를 반환합니다. 이러한 하드웨어 정보는 즉각적으로 문제를보고 있지만, 시간을 통해 서버 하드웨어를 제어하는 제어 명령을 전송, 적시성, 그것을 충족하기 어렵다. HTTP 서버가 적극적으로 하나의 방향을 요구하기 때문에, 분리 복귀 후에 만 반환하는 요청이있다. 서버 및 하드웨어 장치를 다시 연결되어, 우리는 즉, 서버는 하드웨어 장치에 메시지를 밀어 주도권을받을 수 없어, 다음 HTTP 요청을 통해 하드웨어까지 기다릴 수 있습니다. 이 네트워크 환경에 적합하지 않았다, 많은 사람들이 N 기반의 HTTP 서버 푸시 솔루션의 다양한 말을 할 수있다 여기에서 볼 수 있지만, 미안 해요. 프로젝트의 롱 폴링 또는 네트워크 리소스와 연결하고 유지 보수 모두 하드웨어 성능 HTTP 소비 요구 사항이 고가이기 때문에, 우리는에 계정으로 프로젝트 지상의 요구 사항을해야한다 "제한된 환경을 제공합니다." 저 대역폭 네트워크 불안정성 (예 : 모바일 네트워크, 신호가 약한 지역 등) 환경에서, 대부분 프로젝트가 실패함으로써, 허용 할 수없는 결과를 초래하다.
왜 MQTT 계약을하는 것이 좋습니다? MQTT 프로토콜은 다음과 같은 기능을 포함하기 때문에 :
1, 작은 네트워크 부하를 최소 크게 HTTP 트래픽에 비해 네트워크를 감소 단지 2 바이트 헤더이다.
2 세션을 들고, 적시 푸시 메시지 서버에 대한 조건을 제공했다.
도 3은,이 공간을 차단하지 않고, 비동기 메시지 메커니즘이다.
4, 예외 인터럽트 알림 메커니즘과 함께, 당신은 정보를 온라인 하드웨어 변경을 얻을 수있는, 적절한 메시지가 떨어졌다.
5, 게시 / 구독 메시징 모델 또는를 사용하여 다 대다 메시징, 구현 및 디커플링의 응용 프로그램입니다.
6, 송신 신뢰도, 제어, 및 서비스 품질 세 번만, 적어도 한 번, 최대 한 번이다. 그것은받은 경우 발행 정보, 대행 서비스 가입자 발행인을 의미합니다.
7, 클라이언트 프로그램이 가볍고, 많은 임베디드 기기에서 실행할 수 있습니다.
8, 낮은 대역폭, 높은 대기 시간, 불안정한 네트워크 환경을 만날 수 있습니다.
MQTT 협정, 각각 두 끝, 및 클라이언트 서비스는 3 개 개의 정체성, 즉 게시자 (게시), 에이전트 (브로커), 가입자 (가입)이있다.
서비스가 세 프록시 신원 정체성의 하나 인 프록시 서비스를 실행해야하므로 MQTT 협정에서 클라이언트는 클라이언트 엔드 - 투 - 메시지를 보내고, 서버 관리를 통해 할당해야합니다 직접 구현 될 수 없습니다. 게시자라는 메시지를 보낸 사람은 메시지의 수신자는 가입자를 호출 할 필요가있다. 에이전트에 메시지를 보내 게시, (이 가입하는 것입니다) 메시지를 수신 할 필요가있는 모든 점검을 담당하는 에이전트는, 그것은에 전달 될 필요가있다. MQTT 계약 메시지 라벨에 추가되는 표준 테마를 개발할 수 있도록하기 때문에, 서로 다른 메시지를 식별합니다. 포스트 소유자는 항상이 라벨 테마 (주제)를 호출 할 사람을 결정하기 위해 전달하기 위해이 라벨에 가입 한 에이전트에 따라 라벨을 가지고 전송, 라벨은 우리가 전화 부하의 내용을 전송하는 데 필요한 정보를 (전달 페이로드).
클라이언트와 서버가 처음으로 연결되었을 때 중단 알림 메커니즘을 달성하기 위해, 그래서, 그것은 상대적으로 특정 테마를 수행하는 것이 필요하다, 주제는 그들이 떨어 뜨리면, 파티가있는 정보의 일부를 떨어 것을 알 필요가 알려드립니다이다 유언장 메시지 (의지 메시지). 온라인 자신의 주제는, 그가 특정 시간 (하트 비트 간격이 살아 타이머를 유지 예) 떨어졌다 때, 아무것도하지 않는 에이전트를 전달,이 주제에 가입 확인합니다 에이전트, 그것은, (물론, 사람들이 구독 할 수 있습니다) 사람에게 전달됩니다 이것은 (감소) 통지를 취소 할 수 있습니다.
철저 어떻게 작업 공정 MQTT 계약을 이해하기 위해 계속 다음.
출판사, 가입자, 에이전트 및 주제 구독 출판 관계 :
그래프에 의해, 우리는 같은 클라이언트가 모두 게시자 될 수 있음을 볼 수있다, 또한 가입자가 될 수 있습니다. 테마는 하나의 발행인이다, 그러나 당신은 가입자를 많이 가질 수 있습니다. 클라이언트는 여러 주제에 가입 할 수 있습니다.
클라이언트는 프록시에 연결 :
첫 번째 단계는 연결을 설정하는 것입니다, MQTT 계약 TCP / IP 기반의 통신 프로토콜을 설정하는 것입니다, 먼저 클라이언트와 프록시 서버 간의 TCP 연결을 설정해야합니다. 에 액세스 할 수 있도록 클라이언트들을 때 연결을 설정하는 프로세스가 클라이언트 이니셔티브에 의해 시작되어, 프록시 서비스를 즉시 처리 할 것, 청취 상태 지정된 포트에왔다. 클라이언트가 연결 요청을 시작하면, 클라이언트가 (공식 프로그램이 허용하지 않습니다를 어떤 계정 암호 제외) 클라이언트 ID, 우리의 계좌 번호, 비밀번호를 전달, 같은 하트 비트와 같은 데이터. 계정 암호가 세션 식별자를 구축 할 수 있다면, 연결 한 다음 저장, 세션에 클라이언트 ID를 결합하고, (하트 비트 간격을 기록 시작할 수 있도록하고 떨어 여부를 결정 여부를 자신의 연결 구성을 확인하기 위해 허가를받은 후 대행 서비스 당신이 건너 가입하지 않은 경우) 메시지 및 성공적 클라이언트 연결 확인 메시지를 다시 보내드립니다, 클라이언트가 성공적으로 연결 한 후 확인 메시지를 수신하고, 다음 단계 (보통 시작은), 주제에 가입. 그림 성공적인 연결의 개략도는 연결에 실패하고, 다시 디자인에 대한보다 구체적인 될 것입니다 수있는 뇌 보충을 거부했다.
客户端订阅主题：
客户端将需要订阅的主题经过SUBSCRIBE报文发送给代理服务，代理服务则将这个主题记录到该客户端ID下（以后有这个主题发布就会发送给该客户端），然后回复确认消息SUBACK报文，客户端接到SUBACK报文后知道已经订阅成功，则处于等待监听代理服务推送的消息，也可以继续订阅其他主题或发布主题。
客户端发布主题：
当某一客户端发布一个主题到代理服务后，代理服务先回复该客户端收到主题的确认消息，该客户端收到确认后就可以继续自己的逻辑了。但这时主题消息还没有发给订阅了这个主题的客户端，代理要根据质量级别（QoS）来决定怎样处理这个主题。所以这里充分体现了是MQTT协议是异步通信模式，不是立即端到端反应的。
如果发布和订阅时的质量级别QoS都是至多一次，那代理服务则检查当前订阅这个主题的客户端是否在线，在线则转发一次，收到与否不再做任何处理。这种质量对系统压力最小。
如果发布和订阅时的质量级别QoS都是至少一次，那要保证代理服务和订阅的客户端都有成功收到才可以，否则会尝试补充发送（具体机制后面讨论）。这也可能会出现同一主题多次重复发送的情况。这种质量对系统压力较大。
如果发布和订阅时的质量级别QoS都是只有一次，那要保证代理服务和订阅的客户端都有成功收到，并只收到一次不会重复发送（具体机制后面讨论）。这种质量对系统压力最大。
代理最终将主题消息转发给订阅者，至少是做了转发操作，成功与否决定质量等级。更详细的消息质量等级控制后面会有专门详细叙述。
关于MQTT协议的实现原理通俗解释就到这里，希望能让刚刚接触MQTT的开发者有个整体流程的印象和理解，后面会详细讨论MQTT协议的定义、配置等。
本节完，待续......