웹 서버와 CGI

이번 주에는 에코 서버, 타이니 웹 서버를 직접 만들어보았다. (주로 이미 짜여있는 코드 해석이 전부이긴 했지만)

서버를 열고 정적 요청과 동적 요청을 보내보면서 웹 서버와 CGI, WAS에 대한 개념이 조금 잡히는 것 같아 전체적으로 개념을 정리해보기로 했다.

 

나는 '무언가를 이해하려면 그것을 직접 만들어보는 게 최고의 방법이다'라는 생각 하나로 정글의 커리큘럼을 믿기로 했는데, 이번 주차에 많이 실감이 되었다!

항상 헷갈리던 웹 서버와 WAS 개념, 그리고 웹 서버의 발전 과정을 정리할 수 있었던 한 주였다.

 

그래서 8주차 발표 주제는 웹 서버와 CGI ~

오늘 남은 시간에는 mutex를 이용한 스레드 동시성이 구현된 프록시 서버도 한 번 보고 마무리할 예정이다.

 

 

먼저 CGI에 대해 설명하기 전에 웹 서버에 대해 살펴보자. 

웹 서버는 클라이언트로부터 HTTP 요청을 받아 정적 컨텐츠를 응답으로 돌려주는 프로그램이다.

(HTML 문서, CSS, Javascript, 이미지, 파일 등 즉시 응답 가능한 컨텐츠)

이 웹 서버는 정적 컨텐츠만 꺼내서 응답으로 보내줄 수 있다.

 

그런데 우리가 DB를 조회하고 싶을 수도 있고 검색이나 정렬 등 어떤 로직을 수행한 결과를 돌려받고싶을 수도 있다.

그래서 초창기에는 CGI를 사용했다.

 

웹 서버가 외부 애플리케이션을 돌릴 때 어떻게 그 애플리케이션을 실행해야될지에 대해서 정의된 표준화된 프로토콜이다.

프로토콜이기 때문에 어떤 언어로도 작성될 수 있다. (이전 글 중 CGI 포스팅이 있는데 참고하기)

 

HTTP request의 URL에 프로그램 경로와 전달할 매개변수를 지정해주면 CGI 인터페이스가 알아듣고 해석해서 해당 애플리케이션을 실행한다.

 

수행 절차는 다음과 같다.

• 웹 서버가 처리할 수 없는 동적인 처리가 필요한 요청이 오면 외부 프로그램을 호출
  • 동적 처리가 필요한지는 HTTP request 시작 라인에 포함된 URI로 판단할 수 있음
  • 위 그림의 경우 서버의 /cgi-bin경로에 존재하는 adder.c라는 애플리케이션에 인자로 n1=3, n2=5를 전달하여 실행 결과를 반환해달라는 요청
• 외부 프로그램이 이를 처리하여 HTML로 반환하면 웹 서버가 받아 브라우저로 전송

 

 

그런데 CGI는 문제점이 있다. 하나의 클라이언트 요청을 처리하기 위해 매번 하나의 Process를 새로 생성한다.

따라서 많은 요청이 발생할 경우 서버 리소스가 낭비되는 문제가 발생한다.

 

FastCGI를 쓰면 재사용 가능한 프로세스 풀이 제공된다.

사용자가 요청을 보내면 새로운 프로세스가 생성되는데, 그 프로세스를 닫지 않고 똑같은 사용자가 또 요청을 보낼 때 해당 프로세스를 재사용한다.

프로세스 마다 사용자로 식별해놓고 계속 재사용하므로 CGI 방식보다 서버 리소스 낭비가 적다.

 

WAS (Web Application Server)

 

예전에는 요청마다 단순히 CGI를 실행해서 동적 데이터를 처리했다면 지금은 WAS라는 서버를 상시 띄워두고 동적 데이터를 처리한다.

WAS는 DB 접근, 세션 관리, 인증 등 여러 처리를 같이 해준다.

 

그러면 WAS가 동적 컨텐츠를 전달 가능하다면 정적 컨텐츠, 동적 컨텐츠 처리를 모두 다 WAS에게 다 맡기고 서버를 WAS 하나만 쓰면 되지 않은가? 왜 클라이언트 요청을 웹 서버가 앞단에서 먼저 받고 그 다음에 동적 요청만 WAS에게 맡길까?

 

세 가지 이유가 있다.

먼저 정적/동적 컨텐츠 처리하는 곳을 분리할 수 있기 때문이다.

