애플리케이션 서버와 웹 서버의 차이점은 무엇입니까?
대부분의 경우 이러한 용어는 웹 서버와 응용 프로그램 서버가 같은 의미로 사용됩니다.
다음은 Web Server 및 Application Server의 주요 차이점 중 일부입니다.
이러한 구성의 예로는 Apache Tomcat HTTP Server 및 Oracle (이전의 BEA) WebLogic Server가 있습니다. Apache Tomcat HTTP Server는 Web Server이고 Oracle WebLogic은 Application Server입니다.
어떤 경우에는 서버가 IIS 및 .NET 런타임과 같이 긴밀하게 통합됩니다. IIS는 웹 서버입니다. .NET 런타임 환경이 갖추어 진 경우 IIS는 응용 프로그램 서비스를 제공 할 수 있습니다.
두 용어는 매우 일반적인 것이고 다른 하나는 어떤 경우에는 그 반대입니다.
웹 서버: http 프로토콜을 사용하여 웹에 콘텐츠를 제공합니다.
응용 프로그램 서버: 비즈니스 로직 및 프로세스를 호스팅하고 노출합니다.
애플리케이션 서버는 웹 서버가 HTTP 프로토콜을 통해 모든 것을 노출한다는 점이 주요 포인트라고 생각합니다.
즉, 많은 시나리오에서 웹 서버가 응용 프로그램 서버의 프론트 엔드를 만드는 데 사용된다는 것을 알 수 있습니다. 즉, 사용자가 웹 서버에서 발견 한 비즈니스 규칙과 상호 작용할 수있는 웹 페이지 집합을 노출합니다. 응용 프로그램 서버.
이 차이점, 유사성 및 둘 모두가 함께 작동 할 수있는 방법을 명확하게 이해할 수있는 몇 가지 시나리오에 대한 자세한 대답입니다.
응용 프로그램 서버때로는웹 서버. 웹 서버가 주로 처리하는 동안HTTP 프로토콜, 응용 프로그램 서버는 다음과 같은 여러 가지 다른 프로토콜을 처리합니다.제한되지 않음, HTTP.
웹 서버의 주된 업무는 다음과 같습니다.사이트 내용 표시응용 프로그램 서버는 다음과 같습니다.논리 담당, 사용자와 표시된 콘텐츠 간의 상호 작용 응용 프로그램 서버는 다음과 같습니다.함께 일하는하나는 표시되고 다른 하나는 상호 작용하는 웹 서버와 연결됩니다.
서버와 클라이언트간에 앞뒤로 이동하는 정보는 단순한 표시 마크 업에만 국한되지 않고 둘 사이의 상호 작용에만 국한됩니다.
대부분의 경우 서버가구성 요소 API를 통한 상호 작용,와 같은J2EE(Java 2 플랫폼),EJB(Enterprise JavaBean)및 다른 다른 응용 소프트웨어 모델을 포함한다.
예 :
응용 프로그램 서버가 웹 서버와 작동하는 시나리오 대 응용 프로그램 서버가없는 시나리오의 차이를 이해하는 가장 좋은 방법은 온라인 상점을 이용하는 것입니다.
시나리오 1 : 응용 프로그램 서버가없는 웹 서버
웹 서버 만 있고 응용 프로그램 서버가없는 온라인 상점이 있습니다. 이 사이트는 제품을 선택할 수있는 디스플레이를 제공합니다. 쿼리를 제출하면 사이트에서 조회를 수행하고 HTML 결과를 클라이언트에 반환합니다. 웹 서버는 귀하의 질의를 데이터베이스 서버에 직접 보내고 (다음 번 너겟에서 설명 할 것입니다.) 응답을 기다립니다. 수신 된 웹 서버는 응답을 HTML 파일로 공식화하여 웹 브라우저로 보냅니다. 서버와 데이터베이스 서버 간의 앞뒤 통신은 쿼리가 실행될 때마다 발생합니다.
시나리오 2 : 응용 프로그램 서버가있는 웹 서버
실행하려는 쿼리가 이미 완료되었지만 그 이후로 데이터가 변경되지 않은 경우 서버는 데이터베이스 서버에 요청을 보낼 필요없이 결과를 생성합니다. 이를 통해 두 x 째 클라이언트가 동일한 정보에 액세스 할 수 있고 또 다른 중복 조회를 데이터베이스 서 v에 보내지 않고도 실시간의 신뢰할 수있는 정보를 수신 할 수있는 실시간 조회가 가능합니다. 서버는 기본적으로 데이터베이스 서버와 웹 서버 간의 중간 역할을합니다. 이렇게하면 첫 번째 시나리오에서 가져온 정보를 재사용 할 수 있습니다.이 정보는 특정 "사용자 정의 된"HTML 페이지에 포함되어 있기 때문에 재사용이 가능하지 않습니다. 두 번째 클라이언트는 정보를 다시 요청하고 요청 된 정보가 포함 된 다른 HTML 포함 페이지를 수신해야합니다. 매우 비효율적입니다. 이 유형의 서버는 보안, 트랜잭션 처리, 메시징 및 자원 풀링을 포함하여 자체 자원을 관리 할 수있는 기능이있어서 매우 유연합니다.
이러한 다양한 복잡한 작업을 지원하기 위해이 서버는 리던던시, 우수한 처리 성능 및 많은 양의 RAM을 내장하여 실시간으로 가져 오는 모든 데이터를 처리해야합니다.
희망이 도움이됩니다.
the application server deals with several different protocols, including, but not limited, to HTTP
< - http 요청을 확실히 처리한다고 - 정확하지 않습니다. - AD7six
Rutesh와 jmservera가 지적했듯이 구별은 애매한 것입니다. 역사적으로, 그들은 달랐지 만 90 년대에이 두 가지 이전에 별개의 범주는 기능을 혼합하고 효과적으로 병합했습니다. 이 시점에서 "App Server"제품 카테고리가 "웹 서버"카테고리의 엄격한 수퍼 세트라고 상상하는 것이 가장 좋습니다.
일부 역사. 초기에 Mosaic 브라우저와 하이퍼 링크 된 컨텐트에서는 HTTP를 통해 웹 페이지 컨텐트와 이미지를 제공하는 "웹 서버"라는이 제품이 발전했습니다. 대부분의 콘텐츠는 정적이었고 HTTP 1.0 프로토콜은 파일을 전달하는 방법이었습니다. 빠르게 "웹 서버"범주는 CGI 기능을 포함하도록 발전하여 동적 요청을 생성하기 위해 각 웹 요청에 대한 프로세스를 효과적으로 실행합니다. HTTP는 성숙되었고 제품은 캐싱, 보안 및 관리 기능을 통해 더욱 정교 해졌습니다. 기술이 성숙 해짐에 따라 Kiva와 NetDynamics에서 제공하는 회사 별 Java 기반 서버 측 기술을 사용하게되었습니다. 결국이 기술은 모두 JSP로 병합되었습니다. MS는 1996 년에 Windows NT 4.0으로 ASP를 추가했다. 정적 웹 서버는 새로운 트릭을 배웠기 때문에 많은 시나리오에서 효과적인 "응용 프로그램 서버"였습니다.
병렬 카테고리에서 앱 서버는 오랜 시간 동안 진화하여 존재 해왔다. 회사는 IMS 및 CICS와 같은 메인 프레임 응용 프로그램 관리 및 모니터링 환경에서 철학적으로 파생 된 Tuxedo, TopEnd, Encina와 같은 Unix 용 제품을 제공했습니다. Microsoft의 서비스는 MTS (Microsoft Transaction Server)였습니다. 나중에 MTS가 COM +로 발전했습니다. 이들 제품의 대부분은 "뚱뚱한"클라이언트를 서버에 연결하기 위해 "닫힌"제품 별 통신 프로토콜을 지정했습니다. (Encina의 경우 통신 프로토콜은 DCE RPC이고, MTS의 경우 DCOM이었습니다.) 1995/96에서 이러한 전통적인 응용 프로그램 서버 제품은 처음에는 게이트웨이를 통해 기본 HTTP 통신 기능을 내장하기 시작했습니다. 그리고 선들이 흐려지기 시작했습니다.
웹 서버는 더 높은로드,보다 많은 동시성 및 더 나은 기능을 처리하는 것과 관련하여 점점 성숙 해졌습니다. 앱 서버는 점점 더 많은 HTTP 기반 통신 기능을 제공했습니다.
이 시점에서 "app server"와 "web server"사이의 줄은 퍼지 (fuzzy)입니다. 그러나 사람들은 강조의 문제로서 용어를 계속해서 다르게 사용합니다. 누군가가 "웹 서버"라고 말하면 HTTP 중심의 웹 UI, 지향적 인 응용 프로그램을 자주 생각합니다. 누군가가 "앱 서버"라고 말하면 "부하, 엔터프라이즈 기능, 트랜잭션 및 대기열, 다중 채널 통신 (HTTP + 이상)"이 더 중요하다고 생각할 수 있습니다. 그러나 종종 두 가지 작업 부하 요구 사항을 처리하는 동일한 제품입니다.
웹 서버
운영python -m 'SimpleHTTPServer'
가서http://localhost:8080. 보시다시피 웹 서버가 작동합니다. 서버는 컴퓨터에 저장된 HTTP를 통해 파일을 제공하기 만합니다. 요점은이 모든 것이 HTTP 프로토콜에서 수행된다는 것입니다. 또한 예를 들어 저장된 파일을 제공하는 것과 똑같은 일을하지만 다른 프로토콜 위에 FTP 서버가 있습니다.
응용 프로그램 서버
아래처럼 작은 애플리케이션이 있다고 가정 해 보겠습니다.플라스크).
@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()
.
이 코드를 실행하려면 클라이언트에서 요청을 수신하고 코드를 사용하여 동적으로 반환 할 수있는 프로그램 또는 모듈 인 응용 프로그램 서버가 필요합니다. 이 예제에서 우리는 매우 나쁜 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
중요한 차이점은 애플리케이션 서버가분산 된 구성 요소원격 호출 및 분산 트랜잭션과 같은 기능을 제공하는 기술EJBJava 세계 또는COM +Microsoft 플랫폼. HTTP 서버는 종종 마이크로 소프트 또는 서블릿 기반의 ASP (.NET)와 같은 스크립팅, 자바와 PHP의 경우 JSP 및 아파치의 경우 CGI를 비롯한 스크립팅과 같은 더 간단한 프로그래밍 환경을 지원합니다.
이전에는 애플리케이션 서버 영역에 있었던로드 밸런싱, 클러스터링, 세션 페일 오버, 커넥션 풀링 등과 같은 다른 기능들이 웹 서버에서도 직접 또는 타사 제품을 통해 제공되고 있습니다.
끝으로, Spring Framework와 같은 "경량 컨테이너"를 사용하면 그림이 더 왜곡되므로 애플리케이션 서버의 목적을 보완하는보다 간단한 방법으로 애플리케이션 서버 인프라를 사용하지 않아도됩니다. 또한 애플리케이션의 배포 측면이 분산 패러다임에서 SOA 패러다임으로 옮겨 가고 있기 때문에 기존 애플리케이션 서버의 공간은 점차 줄어들고 있습니다.
웹 서버는 HTTP / HTTPS 요청을 독점적으로 처리합니다. HTTP / HTTPS 프로토콜을 사용하여 웹에 컨텐츠를 제공합니다.
응용 프로그램 서버는 HTTP를 포함하여 여러 프로토콜을 통해 비즈니스 논리를 응용 프로그램에 제공합니다. 응용 프로그램은 객체에 대한 메소드를 호출하는 것처럼이 논리를 사용할 수 있습니다. 대부분의 경우 서버는 Java EE (Java Platform, Enterprise Edition) 응용 프로그램 서버에있는 EJB (Enterprise JavaBean) 구성 요소 모델과 같은 구성 요소 API를 통해이 비즈니스 논리를 노출합니다. 요점은 웹 서버가 http 프로토콜을 통해 모든 것을 노출하는 반면 애플리케이션 서버는 이에 제한되지 않는다는 점입니다. 따라서 응용 프로그램 서버는 일반적으로 다음을 포함하는 웹 서버보다 훨씬 많은 서비스를 제공합니다.
대부분의 응용 프로그램 서버에는 웹 서버가 통합되어있어 응용 프로그램 서버가 웹 서버에서 가능한 모든 기능을 수행 할 수 있습니다. 또한 App Server에는 연결 풀링, 객체 풀링, 트랜잭션 지원, 메시징 서비스 등과 같은 응용 프로그램 수준 서비스를 지원하는 구성 요소 및 기능이 있습니다.
응용 프로그램 서버는 웹 서버에서 실행될 수 있지만 (항상 그런 것은 아닙니다) 프로그램 논리를 실행하고 그 결과는 웹 서버에서 전달할 수 있습니다. 이것이 웹 서버 / 애플리케이션 서버 시나리오의 한 예입니다. 마이크로 소프트 세계의 좋은 예가 Internet Information Server / SharePoint Server 관계입니다. IIS는 웹 서버입니다. SharePoint는 응용 프로그램 서버입니다. SharePoint는 IIS의 "상단"에 위치하여 특정 논리를 실행하고 IIS를 통해 결과를 제공합니다. 자바 세계에서는 아파치와 톰캣과 비슷한 시나리오가있다.
웹 서버는 동적 콘텐트를위한 정적 콘텐트와 응용 프로그램 서버에 매우 적합하기 때문에 대부분의 프로덕션 환경에는 응용 프로그램 서버에 대한 역방향 프록시 역할을하는 웹 서버가 있습니다. 즉, 페이지 요청을 처리하는 동안 이미지 / 정적 HTML과 같은 정적 컨텐츠가 요청을 해석하는 웹 서버에 의해 제공됩니다. 어떤 종류의 필터링 기술 (주로 요청 된 리소스의 확장)을 사용하여 웹 서버는 동적 콘텐츠 요청을 식별하고 앱 서버로 투명하게 전달합니다.
그러한 구성의 예로 Apache HTTP Server 및 BEA WebLogic Server가 있습니다. Apache HTTP Server는 Web 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+
짧게웹 서버http를 통해 사용자에게 웹 페이지를 제공하는 서버입니다. 안애플리케이션 서버는 시스템의 비즈니스 로직을 호스팅하는 서버입니다. 그것은 종종 장기 실행 / 배치 프로세스 및 / 또는 사람이 소비하지 않는 interop 서비스 (REST / JSON 서비스, SOAP, RPC 등)를 호스트합니다.
웹 서버와 응용 프로그램 서버 간의 주요 차이점은 웹 서버가 정적 페이지를 제공한다는 것입니다. HTML 및 CSS, Application Server는 서버 사이드 코드를 실행하여 동적 컨텐츠를 생성합니다. JSP, Servlet 또는 EJB.
어느 것을 사용해야합니까?
웹 서버와 응용 프로그램 서버 및 웹 컨테이너의 차이점을 알게되면이를 언제 사용하는지 파악하기 쉽습니다.
당신은web server
정적 웹 페이지를 제공하는 경우 Apache HTTPD와 유사합니다. 동적 컨텐트를 생성하는 JSP와 Servlet을 가진 자바 애플리케이션을 가지고 있다면web containers
톰캣이나 부두처럼. 동안,EJB, 분산 트랜잭션, 메시징 및 기타 고급 기능을 사용하는 Java EE 응용 프로그램이있는 경우너보다 완전한 본격적인application server
JBoss, WebSphere 또는 오라클의 WebLogic과 유사합니다.
웹 컨테이너는 Web Server의 일부이며 Web Server는 Application Server의 일부입니다.
웹 서버는 웹 컨테이너로 구성되며, Application Server는 웹 컨테이너와 EJB 컨테이너로 구성됩니다.
응용 프로그램 서버는 일반적으로 자원 집약적 인 장기 실행 프로세스를 용이하게하기 위해 설계 및 배포됩니다.
웹 서버는 자원 집약적이지 않은 짧은 버스트에 일반적으로 사용됩니다. 이것은 주로 웹 기반 트래픽 제공을 용이하게하기위한 것입니다.
웹 서버는 HTTP 프로토콜을 실행하여 웹 페이지를 제공합니다. 응용 프로그램 서버는 웹 서버에서 실행될 수 있지만 (항상 그런 것은 아닙니다) 프로그램 논리를 실행하고 그 결과는 웹 서버에서 전달할 수 있습니다. 이것이 웹 서버 / 애플리케이션 서버 시나리오의 한 예입니다.
마이크로 소프트 세계의 좋은 예가 Internet Information Server / SharePoint Server 관계입니다. IIS는 웹 서버입니다. SharePoint는 응용 프로그램 서버입니다. SharePoint는 IIS의 "상단"에 위치하여 특정 논리를 실행하고 IIS를 통해 결과를 제공합니다.
자바 세계에서는 아파치와 톰캣과 비슷한 시나리오가있다.
처음에는 웹 서버가 HTTP 프로토콜을 통해 웹 컨텐트 (HTML 및 정적 컨텐트)를 제공합니다. 반면에 애플리케이션 서버는 n 계층 아키텍처의 HTTP를 비롯한 다양한 프로토콜을 통해 비즈니스 로직 및 프로세스를 구축하고 클라이언트 애플리케이션에 공개 할 수있는 컨테이너입니다.
따라서 응용 프로그램 서버는 일반적으로 다음을 포함하는 웹 서버보다 훨씬 많은 서비스를 제공합니다.
, AFAIKATG 디나모90 년대 후반에 처음으로 응용 프로그램 서버 중 하나였습니다 (위의 정의에 따라). 2000 년 초, 일부 독점적 애플리케이션 서버의 통치였습니다.ColdFusion(CFML AS),BroadVision(Server-side JavaScript AS), 등등. 그러나 아무도는 정말로 자바 어플리케이션 서버 시대에서 살아남지 못했습니다.
이 둘 사이의 국경이 점점 더 얇아지고 있습니다.
응용 프로그램 서버는 비즈니스 논리를 클라이언트에 표시합니다. 그래서 그것과 비슷한 어플리케이션 서버는 일련의 메소드들로 구성되어 있습니다. (반드시 그런 것은 아니지만 네트워크화 된 컴퓨터로도 소프트웨어를 실행할 수 있습니다) 비즈니스 로직을 수행 할 수 있습니다. 따라서 HTML 컨텐트가 아닌 원하는 결과 만 출력합니다. (메소드 호출과 유사). 따라서 엄격하게 HTTP 기반이 아닙니다.
그러나 웹 서버는 HTML 콘텐츠를 웹 브라우저에 전달합니다 (엄밀히 말하자면 HTTP 기반). 웹 서버는 정적 웹 자원 만 처리 할 수 있었지만 서버 측 스크립팅의 등장으로 웹 서버는 동적 내용도 처리 할 수있었습니다. 웹 서버가 요청을 가져 와서 스크립트 (PHP, JSP, CGI 스크립트 등)로 보내 클라이언트에 보낼 HTML 컨텐트를 만듭니다. 그런 다음 웹 서버는 클라이언트로 다시 보내는 방법을 알고 있습니다. 그것이 바로 웹 서버가 실제로 알고있는 것이기 때문입니다.
그런데 요즘 개발자들은이 두 가지를 함께 사용합니다. 웹 서버가 요청을 수락 한 다음 스크립트를 호출하여 HTML을 생성하면 BUT 스크립트는 응용 프로그램 서버 LOGIC (예 : 거래 세부 정보 검색)을 다시 호출하여 HTML 콘텐츠를 채 웁니다.
따라서이 경우 두 서버가 효과적으로 사용되었습니다.
따라서 .... 우리는 오늘날 대부분의 경우 웹 서버가 응용 프로그램 서버의 하위 집합으로 사용된다고 상당히 안전하게 말할 수 있습니다. 하지만 극장에서는 그렇지 않습니다.
나는이 화제에 관하여 많은 기사를 읽고 찾아 냈다이아주 편리한 기사.
Java 용어에는 하나 더 있습니다 :웹 컨테이너(또는보다 엄격하게 서블릿 컨테이너). 웹 서버와 응용 프로그램 서버 사이에 있습니다. Java 용어로 된 웹 컨테이너는 기본적으로만Java EE의 JSP / Servlet 부분을 구현하며 EJB 지원과 같은 Java EE의 핵심 부분이 부족합니다. 한 예로 Apache Tomcat이 있습니다.
응용 프로그램 서버는 클라이언트가 제공하는 서비스에 대한 요청에 대해 모든 프로토콜을 사용하여 모든 채널에서 "수신 대기"하는 시스템 (실제로는 일부 시스템에서 실행되는 실행 가능한 프로세스)이며 이러한 요청을 기반으로 작업을 수행합니다. (클라이언트에 대한 응답을 포함 할 수도 있고 포함하지 않을 수도 있음)
웹 서버는 "인터넷"프로토콜 (http, https, ftp 등) 중 하나를 사용하여 TCP / IP 채널을 "수신 대기"하는 시스템에서 실행되는 프로세스로 수신 요청을 기반으로 수행합니다. 일반적으로 (원래 정의 된대로) 서버에서 정적 HTML 파일에서 가져온 html 웹 페이지를 가져 오거나 생성 한 다음 클라이언트로 보내거나 들어오는 클라이언트 요청의 매개 변수를 기반으로 동적으로 생성합니다.
위의 모든 것은 매우 단순한 것보다 과잉 복잡합니다. 응용 프로그램 서버에는 웹 서버가 있고 응용 프로그램 서버에는 표준 웹 서버보다 몇 가지 추가 / 확장이 있습니다. 예를 들어 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와 다른 기술을 웹 서버에서도 사용할 수 있지만 응용 프로그램 서버는 사용자 편의를 위해 이러한 모든 것을 패키지로 제공합니다. 앱 서버로 완전히 분류되기 위해서는 몇 가지 표준에 의해 설정된 도구 목록을 준수해야합니다.
가장 큰 차이점은 웹 서버가 HTTP 요청을 처리하는 반면 응용 프로그램 서버는 여러 프로토콜에서 비즈니스 논리를 실행한다는 것입니다.
반드시 분명한 경계선이있는 것은 아닙니다. 요즘에는 많은 프로그램이 HTTP 요청 (웹 서버) 처리 및 비즈니스 논리 처리 (응용 프로그램 서버)
실제로 Apache는 웹 서버이고 Tomcat은 응용 프로그램 서버입니다. HTTP 요청이 웹 서버로 오면. 그런 다음 정적 컨텐츠는 웹 서버에 의해 브라우저로 다시 전송됩니다. 거기에 논리가 끝나면 요청이 응용 프로그램 서버로 전송됩니다. 로직을 처리 한 후 응답이 웹 서버로 전송되어 클라이언트로 전송됩니다.
응용 프로그램 서버와 웹 서버는 모두 웹 응용 프로그램을 호스팅하는 데 사용됩니다. 웹 서버는 웹 컨테이너를 처리하는 반면 Application Server는 웹 컨테이너뿐만 아니라 Microsoft 닷넷 용 EJB (Enterprise JavaBean) 컨테이너 또는 COM + 컨테이너를 처리합니다.
Web Server는 HTML, 이미지 등의 HTTP 정적 컨텐츠를 제공하도록 설계되었으며 동적 컨텐츠에는 Perl, PHP, ASP, JSP 등의 스크립트 언어를 지원하는 플러그인이 있으며 HTTP 프로토콜로 제한됩니다. 서버 아래에서는 동적 HTTP 콘텐츠를 생성 할 수 있습니다.
웹 서버의 프로그래밍 환경 :
IIS, ASP (.NET)
Apache Tomcat : 서블릿
부두 : 서블릿
Apache : PHP, CGI
Application Server는 Web Server가 모든 기능을 수행 할 수 있으며 모든 프로토콜을 사용하여 수신 대기하고 App Server는 연결 풀링, 객체 풀링, 트랜잭션 지원, 메시징 서비스 등과 같은 응용 프로그램 수준 서비스를 지원하는 구성 요소 및 기능을 제공합니다.
응용 프로그램 서버의 프로그래밍 환경 :
MTS : COM +
WAS : EJB
JBoss : EJB
WebLogic 응용 프로그램 서버 : EJB
둘 사이에 중복이있을 수 있지만 (일부 웹 서버는 응용 프로그램 서버로 사용될 수도 있음) IMHO가 처리 모델 및 세션 관리에서 갖는 가장 큰 차이점은 다음과 같습니다.
웹 서버 처리 모델에서는 요청 처리에 중점을 둡니다. "세션"의 개념은 거의 가상입니다. 즉, "세션"은 클라이언트와 서버 (따라서 REST) 사이의 상태 표현을 전송하고 / 또는 외부 영구 저장소 (SQL Server, Memcached 등)로 직렬화하여 시뮬레이션합니다.
응용 프로그램 서버에서 세션은 일반적으로 더 명확하며 종종 "세션"의 전체 기간 동안 응용 프로그램 서버의 메모리에있는 개체의 형태를 취합니다.
에서https://en.wikipedia.org/wiki/Web_server
에이웹 서버World Wide Web에서 정보를 배포하는 데 사용되는 기본 네트워크 프로토콜 인 HTTP를 통해 요청을 처리하는 컴퓨터 시스템입니다. 이 용어는 전체 시스템을 의미 할 수 있습니다.HTTP 요청을 받아들이고 감독합니다..
에서https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
응용 프로그램 서버가 웹 서버에서 실행됩니다.(예 : Apache 또는 Microsoft 인터넷 정보 서비스 (IIS)) 및 (거의 항상) SQL 데이터베이스 (예 : PostgreSQL, MySQL 또는 Oracle) 앞에 표시됩니다.
웹 응용 프로그램응용 프로그램 서버에서 실행되며 응용 프로그램 서버가 지원하는 언어로 작성되고 런타임 라이브러리 및 구성 요소를 호출하는 컴퓨터 코드입니다.애플리케이션 서버 오퍼.
특정 아키텍처에 따라 다릅니다. 일부 응용 프로그램 서버는 기본적으로 웹 프로토콜 (HTTP를 통한 XML / RPC / SOAP)을 사용할 수 있으므로 약간의 기술적 차이가 있습니다. 일반적으로 웹 서버는 사용자 지향적이며 HTTP / HTTPS를 통해 다양한 컨텐츠를 제공하지만 응용 프로그램 서버는 사용자 지향적이지 않고 비표준 또는 라우팅 불가능한 프로토콜을 사용할 수 있습니다. 물론 RIA / AJAX를 사용하면 특정 원격 액세스 서비스를 실행하는 클라이언트에게 HTML 이외의 컨텐트 (JSON / XML) 만 제공하여 차이가 더 커질 수 있습니다.
IMO, 그것은 주로 우려를 분리하는 것입니다.
순전히 기술적 인 관점에서 볼 때 단일 웹 서버에서 모든 것을 (웹 컨텐츠 + 비즈니스 로직) 할 수 있습니다. 그렇게한다면 정보는 요청 된 HTML 내용에 내장됩니다. 그 영향은 무엇인가?
예를 들어, 완전히 다른 HTML 콘텐츠를 브라우저에 렌더링하는 두 가지 앱이 있다고 가정 해 보겠습니다. 비즈니스 로직을 app-server로 분리한다면 스크립트를 통해 app-server에서 동일한 데이터를 찾는 다른 웹 서버를 제공 할 수 있습니다. 그러나 로직을 분리하여 웹 서버에 보관하지 않으면 비즈니스 모델을 변경할 때마다 더 많은 시간이 걸리며 신뢰성이 떨어지고 모든 웹 서버에서 변경해야합니다. 발생하기 쉬운 오류.