nginx 의 누락 된 부분 을 조사 하여 보충 하 다.

nginx 작업 원리
nginx 는 핵심 과 모듈 로 구성 되 어 있 으 며, 핵심 은 설정 파일 을 찾 아 클 라 이언 트 요청 을 하나의 location 에 표시 합 니 다. location 에 설 치 된 모든 명령 은 서로 다른 모듈 을 시작 하여 해당 하 는 작업 을 수행 합 니 다.
nginx 모듈 은 기능 에 따라 구분 되 어 있 습 니 다.
    Handler (프로세서 모듈): 요청 을 직접 처리 하고 출력 합 니 다.
    Filters (필터 모듈): 프로세서 모듈 의 출력 내용 을 수정 합 니 다.
    Proxies (에이전트 모듈): 백 엔 드 의 일부 서비스 와 상호작용 을 하여 서비스 에이전트 와 부하 균형 등 기능 을 실현 합 니 다.
요청 --- > nginx 커 널 --- > handler 모듈 --- > filers 모듈 --- > http 해당
nginx 작업 방식: 단일 작업 프로 세 스 와 다 중 작업 프로 세 스 가 있 습 니 다.
    단일 작업 프로 세 스: 주 프로 세 스 를 제외 하고 작업 프로 세 스 도 있 습 니 다. 작업 프로 세 스 는 단일 스 레 드 입 니 다.nginx 기본 값 은 단일 프로 세 스 모드 입 니 다.
          주 프로 세 스 역할: 1. 외부 요청 을 받 고 작업 프로 세 스에 요청 을 맡 깁 니 다.
                 2. 작업 프로 세 스 의 운행 상 태 를 모니터링 합 니 다.
    다 중 작업 프로 세 스: 작업 프로 세 스 는 여러 스 레 드 를 포함 합 니 다.
nginx 는 어떻게 높 은 병발 과 경량급 을 실현 합 니까?
   nginx 는 비동기 적 으로 막 히 지 않 는 이벤트 처리 체 제 를 사용 하여 프로 세 스 가 여러 개의 준 비 된 사건 을 순환 적 으로 처리 합 니 다.epoll 의 경우 준비 되 지 않 은 사건 은 모두 epoll 에 넣 고 이벤트 가 준비 되면 처리 합 니 다.한편, apache 는 모든 요청 이 하나의 작업 스 레 드 를 독점 합 니 다. 병발 수가 수천 에 이 르 렀 을 때 수천 개의 스 레 드 가 요청 을 처리 하고 있 습 니 다. 사용 하 는 메모리 가 매우 크 고 스 레 드 의 컨 텍스트 전환 에 따 른 cpu 비용 도 많 으 며 성능 도 올 라 가기 어렵 습 니 다. 또한 이러한 판 매 는 전혀 의미 가 없습니다. 
nginx 부하 균형 실현
    nginx 가 지원 하 는 스케줄 링 알고리즘:
        1. 폴 링 (기본 값): 설정 파일 의 순서에 따라 요청 을 백 엔 드 서버 에 순서대로 배정 합 니 다.
        2. weight: 가중 폴 링, weight 값 이 클 수록 분 배 된 방문 확률 이 높 습 니 다.

upstream lzs.com {
    server 192.168.1.1 weight=2;
    server 192.168.1.2 weight=1;
    }

        3、ip_hash: 같은 ip 의 방문객 이 같은 백 엔 드 서버 에 고정 적 으로 접근 하여 session 공유 문 제 를 해결 합 니 다.

upstream lzs.com {
    ip_hash;
    server 192.168.1.1 ;
    server 192.168.1.2 ;
    }

  4、url_hash: 같은 url 의 접근 이 같은 백 엔 드 서버 로 향 하고 백 엔 드 캐 시 서버 의 효율 을 향상 시 킵 니 다. 이 알고리즘 을 사용 하려 면 nginx 의 hash 패 키 지 를 다운로드 해 야 합 니 다.
  5. fair: 백 엔 드 서버 의 해당 시간 에 따라 분 배 됩 니 다. 해당 시간 이 짧 은 우선 분 배 됩 니 다. 이러한 알고리즘 을 사용 하려 면 nginx 의 upstream 을 다운로드 해 야 합 니 다.fair 모듈
  6、least_conn: 최소 연결, 웹 요청 은 연결 수가 가장 적은 서버 로 전 송 됩 니 다.
 server 명령 은 백 엔 드 서버 의 ip 와 포트 를 지정 하 는 것 외 에 모든 서버 가 부하 균형 스케줄 링 중인 상 태 를 지정 할 수 있 습 니 다. 자주 사용 하 는 상 태 는 다음 과 같 습 니 다.
    down: 이 서버 는 부하 균형 에 참여 하지 않 습 니 다.
    backup: 다른 서버 가 요청 할 수 없 을 때 만 이 서버 를 사용 합 니 다.

upstream lzs.com {
    server 192.168.1.1;
    server 192.168.1.2 backup;
    }

    *스케줄 링 알고리즘 은 iphash 시 상태 가 backup 일 수 없습니다.
