Java 언어는 어떤 프로토콜을 지원합니까?

다음은 Java 언어에서 일반적으로 사용되는 여러 통신 프로토콜과 프로토콜 성능을 비교한 것입니다

1.RMI

RMI 호출은 예상대로 RMI가 가장 빠르며 거의 모든 경우에 시간은 최소입니다. 특히 데이터 구조가 복잡하고 데이터 양이 많은 경우에는 다른 프로토콜과의 격차가 더욱 뚜렷해집니다. RMI의 성능을 최대한 활용하기 위해 Spring을 사용하는 대신 원래의 RMI 형식(UnicastRemoteObject 객체를 상속함)을 사용하여 서비스를 제공하고 원격 호출을 수행하는 데 효율성을 Spring의 RMI와 비교했습니다. POJO로 포장되었습니다. 결과에 따르면 둘은 기본적으로 동일하며 Spring에서 제공하는 서비스가 약간 더 빠르다는 것을 알 수 있습니다. 처음에는 이것이 Spring의 프록시 및 캐싱 메커니즘이 상대적으로 강력하여 객체를 다시 획득하는 시간을 절약하기 때문이라고 생각됩니다.

2. Hessian

Hessian은 가장 빠른 서버로 알려져 있으며 Java 분야에서 확실한 평판을 갖고 있는 Caucho 회사의 Resin 서버를 호출합니다. 레진의 구성요소인 헤시안의 디자인 또한 매우 유선형이고 효율적이며, 실제 작동을 통해 이를 입증했습니다. 평균적으로 Hessian은 RMI보다 약 20% 정도 느리지만 이는 데이터의 양이 특히 많고 데이터 구조가 복잡한 경우에만 반영될 수 있습니다. 데이터의 양이 중간이거나 적을 경우 Hessian은 RMI보다 느리지 않습니다. Hessian의 장점은 간소화되고 효율적이며 여러 언어에 걸쳐 사용할 수 있으며 프로토콜 사양이 공개되어 모든 언어에 대한 프로토콜 구현을 개발할 수 있다는 것입니다. 현재 구현된 언어로는 java, c++, .net, python, ruby가 있습니다. 아직 델파이 구현이 없습니다. 또한 Hessian은 WEB 서버와 매우 잘 통합되며, WEB 서버의 기능을 통해 많은 수의 사용자의 동시 액세스를 처리하는 데 큰 이점을 가질 수 있습니다. 성숙한 웹 서버에 의해 보장됩니다. RMI 자체는 다중 스레드 서버를 제공하지 않습니다. 게다가 RMI는 방화벽 포트를 열어야 하지만 Hessian은 그렇지 않습니다.

3.Burlap

Burlap과 Hessian은 모두 caucho사의 오픈소스 제품이지만 Hessian은 바이너리 형식을 사용하고 Burlap은 xml 형식을 사용합니다. 테스트 결과, 데이터 구조가 복잡하지 않고 데이터의 양이 중간인 경우 Burlap의 효율성은 여전히 ​​허용 가능하지만, 데이터의 양이 많으면 효율성이 급격히 떨어지는 것으로 나타났습니다. 평균적으로 Burlap의 밀리초당 호출 시간은 RMI의 3배입니다. 효율성이 낮은 데에는 두 가지 이유가 있다고 생각합니다. 하나는 XML 데이터 설명 내용이 너무 많고, 다른 한편으로는 우리 모두 알고 있듯이 XML을 구문 분석하는 것이 상대적으로 크다는 것입니다. 특히 리소스 집약적이며 대용량 데이터 볼륨의 경우 특히 그렇습니다.

4.HttpInvoker

HttpInvoker는 Spring Framework에서 제공하는 JAVA 원격 호출 메소드로, Java의 직렬화 메커니즘을 사용하여 객체 전송을 처리합니다. 테스트 결과에 따르면 효율성은 기본적으로 RMI와 동일하게 여전히 허용 가능합니다. 그러나 JAVA 언어 간 통신에만 사용할 수 있으며, 클라이언트와 서버 모두 SPRING 프레임워크를 사용해야 합니다. 또한 HttpInvoker는 실제로 테스트되지 않았으며 현재 이 프로토콜을 적용하는 프로젝트가 없습니다.

5.web service

AXIS는 WEB SERVICE 구현이 비교적 성숙하고 WEB SERVICE 분야에서 확립되었기 때문에 Apache의 AXIS 구성 요소를 선택했습니다. 데이터 전송, 인코딩, 디코딩 시간만 테스트하기 위해 클라이언트와 서버 모두 캐싱을 사용하며 개체는 한 번만 인스턴스화하면 됩니다. 그러나 테스트 결과에 따르면 웹 서비스의 효율성은 여전히 ​​다른 통신 프로토콜에 비해 10배 느린 것으로 나타났습니다. 동일한 개체를 가리키는 여러 참조의 전송을 고려하면 웹 서비스는 훨씬 더 뒤쳐집니다. RMI, Hessian 및 기타 프로토콜은 참조를 전달할 수 있기 때문에 웹 서비스가 갖는 참조 수는 개체 엔터티의 복사본 수에 따라 달라집니다. 웹 서비스에서 전송되는 과도한 중복 정보는 속도가 느린 이유 중 하나입니다. 모니터링에서는 동일한 데이터를 설명하는 동일한 액세스 요청에 대해 웹 서비스에서 반환되는 데이터의 양이 Hessian 프로토콜의 6.5배에 달하는 것으로 나타났습니다. 또한, WEB SERVICE 처리에도 많은 시간이 소요되며, 현재의 XML 파서는 일반적으로 효율적이지 않으며, xml<-> 테스트 결과, 원격 호출은 로컬 호출보다 빠르며, 이는 주로 xml 파일 인코딩 및 디코딩에 시간이 소요되는 것으로 나타났습니다. 이는 중복 정보보다 더 심각합니다. 중복 정보는 네트워크 대역폭만 차지하며 각 호출의 리소스 소비는 서버의 로드 용량에 직접적인 영향을 미칩니다. (MS 엔지니어들은 WEB SERVICE가 100명 이상의 동시 사용자를 로드할 수 없다고 말한 적이 있습니다.) 테스트 중에 웹 서비스 코딩이 기본이 아닌 유형의 경우 직렬화 및 역직렬화 클래스를 하나씩 등록해야 하는 것으로 나타났습니다. 하나는 매우 어렵습니다. 스텁을 생성하는 것은 더 힘들고 스프링 + RMI/헤센 처리만큼 부드럽고 간결하지 않습니다. 게다가 웹 서비스는 컬렉션 유형을 지원하지 않고 배열만 사용할 수 있어 불편합니다.

위 내용은 Java 언어는 어떤 프로토콜을 지원합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!