Mosquitto의 웹 소켓을 사용하거나 클라이언트를 직접 연결해야합니까?


11

이 블로그 에 따르면 , Mosquitto (MQTT 브로커)는 이제 웹 소켓을 통한 클라이언트 연결을 지원합니다. 웹 소켓 프로토콜 최신 브라우저의 대부분에서 지원 되지만 웹 브라우저는 적절한 TCP 소켓 (아직)을 지원하지 않기 때문에 블로그 기사는 웹 소켓이 브라우저 응용 프로그램에 더 유용하다는 것을 암시하는 것 같습니다 .

네트워크에 다양한 클라이언트가있는 경우 (예 : Raspberry Pis와 같은 마이크로 컨트롤러 기반 센서 및 액추에이터) 직접 TCP 연결보다 웹 소켓을 사용하면 어떤 이점이 있습니까? 웹 소켓 프로토콜의 오버 헤드는 브라우저와 통신 할 때만 가치가 있습니까?


1
모든 네트워크를 코딩하고 있는지 알려주시겠습니까? 즉 모든 노드 또는 클라이언트와 서버 모두? 아니면 다른 사람의 소프트웨어와 상호 작용해야합니까? 당신은 단지 클라이언트를 코딩 할 수있는 것처럼 소리,하지만 난 확신 할 수 없다
Mawg는 분석 재개 모니카 말한다

1
@Mawg 서버는 Mosquitto MQTT 브로커가되지만 모든 클라이언트에 사용할 프로토콜을 선택할 수 있습니다 (그리고 Mosquitto는 웹 소켓과 직접 TCP 연결을 모두 제공하므로 요청했습니다).
Aurora0001

1
여기에 약간의 혼란이 있다고 생각합니다. "직접 TCP"가 @ Auroa0001이 의미하는 바는 웹 소켓을 통한 MQTT 대신 TCP를 통한 MQTT를 사용하고 있다고 가정합니다 (TCP 이상). 두 경우 모두 사용 가능한 라이브러리가 있으므로 소켓 용 코드를 작성할 필요가 없습니다.
ralight

@ ralight 그렇습니다. 질문을 할 때 그것은 정말로 내 의도였습니다. 대답은 약간 엉망이 된 것 같습니다.
Aurora0001

답변:


7

여기서 질문은 "TCP를 통한 MQTT를 사용해야합니까, 또는 웹 소켓을 통한 MQTT를 사용해야합니까 (TCP도 사용)"로 나타납니다. 즉, "웹 소켓 프로토콜에서 MQTT를 캡슐화하는 것이 좋은 생각입니까?"

이것은 (거의) 전적으로 응용 프로그램에 달려 있으며 브라우저에서 메시지를 소비하거나 방화벽으로 인해 웹 소켓 지원이 필요한지 여부입니다. 순수한 MQTT를 위해 포트 1883 이상 8883에서 서버에 액세스 할 수없는 경우 웹 소켓이 가장 좋습니다.

웹 소켓에는 추가 대역폭이 필요하지만 이것이 중요한지 여부는 귀하 만 대답 할 수 있습니다.

또한 현재 Mosquitto 버전에서는 웹 소켓이 제대로 작동하지 않으므로 웹 소켓 메시지를 보내거나받을 때 추가 대기 시간이있을 수 있습니다. 그래도 향후 버전에서는 문제가되지 않을 것입니다.


7

당신은 단지 내부 통신을 할 때 사용자의 네트워크 ( 인트라넷 ), 순수 TCP를 사용하여 잘 될 것입니다. 그러나 다른 서버에 연결해야하는 경우 문제가 발생합니다.

대부분의 최신 서버는 클라이언트가 임의 포트를 통해 연결할 수 없기 때문입니다. 전용 포트만 연결할 수 있습니다. 그게 다야. 따라서 다른 서버에 연결해야하는 경우 순수한 TCP 연결보다는 웹 소켓을 사용하는 것이 좋습니다.

오버 헤드를 고려하고 있다면 그렇게 크지 않습니다 . 웹 소켓의 오버 헤드에 대해 더 알고 싶다면 이 기사 를 참조하십시오 .

제 개인적으로는 웹 소켓을 사용하는 것이 좋습니다.


2
Err, TCP 및 웹 소켓은 프로토콜입니다. tools.ietf.org/html/rfc6455 , TCP는 낮은 수준의 소켓입니다.
Goufalite

@ThisaruGuruge 귀하의 답변에 감사드립니다-질문의 시나리오에서 귀하의 답변으로 판단되는 웹 소켓보다 TCP를 선택한다고 가정합니까? 특히 웹 소켓은 브라우저에서 주로 지원되는 것처럼 보이기 때문에 TCP 소켓보다 웹 소켓을 사용해야하는 코드 오버 헤드가 있습니다.
Aurora0001

1
"대부분의 최신 서버는 클라이언트가 임의의 포트를 통해 연결할 수 없습니다"-서버는 바인딩 할 포트 ( man7.org/linux/man-pages/man2/bind.2.html )와 방화벽을 선택할 수 있습니다 더 제한하십시오. 그러나 "다른 서버에 연결해야 할 경우 문제 발생합니다" 라고 말할 때 동의 하지 않습니다 . " 발생할 있다"고 표현하십시오. 그럼에도 불구하고 구성의 문제입니다. 어떤 소켓이 원시 소켓보다 쉬울 것입니다.
Mawg는 모니카 복원은

6

tl; dr- 항상 무료 라이브러리를 선호합니다


Mosquitto의 웹 소켓을 사용하거나 클라이언트를 직접 연결해야합니까?

끈의 길이는 얼마입니까? (YMMV)

나는 일반적으로 말할 수 있지만 항상 래퍼 라이브러리를 원시 소켓보다 선호합니다 (또는 실제로 라이브러리에서 무료로 얻을 수있는 것을 코딩하는 것을 선호합니다).

코딩이 간단하고 오류가 적습니다. 라이브러리는 일반적으로 라이브러리가 잘 검토되고 테스트되어 수천 명의 다른 사람들이 사용하는 자체적으로 디버깅하고 사용해야하는 코드 인 많은 하우스 키핑 및 오류 처리를 처리합니다. 버그를보고 / 수정합니다.

또한 유지 관리 및 포트 가능성이 적으므로 앱을 개발, 테스트 및 연마하거나 다음 앱으로 전환하는 데 더 많은 시간이 필요합니다.

사서의 장점 (오류 처리, 호스 유지 등)이 훌륭하고 안정적이며 소프트웨어를 얻기 위해 스스로 코딩해야하는 무언가라는 것을 받아들이면 유일한 오버 헤드는 함수 호출 일 것입니다.

성능이 염려되면 프로파일하십시오. 그러나 소켓이 초당 수백 번 활성화되지 않으면 귀찮게하지 않을 것입니다.


TCP 연결 및 (웹) 소켓 연결을위한 무료 라이브러리가 있으며 둘 다 "수신 된 메시지"이벤트가 필요합니다.
Goufalite

2
OP는 효율성 을 위해 TCP 또는 웹 소켓을 사용하는 것이 더 좋은지 알고 싶어하며 "추상 라이브러리를 사용하여 귀찮게하지 마십시오"라고 말합니다. 물론입니다. C #에는 System.Net.Sockets에 TcpClient 라이브러리가 있으며 (너무 잘 ...) 너겟 패키지 (WebSocketSharp)에 websocket 라이브러리가 있습니다. 모든 언어에 대한 일반 MQTT 라이브러리가 있지만 OP는 사용해야하는 프로토콜을 선택하기 위해이를 제어하려고합니다.
Goufalite
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.