전송 프로토콜

Message Queue 소프트웨어를 사용하면 클라이언트가 다양한 저급 전송 프로토콜을 사용하여 브로커와 통신할 수 있습니다. Message Queue는 연결 서비스에 설명된 연결 서비스와 해당 프로토콜을 지원합니다.

프로토콜은 응용 프로그램 요구 사항(암호화, 방화벽을 통한 액세스 가능)을 기반으로 선택하지만 이 선택은 전체 성능에 영향을 미칩니다.

그림 11–2 전송 프로토콜 속도

테스트를 통해 높은 안정성 시나리오(영구 가입이 있고 AUTO_ACKNOWLEDGE 확인 모드를 사용하는 주제 대상에 1k의 지속성 메시지를 보냄)와 높은 성능 시나리오(영구 가입이 없고 DUPS_OK_ACKNOWLEDGE 확인 모드를 사용하는 주제 대상에 1k의 비지속성 메시지를 보냄)의 두 가지 경우에 대해 TCP와 SSL의 처리량을 비교했습니다.

일반적으로 프로토콜은 높은 안정성 사례에서 미치는 영향이 더 적습니다. 이는 아마도 높은 안정성 사례에서 필요한 지속성 오버헤드가 처리량을 제한하는 데 프로토콜 속도보다 더 중요한 요소이기 때문일 것입니다. 또는

• TCP는 브로커와 통신할 수 있는 가장 빠른 방법을 제공합니다.

• SSL은 메시지를 보내고 받을 때 TCP보다 50-70퍼센트 더 느립니다(지속성 메시지의 경우 50퍼센트, 비지속성 메시지의 경우 70퍼센트에 근접). 또한 클라이언트와 브로커(또는 HTTPS의 경우 웹 서버)가 전송할 데이터를 암호화할 때 사용될 개인 키를 설정해야 하므로 SSL을 사용하면 초기 연결 설정이 더 느려집니다(몇 초 걸릴 수 있음). 각 저급 TCP 패킷을 암호화하고 해독하는 데 필요한 추가 처리에 의해 성능이 저하됩니다.

• HTTP는 TCP나 SSL보다 느립니다. HTTP는 웹 서버에서 실행되는 서블릿을 클라이언트와 브로커 사이의 프록시로 사용합니다. 성능 오버헤드는 HTTP 요청의 패킷 캡슐화와 메시지가 브로커에 도달하기 위해 두 개의 홉(클라이언트에서 서블릿으로, 서블릿에서 브로커로)을 통과해야 한다는 점과 관련됩니다.

• 클라이언트와 서블릿 사이 그리고 서블릿과 브로커 사이에서 패킷을 암호화하는 데 필요한 추가 오버헤드로 인해 HTTPS는 HTTP보다 더 느립니다.