🖤 UMC 서버 3주차 스터디 - Web Server & Web Application Server(WAS), Reverse Proxy 🖤

 

 

 

웹이 동작하는 방식을 간단하게 요약하자면 클라이언트에서 요청이 들어오면 서버에서 요청을 처리한 후 반환하는 것이다.

 

예를 들어 로그인을 위해 사용자가 ID와 비밀번호를 입력하고 로그인 버튼을 누르면(요청)

서버에서 로그인 정보가 일치하는지 확인하고(요청 처리) 로그인 성공/실패 화면을 보여주는 것이다(반환)

 

 

 

클라이언트와 서버

 

1 ) 클라이언트

웹에서 클라이언트는 대개 웹 브라우저를 의미한다.

 

2 ) 서버 : 웹 서버(WS), 웹 어플리케이션 서버(WAS)

서버는 웹 서버(ex. Apache, NGINX)와 웹 어플리케이션 서버(WAS - ex. 톰켓)가 있다.

클라이언트에서 특정 요청이 들어오면

웹 서버에서 정적인 컨텐츠 제공이 필요한지, 동적인 컨텐츠 제공이 필요한지 판단한 뒤

정적인 컨텐츠 제공이 필요하다면 웹 서버에서 바로 정적 컨텐츠를 반환함으로써 요청을 처리하고

동적인 컨텐츠 제공이 필요하다면 리버스 프록시를 통해 웹 어플리케이션 서버로 요청을 전달한다.

요청을 전달받은 웹 어플리케이션 서버는 동적인 내용을 처리한다

     

       

( 1 ) 웹 서버 (WS)

웹 서버는 우선 클라이언트의 요청이 정적인 내용인지 동적인 내용인지를 구분한 뒤

정적인 내용이라면 바로 처리를 하고(정적 컨텐츠 반환) 동적인 내용이라면 웹 어플리케이션 서버로 전달한다.

       

nginx 응용

웹 서버 실행 시 nginx의 설정 파일을 먼저 읽는데

nginx의 설정 파일 접근

# 설정 파일이 저장되어 있는 디렉토리로 이동
cd /etc/nginx/sites-available
# default(설정 파일) 읽기
cat default

 

nginx 설정 파일 내용

##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##

# Default server configuration
#
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}
}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#       listen 80;
#       listen [::]:80;
#
#       server_name example.com;
#
#       root /var/www/example.com;
#       index index.html;
#
#       location / {
#               try_files $uri $uri/ =404;
#       }
#}

 

여기서 주목해야 하는 코드는

# root 뒤에 표기한 디렉토리 -> 정적 컨텐츠를 찾아낼 시작 디렉토리
root /var/www/html;
# index 뒤에 표기한 파일 -> 보여줄 정적 컨텐츠
index index.html index.htm index.nginx-debian.html;

root 뒤에 정적 컨텐츠를 찾아낼 시작 디렉토리가 명시되어 있고

index 뒤에 정적 컨텐츠 파일이 쓰여 있다

 

실제로 /var/www/html로 이동해서 안에 있는 파일 리스트를 확인해보면 index.nginx-debian.html 파일을 확인할 수 있고

index.nginx-debian.html 파일 내용을 읽어보면

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

 

nginx를 실행했을 때 default 화면의 html임을 알 수 있다

즉, nginx를 실행했을 때 /var/www/html에 있는 index.nginx-debian.html를 반환한 것이다

다시 말하자면 nginx를 실행했을 때 /var/www/html/index.nginx-debian.html이 실행된 것이다

 

nginx  - 정적 컨텐츠 반환

이걸 응용해서 웹 브라우저에서 요청을 넣었을 때 정적 컨텐츠를 반환하는 코드를 작성해보겠다

이때 웹 브라우저에서 보내는 요청은 '/요청' 을 public ip 뒤에 붙여서 나타낸다

예를 들어 3.34.6.218/temp는 3.34.6.218에 temp 요청을 한 것을 의미한다

 

앞서 봤던 nginx default 파일(설정 파일)의 server block에 아래 코드를 넣어준다

