기사 디렉토리
1.Nginx 구성 파일 구조
Nginx의 핵심 구성 파일은 기본적으로 다음과 같이 배치됩니다 /usr/local/nginx/conf/nginx.conf.
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
# 访问目录/usr/local/nginx/html/index.html文件
location / {
root html;
index index.html index.htm;
}
# 当后台报错500 502 503 504 时访问目录/usr/local/nginx/html/50x.html文件
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
nginx.conf 구성 파일에는 기본적으로 전역 블록, 이벤트 블록, http 블록의 세 가지 블록이 있습니다. http 블록에는 여러 서버 블록을 구성할 수 있으며, 각 서버 블록에는 여러 위치 블록을 구성할 수 있습니다.
# 全局块，主要设置Nginx服务器整体运行的配置指令
指令名 指令值;
# events块,主要设置,Nginx服务器与用户的网络连接,这一部分对Nginx服务器的性能影响较大
events {
指令名 指令值;
}
# http块，是Nginx服务器配置中的重要部分，代理、缓存、日志记录、第三方模块配置...
http {
指令名 指令值;
# server块，是Nginx配置和虚拟主机相关的内容
server {
指令名 指令值;
# location块，基于Nginx服务器接收请求字符串与location后面的值进行匹配，对特定请求进行处理
location / {
指令名 指令值;
}
}
...
}
2. Nginx 전역 블록 지침
01. 사용자 명령
user 지시문을 사용하여 Nginx 서버 작업자 프로세스의 실행 중인 사용자 및 사용자 그룹을 지정할 수도 있습니다. 구문은 다음과 같습니다.
user username [groupname];
이 중 username은 지정하려는 사용자 이름으로, 사용자 이름 또는 사용자 ID일 수 있습니다. groupname은 선택 사항이며 사용자가 속한 사용자 그룹을 지정하는 데 사용됩니다. 사용자 그룹을 지정하지 않으면 기본적으로 동일한 사용자 이름을 가진 사용자 그룹이 사용됩니다.
① nginx 구성 파일 nginx.conf를 수정하고 user 지시문을 사용하여 nginx 작업 프로세스의 사용자를 www로 지정합니다.
[root@192 sbin]# cat /usr/local/nginx/conf/nginx.conf
user www;
worker_processes 1;
events {
worker_connections 1024;
}
http {
# ...
}
이렇게 하면 Nginx 작업자 프로세스가 www 사용자로 실행되고 해당 사용자와 동일한 사용자 그룹을 사용하게 됩니다.
② 새로운 사용자 생성 www:
# 1. 测试nginx配置文件语法是否正确
[root@192 sbin]# ./nginx -t
nginx: [emerg] getpwnam("www") failed in /usr/local/nginx/conf/nginx.conf:2
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed
# 2. 添加用户www
[root@192 sbin]# useradd www
[root@192 sbin]# ./nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
# 3. worker进程的默认用户名为nobody
[root@192 sbin]# ps -ef | grep nginx
root 128666 1 0 22:29 ? 00:00:00 nginx: master process ./nginx
nobody 128667 128666 0 22:29 ? 00:00:00 nginx: worker process
root 129163 2727 0 22:41 pts/0 00:00:00 grep --color=auto nginx
# 4. 重新加载nginx配置文件
[root@192 sbin]# ./nginx -s reload
# 5. worker进程的用户名为www
[root@192 sbin]# ps -ef | grep nginx
root 128666 1 0 22:29 ? 00:00:00 nginx: master process ./nginx
www 129167 128666 0 22:41 ? 00:00:00 nginx: worker process
root 129169 2727 0 22:41 pts/0 00:00:00 grep --color=auto nginx
③ 새로운 /root/html/index.html 페이지를 생성하고 nginx.conf 구성 파일을 수정합니다.
<!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>
<p><em>I am WWW</em></p>
</body>
</html>
# 访问root/html/index.html文件
location / {
root /root/html;
index index.html index.htm;
}
④ 구성 파일을 다시 로드하고 액세스 테스트: http://192.168.38.33/ 현재 사용자에게 /root/html 디렉터리에 액세스할 수 있는 권한이 없기 때문에 페이지에서 403 액세스 거부 오류를 보고합니다.
⑤ index.html 파일을 생성 /home/www/html/index.html하고 nginx.conf 구성 파일을 수정합니다.
[root@192 sbin]# mkdir -p /home/www/html
[root@192 html]# cp -r /root/html/ /home/www/
[root@192 sbin]# ./nginx -s reload
# 访问 /home/www/html/index.html 文件
location / {
root /home/www/html;
index index.html index.htm;
}
⑥ 구성 파일을 다시 로드하고 액세스 테스트: http://192.168.38.33/
# 创建用户www时，默认会创建/home/www目录，用户和用户组都是www,而/root/html目录的用户和用户组都是root
[root@192 home]# ll
drwxr-x--- 4 www www 89 9月 1 21:06 www
따라서 user 명령을 사용하여 작업 프로세스를 시작하고 실행하는 사용자 및 사용자 그룹을 지정할 수 있으므로 시스템의 권한 액세스 제어가 더욱 세련되고 안전해집니다.
02. master_process 명령
nginx의 master_process 지시어는 작업자 프로세스 활성화 여부를 제어하는 데 사용됩니다. nginx에서 마스터 프로세스는 작업자 프로세스를 시작 및 중지하고 일부 신호 및 이벤트를 처리하는 관리 프로세스입니다. 마스터 프로세스가 활성화되면 nginx가 시작될 때 마스터 프로세스가 시작되고 마스터 프로세스에 의해 작업자 프로세스가 시작됩니다. 마스터 프로세스가 비활성화되면 nginx는 작업자 프로세스를 직접 시작합니다.
master_process 지시문의 구문은 다음과 같습니다.
master_process on | off;
master_process가 on으로 설정되면 Nginx는 모든 작업자 프로세스를 관리하기 위해 마스터 프로세스를 시작합니다. master_process가 off로 설정되면 Nginx는 기본 프로세스를 시작하지 않고 요청을 처리하기 위해 작업자 프로세스를 직접 시작합니다. 컨테이너에서 Nginx를 실행하는 등 일부 특수한 경우에는 master_process를 off로 설정해야 할 수도 있습니다. 그러나 대부분의 경우 Nginx가 작업자 프로세스를 더 잘 관리할 수 있도록 master_process를 on으로 설정하는 것이 좋습니다.
[root@192 sbin]# ps -ef | grep nginx
www 1447 128666 0 23:53 ? 00:00:00 nginx: worker process
root 1488 2727 0 23:54 pts/0 00:00:00 grep --color=auto nginx
root 128666 1 0 22:29 ? 00:00:00 nginx: master process ./nginx
[root@192 sbin]# vi /usr/local/nginx/conf/nginx.conf
master_process off;
user www;
worker_processes 1;
# ...
[root@192 sbin]# ./nginx -s stop
[root@192 sbin]# ./nginx
[root@192 sbin]# ps -ef | grep nginx
root 53700 1 0 21:19 ? 00:00:00 ./nginx
root 53776 2727 0 21:20 pts/0 00:00:00 grep --color=auto nginx
03. 작업자_프로세스 지시어
nginx의 Worker_processes 지시문은 Nginx가 시작될 때 작업자 프로세스 수를 설정하는 데 사용됩니다. 각 작업자 프로세스는 클라이언트 요청을 처리하는 데 사용되는 독립적인 프로세스입니다.
Worker_processes 지시문의 구문은 다음과 같습니다.
worker_processes number;
그 중 number는 시작할 작업자 프로세스의 개수를 나타내는 정수이다. 일반적으로 서버 리소스를 최대한 활용하려면 숫자를 CPU 코어 수의 두 배로 설정하는 것이 좋습니다.
예를 들어 서버에 CPU 코어가 4개 있는 경우 작업자_프로세스를 8로 설정할 수 있습니다.
worker_processes 8;
작업자 프로세스가 너무 많으면 리소스 경쟁 및 성능 저하가 발생할 수 있으므로 서버의 하드웨어 구성 및 실제 부하 조건에 따라 Worker_processes 설정을 조정해야 합니다.
[root@192 sbin]# vi /usr/local/nginx/conf/nginx.conf
# master_process off;
user www;
worker_processes 2;
# ...
[root@192 sbin]# ./nginx -s stop
[root@192 sbin]# ./nginx
[root@192 sbin]# ps -ef | grep nginx
root 53904 1 0 21:23 ? 00:00:00 nginx: master process ./nginx
www 53905 53904 0 21:23 ? 00:00:00 nginx: worker process
www 53906 53904 0 21:23 ? 00:00:00 nginx: worker process
root 53910 2727 0 21:23 pts/0 00:00:00 grep --color=auto nginx
04. 데몬 커맨드
Nginx의 전역 블록에서 daemon 지시어를 사용하여 Nginx가 데몬 프로세스로 실행되는지 여부를 설정할 수 있습니다. 데몬은 백그라운드에서 실행되는 프로세스로, 터미널이나 콘솔을 차지하지 않으며 시스템이 시작될 때 자동으로 시작될 수 있습니다.
데몬 지시문의 구문은 다음과 같습니다.
daemon on|off;
그 중 on은 Nginx를 데몬 프로세스로 실행하는 것을 의미하고, off는 Nginx를 포그라운드 프로세스로 실행하는 것을 의미합니다. 기본적으로 Nginx는 데몬으로 실행됩니다.
Nginx가 포그라운드 프로세스로 실행되도록 설정된 경우 터미널이나 콘솔에서 Nginx를 시작하는 명령줄은 Nginx가 수동으로 중지될 때까지 터미널이나 콘솔을 차지합니다. 따라서 일반적으로 Nginx를 데몬으로 실행하도록 설정하는 것이 좋습니다.
05. pid 명령
pid 지시문은 Nginx의 현재 마스터 프로세스의 프로세스 ID가 저장되는 파일 경로를 구성하는 데 사용됩니다. 기본값은 /usr/local/nginx/logs/nginx.pid입니다.
06. error_log 명령어
Nginx의 전역 블록은 Nginx 구성 파일의 http 블록 외부에 있는 명령을 나타냅니다. 그 중 error_log 지시문은 Nginx의 오류 로그 파일 경로와 로그 수준을 설정하는 데 사용됩니다.
error_log 지시문의 구문은 다음과 같습니다.
error_log file [level];
file 매개변수는 절대 경로 또는 상대 경로일 수 있는 오류 로그 파일의 경로를 지정합니다. 경로가 슬래시 /로 시작하면 절대 경로를 나타내고, 그렇지 않으면 Nginx 설치 디렉터리에 대한 상대 경로를 나타냅니다. 예를 들어:
error_log /var/log/nginx/error.log;
error_log logs/error.log;
level 매개변수는 선택사항이며 오류 로그의 수준을 설정하는 데 사용됩니다. Nginx는 다음 8가지 로그 수준을 지원합니다.
- 디버그: 디버깅 수준, 자세한 디버깅 정보를 기록합니다.
- info: 정보 수준, 일반 정보를 기록합니다.
- 주의사항: 주의 수준, 주의가 필요한 정보를 기록합니다.
- 경고: 경고 수준, 경고 정보를 기록합니다.
- error: 오류 수준, 오류 정보를 기록합니다.
- crit: 심각도 수준, 심각한 오류 정보를 기록합니다.
- 경보: 경보 수준, 즉각적인 조치가 필요한 정보를 기록합니다.
- emerg: 긴급 수준, 시스템 충돌과 같은 심각한 오류 메시지를 기록합니다.
level 매개변수가 지정되지 않은 경우 기본값은 오류 수준입니다.
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;
이를 설정할 때 info 이하 수준으로 설정하지 않는 것이 좋습니다. 디스크 I/O 소비가 많이 발생하고 Nginx 성능에 영향을 미치기 때문입니다.
07. include 지시어
Nginx의 전역 블록에서는 include 지시문을 사용하여 다른 구성 파일을 도입할 수 있습니다. 이러한 구성 파일에는 http, 서버, 위치 등과 같은 다른 블록이 포함될 수 있습니다. 이러한 방식으로 구성 파일을 여러 파일로 나누어 관리 및 유지 관리를 용이하게 할 수 있습니다.
예를 들어, Nginx의 전역 블록에서 include 지시문을 사용하여 nginx.conf.d라는 디렉터리에 .conf로 끝나는 모든 파일을 도입할 수 있습니다.
include /etc/nginx/nginx.conf.d/*.conf;
이러한 방식으로 Nginx는 이 디렉터리의 모든 구성 파일을 읽고 이를 기본 구성 파일에 병합합니다. 이것의 장점은 더 쉬운 관리 및 유지 관리를 위해 다양한 구성을 여러 파일로 분산시킬 수 있다는 것입니다.
3. Nginx 이벤트 블록에 대한 지침
01. accept_mutex 명령
accept_mutex 지시문은 연결 요청을 처리할 때 작업자 프로세스의 뮤텍스 잠금 메커니즘을 제어하는 데 사용됩니다. Nginx에서는 여러 작업자 프로세스가 동시에 연결 요청을 처리할 수 있지만 경쟁 조건을 피하기 위해 각 작업자 프로세스는 연결 요청을 처리할 때 하나의 작업자 프로세스만 동시에 연결 요청을 처리하도록 보장하기 위해 뮤텍스를 획득해야 합니다. .
accept_mutex on|off;
accept_mutex 지시어는 뮤텍스 잠금을 획득할 때 작업자 프로세스의 동작을 제어하는 데 사용됩니다. 기본적으로 accept_mutex 지시문의 값은 on입니다. 이는 뮤텍스 잠금 메커니즘이 활성화되었음을 의미합니다. 이 경우 각 작업자 프로세스는 연결 요청을 처리할 때 뮤텍스를 획득하려고 시도하며, 획득에 실패하면 절전 상태로 들어가 다른 작업자 프로세스가 뮤텍스를 해제할 때까지 기다린 후 다시 획득을 시도합니다.
accept_mutex 지시문의 값이 off로 설정되면 뮤텍스 잠금 메커니즘이 비활성화된다는 의미입니다. 이 경우 각 작업자 프로세스는 연결 요청을 처리할 때 뮤텍스를 획득하려고 시도하지 않고 대신 연결 요청을 직접 처리합니다. 이 방법은 작업자 프로세스의 동시 처리 기능을 향상시킬 수 있지만 경쟁 조건이 발생할 수도 있으므로 주의해서 사용해야 합니다.
즉, accept_mutex 지시문은 연결 요청을 처리할 때 작업자 프로세스의 뮤텍스 잠금 메커니즘을 제어하는 데 사용되며 실제 상황에 따라 구성할 수 있습니다.
02. multi_accept 지시어
multi_accept 지시문은 여러 네트워크 연결을 동시에 수신하도록 허용할지 여부를 설정하는 데 사용됩니다. multi_accept가 비활성화된 경우 하나의 nginx 작업자 프로세스는 동시에 하나의 새 연결만 허용할 수 있습니다. 그렇지 않으면 작업자 프로세스가 모든 새 연결을 동시에 수락할 수 있습니다.
multi_accept on|off;
그러나 multi_accept를 켜면 작업자 프로세스가 짧은 시간 내에 많은 수의 연결을 처리해야 하기 때문에 CPU 부하가 증가합니다. 따라서 서버의 CPU 자원이 제한되어 있는 경우 multi_accept를 활성화하지 않는 것이 좋습니다. 또한, 서버의 네트워크 대역폭이 작은 경우에는 multi_accept를 활성화하지 않는 것이 좋습니다. 이로 인해 연결 대기 시간이 길어지고 동시 처리 능력이 저하될 수 있기 때문입니다.
03. 작업자_연결 지시어
Worker_connections는 Nginx 서버를 구성하는 데 사용되는 지시어로, 각 작업자 프로세스가 동시에 처리할 수 있는 최대 연결 수를 설정하는 데 사용됩니다.
구문은 다음과 같습니다.
worker_connections number;
기본적으로 Worker_connections 값은 512입니다. 이는 각 작업자 프로세스가 최대 512개의 연결을 동시에 처리할 수 있음을 의미합니다. 이 제한에 도달하면 연결 슬롯을 사용할 수 있을 때까지 새 연결이 지연됩니다.
Worker_connections 값은 서버의 로드 및 성능 요구 사항에 따라 조정되어야 합니다. 서버에서 기본 제한을 초과하는 연결이 자주 발생하는 경우 이 값을 적절하게 늘릴 수 있습니다. 다만, 값이 너무 높을 경우 서버 자원의 과도한 소모가 발생할 수 있으므로 실제 상황에 맞게 조정이 필요하다는 점을 유의하시기 바랍니다.
04. 명령어 사용
use 지시문은 Nginx 서버가 네트워크 메시지를 처리하기 위해 선택하는 이벤트 드라이버를 설정하는 데 사용됩니다.
use method;
기본값은 운영체제에 따라 결정되며, 여기서 선택한 이벤트 처리 모델은 Nginx 최적화 부분에서 중요한 부분이며, 메소드에 대한 선택값으로는 select/poll/epoll/kqueue 등이 있습니다.
05. Events 지시문 구성 예시
Nginx 구성 파일 nginx.conf를 열고 다음 구성을 추가합니다.
events{
accept_mutex on;
multi_accept on;
worker_commections 1024;
use epoll;
}
테스트 시작
./nginx -t
./nginx -s reload
4. Nginx http 차단 지침
01. MIME 유형 정의
브라우저에 표시될 수 있는 콘텐츠에는 다양한 파일, 미디어 및 HTML, XML, GIF 등과 같은 기타 리소스가 포함되어 있으며 이러한 리소스를 구별하기 위해 브라우저는 MIME 유형을 사용해야 합니다. MIME 유형은 웹을 통해 전송되는 파일 유형을 나타내는 데 사용되는 표준입니다. 웹 서버로서 Nginx는 프런트 엔드에서 요청한 리소스 유형도 식별할 수 있어야 합니다.
Nginx 구성 파일에는 기본적으로 두 줄의 구성이 있습니다.
http {
include mime.types;
default_type application/octet-stream;
}
위의 예에서 include 지시어는 기본 MIME 유형 정의 파일 mime.types를 포함하는 데 사용되고 default_type 지시어는 기본 MIME 유형을 설정하는 데 사용됩니다.
예를 들어 특정 인터페이스를 요청할 때 특정 텍스트 문자열이나 json 문자열을 반환해야 하는 경우가 있는데, 로직이 매우 간단하거나 단순히 고정된 문자열인 경우 nginx를 사용하면 빠르게 구현할 수 있으므로 따로 작성할 필요가 없습니다. 요청에 응답하는 프로그램으로, 서버 자원 사용량을 줄이고 매우 빠른 응답 성능을 제공할 수 있습니다.
user www;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
server_name localhost;
# 返回指定的文本字符串
location /get_text {
default_type text/html;
return 200 "This is nginx's text";
}
# 返回json字符串
location /get_json{
default_type application/json;
return 200 '{"name":"TOM","age":18}';
}
location / {
root /home/www/html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
}
테스트 액세스:
[root@192 sbin]# curl -i http://192.168.38.33/get_text
HTTP/1.1 200 OK
Server: nginx/1.16.1
Date: Thu, 31 Aug 2023 14:51:04 GMT
Content-Type: text/html
Content-Length: 20
Connection: keep-alive
This is nginx's text
테스트 액세스:
[root@192 sbin]# curl -i http://192.168.38.33/get_json
HTTP/1.1 200 OK
Server: nginx/1.16.1
Date: Thu, 31 Aug 2023 14:49:51 GMT
Content-Type: application/json
Content-Length: 23
Connection: keep-alive
{
"name":"TOM","age":18}
02. access.log 및 log_format 지시문
nginx의 access.log와 error.log는 서버 접속 및 오류 정보를 기록하는 데 사용되는 로그 파일입니다.
access.log는 요청 시간, 클라이언트 IP 주소, 요청된 URL, HTTP 상태 코드, 응답 크기 등을 포함하여 서버에 도착하는 각 요청에 대한 자세한 정보를 기록합니다. 이 로그 파일은 방문 횟수 계산, 사용자 행동 분석 등 서버 액세스를 분석하는 데 사용될 수 있습니다.
error.log는 요청한 파일이 존재하지 않음, 권한 부족, 서버 내부 오류 등 서버가 요청을 처리할 때 발생하는 오류 정보를 기록합니다. 이 로그 파일은 관리자가 적시에 서버 문제를 발견하고 해결하여 서버의 정상적인 작동을 보장하는 데 도움이 될 수 있습니다.
nginx는 서비스 로그의 형식, 크기, 출력 등을 설정하는 기능을 지원하며, access_log 명령어와 log_format 명령어 두 가지 명령어가 필요합니다.
① nginx의 access_log 지시문은 액세스 로그의 출력 경로와 형식을 구성하는 데 사용됩니다. Position http, server, location해당 구문은 다음과 같습니다.
access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
그중 path는 로그 출력 경로를 지정하며 파일 또는 Unix 도메인 소켓일 수 있습니다. 형식은 미리 정의된 형식이나 사용자 정의 형식을 사용할 수 있는 로그 형식을 지정합니다. buffer 매개변수가 지정되면 버퍼링이 활성화되고 size는 버퍼의 크기를 지정합니다. gzip 매개변수가 지정되면 gzip 압축이 활성화됨을 의미하며 level은 압축 수준을 지정합니다. 플러시 매개변수가 지정되면 버퍼가 정기적으로 새로 고쳐지고 시간이 새로 고침 간격을 지정한다는 의미입니다. if 매개변수가 지정되면 조건을 충족하는 요청만 기록된다는 의미입니다.
② log_format 지시문은 로그 형식과 위치를 정의하는 데 사용되며 http구문은 다음과 같습니다.
log_format name string ...;
그 중 name은 로그 형식의 이름이고 string은 로그 형식의 문자열 표현입니다. 문자열에는 $로 시작하는 변수가 포함될 수 있습니다. 예를 들어, remoteaddr은 클라이언트의 IP 주소를 나타내고, remote_addr은 클라이언트의 IP 주소를 나타냅니다.원격 _ _ _ _에이dd r은 클라이언트 의 IP 주소를 나타내고, request_time은 요청 처리 시간을 나타냅니다. 사전 정의된 변수는 nginx 공식 문서에서 찾을 수 있으며, 변수를 사용자 정의할 수도 있습니다. 로그 형식을 정의한 후 access_log 지시문에서 해당 형식을 사용할 수 있습니다.
③ nginx 구성 파일의 기본 서버 액세스 로그 경로 및 형식:
http {
include mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log logs/access.log main;
server {
# ...
}
}
서버의 액세스 로그 보기:
[root@192 sbin]# tail -f /usr/local/nginx/logs/access.log
192.168.38.1 - - [30/Aug/2023:23:23:38 +0800] "GET / HTTP/1.1" 403 555 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36"
192.168.38.1 - - [30/Aug/2023:23:23:38 +0800] "GET /favicon.ico HTTP/1.1" 403 555 "http://192.168.38.33/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36"
④ nginx 구성 파일에서 서버 액세스 로그 경로 및 형식을 사용자 정의합니다.
http {
include mime.types;
default_type application/octet-stream;
log_format my_log_format '========>$remote_addr=======>';
access_log logs/access.log my_log_format;
server {
# ...
}
}
서버의 액세스 로그 보기:
[root@192 sbin]# tail -f /usr/local/nginx/logs/access.log
========>192.168.38.1=======>
========>192.168.38.1=======>
03. sendfile 명령
Nginx 서버가 파일 전송을 위해 sendfile()을 사용하는지 여부를 설정하는 데 사용됩니다. 이 속성은 정적 자원 처리 시 Nginx의 성능을 크게 향상시킬 수 있습니다.
sendfile 지시문은 파일을 보낼 때 성능을 향상시키는 데 사용됩니다. 이를 통해 Nginx는 커널 공간에서 사용자 공간으로 데이터를 복사하지 않고 디스크에서 네트워크 소켓으로 직접 파일 데이터를 보낼 수 있으므로 CPU 및 메모리 사용량이 줄어듭니다.
Nginx에서는 sendfile 지시어가 기본적으로 활성화되어 있습니다. nginx.conf 파일에서 sendfile 지시문을 설정하여 해당 동작을 제어할 수 있습니다. 예를 들어, 다음 지시문을 사용하여 sendfile을 비활성화할 수 있습니다.
sendfile off;
sendfile 지시문은 정적 파일을 보낼 때만 작동하고 동적으로 생성된 콘텐츠에는 작동하지 않습니다. 또한 sendfile 지시문은 파일 설명자 누출을 일으킬 수 있는 일부 운영 체제와 같은 특정 상황에서 문제를 일으킬 수 있습니다. 따라서 sendfile 지시어를 사용할 때 성능과 안정성을 주의 깊게 테스트하고 평가해야 합니다.
04. keepalive_timeout 명령
keepalive_timeout 지시문은 클라이언트와 서버 간의 연결 유지 시간 제한을 설정하는 데 사용됩니다. 클라이언트와 서버 간의 연결이 연결 유지 상태인 경우 클라이언트는 매번 새 연결을 설정하지 않고도 동일한 연결에서 여러 요청을 보낼 수 있습니다. 이는 연결 설정 및 종료의 오버헤드를 줄이고 성능을 향상시킵니다.
keepalive_timeout 지시어의 구문은 다음과 같습니다:
keepalive_timeout timeout;
그중에서 timeout 매개변수는 연결 유지 연결의 시간 초과 시간을 초 단위로 지정합니다. 지정된 시간 내에 새 요청이 도착하지 않으면 연결이 닫힙니다.
Keepalive를 사용하는 이유는 무엇입니까?
우리 모두는 HTTP가 상태 비저장 프로토콜이라는 것을 알고 있습니다.클라이언트는 서버에 TCP 요청을 보내고 서버는 응답이 완료된 후 연결을 끊습니다. 클라이언트가 서버에 여러 요청을 보내는 경우 각 요청은 연결을 다시 생성해야 하며 이는 상대적으로 더 효율적입니다. keepalive 모드를 사용하면 요청을 처리한 후 TCP 연결을 열린 상태로 유지하도록 서버에 지시할 수 있습니다. 이 클라이언트의 다른 요청이 있는 경우 서버는 효율성을 높이기 위해 새 연결을 다시 생성하는 대신 닫히지 않은 이 연결을 사용합니다. 그러나 이 연결은 영원히 유지될 수 없습니다. 이 경우 연결이 너무 많으면 서버의 성능이 저하될 수 있으므로 이때 타임아웃을 설정해야 합니다.
예를 들어 다음 구성은 연결 유지 연결의 제한 시간을 60초로 설정합니다.
keepalive_timeout 60s;
05. keepalive_requests 지시어
keepalive_requests 지시문은 연결 유지 연결에서 처리되는 최대 요청 수를 설정하는 데 사용됩니다. 클라이언트가 Nginx와 연결 유지 연결을 설정하면 동일한 연결에서 여러 HTTP 요청을 보내 연결 설정 및 종료의 오버헤드를 줄이고 성능을 향상시킬 수 있습니다.
이 명령의 구문은 다음과 같습니다.
keepalive_requests number;
그 중 숫자는 연결 유지 연결에서 처리되는 최대 요청 수를 나타냅니다. 기본값은 100입니다.
연결 유지 연결의 요청 수가 keepalive_requests에 지정된 값에 도달하면 Nginx는 연결이 오랫동안 리소스를 점유하지 못하도록 자동으로 연결을 닫습니다. 이 값을 늘려 성능을 향상시킬 수 있지만, 값이 너무 크면 연결이 오랜 시간 동안 리소스를 점유하여 서버 성능에 영향을 줄 수 있다는 점에 유의하세요.
5. 파일 사례 분석으로 Nginx 구성
요구 사항은 다음과 같습니다.
- http://192.168.200.133:8081/server1/location1에 접속할 때 접속한 페이지는 index_sr1_location1.html입니다.
- http://192.168.200.133:8081/server1/location2에 접속할 때 접속한 페이지는 index_sr1_location2.html입니다.
- http://192.168.200.133:8082/server2/location1에 접속할 때 접속한 페이지는 index_sr2_location1.html입니다.
- http://192.168.200.133:8082/server2/location2에 접속할 때 접속한 페이지는 index_sr2_location2.html입니다.
- 액세스한 리소스가 존재하지 않으면 사용자 정의된 404 페이지가 반환됩니다.
- /server1과 /server2의 구성에는 서로 다른 구성 파일을 사용하고 해당 파일을 /home/www/conf.d 디렉터리에 넣은 다음 include를 사용하여 병합합니다.
- /server1 및 /server2에 대해 각각 액세스 로그 파일을 생성합니다.
① 관련 파일을 생성합니다:
[root@192 sbin]# tree /home/www
/home/www
├── conf.d
│ ├── server1.conf
│ └── server2.conf
└── myweb
├── 404.html
├── server1
│ ├── location1
│ │ └── index_sr1_location1.html
│ ├── location2
│ │ └── index_sr1_location2.html
│ └── logs
│ └── access.log
└── server2
├── location1
│ └── index_sr2_location1.html
├── location2
│ └── index_sr2_location2.html
└── logs
└── access.log
[root@192 home]# cat /home/www/myweb/404.html
<h1>This is 404.html in myweb</h1>
[root@192 home]# cat /home/www/myweb/server1/location1/index_sr1_location1.html
<h1>This is index_server1_location1.html</h1>
[root@192 home]# cat /home/www/myweb/server1/location2/index_sr1_location2.html
<h1>This is index_server1_location2.html</h1>
[root@192 home]# cat /home/www/myweb/server2/location1/index_sr2_location1.html
<h1>This is index_server2_location1.html</h1>
[root@192 home]# cat /home/www/myweb/server2/location2/index_sr2_location2.html
<h1> This is index_server2_location2.html</h1>
② 구성 파일/user/local/nginx/nginx.conf:
[root@192 conf]# vi nginx.conf
# 配置允许运行Nginx工作进程的用户和用户组
user www;
# 配置运行Nginx进程生成的worker进程数
worker_processes 2;
# 配置Nginx服务器运行对错误日志存放的路径
error_log logs/error.log;
# 配置Nginx服务器允许时记录Nginx的master进程的PID文件路径和名称
pid logs/nginx.pid;
events{
# 设置Nginx网络连接序列化
accept_mutex on;
# 设置Nginx的worker进程是否可以同时接收多个请求
multi_accept on;
# 设置Nginx的worker进程最大的连接数
worker_connections 1024;
# 设置Nginx使用的事件驱动模型
use epoll;
}
http{
# 定义MIME-Type
include mime.types;
default_type application/octet-stream;
# 配置允许使用sendfile方式运输
sendfile on;
# 配置连接超时时间
keepalive_timeout 65;
# 配置请求处理日志格式
log_format server1 '===>server1 access log';
log_format server2 '===>server2 access log';
include /home/www/conf.d/*.conf;
}
[root@192 sbin]# ./nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
[root@192 sbin]# ./nginx -s reload
③ 구성 파일/home/www/conf.d/server1.conf:
[root@192 conf.d]# cat server1.conf
server{
# 配置监听端口和主机名称
listen 8081;
server_name localhost;
# 配置请求处理日志存放路径
access_log /home/www/myweb/server1/logs/access.log server1;
# 配置错误页面
error_page 404 /404.html;
# 配置处理/server1/location1请求的location
location /server1/location1{
root /home/www/myweb;
index index_sr1_location1.html;
}
# 配置处理/server1/location2请求的location
location /server1/location2{
root /home/www/myweb;
index index_sr1_location2.html;
}
# 配置错误页面转向
location = /404.html {
root /home/www/myweb;
index 404.html;
}
}
④ 구성 파일/home/www/conf.d/server2.conf:
[root@192 conf.d]# cat server2.conf
server{
# 配置监听端口和主机名称
listen 8082;
server_name localhost;
# 配置请求处理日志存放路径
access_log /home/www/myweb/server2/logs/access.log server2;
# 配置错误页面,对404.html做了定向配置
error_page 404 /404.html;
# 配置处理/server1/location1请求的location
location /server2/location1{
root /home/www/myweb;
index index_sr2_location1.html;
}
# 配置处理/server2/location2请求的location
location /server2/location2{
root /home/www/myweb;
index index_sr2_location2.html;
}
# 配置错误页面转向
location = /404.html {
root /home/www/myweb;
index 404.html;
}
}
⑤ 접속 테스트: 403 Forbidden 오류가 표시됩니다.
nginx 오류 로그를 보면 사용자에게 /home/www/myweb/server1/location1 디렉터리를 읽을 수 있는 권한이 없음을 알 수 있습니다.
[root@192 sbin]# tail -f /usr/local/nginx/logs/error.log
2023/09/01 22:05:36 [error] 113845#0: *6 open() "/home/www/myweb/server1/location1" failed (13: Permission denied), client: 192.168.38.33, server: localhost, request: "GET /server1/location1 HTTP/1.1", host: "192.168.38.33:8081"
⑥ Nginx 프로세스를 실행하는 사용자와 디렉터리 접근 권한을 확인하여 Nginx 프로세스 사용자에게 디렉터리 접근 권한이 있는지 확인합니다.
[root@192 sbin]# ps aux | grep nginx
root 113496 0.0 0.0 20684 1472 ? Ss 21:55 0:00 nginx: master process ./nginx
www 113844 0.0 0.0 21076 1400 ? S 22:04 0:00 nginx: worker process
www 113845 0.0 0.0 21076 1644 ? S 22:04 0:00 nginx: worker process
root 114050 0.0 0.0 112824 980 pts/0 R+ 22:08 0:00 grep --color=auto nginx
[root@192 sbin]# ll /home/www/myweb/server1/location1
-rwxr-x--- 1 root root 46 9月 1 21:04 index_sr1_location1.html
# 给home/www/目录下的目录和文件添加用户名和用户组www
[root@192 home]# sudo chgrp -R www /home/www/
[root@192 home]# sudo chown -R www /home/www/
[root@192 home]# cd /home/www/myweb/server2/location1
[root@192 location1]# ll
-rwxrwxrwx 1 www www 46 9月 1 21:05 index_sr2_location1.html
⑦ 테스트를 실행합니다:
[root@192 sbin]# curl http://192.168.38.33:8081/server1/location2/
<h1>This is index_server1_location2.html</h1>
[root@192 sbin]# curl http://192.168.38.33:8081/server1/location1/
<h1>This is index_server1_location1.html</h1>
[root@192 sbin]# curl http://192.168.38.33:8081/server2/location1/
<h1>This is 404.html in myweb</h1>
[root@192 sbin]# curl http://192.168.38.33:8082/server2/location1/
<h1>This is index_server2_location1.html</h1>
[root@192 sbin]# curl http://192.168.38.33:8082/server2/location2/
<h1> This is index_server2_location2.html</h1>
6. Nginx를 시스템 서비스로 구성
Nginx 서비스 시작 및 중지와 같은 관련 작업을 용이하게 하기 위해 Nginx 애플리케이션 서비스를 시스템 서비스로 설정합니다.구체적인 구현 단계:
① /usr/lib/systemd/system디렉토리에 다음 내용으로 nginx.service를 추가합니다.
[root@192 conf]# cat /usr/lib/systemd/system/nginx.service
[Unit]
Description=nginx web service
Documentation=http://nginx.org/en/docs/
After=network.target
[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop
PrivateTmp=true
[Install]
WantedBy=default.target
② 추가 완료 후, 권한에 문제가 있는 경우, 권한 설정이 필요합니다.
[root@192 conf]# chmod 755 /usr/lib/systemd/system/nginx.service
③ 시스템 명령을 사용하여 Nginx 서비스를 작동합니다.
# 启动nginx服务
[root@192 conf]# systemctl start nginx
Warning: nginx.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[root@192 conf]# systemctl daemon-reload
[root@192 conf]# systemctl start nginx
# 查看nginx服务状态
[root@192 conf]# systemctl status nginx
● nginx.service - nginx web service
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
Active: active (running) since 五 2023-09-01 23:08:54 CST; 2min 24s ago
Docs: http://nginx.org/en/docs/
Main PID: 116647 (nginx)
CGroup: /system.slice/nginx.service
├─116647 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
└─116648 nginx: worker process
9月 01 23:08:54 192.168.38.33 systemd[1]: Starting nginx - high performance web server...
9月 01 23:08:54 192.168.38.33 systemd[1]: New main PID 7638 does not exist or is a zombie.
9月 01 23:08:54 192.168.38.33 systemd[1]: Started nginx - high performance web server.
# 停止nginx服务
[root@192 conf]# systemctl stop nginx
[root@192 conf]# systemctl status nginx
● nginx.service - nginx web service
Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Docs: http://nginx.org/en/docs/
8月 28 22:00:10 192.168.38.33 systemd[1]: Failed to parse PID from file /usr/local/nginx/logs/nginx.pid: Invalid argument
8月 28 22:00:10 192.168.38.33 systemd[1]: Started nginx - web server.
8月 28 22:23:13 192.168.38.33 systemd[1]: nginx.service: main process exited, code=killed, status=9/KILL
8月 28 22:23:13 192.168.38.33 systemd[1]: Unit nginx.service entered failed state.
8月 28 22:23:13 192.168.38.33 systemd[1]: nginx.service failed.
9月 01 23:08:54 192.168.38.33 systemd[1]: Starting nginx - high performance web server...
9月 01 23:08:54 192.168.38.33 systemd[1]: New main PID 7638 does not exist or is a zombie.
9月 01 23:08:54 192.168.38.33 systemd[1]: Started nginx - high performance web server.
9月 01 23:11:27 192.168.38.33 systemd[1]: Stopping nginx web service...
9月 01 23:11:27 192.168.38.33 systemd[1]: Stopped nginx web service.
# 重新启动nginx服务
[root@192 conf]# systemctl restart nginx
# 重新加载nginx配置文件
[root@192 conf]# systemctl reload nginx
# 开机启动nginx服务
[root@192 conf]# systemctl enable nginx
Created symlink from /etc/systemd/system/default.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.
7. Nginx 명령을 시스템 환경에 구성
이전 작업 후에 nginx 구성 파일을 시작, 닫기 또는 다시 로드하려면 먼저 nginx 설치 디렉터리의 sbin 디렉터리에 들어간 다음 nginx 보조 실행 파일을 사용하여 작동해야 한다는 것을 알 수 있습니다. , 작업이 상대적으로 번거롭다고 하는데 이 부분을 어떻게 최적화할 수 있을까요?
① /etc/profile 파일을 수정하고 파일 마지막 줄에 다음을 추가합니다.
export PATH=$PATH:/usr/local/nginx/sbin
[root@192 conf]# vi /etc/profile
[root@192 conf]# source /etc/profile
② 모든 디렉터리에서 nginx 관련 명령의 실행을 테스트합니다.
[root@192 conf]# systemctl status nginx
● nginx.service - nginx web service
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since 五 2023-09-01 23:11:41 CST; 7min ago
Docs: http://nginx.org/en/docs/
Main PID: 116813 (nginx)
CGroup: /system.slice/nginx.service
├─116813 nginx: master process /usr/local/nginx/sbin/nginx
├─116826 nginx: worker process
└─116827 nginx: worker process
9月 01 23:11:41 192.168.38.33 systemd[1]: Starting nginx web service...
9月 01 23:11:41 192.168.38.33 nginx[116810]: nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
9月 01 23:11:41 192.168.38.33 nginx[116810]: nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
9月 01 23:11:41 192.168.38.33 systemd[1]: Failed to parse PID from file /usr/local/nginx/logs/nginx.pid: Invalid argument
9月 01 23:11:41 192.168.38.33 systemd[1]: Started nginx web service.
9月 01 23:11:48 192.168.38.33 systemd[1]: Reloading nginx web service.
9月 01 23:11:48 192.168.38.33 systemd[1]: Reloaded nginx web service.