1. Nginx는 무엇입니까?
Nginx는 종종 부하 분산 서버로 사용되는 고성능 HTTP 및 역방향 프록시 서버입니다.
2. Nginx를 사용하는 이유
크로스 플랫폼, 간단한 구성,
비 차단, 높은 동시 연결 :
20,000 ~ 30,000 개의 동시 연결 처리, 공식 모니터링은 50,000 개의 동시 연결을 지원할 수 있습니다.
작은 메모리 소비 :
10 개의 nginx 만 사용하여 150M 메모리를 차지할 수 있습니다. , Nginx는 단계적 자원 할당 기술을 채택하여
정적 파일을 잘 처리하고 메모리를 적게 사용합니다.
내장 된 상태 확인 기능 :
서버가 다운되면 상태 확인이 수행되고 다시 전송 된 요청은 다음으로 전송되지 않습니다. 다운 서버. 다른 노드에 요청을 다시 제출하십시오.
대역폭 절약 :
GZIP 압축 지원, 브라우저 로컬 캐시
안정성을 높게 추가 할 수 있습니다 .
다운 타임 가능성이 매우 작습니다.
마스터 / 작업자 구조 :
마스터 프로세스,
사용자 요청 을 수신 하기 위한 하나 이상의 작업자 프로세스 생성 비동기 :
브라우저가 nginx를 요청합니다. 서버로 전송 된 모든 사용자 요청은 먼저 수신 된 다음 백엔드 웹 서버로 일회용으로 전송되어 웹 서버, 웹 서버에 대한 부담을 크게 줄이면서 반환 데이터를 수신하는 동안 브라우저 클라이언트
네트워크에 따라 전송됩니다. 핑이 성공하는 한로드 밸런싱
은 여러 nginx 서버를 가질 수 있습니다.
3. Nginx 성능이 그렇게 높은 이유는 무엇입니까?
이벤트 처리 메커니즘 덕분에 :
비동기식 비 차단 이벤트 처리 메커니즘 : epoll 모델 사용, 대기열 제공, 대기열 해결
4. 멀티 스레딩을 사용하지 않는 이유는 무엇입니까?
Apache Tomcat : 여러 프로세스 또는 스레드를 생성하면 각 프로세스 또는 스레드가 CPU와 메모리를 할당하고 (스레드는 프로세스보다 훨씬 작으므로 작업자는 성능보다 높은 동시성을 지원함) 동시성이 너무 높아서 서버 리소스를 소모 할 수 없습니다.
Nginx : 단일 스레드는 요청을 비동기 및 비 차단 방식으로 처리하는 데 사용되며 (관리자는 기본 Nginx 프로세스에서 작업자 프로세스 수를 구성 할 수 있음) (epoll) 각 요청에 대해 CPU 및 메모리 리소스를 할당하지 않아 많은 비용을 절약합니다. 리소스 및 많은 CPU 컨텍스트 전환 감소. 이것이 Nginx가 더 높은 동시성을 지원하는 이유입니다.
Nginx가 요청을 처리하는 방법에 대해 이야기하겠습니다.
먼저 nginx가 시작되면 구성 파일을 구문 분석하여 모니터링해야하는 포트 및 IP 주소를 가져온 다음 nginx의 마스터 프로세스에서
먼저 모니터링되는 소켓을 초기화합니다 (소켓 생성, addrreuse 및 기타 옵션 설정, 지정된 IP 주소 포트에 바인딩 한 다음 수신 대기).
그런 다음 fork (기존 프로세스가 fork 함수를 호출하여 새 프로세스를 생성 할 수 있습니다. fork에 의해 생성 된 새 프로세스를 하위 프로세스라고 함) 및 여러 하위 프로세스가 나옵니다.
그런 다음 자식 프로세스는 새 연결을 수락하기 위해 경쟁합니다. 이 시점에서 클라이언트는 nginx에 대한 연결을 시작할 수 있습니다. 클라이언트가 nginx와 3 방향 핸드 셰이크를 수행하고 nginx와 연결을 설정할 때
이 시점에서 특정 자식 프로세스는 성공적으로 수락하고 설정된 연결의 소켓을 얻은 다음 연결의 nginx 캡슐화, 즉 ngx_connection_t 구조를 만듭니다.
nginx가 비동기 및 비 차단 방식으로 처리되는 이유는 무엇입니까?
요청의 전체 프로세스를 살펴보십시오. 먼저 요청이 들어오고 연결이 설정되고 데이터가 수신되고 데이터가 수신 된 후 데이터가 전송됩니다.
시스템 하단에만 해당되는 읽기 및 쓰기 이벤트입니다. 읽기 및 쓰기 이벤트가 준비되지 않은 경우 작동하지 않아야합니다. 비 차단 방식으로 호출되지 않으면 호출을 차단해야합니다. 이벤트가 준비되지 않은 경우 대기만 가능하며 이제 이벤트가 준비되면 계속할 수 있습니다. 차단 호출은 커널로 들어가서 다른 사람들이 사용할 수 있도록 CPU를 내 보냅니다. 단일 스레드 작업자의 경우 분명히 부적절합니다. 네트워크 이벤트가 더 많으면 모두가 대기합니다. CPU가 유휴 상태이면 아무도 그것을 사용하지 않을 것이고 CPU가 사용될 것입니다. 당연히 높은 동시성은 물론 속도가 올라갈 수 없습니다. 프로세스 수를 늘리라고 하셨는데이 모델과 아파치 스레딩 모델의 차이점은 무엇입니까?주의를 기울이고 불필요한 컨텍스트 전환을 추가하지 마십시오. 따라서 nginx에서 시스템 호출 차단은 가장 금기시됩니다. 차단하지 말고 차단하지 마십시오. Non-blocking은 이벤트가 준비되지 않은 경우 즉시 EAGAIN으로 돌아가 이벤트가 아직 준비되지 않았 음을 알리는 것을 의미합니다. 당황하는 이유는 무엇입니까? 나중에 다시 오십시오. 자, 잠시 후 이벤트가 준비 될 때까지 이벤트를 다시 확인하고,이 기간 동안에는 먼저 다른 일을 한 다음 이벤트가 정상인지 확인하십시오. 차단되지는 않지만 수시로 이벤트 상태를 확인해야하며 더 많은 일을 할 수 있지만 오버 헤드는 적지 않습니다.
nginx에서 지원하는 이벤트 모델
Nginx는 use 명령으로 지정할 수있는 다음과 같은 연결 처리 방법 (I / O 다중화 방법)을 지원합니다.
● 표준 방법 선택. 현재 플랫폼에 더 효과적인 방법이없는 경우 컴파일시 기본 방법입니다. 구성 매개 변수 –with-select_module 및 –without-select_module을 사용하여이 모듈을 활성화하거나 비활성화 할 수 있습니다.
● 설문 조사 표준 방법. 현재 플랫폼에 더 효과적인 방법이없는 경우 컴파일시 기본 방법입니다. 구성 매개 변수 –with-poll_module 및 –without-poll_module을 사용하여이 모듈을 활성화 또는 비활성화 할 수 있습니다.
● kqueue – FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 및 MacOS X에서 사용되는 효율적인 방법입니다. 이중 프로세서 MacOS X 시스템에서 kqueue를 사용하면 커널 충돌이 발생할 수 있습니다.
● epoll- 리눅스 커널 버전 2.6 이상 시스템에서 사용되는 효율적인 방법. SuSE 8.2와 같은 일부 배포판에는 2.4 버전의 커널에서 epoll을 지원할 수있는 패치가 있습니다.
● Linux 커널 버전 2.2.19 이후의 시스템에서 사용되는 rtsig 실행 가능한 실시간 신호. 기본적으로 1024 개 이하의 POSIX 실시간 (대기열) 신호가 전체 시스템에 나타날 수 있습니다. 이 상황은 고부하 서버의 경우 비효율적이므로 커널 매개 변수 / proc / sys / kernel / rtsig-max를 조정하여 대기열 크기를 늘려야합니다. 그러나 Linux 커널 버전 2.6.6-mm2부터이 매개 변수는 더 이상 사용되지 않으며 각 프로세스에 대해 독립적 인 신호 대기열이 있습니다.이 대기열의 크기는 RLIMIT_SIGPENDING 매개 변수로 조정할 수 있습니다. 대기열이 너무 혼잡하면 nginx는 포기하고 연결이 정상으로 돌아올 때까지 poll 메소드를 사용하여 연결을 처리하기 시작합니다.
● / dev / poll – Solaris 7 11 / 99 +, HP / UX 11.22+ (eventport), IRIX 6.5.15+ 및 Tru64 UNIX
5.1A + 에서 사용되는 효율적인 방법 ● eventport – Solaris 10 In에서 사용되는 효율적인 방법 커널 충돌을 방지하려면이 보안 패치를 설치해야합니다.
Linux에서는 epoll만이 효율적인 방법입니다 epoll의 효율성
Epoll은 대량의 핸들을 처리하기 위해 Linux 커널에 의해 개선 된 폴링입니다. epoll을 사용하려면 epoll_create (2), epoll_ctl (2), epoll_wait (2)의 세 가지 시스템 호출 만 필요합니다. 2.5.44 커널 (epoll (4)는 Linux 커널 2.5.44에 도입 된 새로운 API)에서 도입되었으며 2.6 커널에서 널리 사용됩니다.
epoll의 장점
● 많은 수의 소켓 디스크립터 (FD)를 여는 프로세스 지원
선택 가장 견딜 수없는 것은 프로세스가 FD_SETSIZE로 설정된 특정 한계 (기본값은 2048)를 여는 것입니다. 수만 개의 연결을 지원해야하는 IM 서버의 경우 분명히 너무 적습니다. 이때이 매크로를 수정 한 다음 커널을 다시 컴파일하도록 선택할 수 있지만 정보에 따르면 네트워크 효율성이 저하된다는 내용도 있습니다. 둘째, 다중 프로세스 솔루션 (기존 Apache 솔루션)을 선택할 수 있습니다. 그러나 Linux에서 생성되었지만 프로세스 비용은 상대적으로 적지 만 여전히 무시할 수 없으며 프로세스 간의 데이터 동기화가 스레드 간의 동기화보다 훨씬 덜 효율적이므로 완벽한 솔루션이 아닙니다. 그러나 epoll에는이 제한이 없습니다. 지원하는 FD의 상한은 열린 파일의 최대 개수입니다.이 숫자는 일반적으로 2048보다 훨씬 큽니다. 예를 들어 1GB의 메모리가있는 컴퓨터에서 약 100,000 개입니다. 특정 개수 cat / proc / sys / fs / file-max 일 수 있습니다. 일반적으로이 숫자는 시스템 메모리와 많은 관련이 있습니다.
● IO 효율성은 FD 수가 증가해도 선형 적으로 감소하지 않습니다.
기존 선택 / 폴링의 또 다른 치명적인 약점은 많은 소켓 세트가 있지만 네트워크 지연으로 인해 소켓의 일부만 항상 "활성"상태이지만 select / poll은 매번 모든 소켓을 선형으로 스캔합니다. call 효율성의 선형 감소의 결과입니다. 그러나 epoll에는이 문제가 없습니다. "활성"소켓에서만 작동합니다. epoll은 커널 구현에서 각 fd의 콜백 함수에 따라 구현되기 때문입니다. 그러면 "활성"소켓 만 콜백 함수를 능동적으로 호출하고 다른 유휴 상태 소켓은 호출하지 않습니다.이 시점에서 epoll은 "의사"AIO를 구현합니다.이 시점의 추진력은 os 커널이기 때문입니다. 일부 벤치 마크에서 모든 소켓이 기본적으로 활성화 된 경우 (예 : 고속 LAN 환경에서 epoll은 select / poll만큼 효율적이지 않습니다. 반대로 epoll_ctl을 너무 많이 사용하면 효율성이 약간 떨어집니다. 그러나 일단 유휴 연결을 사용하여 WAN 환경을 시뮬레이션하면 epoll의 효율성이 선택 / 폴링보다 훨씬 높습니다.
● mmap을 사용하여 커널과 사용자 공간 간의 메시지 전송을 가속화합니다.
이것은 실제로 epoll의 구체적인 실현을 포함합니다. select, poll, epoll에 관계없이 커널은 FD 메시지를 사용자 공간에 알려야합니다. 불필요한 메모리 복사를 방지하는 방법은 매우 중요합니다.이 시점에서 epoll은 커널과 사용자 공간 mmap에 의해 동일하게 구현됩니다. 기억. 2.5 커널에서 epoll을 따르기를 원한다면 수동 mmap 단계를 절대 잊지 못할 것입니다.
● 커널 미세 조정
이것은 실제로 epoll의 장점이 아니라 전체 Linux 플랫폼의 장점입니다. Linux 플랫폼을 의심 할 수도 있지만 커널을 미세 조정하는 기능을 제공하는 Linux 플랫폼을 피할 수는 없습니다. 예를 들어 커널 TCP / IP 프로토콜 스택이 메모리 풀을 사용하여 sk_buff 구조를 관리하는 경우이 메모리 풀 (skb_head_pool)의 크기는 런타임 동안 동적으로 조정될 수 있습니다. echo XXXX> / proc / sys / net / core / hot_list_length. 예를 들어, 수신 기능의 두 번째 매개 변수 (TCP가 3 방향 핸드 셰이크를 완료하기위한 패킷 대기열의 길이)는 플랫폼의 메모리 크기에 따라 동적으로 조정할 수 있습니다. 데이터 패킷의 수는 많지만 각 데이터 패킷 자체의 크기는 작은 특수 시스템에서 최신 NAPI 네트워크 카드 드라이버 아키텍처를 사용해보십시오.
(epoll 콘텐츠는 epoll_ Interactive Encyclopedia 참조)
작업자 수를 CPU 코어 수로 설정하는 것이 좋습니다. 여기서 이해하기 쉽습니다. 작업자가 많을수록 프로세스가 CPU 리소스를 놓고 경쟁하게됩니다. 필요한 컨텍스트 전환. 또한 nginx는 멀티 코어 기능을보다 효율적으로 활용하기 위해 CPU 어피 니티에 대한 바인딩 옵션을 제공하며, 프로세스 전환으로 인해 캐시가 무효화되지 않도록 특정 프로세스를 특정 코어에 바인딩 할 수 있습니다. 이와 같은 작은 최적화는 nginx에서 매우 일반적이며 nginx 작성자의 고된 노력을 보여줍니다. 예를 들어 nginx가 4 바이트 문자열을 비교할 때 4 개의 문자를 int 유형으로 변환 한 다음 비교하여 CPU의 명령어 수를 줄입니다.
5. Nginx는 요청을 어떻게 처리합니까?
먼저 nginx가 시작되면 구성 파일을 구문 분석하여 모니터링해야하는 포트와 IP 주소를 얻은 다음 nginx의 마스터 프로세스에서 먼저 모니터링되는 소켓을 초기화 한 다음 수신 대기 한 다음 여러 하위 프로세스를 분기합니다. . 하위 프로세스는 새 연결을 수락하기 위해 경쟁합니다.
이 시점에서 클라이언트는 nginx에 대한 연결을 시작할 수 있습니다. 클라이언트가 nginx와 3 방향 핸드 셰이크를 수행하고 nginx와 연결을 설정하면 특정 자식 프로세스가 성공적으로 수락 한 다음 연결을 캡슐화하는 nginx, 즉 ngx_connection_t 구조를 생성하고 이에 따라 해당 이벤트 처리 모듈을 호출합니다. http 모듈과 같은 이벤트에 클라이언트와 데이터를 교환합니다.
마지막으로 nginx 또는 클라이언트가 주도적으로 연결을 종료합니다.이 시점에서 연결이 끊어집니다.
6. 정방향 프록시, 역방향 프록시 정방향 프록시의
요약은 한 문장으로 : 프록시 프록시는 클라이언트입니다. 예를
들어 Google에 대한 국내 액세스는 벽에 의해 차단되지만 다른 국가의 서버에 액세스하여 결과를 얻을 수 있습니다. 구글에 액세스.
프록시 경우가 긍정적 인 경우, 다른 국가의 서버에 직접 벽의 문제와 앞으로 여러분의 방문을 해결
클라이언트와 실제 서버 사이에 위치한 서버 구글에서 . 콘텐츠를 얻기 위해서는 프록시는 요청을 보내고 대상 (원래 서버)을 지정한 다음 프록시는 요청을 원본 서버로 전달하고 획득 한 콘텐츠를 클라이언트에 반환합니다. 클라이언트는 정방향 프록시를 사용할 수 있습니다.
역방향 프록시 요약은 한 문장 일뿐입니다. 프록시 프록시는 서버
역방향 프록시로 방문하려는 주소가 어디에 있는지 전혀 모르지만 일단 서버를 방문하면이 서버가 실제로 다른 서버를 방문합니다. 이후 데이터를 가져 오면 사용자에게 반환됩니다. 데이터의 출처도 모릅니다.
역방향 프록시는 프록시 서버를 사용하여 인터넷에서 연결 요청을 수락 한 다음 내부의 서버로 요청을 보내는 것을 의미합니다. 획득 한 결과는 인터넷에서 연결을 요청하는 클라이언트에게 반환됩니다. 이때 프록시 서버는 외부에서 역방향 프록시 서버 역할을합니다.
7.
동적 리소스와 정적 리소스의 분리는 동적 동적 웹 사이트의 웹 페이지를 특정 규칙에 따라 분리합니다. 변경 가능한 리소스는 자주 변경되는 리소스와 구별됩니다. 동적 리소스와 정적 리소스를 분리 한 후 정적 리소스의 특성에 따라 캐시 할 수 있습니다. 이것이 핵심 아이디어입니다. 웹 사이트 정적 처리
동적 리소스와 정적 리소스의 분리 간단한 요약은 동적 파일과 정적 파일의 분리입니다.
위치 ~. (png | jpg | css | js | htm | html) { root / home }
8. 동적 및 정적 분리를 수행하는 이유는 무엇입니까?
소프트웨어 개발에서 일부 요청은 백그라운드에서 처리해야하며 (예 : .jsp, .do 등) 일부 요청은 백그라운드에서 처리 할 필요가 없습니다 (예 : css, html, jpg, Node.js 등 파일)
백그라운드에서 처리 할 필요가없는 이러한 파일을 정적 파일이라고하며 그렇지 않으면 동적 파일이라고합니다. 따라서 백그라운드 처리는 정적 파일을 무시합니다. 누군가 내가 백그라운드에서 정적 파일을 무시하면 끝날 것이라고 말할 것입니다.
물론 가능하지만 백그라운드의 요청 수가 크게 증가합니다. 리소스의 응답 속도에 대한 요구 사항이있는 경우이 동적 및 정적 분리 전략을 사용하여 동적 및 정적 분리를 해결해야합니다. 웹 사이트 정적 리소스 (HTML, JavaScript, CSS, img 등 파일)를 백엔드 응용 프로그램에서 사용자 향상 정적 코드에 액세스하는 속도는 백그라운드 애플리케이션에 대한 액세스를 줄입니다.
여기서 우리는 정적 자원을 nginx에 넣고 동적 자원을 tomcat 서버로 전달합니다. 결국 Tomcat의 장점은 동적 요청을 처리하는 것입니다.
9.로드 밸런싱
로드 밸런싱은 프록시 서버가 수신 된 요청을 각 서버에
균형 잡힌 방식으로 분배하는 것을 의미합니다. 로드 밸런싱은 주로 네트워크 혼잡 문제를 해결하고 서버 응답 속도를 높이며 주변 서비스를 제공하며 액세스 품질을 향상시키고 백그라운드를 줄입니다. 서버 동시성 압력
tomcatlist { ip + port [ weigth = 3 ], ip + port [weigth = 1 ], … } location / { pass_proxy tomcat }
10. nginx와 Apache의 차이점
가볍고 Apache보다 적은 메모리와 리소스를 차지합니다.
Anti-concurrency, nginx 처리 요청은 비동기 및 비 차단이며 Apache는 차단합니다. 높은 동시성에서 nginx는 낮은 리소스, 낮은 소비 및 고성능을 유지할 수 있습니다.
고도로 모듈화 된 디자인, 비교적 간단한 모듈 작성
핵심 차이점은 apache는 동기식 다중 프로세스 모델이고 하나의 연결은 하나의 프로세스에 해당하고, nginx는 비동기식이며 여러 연결 (만 수준)은 하나의 프로세스에 해당 할 수 있다는 것입니다.
nginx의 최적화 옵션은 무엇입니까?
일반적으로 사용되는 nginx의 최적화 콘텐츠에는 주로 다음 콘텐츠가 포함됩니다.
1. 버전 정보 숨기기
2. 수정할 nginx의 소스 코드 숨기기
3. nginx 서비스의 기본 사용자 변경
4. nginx 시작을위한 낮은 전력
5. nginx 프로세스 수 최적화
6. 다른 nginx 프로세스를 다른 CPU에 바인딩
7. Nginx 이벤트 처리 모델 최적화
8. 단일 nginx 프로세스에서 허용하는 최대 클라이언트 연결 수 조정
9. nginx 작업자 프로세스에서 열린 파일 수 구성
10. 효율적인 파일 전송 모드 켜기
11. 성능 최적화를위한 Nginx gzip 압축
12. 로그 폴링을 구현하는 스크립트 작성
13. 불필요한 로그를 기록하지 마십시오
14. 액세스 로그에 대한 권한 설정
15. 확장자에 따라 프로그램 및 파일 액세스 제한
16. 지정된 디렉토리의 모든 파일 및 디렉토리에 대한 액세스 금지
17. 웹 사이트 소스에서 IP 액세스 제한
18. 불법 도메인 이름 확인이 회사 웹 사이트에 액세스하지 못하도록 nginx 구성
19.nginx 반 파충류 최적화
20. nginx 동시 연결 수 제어