location /temp {
		root /var/www;
        	index temp.html
        	try_files $uri $uri/ =404;
	}

이는 /temp 요청이 들어왔을 때

root 뒤에 있는 /var/www 디렉토리에서 찾기 시작해 /temp 디렉토리 내에 있는 temp.html을 찾아서 반환한다는 의미다

이때 아까와 다른 점은 시작 디렉토리인 /var/www에 바로 html 파일이 있는 것이 아니라

/var/www 내의 /temp 디렉토리 즉, /var/www/temp 에 정적 컨텐츠인 temp.html 파일이 존재한다는 것이다

 

nginx의 설정파일을 수정한 뒤에는 변경 사항 반영을 위해 꼭 restart를 해줘야 한다

sudo systemctl restart nginx

 

이때 오류가 발생한다면 보통 수정한 설정 파일에 문법 오류가 있다는 뜻이므로

sudo nginx -t

이 코드를 통해 문법 오류 확인 후 설정 파일을 다시 수정한 후 진행하면 된다

 

restart까지 완료했다면 아까 /temp 요청을 수행하기 위한 작업을 진행하면 된다

1.  /temp 디렉토리 생성
2.  /var/www/temp 내에 temp.html 생성 및 편집

 

# temp 디렉토리 생성
sudo mkdir temp

# 생성한 temp 디렉토리 내로 이동
cd /var/www/temp
# temp.html 파일 생성 및 편집
sudo vi temp.html

 

temp.html 편집

<h1> hello UMC! <h1>

 

이후 public ip/temp를 주소창에 입력하면 아래와 같은 화면이 출력되는 것을 확인할 수 있다

위의 과정을 잘 응용하면 아래와 같은 화면도 출력할 수 있다

왼쪽부터 순서대로 /web 요청, /web/ddol.html 요청, /text/hello.text 요청에 대한 출력

 

 

( 2 ) 웹 어플리케이션 서버(WAS)

WAS는 우선 앞서 말했던 웹 서버의 기능을 수행하고

WAS에 포함되어 있는 웹 컨테이너(ex. JSP, Servlet)에서 동적인 내용을 처리한다.

 

간단하게 JSP와 Servlet에 대해 설명하자면 

- Servlet : JAVA 코드 안에 html 코드 -> DB관련 내용 처리에 유용

- JSP : html 코드 안에 JAVA 코드 -> View관련 내용 처리에 유용

JSP는 Servlet의 단점을 보완하여 만들어졌기 때문에 최근에는 JSP를 주로 사용한다.

다만 서버 내로 들어오면 JSP는 Servlet으로 변환된다.

                

WAS 안에는 웹 서버의 기능이 포함되어 있는데 웹 서버와 WAS를 동시에 사용하는 이유는 무엇일까?

이유는 크게 3가지로 보는데

1.  웹 서버 내에서 다른 언어를 동시에 사용하는 경우

2.  보안 강화

3.  특정 서버에서 과부화가 올 경우 다른 서버를 이용할 수 있도록 하려고

 

 

리버스 프록시(Reverse Proxy)

앞서 나온 리버스 프록시란 같은 네트워크 내에 속하는 서버끼리의 통신을 관리하는 것이다

 

포워드 프록시와 비교해보자면 리버스 프록시는 웹 서버 옆에 놓여 네트워크 내에 있는 서버끼리의 통신을 관리한다면

포워드 프록시는 클라이언트 옆에 놓여 외부 서버와의 통신을 관리한다는 것이다

 

nginx 응용

위에서 WS를 이용해 정적 컨텐츠를 반환하는 방법을 알았으니

이번에는 WS에서 리버스 프록시를 통해 동적 컨텐츠를 제공하는 WAS에 접근하는 코드를 작성해보자

location / {
                proxy_pass http://localhost:3000; # <- 프록시 설정
        }

이 코드는 /요청을 보내면 리버스 프록시를 통해 3000번 포트의 프로세스로 요청을 전달해준다는 의미다

 

결과는!

아직 3000번 포트의 프로세스가 존재하지 않기 때문에 위와 같은 오류가 발생한다