Jetty와 Tomcat은 모두 애플리케이션 서버라고 합니다. 그러나 부두는 시작하는 두 가지 방법을 제공합니다. 직접 코드를 작성하여 부두를 시작하는 기능이 내장되어 있습니다. Tomcat과 동일한 또 다른 배포 방법은 war 패키지를 부두에 배포하는 것입니다. 임베디드 배포로 인해 유연성이 향상됩니다. 코드 배포는 각 환경에 Tomcat을 배포하기 위해 운영 및 유지 관리에 의존할 필요가 없습니다. 간단히 말하면 개발자에게 더 많은 선택권을 주는 방법이 하나 더 있습니다. 물론 jetty는 tomcat보다 늦게 나왔기 때문에 성능이나 아키텍처 면에서는 tomcat보다 상대적으로 좋습니다.
귀하의 질문에 언급된 솔루션은 몇 가지 새로운 기술(nodejs)을 사용하여 프런트엔드와 백엔드를 완전히 분리하므로 개발에 더 효율적일 수 있습니다.
당신이 말하는 긴 연결이 WebSocket인지, Comet인지, HTTP Keep-Alive인지 모르겠습니다. Jetty와 Tomcat은 모두 세 가지를 모두 지원합니다. 성능 측면에서: WebSocket과 HTTP Keep-Alive는 업계 표준이며 둘 사이에는 큰 성능 차이가 없습니다. 통일된 표준이 없기 때문에 Jetty와 Tomcat의 API인 Comet은 다릅니다. 하지만 업계에서는 둘 다 NIO를 지원하기 때문에 개인적으로 성능에는 큰 차이가 없다고 생각합니다.
둘 중 하나를 선택하는 것은 개인적인 습관(예: 저는 개인적으로 Jetty를 좋아합니다)이나 회사 규정 등의 문제일 수 있습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
매우 빠르게 시작되므로 개발 중에 사용됩니다.
주제에서 약간 벗어났습니다.
Jetty와 Tomcat은 모두 애플리케이션 서버라고 합니다. 그러나 부두는 시작하는 두 가지 방법을 제공합니다.
직접 코드를 작성하여 부두를 시작하는 기능이 내장되어 있습니다.
Tomcat과 동일한 또 다른 배포 방법은 war 패키지를 부두에 배포하는 것입니다.
임베디드 배포로 인해 유연성이 향상됩니다. 코드 배포는 각 환경에 Tomcat을 배포하기 위해 운영 및 유지 관리에 의존할 필요가 없습니다.
간단히 말하면 개발자에게 더 많은 선택권을 주는 방법이 하나 더 있습니다.
물론 jetty는 tomcat보다 늦게 나왔기 때문에 성능이나 아키텍처 면에서는 tomcat보다 상대적으로 좋습니다.
귀하의 질문에 언급된 솔루션은 몇 가지 새로운 기술(nodejs)을 사용하여 프런트엔드와 백엔드를 완전히 분리하므로 개발에 더 효율적일 수 있습니다.
당신이 말하는 긴 연결이 WebSocket인지, Comet인지, HTTP Keep-Alive인지 모르겠습니다. Jetty와 Tomcat은 모두 세 가지를 모두 지원합니다. 성능 측면에서:
WebSocket과 HTTP Keep-Alive는 업계 표준이며 둘 사이에는 큰 성능 차이가 없습니다.
통일된 표준이 없기 때문에 Jetty와 Tomcat의 API인 Comet은 다릅니다. 하지만 업계에서는 둘 다 NIO를 지원하기 때문에 개인적으로 성능에는 큰 차이가 없다고 생각합니다.
둘 중 하나를 선택하는 것은 개인적인 습관(예: 저는 개인적으로 Jetty를 좋아합니다)이나 회사 규정 등의 문제일 수 있습니다.