# Nginx 선택 근거

###### tags: `유플러스-What I learned`

### 웹 서버
- HTTP 요청을 읽어서 응답을 해주는 프로그램
- 상용으로 많이 쓰이는 웹 서버 프로그램은 크게 apache와 nginx 있음.

### Apache vs nginx

#### 1. Apache
- 기본적으로 2가지 방식이 있음.
- Prefork MPM(Multi Processing Module)
- HTTP 요청이 올 때마다 프로세스 복제해서 각각 별도 프로세스에서 해당 HTTP 요청 처리
- Worker MPM
- 하나의 HTTP 연결 후, 여러 요청을 처리하기 위해 복제된 프로세스 내에서 여러 쓰레드를 생성해서 여러 HTTP 요청

- 아무래도 이런 방식은 프로세스를 생성하든 쓰레드를 생성하든 요청에 따라 뭔가를 생성해야한다. 더 좋은 방법이 없을까?

#### 2. Nginx
- Event Driven 방식으로 구동
- 하나의 프로세스로 동작하며, HTTP 요청을 event로 비동기식으로 처리함.
- 대부분의 HTTP 응답은 결국 html 파일을 제공하는 것이므로, IO 작업. IO 작업으로 event를 포워딩하고, 요청 순이 아닌, 요청이 끝난 순으로 처리함.
- HTTP 요청마다 프로세스든 쓰레드등 생성이 필요없으므로, 시스템 자원 관리에 장점이 있음.

#### 결론
Apache와 nginx 중 HTML 파일 사이즈, 어떤 추가 기능을 쓰느냐 등 다양한 조건 때문에 무엇이 더 무조건 성능이 좋다고는 이야기 할 수 없음. 하지만 많은 접속자가 있을 경우, 시스템 자원 관리 효율성 때문에 Nginx가 일반적으로는 성능이 더 좋을 수 있으므로 해당 프로젝트에서는 Nginx를 사용함.

### ubuntu 컨테이너 만들어서 실습해보기

- 내부는 80, 외부는 8080으로 열어주기 / 컨테이너 이름 myos / 우분투 20.04 사용하겠다.
$ sudo su
$ docker run -dit -p 80:8080 --name myos ubuntu:20.04

- 컨테이너 접속하기
$ docker exec -it myos /bin/bash

$ apt-get update

- nginx 설치
$ apt-get install nginx=1.18.0-0ubuntu1

$ apt-get install vim

- nginx conf 파일 찾아보기
$ find -name nginx.conf
> ./etc/nginx/nginx.conf

이 설정 파일에 대해 완벽히 이해할 필요는 없음! 추후 참고용

- include


이렇게 include 된 폴더의 파일들이 자동으로 nginx.conf의 include 명령을 통해 웹 서버에 적용 됨.

- include 된 sited-enabled의 default 파일을 보자.
- listen은 HTTP 요청을 받을 포트 설정
- default_server는 모든 웹서버 요청을 받는다는 의미


- 포트 8080으로 설정해보자.

- 수정 했으니까 nginx 다시 켜보기

$ service nginx restart
(이 명령도 확인해 봐야함.)

- 현재 ip 주소로 가면 nginx 기본 index.html 파일 보임.


- root 뒤에 어디에서 html 파일 참고하겠냐가 정의 돼 있음.


- 폴더에서 index 찾고 없으면 index.html 찾고 없으면 index.nginx-debian.htm 찾겠다.

- index.nginx-debian.html을 수정해보자

- html 파일 있는 경로 가보기

$ cd /var/www/html

$ vi index.nginx-debian.html



- blog 라는 데로 리다이렉트 보내고 싶어.

- $ cd /var/www
- $ cd html
- $ cp index.nginx-debian.html ../blog/index.html
- $ cd blog
- $ vi index.html
- Welcome to Blog로 바꿔주기
- sites-enabled default 파일도 수정 (location)

- localhost/blog/


# nginx reverse proxy

### Proxy Server
- 원래 클라이언트와 서버가 통신을 함.
- 여기에 중간에 있으면서 뭔가 다른 곳으로 연결한다든지 하는 역할
- 클라이언트가 자신을 통해 `다른 네트워크 서비스에 접속`하게 해줄 수 있는 서버

### Forward Proxy란


- 중국은 Forward Proxy 서버가 있어서 중국 내 모든 사용자의 접속을 다 받아서, 국외 인터넷 접속을 제어함.
이렇게 중간에 있으면서 어디로 가는 거 막아주는 역할도 할 수 있음.

- 클라이언트가 외부 인터넷에 직접 접근하는 것이 아니라,
- 클라이언트가 Proxy 서버에 외부 인터넷 접근 요청을 하고,
- Proxy Server가 외부 인터넷에 대신 접속하여 결과를 받은 후, 클라이언트에 전달하는 서버


- 꼭 나쁜 건 아닌게, 아프리카에서 한국서버 접속하려는데 너무 느리다 => 클라이언트가 자주 접속하는 외부 인터넷 서비스를 캐쉬로 저장해서 성능향상 가능

### Reverse Proxy란

- 클라이언트가 Reverse Proxy에 요청하면, Reverse Proxy가 관련 요청에 따라 적절한 내부 서버에 접속하여, 결과를 받은 후, 클라이언트에 전달.

#### 예시1 : 트래픽 몰릴 때 분산


#### 예시2 : 적절한 서버로 이동


- 즉, 서버를 여러대 두고, 클라이언트가 요청하면 `적절한 서버로 분산`해주는 기능

- 내부 데이터베이스 등의 직접 접속등을 허용하지 않을 수 있으므로 보안에도 유익함.

- 요청 트래픽을 관리할 수 있는 로드 밸런싱 등에도 유익함.

### Forward와 Reverse 차이가 뭐냐?

Reverse는 목적지 서버 내부를 한번 거쳤다가 출발지 서버로 해당 내용을 보내주는 거고 (그러니까 `사용자는 목적지 서버랑 직접 접속은 못하는 거!`)

Forward는 경유지 느낌으로 목적지 서버 가는거!