응용 프로그램 서버와 웹 서버의 차이점은 무엇입니까?
답변:
대부분 웹 서버와 응용 프로그램 서버라는 용어는 서로 바꿔 사용할 수 있습니다.
다음은 Web Server 및 Application Server 기능의 주요 차이점 중 일부입니다.
- 웹 서버는 HTTP 컨텐츠를 제공하도록 설계되었습니다. App Server는 HTTP 콘텐츠도 제공 할 수 있지만 HTTP에만 국한되지는 않습니다. RMI / RPC와 같은 다른 프로토콜 지원을 제공 할 수 있습니다.
- 웹 서버는 대부분 정적 컨텐츠를 제공하도록 설계되었지만 대부분의 웹 서버에는 Perl, PHP, ASP, JSP 등과 같은 스크립트 언어를 지원하는 플러그인이있어 이러한 서버가 동적 HTTP 컨텐츠를 생성 할 수 있습니다.
- 대부분의 응용 프로그램 서버에는 웹 서버가 통합되어 있으므로 Web Server는 가능한 모든 웹 서버를 수행 할 수 있습니다. 또한 App Server에는 연결 풀링, 객체 풀링, 트랜잭션 지원, 메시징 서비스 등과 같은 응용 프로그램 수준 서비스를 지원하는 구성 요소와 기능이 있습니다.
- 웹 서버는 정적 콘텐츠 및 동적 콘텐츠 용 앱 서버에 적합하므로 대부분의 프로덕션 환경에는 웹 서버가 앱 서버에 대한 리버스 프록시 역할을합니다. 즉, 페이지 요청을 처리하는 동안 이미지 / 정적 HTML과 같은 정적 컨텐츠는 요청을 해석하는 웹 서버에서 제공됩니다. 어떤 종류의 필터링 기술 (주로 요청 된 리소스의 확장)을 사용하여 웹 서버는 동적 콘텐츠 요청을 식별하고 앱 서버로 투명하게 전달합니다.
이러한 구성의 예는 Apache Tomcat HTTP Server 및 Oracle (이전 BEA) WebLogic Server입니다. Apache Tomcat HTTP Server는 웹 서버이고 Oracle WebLogic은 Application Server입니다.
경우에 따라 서버는 IIS 및 .NET 런타임과 같이 밀접하게 통합되어 있습니다. IIS는 웹 서버입니다. .NET 런타임 환경을 갖추면 IIS는 응용 프로그램 서비스를 제공 할 수 있습니다.
이것은 차이점, 유사점 및 둘 다 함께 작동하는 방법과 모든 방법을 명확하게 이해하는 몇 가지 시나리오에 대한 자세한 답변입니다.
Application Server 는 때때로 웹 서버 와 혼합되는 용어입니다 . 웹 서버는 주로 HTTP 프로토콜을 처리하지만 , Application Server는 HTTP를 포함하지만 이에 국한되지 않는 여러 가지 프로토콜 을 처리 합니다.
웹 서버의 주요 업무는 사이트 컨텐츠 를 표시하는 것이며 애플리케이션 서버는 사용자와 표시된 컨텐츠 사이의 상호 작용 , 논리를 담당 합니다. 응용 프로그램 서버는 웹 서버 와 함께 작동 하여 웹 서버가 표시되고 다른 서버가 상호 작용합니다.
서버와 클라이언트간에 앞뒤로 이동하는 정보는 단순한 디스플레이 마크 업으로 제한되지 않고 둘 사이의 상호 작용으로 제한됩니다.
대부분의 경우 서버 는 J2EE (Java 2 Platform) , EJB (Enterprise JavaBean) 및 기타 다른 응용 프로그램 소프트웨어 모델과 같은 구성 요소 API를 통해 이러한 상호 작용을 만듭니다 .
예를 들면 :
응용 프로그램 서버가 웹 서버와 작동하는 시나리오와 응용 프로그램 서버가없는 시나리오는 온라인 상점을 통한 시나리오의 차이점을 이해하는 가장 좋은 방법입니다.
시나리오 1 : 애플리케이션 서버가없는 웹 서버
웹 서버 만 있고 응용 프로그램 서버가없는 온라인 상점이 있습니다. 이 사이트는 제품을 선택할 수있는 디스플레이를 제공합니다. 쿼리를 제출하면 사이트에서 조회를 수행하고 HTML 결과를 클라이언트에 다시 반환합니다. 웹 서버는 쿼리를 데이터베이스 서버로 직접 전송합니다 (내버려 두 번째 너깃에서 설명하겠습니다). 응답을 기다립니다. 수신되면 웹 서버는 응답을 HTML 파일로 공식화하여 웹 브라우저로 보냅니다. 서버와 데이터베이스 서버 간의이 통신은 쿼리가 실행될 때마다 발생합니다.
시나리오 2 : 애플리케이션 서버가있는 웹 서버
실행하려는 조회가 이미 수행되었고 그 이후로 데이터가 변경되지 않은 경우, 서버는 요청을 데이터베이스 서버로 보내지 않고도 결과를 생성합니다. 이를 통해 두 번째 클라이언트가 동일한 정보에 액세스하고 데이터베이스 서버에 다른 중복 쿼리를 보내지 않고도 신뢰할 수있는 실시간 정보를 실시간으로받을 수있는 실시간 쿼리가 가능합니다. 서버는 기본적으로 데이터베이스 서버와 웹 서버 사이의 중간 역할을합니다. 이렇게하면 첫 번째 시나리오에서 가져온 정보를 재사용 할 수 있습니다.이 정보는 특정 "사용자 정의 된"HTML 페이지에 포함되므로 재사용 할 수있는 프로세스가 아닙니다. 두 번째 클라이언트는 정보를 다시 요청하고 요청 된 정보가 포함 된 또 다른 HTML 삽입 페이지를 수신해야합니다.
이러한 다양한 복잡한 작업을 지원하려면이 서버에는 중복 데이터, 뛰어난 처리 성능 및 많은 양의 RAM이 있어야 실시간으로 가져 오는 모든 데이터를 처리 할 수 있습니다.
도움이 되었기를 바랍니다.
the application server deals with several different protocols, including, but not limited, to HTTP<-그것은 http 요청을 확실히 처리한다고 말합니다-정확하지 않습니다.
두 용어 모두 매우 일반적인 용어로, 다른 용어를 포함하는 용어도 있고 그 반대의 경우도 있습니다.
웹 서버 : http 프로토콜을 사용하여 웹에 콘텐츠를 제공합니다.
응용 프로그램 서버 : 비즈니스 논리 및 프로세스를 호스팅하고 노출합니다.
요점은 웹 서버가 http 프로토콜을 통해 모든 것을 노출시키는 반면 응용 프로그램 서버는 이에 제한되지 않는다는 것입니다.
즉, 많은 시나리오에서 웹 서버가 애플리케이션 서버의 프론트 엔드를 작성하는 데 사용되고 있음을 알 수 있습니다. 즉, 사용자가 웹 서버에서 발견 된 비즈니스 규칙과 상호 작용할 수있는 웹 페이지 세트를 노출합니다 응용 프로그램 서버.
웹 서버
실행 python -m 'SimpleHTTPServer'하고 http : // localhost : 8080으로 이동 하십시오 . 당신이 보는 것은 작동하는 웹 서버입니다. 서버는 단순히 컴퓨터에 저장된 HTTP를 통해 파일을 제공합니다. 요점은이 모든 것이 HTTP 프로토콜 위에서 수행된다는 것입니다. 예를 들어 정확히 동일한 작업 (저장된 파일 제공)을 수행하지만 다른 프로토콜 위에있는 FTP 서버도 있습니다.
응용 프로그램 서버
아래와 같은 작은 응용 프로그램이 있다고 가정 해보 십시오 ( Flask의 조각 ).
@app.route('/')
def homepage():
return '<html>My homepage</html>'
@app.route('/about')
def about():
return '<html>My name is John</html>'
작은 예제 프로그램은 URL 매핑 /함수에 homepage()와 /about함수에 about().
이 코드를 실행하려면 클라이언트의 요청을 듣고 코드를 사용하여 동적으로 무언가를 반환하는 프로그램 또는 모듈 인 응용 프로그램 서버 (예 : Gunicorn)가 필요합니다. 이 예에서는 아주 나쁜 HTML을 반환합니다.
다른 사람들이 말하는 비즈니스 논리는 무엇입니까? URL은 코드베이스의 특정 위치에 매핑되므로 프로그램 작동 방식에 대한 논리를 가정하고 있습니다.
리 캡핑
웹 서버 -어딘가에 저장된 파일을 제공합니다 (가장 .css, .html, .js). 일반적인 웹 서버는 Apache, Nginx 또는 Python의 SimpleHTTPServer입니다.
응용 프로그램 서버 -즉시 생성 된 파일을 제공합니다. 기본적으로 대부분의 웹 서버에는 일종의 플러그인이 있거나 내장 기능이 내장되어 있습니다. Gunicorn (Python), Unicorn (Ruby), uWSGI (Python) 등과 같은 엄격한 응용 프로그램 서버도 있습니다.
실제로 애플리케이션 서버의 코드를 사용하여 웹 서버를 빌드 할 수 있습니다. 이것은 개발 중에 컴퓨터에서 여러 서버를 실행하고 싶지 않은 경우에 수행됩니다.
Rutesh와 jmservera가 지적했듯이, 구별은 모호한 것입니다. 역사적으로, 그것들은 달랐지만, 90 년대를 통해이 두 가지 별개의 카테고리는 기능을 혼합하고 효과적으로 병합했습니다. 이 시점에서 "앱 서버"제품 카테고리가 "웹 서버"카테고리의 엄격한 상위 세트라고 생각하는 것이 가장 좋습니다.
일부 역사. Mosaic 브라우저와 하이퍼 링크 컨텐츠의 초기에는 HTTP를 통해 웹 페이지 컨텐츠와 이미지를 제공하는 "웹 서버"라는 것이 진화했습니다. 대부분의 내용은 정적이고 HTTP 1.0 프로토콜은 파일을 전달하는 방법 일뿐입니다. "웹 서버"범주는 CGI 기능을 포함하도록 빠르게 진화하여 각 웹 요청에서 프로세스를 효과적으로 시작하여 동적 컨텐츠를 생성합니다. 캐싱, 보안 및 관리 기능을 통해 HTTP도 성숙하고 제품이 더욱 정교 해졌습니다. 기술이 발전함에 따라 Kiva와 NetDynamics에서 회사 별 Java 기반 서버 측 기술을 확보했으며, 결국 JSP에 통합되었습니다. Microsoft는 1996 년에 ASP를 Windows NT 4.0에 추가했습니다. 정적 웹 서버는 몇 가지 새로운 트릭을 배웠으므로 효과적인 "
병렬 범주에서 앱 서버는 오랫동안 진화하여 존재했습니다. 회사는 IMS 및 CICS와 같은 메인 프레임 애플리케이션 관리 및 모니터링 환경에서 철학적으로 파생 된 Tuxedo, TopEnd, Encina와 같은 Unix 용 제품을 제공했습니다. Microsoft의 제품은 Microsoft Transaction Server (MTS)였으며 나중에 COM +로 발전했습니다. 이러한 제품의 대부분은 "폐쇄 된"제품 별 통신 프로토콜을 지정하여 "지방"클라이언트를 서버에 상호 연결합니다. Encina의 경우 통신 프로토콜은 DCE RPC이고 MTS의 경우 DCOM 등이었습니다. 1995/96 년에 이러한 전통적인 앱 서버 제품은 처음에는 게이트웨이를 통해 기본 HTTP 통신 기능을 포함하기 시작했습니다. 그리고 선이 흐려지기 시작했습니다.
웹 서버는 더 높은로드, 동시성 및 더 나은 기능 처리와 관련하여 점점 더 성숙해졌습니다. 앱 서버는 점점 더 많은 HTTP 기반 통신 기능을 제공했습니다.
이 시점에서 "앱 서버"와 "웹 서버"사이의 경계는 희미한 것입니다. 그러나 사람들은 강조의 문제로 용어를 계속 다르게 사용합니다. 누군가 "웹 서버"라고 말하면 종종 HTTP 중심의 웹 UI 지향 앱을 생각합니다. 누군가 "앱 서버"라고 말하면 "더 많은 부하, 엔터프라이즈 기능, 트랜잭션 및 큐, 다중 채널 통신 (HTTP + 이상)"이라고 생각할 수 있지만 종종 두 가지 워크로드 요구 사항을 모두 제공하는 동일한 제품입니다.
- IBM의 "앱 서버"인 WebSphere에는 자체 번들 웹 서버가 있습니다.
- 또 다른 전통적인 앱 서버 인 WebLogic도 마찬가지입니다.
- Microsoft의 응용 프로그램 서버 인 Windows (파일 및 인쇄 서버, 미디어 서버 등)는 IIS를 번들로 제공합니다.
많은 사람들이 이전에 말했듯이 웹 서버는 HTTP 탄원을 처리하는 반면 응용 프로그램 서버는 분산 구성 요소의 탄원을 처리합니다. 따라서 차이점을 이해하는 가장 쉬운 방법은 제공하는 프로그래밍 환경과 관련하여 두 제품을 비교하는 것입니다.
웹 서버-> 프로그래밍 환경
IIS : ASP (.NET)
톰캣 : 서블릿
부두 : 서블릿
아파치 : Php, CGI
어플리케이션 서버-> 프로그래밍 환경
MTS : COM +
WAS : EJB
JBoss : EJB
WebLogic Application Server : EJB
중요한 차이점은 응용 프로그램 서버가 일부 분산 구성 요소 기술을 지원 하여 Java 세계의 EJB 또는 Microsoft 플랫폼의 COM + 와 같은 원격 호출 및 분산 트랜잭션과 같은 기능을 제공한다는 것 입니다. Http 서버는 종종 Microsoft 나 Servlet 기반의 경우 ASP (.NET)와 같은 스크립팅과 같은 일부 간단한 프로그래밍 환경을 지원합니다 (JSP 등).
응용 프로그램 서버 영역에서 사용되었던로드 균형 조정, 클러스터링, 세션 페일 오버, 연결 풀링 등과 같은 다른 기능은 웹 서버에서 직접 또는 일부 타사 제품을 통해 사용할 수 있습니다.
마지막으로 Spring Framework와 같은 "경량 컨테이너"로 인해 그림이 더 왜곡되어 응용 프로그램 서버의 목적을 응용 프로그램 서버 인프라없이 더 간단한 방식으로 보완하는 경우가 있습니다. 또한 응용 프로그램의 배포 측면이 분산 구성 요소에서 서비스 패러다임 및 SOA 아키텍처로 이동하고 있기 때문에 기존 응용 프로그램 서버를위한 공간이 줄어 듭니다.
웹 서버와 애플리케이션 서버의 주요 차이점은 웹 서버는 HTML 및 CSS와 같은 정적 페이지를 제공하는 반면 Application Server는 JSP, Servlet 또는 EJB와 같은 서버 측 코드를 실행하여 동적 컨텐츠를 생성하는 것입니다.
어느 것을 사용해야합니까?
웹과 응용 프로그램 서버와 웹 컨테이너의 차이점을 알게되면 언제 사용할 것인지 쉽게 알 수 있습니다. web server정적 웹 페이지를 제공하는 경우 비슷한 Apache HTTPD 가 필요 합니다. 동적 컨텐츠를 생성하기 위해 JSP 및 Servlet 만있는 Java 애플리케이션이있는 경우 web containersTomcat 또는 Jetty 가 필요합니다 . 하지만, 자바 EE의 EJB를 사용하여 응용 프로그램, 분산 트랜잭션, 메시징 및 다른 공상이있는 경우 기능 이 본격적인 풀 필요 이상으로 application server보스는 WebSphere 또는 오라클 웹 로직과 같이합니다.
웹 컨테이너는 Web Server의 일부이고 Web Server는 Application Server의 일부입니다.
Web Server는 웹 컨테이너로 구성되는 반면 Application Server는 EJB 컨테이너뿐만 아니라 웹 컨테이너로 구성됩니다.
간단히 말해서 웹 서버 는 http를 통해 사용자에게 웹 페이지를 제공하는 서버입니다. 응용 프로그램 서버는 시스템에 대한 비즈니스 로직을 호스팅하는 서버입니다. 장기 실행 / 일괄 처리 프로세스 및 / 또는 사람이 소비하지 않는 interop 서비스 (REST / JSON 서비스, SOAP, RPC 등)를 모두 호스팅합니다.
웹 서버는 HTTP / HTTPS 요청을 독점적으로 처리합니다. HTTP / HTTPS 프로토콜을 사용하여 웹에 컨텐츠를 제공합니다.
애플리케이션 서버는 HTTP를 포함하여 여러 프로토콜을 통해 애플리케이션 프로그램에 비즈니스 로직을 제공합니다. 응용 프로그램은 오브젝트에서 메소드를 호출하는 것처럼이 논리를 사용할 수 있습니다. 대부분의 경우 서버는 Java EE (Java Platform, Enterprise Edition) 애플리케이션 서버에있는 EJB (Enterprise JavaBean) 컴포넌트 모델과 같은 컴포넌트 API를 통해이 비즈니스 로직을 노출합니다. 요점은 웹 서버가 http 프로토콜을 통해 모든 것을 공개하지만 애플리케이션 서버는 이에 제한되지 않는다는 것입니다. 따라서 응용 프로그램 서버는 일반적으로 다음을 포함하는 웹 서버보다 훨씬 더 많은 서비스를 제공합니다.
- (독점적이든 아니든) API
- 로드 밸런싱, 페일 오버 ...
- 객체 수명주기 관리
- 상태 관리 (세션)
- 자원 관리 (예 : 데이터베이스에 대한 연결 풀)
대부분의 응용 프로그램 서버에는 웹 서버가 통합되어 있으므로 Web Server는 가능한 모든 웹 서버를 수행 할 수 있습니다. 또한 App Server에는 연결 풀링, 객체 풀링, 트랜잭션 지원, 메시징 서비스 등과 같은 응용 프로그램 수준 서비스를 지원하는 구성 요소와 기능이 있습니다.
응용 프로그램 서버는 웹 서버에서 프로그램 논리를 실행하기 위해 웹 서버에서 실행될 수 있지만 항상 그런 것은 아닙니다. 결과는 웹 서버에 의해 전달 될 수 있습니다. 이것이 웹 서버 / 애플리케이션 서버 시나리오의 한 예입니다. Microsoft 세계에서 좋은 예는 인터넷 정보 서버 / SharePoint 서버 관계입니다. IIS는 웹 서버입니다. SharePoint는 응용 프로그램 서버입니다. SharePoint는 IIS의 "최상위"에 위치하고 특정 논리를 실행하며 IIS를 통해 결과를 제공합니다. Java 세계에서는 예를 들어 Apache 및 Tomcat과 비슷한 시나리오가 있습니다.
웹 서버는 정적 콘텐츠 및 동적 콘텐츠 용 앱 서버에 적합하므로 대부분의 프로덕션 환경에는 웹 서버가 앱 서버에 대한 리버스 프록시 역할을합니다. 즉, 페이지 요청을 처리하는 동안 images / Static html과 같은 정적 컨텐츠는 요청을 해석하는 웹 서버에서 제공됩니다. 어떤 종류의 필터링 기술 (주로 요청 된 리소스의 확장)을 사용하여 웹 서버는 동적 콘텐츠 요청을 식별하고 앱 서버로 투명하게 전달합니다.
이러한 구성의 예는 Apache HTTP Server 및 BEA WebLogic Server입니다. Apache HTTP Server는 웹 서버이고 BEA WebLogic은 Application Server입니다. 경우에 따라 서버는 IIS 및 .NET 런타임과 같이 밀접하게 통합되어 있습니다. IIS는 웹 서버입니다. .NET 런타임 환경을 갖춘 IIS는 응용 프로그램 서비스를 제공 할 수 있습니다
Web Server Programming Environment
Apache PHP, CGI
IIS (Internet Information Server) ASP (.NET)
Tomcat Servlet
Jetty Servlet
Application Server Programming Environment
WAS (IBM's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's) EJB
JBoss AS EJB
MTS COM+
이 둘의 경계는 점점 더 얇아지고 있습니다.
어플리케이션 서버는 비즈니스 로직을 클라이언트에게 노출시킵니다. 이는 애플리케이션 서버가 비즈니스 로직을 수행하기위한 일련의 방법으로 구성됨을 의미합니다. 따라서 HTML 컨텐츠가 아닌 원하는 결과를 간단히 출력합니다. (메소드 호출과 유사). 따라서 엄격하게 HTTP 기반이 아닙니다.
그러나 웹 서버는 HTML 컨텐츠를 웹 브라우저 (Strictly HTTP 기반)로 전달합니다. 웹 서버는 정적 웹 리소스 만 처리 할 수 있었지만 서버 측 스크립팅의 출현으로 웹 서버는 동적 내용도 처리 할 수있었습니다. 웹 서버가 요청을 가져 와서 관련 스크립트 (PHP, JSP, CGI 스크립트 등)로 보내 HTML 컨텐츠를 클라이언트로 보낼 수 있도록합니다. 컨텐츠가 수신되면 웹 서버는 HTML 페이지를 클라이언트로 보냅니다.
그러나 요즘에는이 두 서버가 함께 사용됩니다. 웹 서버가 요청을받은 다음 HTML 컨텐츠를 작성하는 스크립트를 호출합니다. 그런 다음 스크립트는 다시 애플리케이션 서버 LOGIC (예 : 트랜잭션 세부 사항 검색)을 호출하여 HTML 컨텐츠를 채 웁니다.
따라서 두 서버 모두 효과적으로 사용됩니다.
따라서 .... 오늘날 대부분의 경우 웹 서버가 응용 프로그램 서버의 하위 집합으로 사용된다고 안전하게 말할 수 있습니다. 그러나 연극 적으로는 그렇지 않습니다.
나는이 주제에 대한 많은 기사를 읽고 발견 이 매우 편리 기사를.
응용 프로그램 서버는 제공하는 모든 서비스에 대한 클라이언트의 요청을 "모든 프로토콜에서 프로토콜을 사용하여" "수신"하는 컴퓨터 (실제로 일부 컴퓨터에서 실행되는 실행 가능한 프로세스)이며 해당 요청에 따라 무언가를 수행합니다. (고객에게 respose를 포함하거나 포함하지 않을 수 있음)
웹 서버는 "인터넷"프로토콜 중 하나 (http, https, ftp 등)를 사용하여 TCP / IP 채널에서 "수신"하는 시스템에서 실행되는 프로세스이며 들어오는 요청을 기반으로하는 모든 작업을 수행합니다. .. 일반적으로 (원 본적으로 정의 된대로), 서버의 정적 html 파일에서 가져 오거나 수신 클라이언트 요청의 매개 변수를 기반으로 동적으로 구성된 HTML 웹 페이지를 가져 오거나 생성하여 클라이언트에 리턴했습니다.
웹 서버는 HTTP 프로토콜을 실행하여 웹 페이지를 제공합니다. 응용 프로그램 서버는 프로그램 로직을 실행하기 위해 웹 서버에서 실행될 수 있지만 항상 그런 것은 아닙니다. 그 결과는 웹 서버에서 제공 될 수 있습니다. 이것이 웹 서버 / 애플리케이션 서버 시나리오의 한 예입니다.
Microsoft 세계에서 좋은 예는 인터넷 정보 서버 / SharePoint 서버 관계입니다. IIS는 웹 서버입니다. SharePoint는 응용 프로그램 서버입니다. SharePoint는 IIS의 "최상위"에 위치하고 특정 논리를 실행하며 IIS를 통해 결과를 제공합니다.
Java 세계에서는 예를 들어 Apache 및 Tomcat과 비슷한 시나리오가 있습니다.
우선, 웹 서버는 HTTP 프로토콜을 통해 웹 컨텐츠 (HTML 및 정적 컨텐츠)를 제공합니다. 반면에 응용 프로그램 서버는 n- 계층 아키텍처의 HTTP를 포함한 다양한 프로토콜을 통해 비즈니스 논리 및 프로세스를 구축하고 클라이언트 응용 프로그램에 노출 할 수있는 컨테이너입니다.
따라서 응용 프로그램 서버는 일반적으로 다음을 포함하는 웹 서버보다 훨씬 더 많은 서비스를 제공합니다.
- (독점적이든 아니든) API
- 객체 수명주기 관리
- 상태 관리 (세션)
- 자원 관리 (예 : 데이터베이스에 대한 연결 풀)
- 로드 밸런싱, 페일 오버 ...
AFAIK, ATG Dynamo 는 90 년대 후반 (위의 정의에 따라) 최초의 애플리케이션 서버 중 하나였습니다. 2000 년 초에는 CFML AS ( ColdFusion ), BroadVision (Server-side JavaScript AS) 등과 같은 일부 독점적 인 응용 프로그램 서버가 사용되었습니다 . 그러나 실제로 Java 응용 프로그램 서버 시대를 살아남은 사람은 없었습니다.
기본 이해 :
클라이언트 서버 아키텍처
서버 :> 요청을 처리합니다.
클라이언트 :> 서비스를 소비합니다.
웹 서버 및 응용 프로그램 서버는 클라이언트의 서버 역할을하는 소프트웨어 응용 프로그램입니다.
그들은 활용 장소에 따라 이름을 얻었습니다.
Web server :> serve web content
:> Like Html components
:> Like Javascript components
:> Other web components like images,resource files
:> Supports mainly web protocols like http,https.
:> Supports web Request & Response formats.
사용법-
we require low processing rates, regular processing practices involves.예 : 웹 기반 콘텐츠 만 제공하는 모든 평면 서버는 일반적으로 기성품으로 제공됩니다.
Application server :> Serve application content/component data(Business data).
:> These are special kind which are custom written
designed/engineered for specific
purpose.some times fully unique in
their way and stands out of the crowd.
:> As these serves different types of data/response contents
:> So we can utilize these services for mobile client,web
clients,intranet clients.
:> Usually application servers are services offered on different
protocols.
:> Supports different Request& Response formats.
사용법-
we require multi point processing, specialized processing techniques involves like for AI.예 : Google은 서버, Google 검색 서버, Google 문서 서버, Microsoft 365 서버, AI 용 Microsoft 컴퓨터 비전 서버를 매핑합니다.
이를 4 계층 / n 계층 아키텍처에서 계층 / 계층 구조로 가정 할 수 있습니다.
So they can provide
load balancing,
multiple security levels,
multiple active points,
even they can provide different request processing environments.
표준 아키텍처 유추에 대해서는이 링크를 따르십시오.
https://docs.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10)
위의 모든 것은 매우 간단한 것을 복잡하게 만듭니다. 응용 프로그램 서버에는 웹 서버가 포함되어 있으며 응용 프로그램 서버에는 표준 웹 서버보다 몇 가지 추가 / 확장 기능이 있습니다. TomEE를 예로 들어 보면 :
CDI - Apache OpenWebBeans
EJB - Apache OpenEJB
JPA - Apache OpenJPA
JSF - Apache MyFaces
JSP - Apache Tomcat
JSTL - Apache Tomcat
JTA - Apache Geronimo Transaction
Servlet - Apache Tomcat
Javamail - Apache Geronimo JavaMail
Bean Validation - Apache BVal
Tomcat (웹 컨테이너 / 서버)은 앱 서버 무기고의 또 다른 도구 일뿐입니다. 원하는 경우 웹 서버에서 JPA 및 기타 기술을 얻을 수 있지만 응용 프로그램 서버는 편의를 위해 이러한 모든 것을 패키징합니다. 앱 서버로 완전히 분류 되려면 기본적으로 일부 표준에서 제시 한 도구 목록을 준수해야합니다.
에서 https://en.wikipedia.org/wiki/Web_server
웹 서버는 HTTP를 통해 처리 요청, 기본 네트워크 프로토콜은 월드 와이드 웹에 정보를 배포하는 데 사용하는 컴퓨터 시스템입니다. 이 용어는 전체 시스템 또는 HTTP 요청 을 승인하고 감독하는 소프트웨어를 의미 할 수 있습니다 .
에서 https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
응용 프로그램 서버는 웹 서버 (예 : Apache 또는 Microsoft 인터넷 정보 서비스 (IIS))와 SQL 데이터베이스 (예 : PostgreSQL, MySQL 또는 Oracle) 앞에서 실행됩니다.
웹 응용 프로그램 은 응용 프로그램 서버에서 실행되며 응용 프로그램 서버가 지원하는 언어로 작성되고 응용 프로그램 서버가 제공 하는 런타임 라이브러리 및 구성 요소를 호출하는 컴퓨터 코드입니다 .
응용 프로그램 서버와 웹 서버는 모두 웹 응용 프로그램을 호스팅하는 데 사용됩니다. 반면에 웹 서버는 웹 컨테이너를 처리합니다. Application Server는 웹 컨테이너뿐만 아니라 Microsoft dot Net 용 EJB (Enterprise JavaBean) 컨테이너 또는 COM + 컨테이너를 처리합니다.
Web Server는 HTML, 이미지 등과 같은 HTTP 정적 컨텐츠를 제공하도록 설계되었으며 동적 컨텐츠를 위해 Perl, PHP, ASP, JSP 등과 같은 스크립팅 언어를 지원하는 플러그인이 있으며 HTTP 프로토콜로 제한됩니다. 아래 서버는 동적 HTTP 컨텐츠를 생성 할 수 있습니다.
웹 서버의 프로그래밍 환경 :
IIS : ASP (.NET)
아파치 톰캣 : 서블릿
부두 : 서블릿
아파치 : Php, CGI
Application Server는 Web Server가 수행 할 수있는 모든 작업을 수행 할 수 있으며 프로토콜을 사용하여 수신 할 수 있으며 App Server에는 연결 풀링, 객체 풀링, 트랜잭션 지원, 메시징 서비스 등과 같은 응용 프로그램 수준 서비스를 지원하는 구성 요소와 기능이 있습니다.
응용 프로그램 서버의 프로그래밍 환경 :
MTS : COM +
WAS : EJB
JBoss : EJB
WebLogic 응용 프로그램 서버 : EJB
두 웹 서버 사이에 겹치는 부분이있을 수 있지만 (일부 웹 서버는 응용 프로그램 서버로 사용될 수도 있음) IMHO의 가장 큰 차이점은 처리 모델과 세션 관리에 있습니다.
웹 서버 처리 모델에서는 요청 처리에 중점을 둡니다. "세션"의 개념은 거의 가상입니다. 즉, "세션"은 클라이언트와 서버간에 상태 표현을 전송하고 (따라서 REST)이를 외부 영구 저장소 (SQL Server, Memcached 등)로 직렬화하여 시뮬레이션됩니다.
응용 프로그램 서버에서 세션은 일반적으로보다 명시 적이며 종종 "세션"전체 기간 동안 응용 프로그램 서버의 메모리에있는 개체 형태를 취합니다.
특정 아키텍처에 따라 다릅니다. 일부 응용 프로그램 서버는 기본적으로 웹 프로토콜 (XML / RPC / SOAP over HTTP)을 사용할 수 있으므로 기술적 차이가 거의 없습니다. 일반적으로 웹 서버는 HTTP / HTTPS를 통해 다양한 컨텐츠를 제공하는 사용자 대면 인터페이스이며, 응용 프로그램 서버는 사용자 대면 기능이 아니며 비표준 또는 라우팅 불가능한 프로토콜을 사용할 수 있습니다. 물론 RIA / AJAX를 사용하면 특정 원격 액세스 서비스를 펌핑하는 클라이언트에게 HTML 이외의 콘텐츠 (JSON / XML) 만 제공하여 차이를 더욱 흐리게 할 수 있습니다.
IMO는 주로 관심사 분리에 관한 것입니다.
순수한 기술적 관점에서 단일 웹 서버에서 모든 것을 수행 할 수 있습니다 (웹 컨텐츠 + 비즈니스 로직). 그렇게하면 정보가 요청 된 HTML 내용에 포함됩니다. 영향은 무엇입니까?
예를 들어, 브라우저에서 완전히 다른 HTML 컨텐츠를 렌더링하는 2 개의 서로 다른 앱이 있다고 가정하십시오. 비즈니스 로직을 앱 서버로 분리하려는 경우 스크립트를 통해 앱 서버에서 동일한 데이터를 찾는 다른 웹 서버를 제공 할 수 있습니다. 그러나 로직을 분리하지 않고 웹 서버에 보관하지 않으면 비즈니스 모델을 변경할 때마다 더 많은 시간이 걸리고 신뢰성이 떨어지며 웹 서버마다 변경됩니다. 발생하기 쉬운 오류.