-
📝 학습 목표
-
🤔 웹 서버 & 웹 어플리케이션 서버
-
✒️ 0. 들어가기 전
-
✒️ 1. Web Server 정적 콘텐츠 호스팅
-
✒️ 2. NGINX에서의 정적 콘텐츠 호스팅
-
💡 nginx 설정 파일에서의 location 블록 수정하기
-
💡 location block으로 여러 경우 다르게 호스팅 해보기
-
✒️ 3. Web Server VS Web Application Server(WAS)
-
✒️ 4. Reverse Proxy (역방향 프록시)
-
💡 순방향 프록시와 역방향 프록시
-
✒️ 5. NGINX에서 리버스 프록시 설정하기
-
💡 왜 502 에러가 뜨는가!?
📝 학습 목표
- Web Server와 Web application Server의 차이를 이해한다.
- Reverse Proxy를 이해하고 적용한다.
🤔 웹 서버 & 웹 어플리케이션 서버
Web Server와 Web Aplication Server???
둘이 무엇이 다른 걸까?
일단, 설명에 들어가기 전에
Web Server의 개념이 먼저 나왔고, Web Aplication Server는 이후에 등장했다는 것을 알아두자.
사실, 웹 기술의 발전 과정을 보면 이해하기 쉽다.
1. 정적 웹 페이지 서비스 : 보통 초기 웹 단계에서는 정적인 HTML 페이지만을 서비스하고, 사용자도 매우 많지 않았다.
2. 웹 서버의 등장 : 초기 웹에서 정적 콘텐츠를 제공하는 데 사용되었다!
Apache, Nginx 등의 웹 서버가 등장하면서, 정적 파일 제공을 위한 서버의 역할이 확립되었다!
3. 동적 웹 페이지와 CGI : 동적 콘텐츠 생성의 요구! -> CGI 와 같은 기술 등장 (이런게 있구나~ 하고 넘어가자)
4. 웹 어플리케이션 서버의 등장 : 그러나 CGI는 성능, 보안 등 많은 문제가 있었다.
이에 대응하기 위해, 동적인 콘텐츠를 생성하고 관리하는 역할인 서버의 등장!
Q. 어떻게 동적인 콘텐츠를 효과적이게 생성할 수 있었을까!?
A. (정적 방식) 미리 정해진 콘텐츠를 준비해두고 (html, css 등 저장해두고) 요청이 오면 응답으로 주는 것이 아닌,
(동적 방식) 요청이 올 때마다 해당 요청에 적절한 콘텐츠를 그때 그때 생성해서 전달할 수 있다면 효율적일 것이다!
* 클라이언트의 요청에 대해 적절한 데이터를 만들어주는 서버 : Web Application Server(WAS)
우리가 자주 쓰는 WAS는 Node.js와 Springboot가 있다!
✒️ 0. 들어가기 전
Web Server가 실제로 어떻게 정적인 콘텐츠를 응답으로 주는지(정적 콘텐츠 호스팅)
Web Application Server와 어떻게 다르며 어떻게 WS와 함께 동작하는지
✒️ 1. Web Server 정적 콘텐츠 호스팅
이전 시간에 말헀던 내용들을 복습해보자.
IP 주소를 통해 식별된 컴퓨터의 프로세스는 특정 포트 번호를 사용하여 데이터를 주고받는다.
그리고 2-2 실습에서 했던 "보안그룹에서 TCP 80번 포트를 열어준 이유" 는
EC2의 IP 주소를 통해 식별 -> 80번 포트로 열림 NGINX로 요청을 보내기 위함!
* Nginx는 빠르고 가벼운 웹 서버로, 정적인 웹 사이트를 호스팅하고 관리하는 데 사용됩니다.
그리고 우리는 NGINX 를 설치한 뒤 다음과 같은 화면을 마주했다!
NGINX가 우리의 요청에 따라 -> 정적인 컨텐츠인 HTML을 응답한 것이다!
물론이 정적 컨텐츠는 미리 저장해둔 것이다!
그럼 Request에 따라 어떤 Response를 줄 건지에 대한 판단은 어떻게 할 수 있을까?
✒️ 2. NGINX에서의 정적 콘텐츠 호스팅
NGINX가 어떻게 실행되는 지 부터 차근차근 알아보자!
웹 서버가 실행될 때 NGINX의 설정 파일을 읽으며 실행된다.
<ubuntu 기준>
/etc/nginx/sites-available 디렉토리에서 default가 nginx의 설정 파일입니다.
(어떤 터미널에서 코드를 치지? : 이전 포스트의 "NGINX 설치하고 브라우저에서 접속해보기 (Test)" 참고)
cd /etc/nginx/sites-available
cat default
해당 명령어를 입력하면, 아래의 default 설정값들이 쭈욱~~~~ 나온다.
그 중에서 중요한 부분만 발췌해보았다.
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
# 중략
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
# 중략
}- listen 80 default_server; & listen [::]:80 default_server; : 서버가 80번 포트에서 요청을 수신한다!
- root /var/www/html; : 웹 페이지 (정적 콘텐츠)파일이 위치한 디렉토리!
- index index.html index.htm index.nginx-debian.html; : 서버가 3개의 파일을 찾아 첫 화면으로 보여준다는 것.
우리가 아까 보았던!!!!! 흰페이지 이다! - server_name _; : 서버가 모든 호스트명에 대해 요청을 수락한다는 것
- location / { ... } : 모든 요청에 대해 정적 파일을 서빙! 존재하지 않는 파일이나 디렉토리에 대해서는 404 에러를 반환.
중요한 것은
root /var/www/html을 통해 정적 콘텐츠를 위치한 시작 디렉토리를 설정하고
index를 통해 기본 요청이 온 경우 어떤 파일을 줄지 설정해 놓았다는 것
->
이에 따라 / Request가 들어오면
/var/www/html/index.nginx-debian.thml을 응답으로 준 것을 확인할 수 있다
💡 nginx 설정 파일에서의 location 블록 수정하기
위에서 location / { ... } 블록은 모든 요청에 대해 정적 파일을 서빙! 해주는 역할이라고 하였다.
해당 파일을 수정해보자!
(해당 파일은 설정 파일로써 기본적으로 'read-only' 권한으로 처리되어 있다.)
(강제로 sudo로 수정해보자.)
* sudo 로 수정할 때는 항상 주의하도록 하자!
cd /etc/nginx/sites-available
sudo vi default
이러면 vi 편집기 모드로 변경될 것이다. (자세한 사용법은 구글링 해보자..)
location / 아래에 해당 코드를 추가해보자!
-> i (편집 모드) -> 키보드로 이동 후 코드 수정 -> exc 누른 후, 마지막 줄이 깜빡일때 -> :wq (저장 후 나가기)
location /temp {
root /var/www;
index temp.html;
try_files $uri $uri/ =404;
}
대충 눈치 챘죠!?
홈화면에 가면 /var/www 디렉토리에 있는 temp.html 띄운다는 것!
cd /var/www
sudo mkdir temp
cd temp
sudo vi temp.html<h1> 아무말이나 적어봐용 <h1>sudo systemctl restart nginx <- nginx설정 변경이 되었으니 재실행!
그리고, /temp 로 접근해보면, 해당 페이지를 볼 수 있다!
만약에 권한 문제가 뜬다면... 404 ERROR
https://devfoxstar.github.io/web/nginx-403-forbidden/ 참고
즉,
location /y{
root /x;
index c.html;
}
이 설정은 ip/y/ 로 요청이 오면, /x/y에서 c.hmtl을 찾아라 ! 라는 뜻
즉, 우리의 경우 /temp로 이동했을 때, /var/www/temp 의 temp.html을 찾은 것!
참고로 index는 /y 뒤에 어떤 것도 붙지 않았을 때! 의 경로를 말한다!
root 안에 text.html을 만들면,
ip/temp/text.html로 이동 가능하다!
💡 location block으로 여러 경우 다르게 호스팅 해보기
1. /web 경로에 대해 기본적으로 welcome!이 포함된 html을 보여주고 ddol.html 파일을 요청 할 경우 html 문서를 응답으로 주고 그 외의 경우는 에러 응답
2. /text 경로에 대해서는 기본 호스팅이 없고 hello.txt를 요청 시 hello world 문자열을 응답으로 주고 그 외의 경우는 에러 응답
해당 요구사항에 맞게 한 번 테스트 해보자!
✒️ 3. Web Server VS Web Application Server(WAS)
지금까지 웹 서버가 어떻게 동작하는지!
그리고 어떻게 저장된 정적인 파일들을 응답하는지 알아보았다!
그렇다면, WAS는 어떻게 Web Server와 함께 동작할 수 있을까?
그냥 평소 하던대로 Springboot나 Node.js를 돌리면, WAS만 돌아갈 뿐이지, Web Server는 중간에 없는 형태가 된다..
그럼 우리 tistory를 WAS 하나만 둔 아키텍쳐로 구성하였다고 하자!
(SpringBoot로 돌린다고 가정 :8080)
그럼 우리는 jinhos-devlog.tistory.com:8080으로 접속해야한다...
하지만, 우리는 항상 웹 서버로 요청을 보낸다!
( jinhos-devlog.tistory.com = jinhos-devlog.tistory.com:80 )
(기본적으로 HTTP 프로토콜에서 80번 포트 사용)
어떻게 이런일이 가능하지!?
✒️ 4. Reverse Proxy (역방향 프록시)
역방향 프록시(Reverse Proxy)는 컴퓨터 네트워크 분야에서 사용되는 용어이다!
정의는 : 클라이언트와 서버 간의 통신을 중계하고 보안, 성능 개선 등의 목적을 위해 중간에 위치하는 서버
쉽게 말하면, 클라이언트 요청을 대신 받아서 해당 요청을 서버로 전달하고, 서버로부터 받은 응답을 클라이언트에게 반환해준다!
참고로, 서버가 클라이언트에게 응답을 보내듯이,
connect() 시스템 콜과 같은 요청을 보내는 시스템 콜을 통해 다른 서버에게 다시 요청을 보낼 수도 있다!
💡 순방향 프록시와 역방향 프록시
순방향 프록시(Forward Proxy):
- 클라이언트가 외부 서버에 직접 접근하지 못하도록 막힌 경우, 클라이언트의 요청을 받아 외부 서버에 대신 접근하여 요청을 전달하는 프록시 서버
역방향 프록시(Reverse Proxy)
- 클라이언트의 요청을 받아 백엔드 서버에 전달하고, 백엔드 서버로부터 받은 응답을 클라이언트에게 반환하는 프록시 서버
- 일반적으로 서버의 보안을 강화하고 로드 밸런싱, SSL 암호화, 캐싱, 압축 등의 기능을 제공하는 데 사용된다.
- Gateway도 이러한 방식이다!
✒️ 5. NGINX에서 리버스 프록시 설정하기
기존 NGINX 설정 파일을 아래와 같이 변경해보자!
location / {
proxy_pass http://localhost:3000; <- 프록시 설정
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
위 의 설정을 보면 /요청에 대해 우선적으로 프록시로써 요청을 건네주도록 추가했다.
이 때, localhost:3000의 프로세스로 요청을 보내도록 설정한 것이다.
이는 리버스 프록시를 설정한 것!
이제 sudo systemctl restart nginx로 nginx를 재시작 한 후
다시 재접속 해보자
💡 왜 502 에러가 뜨는가!?
당연히 현재 3000번 포트를 가진 프로세스가 하나도 실행되지 않고 있기 때문...
해당 내용은 나중에 포스팅 에서 다시 다루겠당~~~
📝 학습 목표
- Web Server와 Web application Server의 차이를 이해한다.
- Reverse Proxy를 이해하고 적용한다.
🤔 웹 서버 & 웹 어플리케이션 서버
Web Server와 Web Aplication Server???
둘이 무엇이 다른 걸까?
일단, 설명에 들어가기 전에
Web Server의 개념이 먼저 나왔고, Web Aplication Server는 이후에 등장했다는 것을 알아두자.
사실, 웹 기술의 발전 과정을 보면 이해하기 쉽다.
1. 정적 웹 페이지 서비스 : 보통 초기 웹 단계에서는 정적인 HTML 페이지만을 서비스하고, 사용자도 매우 많지 않았다.
2. 웹 서버의 등장 : 초기 웹에서 정적 콘텐츠를 제공하는 데 사용되었다!
Apache, Nginx 등의 웹 서버가 등장하면서, 정적 파일 제공을 위한 서버의 역할이 확립되었다!
3. 동적 웹 페이지와 CGI : 동적 콘텐츠 생성의 요구! -> CGI 와 같은 기술 등장 (이런게 있구나~ 하고 넘어가자)
4. 웹 어플리케이션 서버의 등장 : 그러나 CGI는 성능, 보안 등 많은 문제가 있었다.
이에 대응하기 위해, 동적인 콘텐츠를 생성하고 관리하는 역할인 서버의 등장!
Q. 어떻게 동적인 콘텐츠를 효과적이게 생성할 수 있었을까!?
A. (정적 방식) 미리 정해진 콘텐츠를 준비해두고 (html, css 등 저장해두고) 요청이 오면 응답으로 주는 것이 아닌,
(동적 방식) 요청이 올 때마다 해당 요청에 적절한 콘텐츠를 그때 그때 생성해서 전달할 수 있다면 효율적일 것이다!
* 클라이언트의 요청에 대해 적절한 데이터를 만들어주는 서버 : Web Application Server(WAS)
우리가 자주 쓰는 WAS는 Node.js와 Springboot가 있다!
✒️ 0. 들어가기 전
Web Server가 실제로 어떻게 정적인 콘텐츠를 응답으로 주는지(정적 콘텐츠 호스팅)
Web Application Server와 어떻게 다르며 어떻게 WS와 함께 동작하는지
✒️ 1. Web Server 정적 콘텐츠 호스팅
이전 시간에 말헀던 내용들을 복습해보자.
IP 주소를 통해 식별된 컴퓨터의 프로세스는 특정 포트 번호를 사용하여 데이터를 주고받는다.
그리고 2-2 실습에서 했던 "보안그룹에서 TCP 80번 포트를 열어준 이유" 는
EC2의 IP 주소를 통해 식별 -> 80번 포트로 열림 NGINX로 요청을 보내기 위함!
* Nginx는 빠르고 가벼운 웹 서버로, 정적인 웹 사이트를 호스팅하고 관리하는 데 사용됩니다.
그리고 우리는 NGINX 를 설치한 뒤 다음과 같은 화면을 마주했다!
NGINX가 우리의 요청에 따라 -> 정적인 컨텐츠인 HTML을 응답한 것이다!
물론이 정적 컨텐츠는 미리 저장해둔 것이다!
그럼 Request에 따라 어떤 Response를 줄 건지에 대한 판단은 어떻게 할 수 있을까?
✒️ 2. NGINX에서의 정적 콘텐츠 호스팅
NGINX가 어떻게 실행되는 지 부터 차근차근 알아보자!
웹 서버가 실행될 때 NGINX의 설정 파일을 읽으며 실행된다.
<ubuntu 기준>
/etc/nginx/sites-available 디렉토리에서 default가 nginx의 설정 파일입니다.
(어떤 터미널에서 코드를 치지? : 이전 포스트의 "NGINX 설치하고 브라우저에서 접속해보기 (Test)" 참고)
cd /etc/nginx/sites-available
cat default
해당 명령어를 입력하면, 아래의 default 설정값들이 쭈욱~~~~ 나온다.
그 중에서 중요한 부분만 발췌해보았다.
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
# 중략
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
# 중략
}- listen 80 default_server; & listen [::]:80 default_server; : 서버가 80번 포트에서 요청을 수신한다!
- root /var/www/html; : 웹 페이지 (정적 콘텐츠)파일이 위치한 디렉토리!
- index index.html index.htm index.nginx-debian.html; : 서버가 3개의 파일을 찾아 첫 화면으로 보여준다는 것.
우리가 아까 보았던!!!!! 흰페이지 이다! - server_name _; : 서버가 모든 호스트명에 대해 요청을 수락한다는 것
- location / { ... } : 모든 요청에 대해 정적 파일을 서빙! 존재하지 않는 파일이나 디렉토리에 대해서는 404 에러를 반환.
중요한 것은
root /var/www/html을 통해 정적 콘텐츠를 위치한 시작 디렉토리를 설정하고
index를 통해 기본 요청이 온 경우 어떤 파일을 줄지 설정해 놓았다는 것
->
이에 따라 / Request가 들어오면
/var/www/html/index.nginx-debian.thml을 응답으로 준 것을 확인할 수 있다
💡 nginx 설정 파일에서의 location 블록 수정하기
위에서 location / { ... } 블록은 모든 요청에 대해 정적 파일을 서빙! 해주는 역할이라고 하였다.
해당 파일을 수정해보자!
(해당 파일은 설정 파일로써 기본적으로 'read-only' 권한으로 처리되어 있다.)
(강제로 sudo로 수정해보자.)
* sudo 로 수정할 때는 항상 주의하도록 하자!
cd /etc/nginx/sites-available
sudo vi default
이러면 vi 편집기 모드로 변경될 것이다. (자세한 사용법은 구글링 해보자..)
location / 아래에 해당 코드를 추가해보자!
-> i (편집 모드) -> 키보드로 이동 후 코드 수정 -> exc 누른 후, 마지막 줄이 깜빡일때 -> :wq (저장 후 나가기)
location /temp {
root /var/www;
index temp.html;
try_files $uri $uri/ =404;
}
대충 눈치 챘죠!?
홈화면에 가면 /var/www 디렉토리에 있는 temp.html 띄운다는 것!
cd /var/www
sudo mkdir temp
cd temp
sudo vi temp.html
<h1> 아무말이나 적어봐용 <h1>
sudo systemctl restart nginx <- nginx설정 변경이 되었으니 재실행!
그리고, /temp 로 접근해보면, 해당 페이지를 볼 수 있다!
만약에 권한 문제가 뜬다면... 404 ERROR
https://devfoxstar.github.io/web/nginx-403-forbidden/ 참고
즉,
location /y{
root /x;
index c.html;
}
이 설정은 ip/y/ 로 요청이 오면, /x/y에서 c.hmtl을 찾아라 ! 라는 뜻
즉, 우리의 경우 /temp로 이동했을 때, /var/www/temp 의 temp.html을 찾은 것!
참고로 index는 /y 뒤에 어떤 것도 붙지 않았을 때! 의 경로를 말한다!
root 안에 text.html을 만들면,
ip/temp/text.html로 이동 가능하다!
💡 location block으로 여러 경우 다르게 호스팅 해보기
1. /web 경로에 대해 기본적으로 welcome!이 포함된 html을 보여주고 ddol.html 파일을 요청 할 경우 html 문서를 응답으로 주고 그 외의 경우는 에러 응답
2. /text 경로에 대해서는 기본 호스팅이 없고 hello.txt를 요청 시 hello world 문자열을 응답으로 주고 그 외의 경우는 에러 응답
해당 요구사항에 맞게 한 번 테스트 해보자!
✒️ 3. Web Server VS Web Application Server(WAS)
지금까지 웹 서버가 어떻게 동작하는지!
그리고 어떻게 저장된 정적인 파일들을 응답하는지 알아보았다!
그렇다면, WAS는 어떻게 Web Server와 함께 동작할 수 있을까?
그냥 평소 하던대로 Springboot나 Node.js를 돌리면, WAS만 돌아갈 뿐이지, Web Server는 중간에 없는 형태가 된다..
그럼 우리 tistory를 WAS 하나만 둔 아키텍쳐로 구성하였다고 하자!
(SpringBoot로 돌린다고 가정 :8080)
그럼 우리는 jinhos-devlog.tistory.com:8080으로 접속해야한다...
하지만, 우리는 항상 웹 서버로 요청을 보낸다!
( jinhos-devlog.tistory.com = jinhos-devlog.tistory.com:80 )
(기본적으로 HTTP 프로토콜에서 80번 포트 사용)
어떻게 이런일이 가능하지!?
✒️ 4. Reverse Proxy (역방향 프록시)
역방향 프록시(Reverse Proxy)는 컴퓨터 네트워크 분야에서 사용되는 용어이다!
정의는 : 클라이언트와 서버 간의 통신을 중계하고 보안, 성능 개선 등의 목적을 위해 중간에 위치하는 서버
쉽게 말하면, 클라이언트 요청을 대신 받아서 해당 요청을 서버로 전달하고, 서버로부터 받은 응답을 클라이언트에게 반환해준다!
참고로, 서버가 클라이언트에게 응답을 보내듯이,
connect() 시스템 콜과 같은 요청을 보내는 시스템 콜을 통해 다른 서버에게 다시 요청을 보낼 수도 있다!
💡 순방향 프록시와 역방향 프록시
순방향 프록시(Forward Proxy):
- 클라이언트가 외부 서버에 직접 접근하지 못하도록 막힌 경우, 클라이언트의 요청을 받아 외부 서버에 대신 접근하여 요청을 전달하는 프록시 서버
역방향 프록시(Reverse Proxy)
- 클라이언트의 요청을 받아 백엔드 서버에 전달하고, 백엔드 서버로부터 받은 응답을 클라이언트에게 반환하는 프록시 서버
- 일반적으로 서버의 보안을 강화하고 로드 밸런싱, SSL 암호화, 캐싱, 압축 등의 기능을 제공하는 데 사용된다.
- Gateway도 이러한 방식이다!
✒️ 5. NGINX에서 리버스 프록시 설정하기
기존 NGINX 설정 파일을 아래와 같이 변경해보자!
location / {
proxy_pass http://localhost:3000; <- 프록시 설정
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
위 의 설정을 보면 /요청에 대해 우선적으로 프록시로써 요청을 건네주도록 추가했다.
이 때, localhost:3000의 프로세스로 요청을 보내도록 설정한 것이다.
이는 리버스 프록시를 설정한 것!
이제 sudo systemctl restart nginx로 nginx를 재시작 한 후
다시 재접속 해보자
💡 왜 502 에러가 뜨는가!?
당연히 현재 3000번 포트를 가진 프로세스가 하나도 실행되지 않고 있기 때문...
해당 내용은 나중에 포스팅 에서 다시 다루겠당~~~
