Part.1 웹서버란 무엇인가

📌 이 글을 왜 쓰는가

2월 초 흔히 말하는 백엔디를 모두 경험해 봤다. flask를 이용해 웹을 만들면서 프론트엔드에 대한 매력도 느끼고 DB에 대해 더 알고 싶고 또 가장 베이스인 백엔드 공부도 해보고 싶단 생각이 들었다. 4월 초 운이 좋게도 django를 공부할 수 있었는데 제대로 해보고 싶은 마음에 든 생각의 첫 시작은 근데, 도대체 서버가 뭐야?였다. 그렇게 서버를 공부하다 보니 HTTP는 뭔데? 로 빠져 결국 서버와 네크워크에 대해 거의 일주일 동안 공부했더란다. 서버와 클라이언트가 왜 분리되어 있어야 하는지, http 프로토콜은 어떻게 작동하는지, 웹 서버에 대한 전반적인 이해와 db를 가져오는 api에 대한 이해까지 또 이걸 구현하기 위한 python webframework 까지 그 첫 페이지로서 웹서버란 무엇인가를 작성하고 있는데 다 쓰고 보니 생각보다 별게 없는 것 같기도 하고 근데 왜 이렇게 어려웠을까? 하나의 document를 보고 공부하지 못해서 그런가ㅠㅠ
여튼 이건 웹서버의 첫 페이지로 두 번째는 진짜 HTTP 프로토콜에 대한 포스팅 세 번째는 그렇게 공부하다 보니 대용량 서버 트래픽 처리가 궁금해져 또 공부하고 그렇게 서버와 아키텍처로 넘어가게 된 이야기까지... 아키텍처, 서버, 네트워크에 대한 포스팅을 시작해 보려 한다!



목표
이 글을 읽고 web server/ http/ web server와 was의 차이 그리고 WSGi/python framework/ API
즉 백엔드 로직에 대해 전반적인 그림을 그릴 수 있다.

 

 

1. web server?

웹 브라우저와 같은 클라이언트로부터
HTTP 프로토콜로 요청을 받아,
HTML 문서 등과 같은 정적 웹 페이지를 응답해주는 소프트웨어

1-1. 하드웨어 vs 소프트웨어

• 하드웨어 측면,
  • web server는 web server의 소프트웨어와 website의 컴포넌트 파일들을 저장하는 컴퓨터 (컴포넌트 파일에는 HTML 문서, images, CSS stylesheets, 그리고 JavaScript files 등)
  • Web server는 인터넷에 연결되어 웹에 연결된 다른 기기들이 웹 서버의 데이터(컴포넌트 파일들)를 주고받을 수 있도록 한다.
• 소프트웨어 측면,
  • web server는 기본적으로 웹 사용자가 어떻게 호스트 파일들에 접근하는지를 관리한다.
  • HTTP 서버는 URL(Web addresses)과 HTTP(당신의 브라우저가 웹 페이지를 보여주기 위해 사용하는 프로토콜)의 소프트웨어 일부이다.
  

브라우저가 웹 서버에서 불려진 파일을 필요로 할때, 브라우저는 HTTP를 통해 파일을 요청-> 요청이 올바른 웹 서버(하드웨어)에 도달하였을 때 -> HTTP 서버(software)는 요청된 문서를 HTTP를 이용해 전달

웹 사이트를 공개하기 위해서는, 당신은 정적 혹은 동적 웹 서버가 필요하다.

• 정적 웹 서버: HTTP 서버 (소프트웨어)가 있는 컴퓨터(하드웨어)로 구성되어 있습니다. 서버가 그 불려진 파일을 당신의 브라우저에게 전송하기 때문에 "정적" 웹 서버
• 동적 웹 서버: 정적 웹 서버와 추가적인 소프트웨어(대부분 일반적인 애플리케이션 서버와 데이터베이스)로 구성. 애플리케이션 서버가 HTTP 서버를 통해 당신의 브라우저에게 불려진 파일들을 전송하기 전에, 애플리케이션 서버가 업데이트하기 때문에 "동적" 웹 서버
• 최종 웹페이지들을 생성하기 위해, 애플리케이션 서버는 데이터베이스로 온 컨텐츠들로 이루어진 HTML 템플릿을 채운다. 사이트들은 수 천개의 웹페이지들을 가지고 있지만, 그것들은 실제의 HTML 문서가 아니라 오직 약간의 HTML 템플릿과 엄청 큰 데이터베이스로 되어있다

1-2. 호스팅 파일들

웹 서버는 처음에 HTML 문서라고 불리는 웹 사이트의 파일들과 이미지, CSS 스타일시트, JavaScript 파일, 폰트, 비디오를 포함한 관련된 것들을 저장해야한다.

기술적으로, 컴퓨터에 있는 그 파일들을 불러올수 있지만, 그것들을 전담하는 웹 서버에 저장하는것이 훨씬 더 편리함.

전담하는 웹서버는:

