웹 소켓? 많은 웹 사이트에서는 폴링을 사용하여 푸시 기술을 구현합니다. 폴링은 브라우저가 서버에 HTTP 요청을 보낸 다음 서버가 브라우저에 최신 데이터를 반환하는 특정 간격 (예: 1 초) 입니다. 투표의 단점은 분명하다. 브라우저는 지속적으로 서버에 요청을 보내야 합니다. 그러나 HTTP 요청의 헤더는 길고 실제로 전송되는 데이터는 작을 수 있어 대역폭과 서버 자원 낭비를 초래할 수 있습니다.
Comet 은 AJAX 를 사용하여 폴링을 개선하여 양방향 통신을 가능하게 합니다. 그러나 Comet 은 여전히 요청을 보내야 하며, Comet 에서는 긴 링크가 널리 사용되고 있으며 많은 서버 대역폭과 자원을 소모합니다.
따라서 웹 소켓 프로토콜이 등장했습니다. 브라우저는 자바스크립트를 통해 웹 소켓 연결 설정 요청을 서버에 보냅니다. 연결이 설정되면 클라이언트와 서버는 TCP 연결을 통해 직접 데이터를 교환합니다. 웹 소켓 연결은 기본적으로 TCP 연결입니다.
웹 소켓은 데이터 전송의 안정성과 데이터 전송의 크기에서 큰 성능 우위를 가지고 있습니다. Websocket.org 는 폴링과 웹 소켓의 성능 이점을 비교합니다.
HTTP 교체 교육은 매번 87 1 바이트를 반환해야 하며 웹 소켓은 한 번에 2 바이트만 필요합니다.
용례 A: 1000 개 클라이언트가 초당 한 개의 메시지를 받아들이고, 네트워크 처리량 (2 * 1000)= 2000 바이트 = 16000 비트 초당.
용례 B: 10000 개 클라이언트가 초당 한 개의 메시지를 받아들이고, 네트워크 처리량 (2 * 10000)= 20000 바이트 = 160000 비트 초당.
사용 사례 C: 100000 개 클라이언트가 초당 메시지를 수신합니다. 네트워크 처리량 (2 * 100000)= 200000 바이트 = 1, 600000 비트
MQTT 프로토콜은 컴퓨팅 기능이 제한적이고 대역폭이 낮고 신뢰할 수 없는 네트워크에서 작동하는 수많은 원격 센서와 제어 장치 간의 통신을 위해 설계되었습니다. 다음과 같은 주요 기능이 있습니다.
통신 오버헤드는 매우 작고 (최소 메시지 크기는 2 바이트), 처리량은 작고, 오버헤드는 매우 작으며 (고정 길이 헤더는 2 바이트), 프로토콜 교환은 최소화되고 네트워크 트래픽은 줄어듭니다.
C, Java, Ruby, Python 등 널리 사용되는 프로그래밍 언어를 지원하는 사용하기 쉬운 클라이언트 );
게시/가입 메시지 모드를 사용하여 일대다 메시지 게시 및 분리 응용 프로그램을 제공합니다.
페이로드 내용을 차단하는 메시지 전송.
TCP/IP 를 사용하여 네트워크 연결을 제공합니다.
메시지 게시에는 불안정한 네트워크의 전송 요구 사항을 충족하기 위해 필요에 따라 메시지를 대상에 도달할 수 있는 세 가지 서비스 품질이 있습니다.
"최대 한 번", 메시지 게시는 기본 TCP/IP 네트워크에 전적으로 의존합니다. 메시지가 손실되거나 중복될 수 있습니다. 이 레벨은 다음과 같은 경우에 사용할 수 있습니다. 환경 센서 데이터가 한 번 손실되어도 상관없다. 곧 두 번째 전송이 있을 것이기 때문이다.
메시지가 도착하도록 "한 번 이상" 을 선택합니다. 그러나 메시지가 중복될 수 있습니다.
"한 번만", 메시지가 한 번 도착했는지 확인합니다. 중복되거나 누락된 메시지가 청구 시스템에서 잘못된 결과를 초래할 때 이 레벨을 사용할 수 있습니다.