애플리케이션 서버와 웹 서버의 차이점은 무엇입니까?
애플리케이션 서버와 웹 서버의 차이점은 무엇입니까?
대부분의 경우 이러한 용어 웹 서버와 응용 프로그램 서버는 같은 의미로 사용됩니다.
다음은 Web Server 및 Application Server 기능의 주요 차이점 중 일부입니다.
- 웹 서버는 HTTP 콘텐츠를 제공하도록 설계되었습니다. App Server는 HTTP 콘텐츠도 제공 할 수 있지만 HTTP에만 국한되지 않습니다. RMI / RPC와 같은 다른 프로토콜 지원을 제공 할 수 있습니다.
- 웹 서버는 대부분 정적 콘텐츠를 제공하도록 설계되었지만 대부분의 웹 서버에는 이러한 서버가 동적 HTTP 콘텐츠를 생성 할 수있는 Perl, PHP, ASP, JSP 등과 같은 스크립팅 언어를 지원하는 플러그인이 있습니다.
- 대부분의 애플리케이션 서버에는 웹 서버가 필수 부분으로 포함되어 있습니다. 즉, 앱 서버는 웹 서버가 할 수있는 모든 작업을 수행 할 수 있습니다. 또한 App Server에는 연결 풀링, 개체 풀링, 트랜잭션 지원, 메시징 서비스 등과 같은 애플리케이션 수준 서비스를 지원하는 구성 요소와 기능이 있습니다.
- 웹 서버는 정적 콘텐츠 및 동적 콘텐츠 용 앱 서버에 적합하기 때문에 대부분의 프로덕션 환경에는 앱 서버에 대한 역방향 프록시 역할을하는 웹 서버가 있습니다. 즉, 페이지 요청을 처리하는 동안 요청을 해석하는 웹 서버에서 정적 콘텐츠 (예 : 이미지 / 정적 HTML)를 제공합니다. 웹 서버는 일종의 필터링 기술 (대부분 요청 된 리소스의 확장)을 사용하여 동적 콘텐츠 요청을 식별하고 앱 서버로 투명하게 전달합니다.
이러한 구성의 예는 Apache Tomcat HTTP Server 및 Oracle (이전 BEA) WebLogic Server입니다. Apache Tomcat HTTP Server는 Web Server이고 Oracle WebLogic은 Application Server입니다.
어떤 경우에는 서버가 IIS 및 .NET Runtime과 같이 긴밀하게 통합되어 있습니다. IIS는 웹 서버입니다. .NET 런타임 환경을 갖춘 경우 IIS는 응용 프로그램 서비스를 제공 할 수 있습니다.
이것은 차이점, 유사성 및 둘 다 함께 작동하는 방법 및 모든 것을 명확하게 이해하기 위해 몇 가지 시나리오를 포함한 자세한 답변입니다.
Application Server 는 때때로 웹 서버 와 혼합되는 용어입니다 . 웹 서버는 주로 HTTP 프로토콜을 처리하지만 애플리케이션 서버는 HTTP를 포함하되 이에 국한되지 않는 여러 프로토콜 을 처리 합니다.
웹 서버의 주요 업무는 사이트 콘텐츠 를 표시하는 것이며 응용 프로그램 서버는 논리 , 사용자와 표시되는 콘텐츠 간의 상호 작용 을 담당 합니다. 애플리케이션 서버는 하나는 표시되고 다른 하나는 상호 작용하는 웹 서버 와 함께 작동 합니다.
서버와 클라이언트 사이를 오가는 정보는 단순한 표시 마크 업에 국한되지 않고 둘 사이의 상호 작용에 국한됩니다.
대부분의 경우 서버 는 J2EE (Java 2 Platform) , EJB (Enterprise JavaBean) 및 기타 다른 애플리케이션 소프트웨어 모델과 같은 컴포넌트 API를 통해이 상호 작용을 생성합니다 .
예 :
응용 프로그램 서버가 웹 서버와 함께 작동하는 시나리오와 응용 프로그램 서버가없는 시나리오의 차이점을 이해하는 가장 좋은 방법은 온라인 상점을 이용하는 것입니다.
시나리오 1 : 애플리케이션 서버가없는 웹 서버
웹 서버 만 있고 응용 프로그램 서버가없는 온라인 상점이 있습니다. 이 사이트는 제품을 선택할 수있는 디스플레이를 제공합니다. 쿼리를 제출하면 사이트에서 조회를 수행하고 HTML 결과를 클라이언트에 반환합니다. 웹 서버는 쿼리를 데이터베이스 서버로 직접 보내고 (인내심을 갖고 다음 너깃에서 설명하겠습니다) 응답을 기다립니다. 수신되면 웹 서버는 응답을 HTML 파일로 공식화하고 웹 브라우저로 보냅니다. 이 서버와 데이터베이스 서버 간의 양방향 통신은 쿼리가 실행될 때마다 발생합니다.
시나리오 2 : 애플리케이션 서버가있는 웹 서버
실행하려는 쿼리가 이전에 이미 수행되었고 그 이후로 데이터가 변경되지 않은 경우 서버는 데이터베이스 서버에 요청을 보내지 않고도 결과를 생성합니다. 이를 통해 두 번째 클라이언트가 데이터베이스 서버에 다른 중복 쿼리를 보내지 않고도 동일한 정보에 액세스하고 신뢰할 수있는 실시간 정보를 수신 할 수있는 실시간 쿼리가 가능합니다. 서버는 기본적으로 데이터베이스 서버와 웹 서버 사이의 중간 역할을합니다. 이렇게하면 첫 번째 시나리오에서 가져온 정보를 재사용 할 수 있습니다.이 정보는 특정 "사용자 정의 된"HTML 페이지에 포함되기 때문에 재사용 가능한 프로세스가 아닙니다. 두 번째 클라이언트는 정보를 다시 요청하고 요청 된 정보가 포함 된 다른 HTML 포함 페이지를 받아야합니다. 매우 비효율적입니다.
이러한 다양한 복잡한 작업을 지원하기 위해이 서버에는 실시간으로 가져 오는 모든 데이터를 처리 할 수있는 중복성, 뛰어난 처리 능력 및 많은 양의 RAM이 있어야합니다.
도움이 되었기를 바랍니다.
두 용어 모두 매우 일반적이며 하나는 다른 용어를 포함하고 경우에 따라 그 반대의 경우도 마찬가지입니다.
웹 서버 : http 프로토콜을 사용하여 웹에 콘텐츠를 제공합니다.
애플리케이션 서버 : 비즈니스 로직 및 프로세스를 호스팅하고 노출합니다.
핵심은 웹 서버가 http 프로토콜을 통해 모든 것을 노출하는 반면 애플리케이션 서버는 이에 제한되지 않는다는 것입니다.
즉, 많은 시나리오에서 웹 서버가 애플리케이션 서버의 프런트 엔드를 만드는 데 사용되고 있음을 알 수 있습니다. 응용 프로그램 서버.
Rutesh와 jmservera가 지적했듯이 구별은 모호합니다. 역사적으로 그것들은 달랐지만 90 년대에는 이전에 구별되었던이 두 범주가 기능을 혼합하고 효과적으로 병합했습니다. 이 시점에서 "앱 서버"제품 범주가 "웹 서버"범주의 엄격한 상위 집합이라고 상상하는 것이 가장 좋습니다.
약간의 역사. Mosaic 브라우저와 하이퍼 링크 콘텐츠의 초기에는 HTTP를 통해 웹 페이지 콘텐츠와 이미지를 제공하는 "웹 서버"라는 것이 진화했습니다. 대부분의 콘텐츠는 정적이었고 HTTP 1.0 프로토콜은 파일을 전달하는 방법에 불과했습니다. 신속하게 "웹 서버"범주는 CGI 기능을 포함하도록 발전하여 동적 콘텐츠를 생성하기 위해 각 웹 요청에 대해 프로세스를 효과적으로 시작했습니다. HTTP도 성숙 해졌고 캐싱, 보안 및 관리 기능을 통해 제품이 더욱 정교 해졌습니다. 기술이 발전함에 따라 Kiva 및 NetDynamics에서 회사 별 Java 기반 서버 측 기술을 얻었으며 결국 모두 JSP로 통합되었습니다. Microsoft는 1996 년에 Windows NT 4.0에 ASP를 추가했습니다. 정적 웹 서버는 몇 가지 새로운 트릭을 배웠으므로 효과적인 "앱 서버"였습니다.
병렬 범주에서 앱 서버는 오랫동안 진화하고 존재했습니다. 회사는 IMS 및 CICS와 같은 메인 프레임 애플리케이션 관리 및 모니터링 환경에서 철학적으로 파생 된 Tuxedo, TopEnd, Encina와 같은 Unix 용 제품을 제공했습니다. Microsoft의 제품은 나중에 COM +로 발전한 MTS (Microsoft Transaction Server)였습니다. 이러한 제품의 대부분은 "지방"클라이언트를 서버에 상호 연결하기 위해 "폐쇄"제품 별 통신 프로토콜을 지정했습니다. (Encina의 경우 통신 프로토콜은 DCE RPC, MTS의 경우 DCOM 등입니다.) 1995/96 년에 이러한 전통적인 앱 서버 제품은 처음에 게이트웨이를 통해 기본 HTTP 통신 기능을 내장하기 시작했습니다. 그리고 선이 흐려지기 시작했습니다.
웹 서버는 더 높은로드, 더 많은 동시성 및 더 나은 기능을 처리하는 측면에서 점점 더 성숙해졌습니다. 앱 서버는 점점 더 많은 HTTP 기반 통신 기능을 제공했습니다.
이 시점에서 "앱 서버"와 "웹 서버"사이의 경계는 모호합니다. 그러나 사람들은 강조의 문제로 용어를 계속 다르게 사용합니다. 누군가 "웹 서버"라고 말하면 종종 HTTP 중심의 웹 UI 지향 앱을 생각합니다. 누군가 "앱 서버"라고 말하면 "더 많은로드, 엔터프라이즈 기능, 트랜잭션 및 큐잉, 다중 채널 통신 (HTTP 등)"이라고 생각할 수 있습니다.하지만 두 가지 워크로드 요구 사항을 모두 충족하는 동일한 제품인 경우가 많습니다.
- WebSphere, IBM의 "앱 서버"에는 자체 번들 웹 서버가 있습니다.
- 또 다른 전통적인 앱 서버 인 WebLogic도 마찬가지입니다.
- Microsoft의 앱 서버 인 Windows (파일 및 인쇄 서버, 미디어 서버 등)는 IIS를 번들로 제공합니다.
웹 서버
http : // localhost : 8080python -m 'SimpleHTTPServer' 을 실행 하고 이동합니다 . 당신이 보는 것은 웹 서버가 작동하는 것입니다. 서버는 단순히 컴퓨터에 저장된 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) 등과 같은 엄격한 애플리케이션 서버도 있습니다.
실제로 애플리케이션 서버의 코드로 웹 서버를 구축 할 수 있습니다. 이것은 개발 중에 컴퓨터에서 실행되는 수많은 다른 서버를 원하지 않는 경우에 수행됩니다.
많은 사람들이 이전에 말했듯이 웹 서버는 HTTP 청원을 처리하고 애플리케이션 서버는 분산 구성 요소에 대한 청원을 처리합니다. 따라서 차이점을 이해하는 가장 쉬운 방법은 제공하는 프로그래밍 환경과 관련하여 두 제품을 비교하는 것입니다.
웹 서버-> 프로그래밍 환경
IIS : ASP (.NET)
Tomcat : 서블릿
부두 : 서블릿
Apache : Php, CGI
애플리케이션 서버-> 프로그래밍 환경
MTS : COM +
WAS : EJB
JBoss : EJB
WebLogic 애플리케이션 서버 : EJB
중요한 차이점은 응용 프로그램 서버가 일부 분산 구성 요소 기술을 지원 하여 Java 세계의 EJB 또는 Microsoft 플랫폼의 COM + 와 같은 원격 호출 및 분산 트랜잭션과 같은 기능을 제공한다는 것 입니다. Http 서버는 종종 좀 더 간단한 프로그래밍 환경을 지원합니다. 종종 스크립팅 (예 : Microsoft의 경우 ASP (.NET) 또는 Servlet 기반의 경우에는 JSP, Java의 경우에는 많은 다른 것, Apache의 경우 PHP의 경우에는 CGI)도 지원합니다.
로드 밸런싱, 클러스터링, 세션 페일 오버, 연결 풀링 등과 같은 다른 기능은 응용 프로그램 서버 영역에 있었지만 웹 서버에서도 직접 또는 일부 타사 제품을 통해 사용할 수 있습니다.
마지막으로, Spring Framework와 같은 "경량 컨테이너"로 인해 그림이 더욱 왜곡된다는 점에 주목할 필요가 있습니다. 이는 종종 애플리케이션 서버 인프라없이 더 간단한 방식으로 애플리케이션 서버의 목적을 보완합니다. 그리고 응용 프로그램의 배포 측면이 분산 구성 요소에서 서비스 패러다임 및 SOA 아키텍처로 이동하고 있기 때문에 기존 응용 프로그램 서버에 필요한 공간이 점점 줄어들고 있습니다.
웹 서버는 HTTP / HTTPS 요청을 독점적으로 처리합니다. HTTP / HTTPS 프로토콜을 사용하여 웹에 콘텐츠를 제공합니다.
애플리케이션 서버는 HTTP를 포함한 여러 프로토콜을 통해 애플리케이션 프로그램에 비즈니스 로직을 제공합니다. 애플리케이션 프로그램은 오브젝트에 대한 메소드를 호출하는 것처럼이 로직을 사용할 수 있습니다. 대부분의 경우 서버는 Java EE (Java Platform, Enterprise Edition) 애플리케이션 서버에있는 EJB (Enterprise JavaBean) 구성 요소 모델과 같은 구성 요소 API를 통해이 비즈니스 논리를 노출합니다. 요점은 웹 서버가 http 프로토콜을 통해 모든 것을 노출하지만 애플리케이션 서버는 이에 제한되지 않는다는 것입니다. 따라서 응용 프로그램 서버는 일반적으로 다음을 포함하는 웹 서버보다 훨씬 많은 서비스를 제공합니다.
- (독점 여부) API
- 부하 분산, 장애 조치 ...
- 개체 수명주기 관리
- 상태 관리 (세션)
- 리소스 관리 (예 : 데이터베이스에 대한 연결 풀)
대부분의 애플리케이션 서버에는 웹 서버가 필수적인 부분으로 포함되어 있습니다. 즉, 앱 서버는 웹 서버가 할 수있는 모든 작업을 수행 할 수 있습니다. 또한 App Server에는 연결 풀링, 개체 풀링, 트랜잭션 지원, 메시징 서비스 등과 같은 애플리케이션 수준 서비스를 지원하는 구성 요소와 기능이 있습니다.
응용 프로그램 서버는 웹 서버에서 실행되어 프로그램 논리를 실행할 수 있습니다 (항상 그런 것은 아님). 결과는 웹 서버에서 제공 할 수 있습니다. 이것이 웹 서버 / 애플리케이션 서버 시나리오의 한 예입니다. Microsoft 세계에서 좋은 예는 Internet Information Server / SharePoint Server 관계입니다. IIS는 웹 서버입니다. SharePoint는 응용 프로그램 서버입니다. SharePoint는 IIS의 "상위"에 있고 특정 논리를 실행하며 IIS를 통해 결과를 제공합니다. 예를 들어 Java 세계에는 Apache 및 Tomcat과 유사한 시나리오가 있습니다.
웹 서버는 정적 콘텐츠 및 동적 콘텐츠 용 앱 서버에 적합하기 때문에 대부분의 프로덕션 환경에는 앱 서버에 대한 역방향 프록시 역할을하는 웹 서버가 있습니다. 즉, 페이지 요청을 서비스하는 동안 이미지 / 정적 HTML과 같은 정적 콘텐츠는 요청을 해석하는 웹 서버에서 제공됩니다. 웹 서버는 일종의 필터링 기술 (대부분 요청 된 리소스의 확장)을 사용하여 동적 콘텐츠 요청을 식별하고 앱 서버에 투명하게 전달합니다.
이러한 구성의 예는 Apache HTTP Server 및 BEA WebLogic Server입니다. Apache HTTP Server는 Web Server이고 BEA WebLogic은 Application Server입니다. 경우에 따라 서버는 IIS 및 .NET Runtime과 같이 긴밀하게 통합됩니다. 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+
간단히 말해서 웹 서버 는 http를 통해 사용자에게 웹 페이지를 제공하는 서버입니다. 응용 프로그램 서버는 시스템에 대한 비즈니스 로직을 호스팅하는 서버입니다. 종종 장기 실행 / 배치 프로세스 및 / 또는 사람이 사용할 수없는 interop 서비스 (REST / JSON 서비스, SOAP, RPC 등)를 호스팅합니다.
웹 서버와 응용 프로그램 서버의 주요 차이점은 웹 서버는 HTML 및 CSS와 같은 정적 페이지를 제공하는 반면 Application Server는 JSP, Servlet 또는 EJB와 같은 서버 측 코드를 실행하여 동적 콘텐츠를 생성하는 역할을한다는 것입니다.
어느 것을 사용해야합니까?
웹과 애플리케이션 서버, 웹 컨테이너의 차이점을 알게되면 언제 사용할지 쉽게 알 수 있습니다. web server정적 웹 페이지를 제공하는 경우 유사한 Apache HTTPD 가 필요 합니다. JSP와 Servlet만으로 동적 콘텐츠를 생성하는 Java 애플리케이션이있는 경우 web containersTomcat 또는 Jetty와 같은 것이 필요합니다 . 반면 EJB, 분산 트랜잭션, 메시징 및 기타 멋진 기능을 사용하는 Java EE 애플리케이션이있는 경우application server JBoss, WebSphere 또는 Oracle의 WebLogic과 같은 완전한 기능 이 필요합니다 .
웹 컨테이너는 Web Server의 일부이고 Web Server는 Application Server의 일부입니다.
Web Server는 웹 컨테이너로 구성되고 Application Server는 웹 컨테이너와 EJB 컨테이너로 구성됩니다.
응용 프로그램 서버는 일반적으로 리소스 집약적 인 더 오래 실행되는 프로세스를 용이하게하도록 설계 및 배포됩니다.
웹 서버는 일반적으로 리소스 집약적이지 않은 짧은 버스트에 사용됩니다. 이것은 주로 웹 기반 트래픽을 제공하기위한 것입니다.
웹 서버는 HTTP 프로토콜을 실행하여 웹 페이지를 제공합니다. 응용 프로그램 서버는 웹 서버에서 실행되어 프로그램 로직을 실행할 수 있습니다 (항상 그런 것은 아님). 그 결과는 웹 서버에서 제공 할 수 있습니다. 이것이 웹 서버 / 애플리케이션 서버 시나리오의 한 예입니다.
Microsoft 세계에서 좋은 예는 Internet Information Server / SharePoint Server 관계입니다. IIS는 웹 서버입니다. SharePoint는 응용 프로그램 서버입니다. SharePoint는 IIS의 "상위"에 있고 특정 논리를 실행하며 IIS를 통해 결과를 제공합니다.
예를 들어 Java 세계에는 Apache 및 Tomcat과 유사한 시나리오가 있습니다.
Java 용어로는 웹 컨테이너 (또는 더 엄격하게는 서블릿 컨테이너) 가 하나 더 있습니다. 즉, 웹 서버와 애플리케이션 서버 사이에 있습니다. Java 용어로 웹 컨테이너는 기본적으로 Java EE의 JSP / Servlet 부분 만 구현하고 EJB 지원과 같은 Java EE의 몇 가지 핵심 부분이없는 애플리케이션 서버입니다 . 예를 들면 Apache Tomcat입니다.
먼저 웹 서버는 HTTP 프로토콜을 통해 웹 콘텐츠 (HTML 및 정적 콘텐츠)를 제공합니다. 반면에 애플리케이션 서버는 n 계층 아키텍처의 HTTP를 포함하여 다양한 프로토콜을 통해 클라이언트 애플리케이션에 비즈니스 로직과 프로세스를 구축하고 노출 할 수있는 컨테이너입니다.
따라서 응용 프로그램 서버는 일반적으로 다음을 포함하는 웹 서버보다 훨씬 많은 서비스를 제공합니다.
- (독점 여부) API
- 개체 수명주기 관리,
- 상태 관리 (세션),
- 리소스 관리 (예 : 데이터베이스에 대한 연결 풀),
- 부하 분산, 장애 조치 ...
AFAIK, ATG Dynamo 는 90 년대 후반 (위의 정의에 따라) 최초의 애플리케이션 서버 중 하나였습니다. 2000 년 초에는 ColdFusion (CFML AS), BroadVision (Server-side JavaScript AS) 등과 같은 일부 독점 응용 프로그램 서버가 통치했습니다 . 그러나 Java 응용 프로그램 서버 시대를 살아남은 것은 없었습니다.
이 둘 사이의 경계는 점점 더 얇아지고 있습니다.
애플리케이션 서버는 비즈니스 로직을 클라이언트에 노출합니다. 따라서 이와 유사한 애플리케이션 서버는 비즈니스 로직을 수행하기위한 일련의 메소드로 구성됩니다 (반드시 네트워크로 연결된 컴퓨터 일 수있어 많은 사람들이 소프트웨어를 실행할 수 있음). 따라서 HTML 콘텐츠가 아닌 원하는 결과를 출력합니다. (메서드 호출과 유사). 따라서 엄격하게 HTTP 기반이 아닙니다.
그러나 웹 서버는 HTML 콘텐츠를 웹 브라우저 (엄격히 HTTP 기반)로 전달합니다. 웹 서버는 정적 웹 리소스 만 처리 할 수 있었지만 서버 측 스크립팅의 출현으로 웹 서버는 동적 콘텐츠도 처리 할 수있었습니다. 웹 서버가 요청을 받아 스크립트 (PHP, JSP, CGI 스크립트 등)로 전달하여 클라이언트로 보낼 HTML 콘텐츠를 생성합니다. 그런 다음 웹 서버는 클라이언트로 다시 보내는 방법을 알고 있습니다. 그것이 웹 서버가 실제로 알고있는 것이기 때문입니다.
하지만 요즘 개발자들은이 두 가지를 함께 사용합니다. 웹 서버가 요청을받은 다음 HTML을 생성하기 위해 스크립트를 호출하는 경우, 스크립트는 HTML 콘텐츠를 채우기 위해 다시 애플리케이션 서버 LOGIC (예 : 트랜잭션 세부 정보 검색)를 호출합니다.
따라서이 경우 두 서버가 모두 효과적으로 사용되었습니다.
따라서 .... 우리는 오늘날 대부분의 경우 웹 서버가 애플리케이션 서버의 하위 집합으로 사용된다고 상당히 안전하게 말할 수 있습니다. 그러나 연극 적으로는 그렇지 않습니다.
나는이 주제에 대한 많은 기사를 읽고 발견 이 매우 편리 기사를.
응용 프로그램 서버는 클라이언트가 제공하는 서비스에 대한 요청을 "수신"(모든 채널에서 임의의 프로토콜 사용) 한 다음 해당 요청에 따라 작업을 수행하는 기계 (실제로는 일부 기계에서 실행되는 실행 프로세스)입니다. (클라이언트에 대한 휴식을 포함하거나 포함하지 않을 수 있음)
웹 서버는 특히 "인터넷"프로토콜 (http, https, ftp 등) 중 하나를 사용하여 TCP / IP 채널에서 "수신"하고 들어오는 요청에 따라 수행하는 작업을 수행하는 컴퓨터에서 실행되는 프로세스입니다. .. 일반적으로 (원래 정의 된대로), 서버의 정적 html 파일에서 가져 오거나 들어오는 클라이언트 요청의 매개 변수를 기반으로 동적으로 구성하여 html 웹 페이지를 가져 오거나 생성하여 클라이언트에 반환했습니다.
Biggest difference is a Web Server handles HTTP requests, while an Application server will execute business logic on any number of protocols.
All of the above is just over-complicating something very simple. An application server contains a web server, an application server just has a couple more additions/extensions to it than standard web servers. If you look at TomEE as an example:
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
You will see that Tomcat (Web container/server) is just another tool in the app servers arsenal. You can get JPA and the other tech in the web server as well if you want, but the application servers just package all of these things for your convenience. To be fully classified as an app server you essentially need to comply with a list of tools set forth by some standard.
Actually Apache is a web server and Tomcat is an application server. When as HTTP request comes to web server. Then static contents send back to browser by web server. Is there and logic do to done, then that request send to the application server. after processing the logic then response send to web server and send to the client.
There is not necessarily a clear dividing line. Nowadays, many programs combine elements of both - serving http requests (web server) and handling business logic (app server)
From https://en.wikipedia.org/wiki/Web_server
A web server is a computer system that processes requests via HTTP, the basic network protocol used to distribute information on the World Wide Web. The term can refer to the entire system, or specifically to the software that accepts and supervises the HTTP requests.
From https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
An application server runs behind a web Server (e.g. Apache or Microsoft Internet Information Services (IIS)) and (almost always) in front of an SQL database (e.g. PostgreSQL, MySQL, or Oracle).
Web applications are computer code which run atop application servers and are written in the language(s) the application server supports and call the runtime libraries and components the application server offers.
Application server and web server both are used to host web application. Web Server is deal with web container on the other hand Application Server is deal with web container as well as EJB (Enterprise JavaBean) container or COM+ container for Microsoft dot Net.
Web Server is designed to serve HTTP static Content like HTML, images etc. and for the dynamic content have plugins to support scripting languages like Perl, PHP, ASP, JSP etc and it is limited to HTTP protocol. Below servers can generate dynamic HTTP content.
Web Server's Programming Environment:
IIS : ASP (.NET)
Apache Tomcat: Servlet
Jetty: Servlet
Apache: Php, CGI
Application Server can do whatever Web Server is capable and listens using any protocol as well as App Server have components and features to support Application level services such as Connection Pooling, Object Pooling, Transaction Support, Messaging services etc.
Application Server's Programming Environment:
MTS: COM+
WAS: EJB
JBoss: EJB
WebLogic Application Server: EJB
Basic understanding :
In client server architecture
Server :> Which serves the requests.
Client :> Which consumes service.
Web server & Application server are both software applications which act as servers to their clients.
They got their names based on their place of utilization.
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.
Usage --
we require low processing rates, regular processing practices involves.Eg: All flat servers generally available ready-made which serves only web based content.
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.
Usage --
we require multi point processing, specialized processing techniques involves like for AI.Eg: Google maps servers, Google search servers,Google docs servers,Microsoft 365 servers,Microsoft computer vision servers for AI.
We can assume them as tiers/Hierarchies in 4-tier/n-tier architecture.
So they can provide
load balancing,
multiple security levels,
multiple active points,
even they can provide different request processing environments.
Please follow this link for standard architecture analogies:
https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658120(v%3dpandp.10)
While there may be overlaps between the two (some web servers may even be used as application servers) the biggest difference IMHO is in the processing model and the session management:
In Web server processing model, the focus is on handling requests; the notion of "session" is pretty much virtual. That is to say that "session" is simulated by transferring the representation of state between client and server (hence REST) and/or serializing it to an external persistent storage (SQL Server, Memcached etc).
In Application server the session is usually more explicit and often takes form of an object living in memory of the application server for the entire duration of the "session".
It depends on the specific architecture. Some application servers may use web protocols natively (XML/RPC/SOAP over HTTP), so there is little technical difference. Typically a web server is user-facing, serving a variety of content over HTTP/HTTPS, while an application server is not user-facing and may use non-standard or non-routable protocols. Of course with RIA/AJAX, the difference could be further clouded, serving only non-HTML content (JSON/XML) to clients pumping particular remote access services.
IMO, it's mostly about separating concerns.
From a purely technical point of view, you can do everything (web content + business logic) in a single web server. If you'd do that, then the information would be embedded inside requested the HTML content. What would be the impact?
예를 들어 브라우저에서 완전히 다른 HTML 콘텐츠를 렌더링하는 두 가지 앱이 있다고 가정 해 보겠습니다. 비즈니스 로직을 앱 서버로 분리하는 경우 스크립트를 통해 앱 서버에서 동일한 데이터를 검색하는 다른 웹 서버를 제공 할 수 있습니다. 그러나 논리를 분리하지 않고 웹 서버에 보관하지 않으면 비즈니스 모델을 변경할 때마다 더 많은 시간이 걸리고 안정성이 떨어지며 보유한 모든 단일 웹 서버에서 논리를 변경하게됩니다. 발생하기 쉬운 오류.
'Program Tip' 카테고리의 다른 글
| Java의 핵심 라이브러리에있는 GoF 디자인 패턴의 예 (0) | 2020.09.30 |
|---|---|
| 구현 vs 확장 : 언제 사용합니까? (0) | 2020.09.30 |
| not : 첫 번째 자식 선택기 (0) | 2020.09.29 |
| 신경망에서 편향의 역할 (0) | 2020.09.29 |
| 코드가있는 어셈블리의 경로를 어떻게 얻습니까? (0) | 2020.09.29 |