• 항상 실행 중이고
• 항상 인터넷과 연결되어 있고
• 항상 같은 IP주소를 가지고 있으며(모든 ISPs (en-US)가 홈 라인에 대해 고정된 IP주소를 제공하는 것은 아닙니다.)
• 제 3자에 의해 유지보수 된다.

좋은 호스팅 제공자를 찾는 것은 당신의 웹 사이트를 구축하는 것의 핵심 부분.
웹 호스팅 솔루션을 설정했다면, 그저 웹 서버에 파일들을 업로드 하면 된다.

1-3. HTTP

웹 서버는 HTTP (hypertext transfer protocol)을 위한 지원. 이름이 의미하듯이, HTTP는 어떻게 두 컴퓨터간의 hypertext(예를 들어, 연결된 웹 문서)를 전송하는 protocol.

프로토콜은 두 컴퓨터간의 통신를 위한 규칙의 집합. HTTP는 문자로 된, 독립적인 프로토콜입니다.

• Textual(문자로 된): 모든 명령어들은 기본 문자이며 사람들이 읽을 수 있습니다.
• Stateless(독립적인): 서버 혹은 클라이언트는 이전의 통신을 기억하지 않는다/ HTTP에만 의존하면, 서버는 당신이 입력한 비밀번호 혹 당신이 처리한 단계를 기억하지 못하기 때문에
  그러한 일들을 위한 애플리케이션 서버가 필요하다.

HTTP는 어떻게 클라이언트와 서버가 통신을 하는지 명확한 규칙을 제공

• 오직 클라이언트만이 HTTP 요청을 만들 수 있으며, 서버에게만 보낼 수 있습니다. 서버는 오직 클라이언트의 HTTP 요청에 응답할 수 있습니다.
• HTTP를 통해 파일을 요청할때, 클라이언트는 반드시 URL 파일들을 제공해야 합니다.
• 웹 서버는 반드시 최소한의 에러 메시지를 포함하여 모든 HTTP 요청에 응답해야합니다.

더 자세하게는 다음 포스팅 참고

2. Back-end

2-1. Static Pages와 Dynamic Pages

• Static Pages
  Web Server는 파일 경로 이름을 받아 경로와 일치하는 file contents를 반환한다.
  항상 동일한 페이지를 반환한다.
  Ex) image, html, css, javascript 파일과 같이 컴퓨터에 저장되어 있는 파일들
• Dynamic Pages
  인자의 내용에 맞게 동적인 contents를 반환한다.
  즉, 웹 서버에 의해서 실행되는 프로그램을 통해서 만들어진 결과물 * Servlet: WAS 위에서 돌아가는 Java Program
  개발자는 Servlet에 doGet()을 구현한다.
  https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

2-2. Web Server와 WAS의 차이

Web Server

• Web Server의 개념: 소프트웨어와 하드웨어로 구분된다.
  • 1) 하드웨어: Web 서버가 설치되어 있는 컴퓨터
  • 2) 소프트웨어: 웹 브라우저 클라이언트로부터 HTTP 요청을 받아 정적인 컨텐츠(.html .jpeg .css 등)를 제공하는 컴퓨터 프로그램
  • Web Server의 기능
  • HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스 하는 기능을 담당한다.
  • 요청에 따라 아래의 두 가지 기능 중 적절하게 선택하여 수행한다.
  • 기능 1)
    • 정적인 컨텐츠 제공
    • WAS를 거치지 않고 바로 자원을 제공한다.
  • 기능 2)
    • 동적인 컨텐츠 제공을 위한 요청 전달
    • 클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다.
    • 클라이언트는 일반적으로 웹 브라우저를 의미한다.
  • Web Server의 예
    Ex) Apache Server, Nginx, IIS(Windows 전용 Web 서버) 등

WAS(Web Application Server)

• WAS의 개념
  • DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server
  • HTTP를 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어(소프트웨어 엔진)이다.
  • “웹 컨테이너(Web Container)” 혹은 “서블릿 컨테이너(Servlet Container)”라고도 불린다.
    • Container란 JSP, Servlet을 실행시킬 수 있는 소프트웨어를 말한다.
    • 즉, WAS는 JSP, Servlet 구동 환경을 제공한다.
• WAS = Web Server + Web Container
  • Web Server 기능들을 구조적으로 분리하여 처리하고자하는 목적으로 제시되었다.
    • 분산 트랜잭션, 보안, 메시징, 쓰레드 처리 등의 기능을 처리하는 분산 환경에서 사용된다.
    • 주로 DB 서버와 같이 수행된다.
  • 현재는 WAS가 가지고 있는 Web Server도 정적인 컨텐츠를 처리하는 데 있어서 성능상 큰 차이가 없다.
• WAS의 주요 기능
  • 프로그램 실행 환경과 DB 접속 기능 제공
  • 여러 개의 트랜잭션(논리적인 작업 단위) 관리 기능
  • 업무를 처리하는 비즈니스 로직 수행
