(참조:https://ninetynine-2026.tistory.com/458)
( :https://hyoje420.tistory.com/25)
웹의 전반적인 구조는 클라이언트가 서버에게 요청한 페이지를 서버에서 잘 가공하여 다시 클라이언트에게 응답하는 구조.
어느 측에서 요청을 처리하느냐에 따라서 client side script 언어와 server side script 언어로 나뉜다. 여기서 server side sript 언어인 JSP, ASP, PHP, Python
JSP(Java Server Page)
:플랫폼 독립성의 성질을 그대로 가져간다. 확장자는 .jsp 서버사이드에서 실행 가능한 자바 파일을 Java Servlet이라고 한다. 실행시 javax.servlet.http.HttpServlet 클래스를 상속받은 자바 소스코드로 변환되어 컴파일 된 후 실행된다. 따라서 .jsp 파일을 클래스로 변환시켜서 컴파일 후 실행시키는 과정을 하는 프로그램이 Java Servlet Container이다.
: JSP는 객체지향적 특성을 가지고 있다. 이미 존재하는 자바의 API도 사용가능하다. 대표적으로 톰캣이라는 WAS 환경이 존재하고 Spring이란 프레임워크가 주축으로 존재하고 있다.
WEB vs WAS
: 클라이언트가 서버에게 어떤 페이지를 요청하고 서버는 그 페이지를 클라이언트에게 전송해준다. 이때 전송하는 페이지는 크게 두 종류가 있는데
1. 정적페이지 ==> HTML, CSS, 이미지 같이 어떤 클라이언트에서 요청해도 동일한 결과를 보여주는 페이지
2. 동적 페이지 ==> PHP 파일, JSP 파일이 대표적으로 존재하며 일정한 데이터의 처리가 필요한 페이지이다. DB에 저장된 특정한 정보를 가져와서 동적으로 생성된 페이지를 말한다.
그래서 등장한게 이건데
웹서버(Web Server)
클라이언트 요청에 정적 컨텐츠들을 HTTP 프로토콜을 이용하여 제공해주는 서버를 뜻한다. 클라이언트의 요청이 동적인 페이지를 요구한다면 그것을 처리할 수 있는 컨테이너 로 전달해준다.
대표는 Apache HTTP server, IIS가 있다.
컨테이너
동적인ㄷ ㅔ이터들을 처리하여 정적인 페이지로 생성시켜주는 SW 모듈. Web container,Servlet container라고도 부른다. PHP, JSP, ASP 등의 요청은 웹서버에서는 처리할 수 없는 형태의 파일이므로 이를 서버로부터 전달받아서 처리된 결과를 다시 웹서버로 전달하는 역할을 한다. (서블렛이란 웹페이지를 동적으로 생성해주는 SW이다. 컨테이너와 동일한 개념)
WAS
Web Applicaiton Server 웹서버로부터 오는 동적인 요청을 처리할 수 있는 서버. 클라이언트에서 .php파일이나 .jsp 파일 등을 요청하게 되면 DB에 접근하여 데이터를 가져와야하는 동적인 처리가 필요하게 된다. 따라서 이런 것들을 처리하여 정적인 HTML 페이지를 생성하고 클라이언트에게 응답하는 역할을 한다. 웹서버의 기능을 WAS에 포함하고 있다고 한다. WAS = Web Server + Container. 대표적ㅇ로는 자바 서블릿 지닌 Apache Tomcat, php 기반 php-fpm.
굳이 웹서버를 두는 이유?
1. WAS를 설치하면 거기서 처리할 수 있는 언어가 한정되어있다.
서버에 아파치 톰캣만 설치했다고 가정하면, 이 웹서버는 오로지 자바 서블릿을 통한 jsp만을 처리할 수 있을 것인데, 서버에서는 때에 따라서 다양한 언어를 사용해야한다. 이 웹서버에서는 다른 언어인 PHP를 처리할 수 없다. 따라서 이런 경우에는 웹서버(아파치)를 두고 PHP를 처리할 수 있는 컨테이너를 설치하여 클라이언트로부터 들어온 요청이 어느 것인가에 따라서 처리하는 컨테이너를 다르게 지정해줄 필요가 있다.
- 로드밸런싱으로 부하를 분산한다.
로드밸런싱이라는 기술은 서버로 들어오는 여러 클라이언트들의요청을 동일한 서비스가 설치된 서버가 나누어서 처리하는 기술. 이 기술을 사용할 때 각 요청을 분산시켜주는 서버를 앞에 하나 두게 된다. 이 서버는 요청 들어오면 여러개의 서버 중 어느 서버로 연결해줄 것인지 결정해주는역할만 하기 때문에 컨테이너가 필요 없다. 따라서 웹서버만 설치하여 정적 데이터만 처리하도록 하면 충분하다.
ASP(Active Server Page)
윈도우에 최적화. visual Basic과 JB Script로 만들어져있다. Java보다는 컴파일 속도가 빠름. 유지 보수에 강점을 둔다. 하나의 프로젝트에서 여러 언어를 동시에 지원한다. 대표적으로 IIS라는 WAS 환경에서 구동되며 ASP.NET이라는 주요 프레임워크가 존재한다.
PHP(Hypertext PreProcessor)
오픈소스여서 비용 발생 아난다.특별한 모듈 설치 필요 없고 주요 OS와의 연동이 원활하게 이루어진다. 유지보수가 어렵대(클래스 설계가 사실상 어려운 구조로 되어있어서) 대부분 아파치 서버에 설치하여 사용하는 경우가 많다. WAS는 php-fpm이 사용된다.
(참조:https://hyoje420.tistory.com/25)
WSGI
HW적, SW적 의미를 함께 가지고 있다. SW적 의미만 알아보면 client의 정적인 리소스 요청을 처리하는 프로그램이며 대표적으로는 Apache HTTP Server와 Nginix가 있다. 동적인 요청이 들어오면 비즈니스 로직을 수행하기 위해 Web Application(혹은 WAS,AS)에게 요청을 위임하고 Web Application은 Web Server에게 로직을 수행한 결과를 다시 돌려준다. 그럼 Web Server가 Web Application과 대화할 수 있는 인터페이스가 필요할것이다. 특히 다양한 종류의 web server와 web application을 interchangable 하게 사용하기 위해서는 잘 정의된 인터페이스가 필수다.
CGI
2003년까지 Python Web Framework는 주로 CGI와 같은 방식으로 Web Server와 대화했다.
-> [web Framework] : 개발자들의 프레임워크는 '특정 프로그램을 개발하기 위한 여러 요소들과 매뉴얼인 룰을 제공하는 프로그램'이다. Django는 파이썬으로 작성된 작성된 오픈소스 웹 애플리케이션 프레임워크로 쉽고 빠르게 웹사이트를 개발할 수 있도록 돕는 구성요소로 이루어져있다. Spring Framework, Ruby on rails, Angular JS(Js기반)
CGI(Common Gateway Interface)는 다음과 같이 동작한다. 먼저 웹서버가 클라이언트로부터 HTTP request를 받는다. 웹서버는 request에 대한 정보(Method, Url, Parameters..)를 environment Variable과 Standard Input을 통해 전달하면서 스크립트를 실행한다. script는 비즈니스 로직을 수행하고 Standard output으로 결과를 웹서버에게 전달한다. 웹서버는 이를 다시 client에게 전달한다. 👉 문제는 매번 다시 스크립트를 실행하여 메모리에 적재하는 과정에서 발생하는 추가적인 시간 요소 등.. => WSGI 등장
WSGI(Web Server Gateway Interface)는 callable object를 통해 웹서버가 요청에 대한 정보를 application에 전달한다. callable object는 Function이나 Object의 형태가 될 수 있으며 웹서버는 callable object를 통해 두 가지 정보를 전해주어야한다. 1) HTTP Request에 대한 정보(Method, URL, Data.. 2)Callback 함수
다음은 각각 함수와 클래스 형태로 정의된 Callable Object의 예이다.
environ이 HTTP Request에 대한 정보를 갖고 있고 start_response가 웹서버에게 결과를 돌려주기 위한 콜백함수이다.
def application(environ, start_response){
body = b'Hello world!\n'
status = '200 OK'
headers = [('Content-type', 'text/plain')]
start_response(status,headers)
return [body]class Application:
def __init__(self, environ, start_response):
self.environ = environ
self.start_response = start_response
def __iter__(self):
body = b'Hellow world!\n'
status = '200 OK'
header =[('Content-type', 'text/plain')]
self.start_response(status, headers)
yield body
Web Application은 HTTP Request에 대한 정보를 가지고 비즈니스 로직을 수행한 뒤에 Callable function을 통해 결과를 웹서버에 반환한다.
이러한 WSGI Interface를 구현하는 웹서버나 어플리케이션을 WSGI compatible 하다고 하며, WSGI compatible한 Application을 WSGI Application이라고 부르기도 한다. 또한 이 WSGI 인터페이스를 구현하기만 한다면 Python Web Server나 Python Framework를 만들어서 기존에 WSGI 를 지원하던 웹서버나 프레임워크와 함께 동작하게 할 수 있다.
(참조 : https://tibetsandfox.tistory.com/22)
웹 서버 자체는 정적인 페이지밖에 보여주지 못한다. 동적인 페이지들은 웹 어플리케이션(장고, 플라스크 등으로 작성된 프로그램)의 도움으로 보게되는 것. 그렇다면 당연히 웹서버와 웹 어플리케이션은 서로 소통할 수 있어야한다. 그러나 Appache, Nginix 등 웹서버는 파이썬 코드를 이해하지 못한다.
- 클라이언트에서 요청을 보낸다.
- 웹서버에서 요청을 받는다. 이때 동적인 페이지를 요청했다면 WSGI 서버(미들웨어라고도 한다)를 호출한다.
- WSGI 서버는 WSGI를 사용하는 웹 어플리케이션(장고..)를 호출한다.
- 호출받은 웹 어플리케이션은 요청에 따라 적절한 처리를 수행한다.
- 수행 결과를 다시 WSGI 서버를 통해 웹 서버로 전달하고, 웹서버는 최종 응답을 클라이언트로 보낸다.
(대표적인 WSGI 서버로는 uWSGI, mod_wsgi, Gunicorn 등이 있다.)
CGI는 플랫폼에 상관없이 동작 가능하고 매번 요청에 대해 프로세스를 생성(fork)한다는 특징이 있다. 요청이 많아질 수록 성능이 저하된다.