WAS는 DB 조회 및 다양한 로직을 처리하는 데 집중해야 한다. 따라서 단순한 정적 컨텐츠는 웹 서버에게 맡기며 기능을 분리시켜 서버 부하를 방지한다. 만약 WAS가 정적 컨텐츠 요청까지 처리하면, 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지고 이로 인해 페이지 노출 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어진다.

 

두 번째로는 빠른 처리가 가능하다는 점이다.

HTML, CSS같은 정적 컨텐츠는 웹 서버가 빨리 디스크에서 꺼내서 클라이언트에게 보내줄 수 있지만 동적 컨텐츠는 애플리케이션 단에서 처리가 필요하므로 응답에 시간이 조금 더 걸린다.

그래서 브라우저에서 정적 컨텐츠만 먼저 렌더링하도록 웹 서버가 먼저 빨리 보내주고, 동적 컨텐츠는 처리되는 대로 따로 보내주면 받는 입장에서 더 빠르게 페이지를 볼 수 있다.

 

세 번째로는 웹 서버가 앞단에서 리버스 프록시 서버 역할을 해준다는 점이다. 리버스 프록시 서버는 서버쪽을 보호해주는 프록시 서버를 뜻하는데(클라이언트쪽을 보호해주는 것은 포워드 프록시 서버라고 함) 클라이언트 요청이 한꺼번에 많이 들어올 때 웹 서버가 앞단에서 먼저 요청을 다 받아서 로드밸런싱을 적절히 해줌으로써 서버 부하를 분산시킬 수 있다.

(리버스 프록시 서버의 더 많은 역할을 보려면 아래 더보기를 참고해주세염)

 

Forward Proxy, Reverse Proxy

Proxy 서버는 클라이언트와 서버 사이에서 정보를 대신 전달해주는 주체이다.

프록시 서버가 없으면 갑자기 많은 사용자가 들어오거나 클라이언트가 자신의 IP정보를 보호하고싶을 때 적절한 처리를 할 수 없다.

 

따라서 Client -> NginX -> Web Server 로 구성해서 사용자의 요청을 NginX가 대신 웹 서버로 전달해주도록 구성한다.

 

forward proxy

클라이언트를 보호

- 보안성 : 클라이언트가 서버에 접속할 때 ip를 숨길 수 있음

- 프록시 서버에서 특정 ip/서버에 대한 접근을 제어할 수 있음

- 성능 : 캐시를 이용해 클라이언트측에서 자주 요청되는 응답들을 캐싱하여 서버까지 가는 레이턴시를 줄일 수 있음

예)

특정 웹사이트에 대한 접근 제어 (특정 시간에만 접근 허용)

유해 컨텐츠, 비업무관련 사이트 차단

프록시는 어떤 서버에 자주 머무는지 등의 데이터를 가지고 있으므로 모니터링으로 사용 가능

 

reverse proxy

서버를 보호

- 보안성 : 프록시를 거쳐야 하기 때문에 서버의 IP에 직접 접근할 수 없다 -> 디도스 공격 예방

- 로드밸런싱 : 서버 부하 분산

- 캐싱

 

2. 정적 컨텐츠/동적 컨텐츠 처리하는 부분을 나눌 수 있다. 

 

 

 

예전에는 요청 마다 단순히 CGI를 실행해서 동적 데이터를 처리했다면

지금은 WAS라는 서버를 상시 띄워두고 동적 데이터를 처리할 수 있다.

그리고 DB처리, 세션 관리, 인증 등 여러 처리를 같이 해준다.

 

 

 

 

 

 

 

https://only-wanna.tistory.com/entry/Web-Web-Server%EC%9B%B9-%EC%84%9C%EB%B2%84%EC%99%80-CGI-Web-Application-ServerWAS-%EC%95%B1-%EC%84%9C%EB%B2%84-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

[Web] Web Server(웹 서버)와 CGI, Web Application Server(WAS, 앱 서버) 알아보기

 

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

[Web] Web Server와 WAS의 차이와 웹 서비스 구조 - Heee's Development Blog

https://www.ibm.com/docs/ko/i/7.5.0?topic=functionality-cgi

CGI

 

https://codechasseur.tistory.com/25

[Web] 웹 서버와 WAS의 차이를 쉽게 알아보자

https://nostressdev.tistory.com/10

웹 서버, CGI, FastCGI - PHP를 사용하는 이유?