위치 일치 규칙
    1. 매 칭 은 일반 매 칭 과 정규 매 칭 으로 나 뉘 고 일반 매 칭 은 정확 한 매 칭 과 최대 접두사 매 칭 으로 나 뉜 다.
    2 、 일반 매 칭 먼저 매 칭 하고 정규 매 칭
   3 、 정규 매 칭 은 최대 접두사 매 칭 을 덮어 씁 니 다
    4. 보통 location 앞 에 지 정 했 어 요. " ^~ ”이 항목 이 일치 할 때 더 이상 일치 하지 않 아 도 됩 니 다.
    5. 매 칭 이 정확하게 일치 할 때 더 이상 매 칭 할 필요 가 없습니다.
  요약: 일치 하 는 우선 순위: 정확 한 일치 > 지정 한 "^ ~" 의 일반 일치 > 정규 일치 > 최대 접두사 일치
 예:

location / {......}    #      ，   /   url，         
location = / {......}    #    url=/，      
location ^~/img/ {……}    #   /img/   url，      
location ~ .*\.(gif|jpg|png)$ {……}    #      

  대소 문자 구분
    ~*：대소 문자 구분 없 음
nginx 에이전트 부분 에서 X - Real - IP 와 X - Forward - for 의 차이 점:
일반적으로 X - Forward - for 는 프 록 시 정 보 를 기록 하 는 데 사용 되 며, 1 급 프 록 시 (익명 프 록 시 제외) 를 거 칠 때마다 프 록 시 서버 는 이번 요청 의 원본 IP 를 X - Forward - for 에 추가 합 니 다.
4.4.4 에서 온 요청 입 니 다. header 는 이 줄 을 포함 합 니 다.

X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3

대표 요청 은 1.1.1.1 에서 보 내 고 3 층 대 리 를 거 쳐 1 층 은 2.2.2.2 이 고 2 층 은 3.3.3.3 이 며 이번 요청 의 출처 는 IP 4.4.4 가 3 층 대리 이다.
반면 X - Real - IP 는 관련 기준 이 없고 위의 예 는 X - Read - IP 가 설정 되 어 있 으 면 두 가지 상황 이 있 을 수 있 습 니 다.

//          ，          IPX-Real-IP: 1.1.1.1
//          ，  Nginx，              IPX-Real-IP: 3.3.3.3

일반적으로 X - Forward - for 를 사용 하면 효과 가 좋 고 완전한 프 록 시 링크 를 기록 할 수 있 습 니 다.
nginx 의 proxy pass 후 url 추가 / 차이 점

1、location /test1/ { 
                proxy_pass http://test2; 
     }

2、location /test1/ { 
                proxy_pass http://test2/; 
     }

위의 두 가지 설정 은 proxy pass 가 전송 하 는 경로 뒤에 있 는 지 여부 에 만 차이 가 있 습 니 다. “/” 상황 1: url 에 접근 하면 =http://test1/test/test.htmlnginx 에이전트 에 의 해 요청 경 로 는 질문 합 니 다.http://test2/test/test.html, test / 를 루트 경로 로 하여 test / 경로 의 자원 을 요청 합 니 다. 
상황 2: url 에 접근 하면 =http://test1/test/test.htmlnginx 에이전트 에 의 해 요청 경로 가 변 경 됩 니 다.http://test2/test.html, server 의 루트 자원 에 직접 접근 
nginx 에서 proxy pass 와 rewrite 의 차이
proxy pass 는 일반적으로 정 의 된 백 엔 드 서버 로 요청 을 바 꾸 는 데 사 용 됩 니 다. 정규 표현 식 매 칭 은 지원 되 지 않 습 니 다.
rewrite 는 일반적으로 요청 한 도 메 인 이름 뒤에 전 달 된 매개 변 수 를 제외 한 문자열 을 수정 하 는 데 사 용 됩 니 다. 정규 표현 식 매 칭 을 지원 합 니 다.http://seanlook.com/a/we/index.php?id=1&u=str / a / we / index. php 만 다시 쓰기
상세 한 것 은 박문 을 참고 할 수 있다http://blog.csdn.net/mchdba/article/details/50042387。
도 난 방지 체인
도 난 은 한 사이트 가 다른 큰 사이트 의 자원 (예 를 들 어 음악, 다운로드, 사진 등) 을 말한다.의 주 소 는 자신의 사이트 에 놓 여 있 습 니 다. 이렇게 자원 이 없 는 사 이 트 는 다른 사이트 의 자원 을 이용 하여 조회 자 에 게 보 여 주 었 고 자신의 사이트 의 방 문 량 을 향상 시 켰 습 니 다. 원래 사이트 에 대해 한편 으로 는 대부분의 데이터 가 손실 되 었 고 다른 한편 으로 는 서버 의 부담 을 가중 시 킬 수 있 습 니 다.
도 난 방지 체인 원리: HTTP 프로 토 콜 의 refer 헤더 필드 를 이용 하여 refer 는 요청 이 어디서 연결 되 었 는 지 기록 하고 refer 를 통 해 링크 출처 를 추적 합 니 다. 원본 이 본 사이트 가 아 닌 것 을 감지 하면 지정 한 페이지 를 막 거나 되 돌려 줍 니 다.
nginx 에서 도 난 방지 체인 설정 은 박문 을 참고 할 수 있 습 니 다.http://blog.csdn.net/yuwenruli/article/details/8541952。