• WAS의 예
  Ex) Tomcat, JBoss, Jeus, Web Sphere 등

2-3. Web Server와 WAS를 구분하는 이유

• Web Server가 필요한 이유?
  클라이언트(웹 브라우저)에 이미지 파일(정적 컨텐츠)을 보내는 과정에서
  이미지 파일과 같은 정적인 파일들은 웹 문서(HTML 문서)가 클라이언트로 보내질 때 함께 가지 않는다. 클라이언트는 HTML 문서를 먼저 받고 그에 맞게 필요한 이미지 파일들을 다시 서버로 요청하면 그때서야 이미지 파일을 받아온다. Web Server를 통해 정적인 파일들을 Application Server까지 가지 않고 앞단에서 빠르게 보내줄 수 있다. 따라서 Web Server에서는 정적 컨텐츠만 처리하도록 기능을 분배하여 서버의 부담을 줄일 수 있다.
• WAS가 필요한 이유?
  웹 페이지는 정적 컨텐츠와 동적 컨텐츠가 모두 존재한다. 사용자의 요청에 맞게 적절한 동적 컨텐츠를 만들어서 제공해야 한다. 이때, Web Server만을 이용한다면 사용자가 원하는 요청에 대한 결과값을 모두 미리 만들어 놓고 서비스를 해야 한다. 하지만 이렇게 수행하기에는 자원이 절대적으로 부족하다. 따라서 WAS를 통해 요청에 맞는 데이터를 DB에서 가져와서 비즈니스 로직에 맞게 그때 그때 결과를 만들어서 제공함으로써 자원을 효율적으로 사용할 수 있다.
• 그렇다면 WAS가 Web Server의 기능도 모두 수행하면 되지 않을까?

결국은 자원 이용의 효율성 및 장애 극복, 배포 및 유지보수의 편의성 을 위해 Web Server와 WAS를 분리하는 것. Web Server를 WAS 앞에 두고 필요한 WAS들을 Web Server에 플러그인 형태로 설정하면 더욱 효율적인 분산 처리가 가능하다.

2-4. django

• reverse proxy server: 웹브라우저의 카운터 파트너로서 서버 쪽에서 정보를 제공하는 소프트웨어를 의미. 클라이언트로부터의 HTTP요청을 받아 정적인 페이지/파일을 돌려준다. 가벼움과 높은 성능을 목표로 웹 서버, 리버스 프록시 및 메일 프록시 기능. 대표적인 웹서버는 Apache, Nginx
• WAS(Web Application Server) 복습
  동적 리소스 처리를 위해 사용. 웹 서버(Nginx)와 웹 애플리케이션(Django)간의 연결을 중계. (Nginx에서 받은 요청을 Django에서 처리하기 위한 중계인 역할을 해준다.) Nginx는 Python을 모르기 때문에 uWSGI는 HTTP 요청을 python으로, Django로 부터 받은 응답을 Nginx가 알 수 있도록 변환해준다.
• WSGI web apllication
• Django는 웹 서버인가?
  장고는 장고만의 웹서버를 쓴다. 개발 목적으로 python으로 짜여진 가벼운 wsgi(web server gateway interface)를 사용하는데, 이걸 웹서버라고 할 수는 있다. 하지만 장고 자체는 웹 프레임워크이고 runserver를 통해 웹 서버와 웹 애플리케이션 서버 역할을 하는 것임. 그러니 장고 document에서 프로덕션 과정에서는 사용하지 않는 것을 추천함.
• DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (We’re in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.) 이 서버를 프로덕션 세팅에서 사용하지마라. 이것은 보안 검수나 퍼포먼스 테스트를 통과하지 않았다. (우리는 웹 서버를 만드려는게 아니고 웹 프레임워크를 만들었고, 그렇기 때문에 프로덕션 환경에서 서버를 향상시키고 싶다면 장고 외의 서버를 사용하라)

• 그렇다면 WSGI 서버는 뭐야?
  WSGI는 Web Server Gateway Interface의 약자
  WSGI는 python application(python script)이 Web Server와 통신하기 위한 표준 Interface이며 Python Framework. WSGI는 서버와 게이트웨이 , 애플리케이션과 프레임워크 양단으로 나눠져 있다. WSGI 리퀘스트를 처리하려면, 서버단에서 환경정보와 콜백 함수를 애플리케이션단에 제공해야 한다. 애플리케이션은 그 요청을 처리하고 미리 제공된 콜백 함수를 통해 서버단에 응답한다. WSGI 미들웨어(라고 불린다.)가 WSGI 서버와 애플리케이션 사이를 보충해주는데, 이 미들웨어는 서버의 관점에서는 애플리케이션으로, 애플리케이션의 관점에서는 서버로 행동한다.

즉, HTTP requests -> Web Server -> WSGI Server(Middleware) -> Django(WSGI를 지원하는 Web Application)

2-5. web server, API server