English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية

  1. 위치
  2. 홈페이지
  3. 경험 노트
  4. 본문

Nginx代理 기능 및 로드バランス 상세 설명

서론

Nginx의 대리 기능과 로드 밸런싱 기능은 가장 많이 사용되는 기능입니다. Nginx의 기본 문법 및 설정에 대한 사항은 이전 기사에서 설명했습니다. 이 기사에서는 대리 기능에 대해 먼저 설명하고, 로드 밸런싱에 대해 자세히 설명합니다.

Nginx 대리 서비스 설정 설명

1이전 기사에서 http 모듈에 다음과 같은 설정이 있습니다. 대리 서버가 상태 코드가404때, 우리는404페이지를 백도우로 이동시킵니다.

error_page 404 https://www.baidu.com; # 오류 페이지

그러나 이 설정은 주의 깊은 사람들에게는 작동하지 않는 것을 발견할 수 있습니다.

이를 작동시키기 위해 반드시 아래의 설정과 함께 사용해야 합니다

proxy_intercept_errors on;  # 대리 서버가 반환하는 상태 코드가400 또는 더 큰 값400, 설정된 error_page 설정이 작동합니다. 기본적으로 off입니다.

2만약 우리의 대리 서버가 get, post 요청 메서드 중 하나만을 받아들이는 경우

proxy_method get;  # 클라이언트의 요청 메서드를 지원합니다. post/get；

3지원하는 http 프로토콜 버전을 설정합니다

proxy_http_version 1.0 ; #Nginx服务器提供代理服务的http协议版本1.0，1.1，默认设置为10 버전

4如果你的nginx服务器给2웹 서버가 대리서버로 사용되고, 로드 밸런싱 알고리즘은 순회를 사용한다면, 당신의 한 가지 기계의 web 프로그램 iis가 꺼지면, 즉 web에 접근할 수 없다면, nginx 서버가 요청을 재배포할 때도 이 접근할 수 없는 web 서버에 요청을 보내게 됩니다. 이 경우 응답 연결 시간이 너무 오래 걸리면 클라이언트의 페이지가 항상 응답을 기다리게 되고, 사용자에게는 경험을 크게 저하시키게 됩니다. 이렇게 이런 상황이 발생하지 않도록 어떻게 해야 하나요? 여기서 저는 문제를 설명하기 위해 그림을 추가했습니다.

　

　로드 밸런싱 중 하나가 web2이런 상황이 발생하면, nginx는 먼저 web로 가去看습니다.1요청을 하지만, nginx가 설정이 잘못되어 있다면 계속해서 요청을 web로 재배포합니다.2그런 다음 web을 기다립니다.2응답이 끝나지 않으면, 우리의 응답 시간이 초과되면 요청을 다시 web로 재배포합니다.1이렇게 응답 시간이 너무 오래 걸리면, 사용자가 기다릴 시간도 더 길어질 것입니다.

아래의 구성은 해결책 중 하나입니다.

proxy_connect_timeout 1;  #nginx服务器与被代理的服务器建立连接的超时时间，默认60秒
proxy_read_timeout 1; #nginx服务器想被代理服务器组发出read请求后，等待响应的超时间，默认为60秒。
proxy_send_timeout 1; #nginx服务器想被代理服务器组发出write请求后，等待响应的超时间，默认为60秒。
proxy_ignore_client_abort on; #客户端断网时，nginx服务器是否终端对被代理服务器的请求。默认为off。

5、upstream 지시자로 서버 그룹을 설정하여 프록시 서버로 사용할 서버를 구성하면, 서버에서 접근 알고리즘은 설정된 로드 밸런싱 규칙을 따릅니다. 동시에 이 지시자를 사용하여 예외 상황이 발생할 때 다음 서버 그룹을 순차적으로 처리할 수 있습니다.

proxy_next_upstream timeout;　 #반전 프록시 upstream에서 설정된 서버 그룹이 故障이 발생하면, 프록시 서버가 반환하는 상태 값입니다.error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off

  • error：연결을 설정하거나 프록시 서버에 요청을 보내거나 응답 정보를 읽을 때 서버가 오류가 발생했습니다.
  • timeout：연결을 설정하거나 프록시 서버에 요청을 보내거나 응답 정보를 읽을 때 서버가 타임아웃이 발생했습니다.
  • invalid_header: 프록시 서버가 반환하는 응답 헤더가 이상합니다.
  • off: 요청을 프록시 서버에 분배할 수 없습니다.
  • http_400，....: 프록시 서버가 반환하는 상태 코드는400，500，502， 등.

6、http를 통해 고객의 실제 IP를 얻고 프록시 서버의 IP를 얻는 것보다 원하는 경우 다음과 같은 설정을 해야 합니다.

proxy_set_header Host $host; #사용자가 브라우저에서 접근한 도메인이 VIP VIP 아래에 바인딩되어 있으면 $host를 사용합니다. 도메인과 포트 www.taobao.com:80
proxy_set_header X-Real-IP $remote_addr; #원 IP 【$remote_addr, HTTP 연결 헤더 내의 정보】를 X에 할당합니다-Real-IP;이렇게 되면 코드에서 $X-Real-IP를 통해 원 IP를 얻습니다
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;#nginx가 프록시 서버로 사용될 때 설정된 IP 목록, 경로를 통해 가는 기기 IP, 프록시 기기 IP를 모두 기록합니다. 【,】로 구분합니다; 코드에서 echo $x-forwarded-for |awk -F, '{print $1}'을 원 IP로 사용합니다

X에 대해-Forwarded-For와 X-Real-IP와 관련된 몇 가지 기사를 추천합니다: HTTP 요청 헤더의 X-Forwarded-For ，이 분은 http 프로토콜에 대한 여러 가지 기사를 작성했습니다. 추천드립니다.

7、아래는 제가 작성한 프록시 설정 관련 구성 파일 일부입니다. 참고용입니다.

  include mime.types;  # 파일 확장자와 파일 타입 매핑 테이블
  default_type 응용 프로그램/octet-stream; #默认文件类型，默认为text/plain
  #access_log off; #取消服务日志  
  log_format myFormat ' $remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格式
  access_log log/access.log myFormat; #combined为日志格式的默认值
  sendfile on;  #允许sendfile方式传输文件，默认为off，可以在http块，server块，location块。
  sendfile_max_chunk 100k; #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。
  keepalive_timeout 65; #连接超时时间，默认为75s，可以在http，server，location块。
  proxy_connect_timeout 1;  #nginx服务器与被代理的服务器建立连接的超时时间，默认60秒
  proxy_read_timeout 1; #nginx服务器想被代理服务器组发出read请求后，等待响应的超时间，默认为60秒。
  proxy_send_timeout 1; #nginx服务器想被代理服务器组发出write请求后，等待响应的超时间，默认为60秒。
  proxy_http_version 1.0 ; #Nginx服务器提供代理服务的http协议版本1.0，1.1，默认设置为1.0版本。
  #proxy_method get;  #支持客户端的请求方法。post/get；
  proxy_ignore_client_abort on; #客户端断网时，nginx服务器是否终端对被代理服务器的请求。默认为off。
  proxy_ignore_headers "Expires" "Set-Cookie"; #Nginx服务器不处理设置的http相应投中的头域，这里空格隔开可以设置多个。
  proxy_intercept_errors on;  #如果被代理服务器返回的状态码为400 또는 더 큰 값400, 설정된 error_page 설정이 작동합니다. 기본적으로 off입니다.
  proxy_headers_hash_max_size 1024; # http 헤더의 해시 테이블 용량의 최대 제한.512문자.
  proxy_headers_hash_bucket_size 128; # nginx 서버가 http 헤더의 해시 테이블을 저장하는 용량.64문자.
  proxy_next_upstream timeout; # 반대 대리 upstream에서 설정된 서버 그룹이 故障이 발생할 때, 대리 서버가 반환하는 상태 값.500|http_502|http_503|http_504|http_404|off
  #proxy_ssl_session_reuse on; 기본적으로 on입니다. 오류 로그에서 “SSL3_GET_FINSHED: digest check failed” 상황이 발생할 때, 이 명령을 off로 설정할 수 있습니다.

Nginx 가중평균 풀링 설명

이전 글에서 nginx가 가지고 있는 중복 풀링 알고리즘에 대해 설명했습니다. 이번에는 설정된 가중평균 풀링을 상세히 설명하겠습니다.

먼저 upstream 설정에 대해 설명드리겠습니다. 이 설정은 대리 서버 주소를 작성하며, 그 다음에는 가중평균 풀링 알고리즘을 설정합니다. 여기서 대리 서버 주소는 다음과 같습니다:2의 작성 방식.

upstream mysvr { 
   server 192.168.10.121:3333;
   server 192.168.10.122:3333;
  }
 server {
    ....
    location ~*^.+$ {     
      proxy_pass http://mysvr; # 요청을 mysvr 정의된 서버 목록으로 전송     
    } 
upstream mysvr { 
   server http://192.168.10.121:3333;
   server http://192.168.10.122:3333;
  }
 server {
    ....
    location ~*^.+$ {     
      proxy_pass mysvr; # 요청을 mysvr 정의된 서버 목록으로 전송     
    }

그런 다음, 실제로 사용할 수 있는 것을 보여드리겠습니다.

1히트레이드: 만약2서버가 있을 때, 서버가 문제가 발생하면 두 번째 서버를 사용하여 서비스를 제공합니다. 서버가 요청을 처리하는 순서: AAAAAΑ 갑자기 A가 중지되었어요, BBBBBBBBBBBBBBB.....

upstream mysvr { 
   server 127.0.0.1:7878; 
   server 192.168.10.121:3333 backup; # 히트레이드   
  }

2루프링: nginx는 기본적으로 루프링을 수행하며 모든 서버의 가중치는 기본적으로1서버가 요청을 처리하는 순서: ABABABABAB....

upstream mysvr { 
   server 127.0.0.1:7878;
   server 192.168.10.121:3333;    
  }

3가중평균 풀링: 설정된 가중치에 따라 서버에 다른 수의 요청을 분배합니다. 설정하지 않으면 기본적으로1서버 요청 순서는 다음과 같습니다: ABBABBABBABBABB....

 upstream mysvr { 
   server 127.0.0.1:7878 weight=1;
   server 192.168.10.121:3333 weight=2;
}

4ip_hash: nginx는 동일한 클라이언트 IP 요청을 동일한 서버로 보냅니다.

upstream mysvr { 
   server 127.0.0.1:7878; 
   server 192.168.10.121:3333;
   ip_hash;
  }

5위에 대한4이 균형 알고리즘에 대해 잘 이해하지 못한다면, 나의 이전 글에 포함된 이미지를 보시면 더 쉽게 이해할 수 있을 것입니다.

이제 nginx의 로드 밸런싱 구성이 매우 간단하고 강력하다는 느낌이 들 것입니다. 그러나 여전히 끝이 아닙니다. 계속해 보겠습니다.

nginx 로드 밸런싱 구성의 몇 가지 상태 매개변수를 설명합니다.

  • down은 현재 server가 로드 밸런싱에 참여하지 않는다는 의미입니다.
  • backup은 예비 서버입니다. 다른 모든 비 backup 서버가 故障이나 바쁘다면, backup 서버를 요청합니다. 따라서 이 서버의 부담은 가장輕습니다.
  • max_fails은 요청이 실패할 수 있는 횟수입니다. 기본值为1최대 횟수를 초과하면 proxy_next_upstream 모듈이 정의한 오류를 반환합니다.
  • fail_timeout은 max_fails 횟수를 초과하면 서비스를 일시 중지하는 시간입니다. fail_timeout과 max_fails를 함께 사용할 수 있습니다.
upstream mysvr { 
   server 127.0.0.1:7878 weight=2 max_fails=2 fail_timeout=2;
   server 192.168.10.121:3333 weight=1 max_fails=2 fail_timeout=1;  
  }

이제 nginx의 내장된 로드 밸런싱 알고리즘은 더 이상 남아 있지 않을 것입니다. nginx의 로드 밸런싱 알고리즘에 더 깊이 이해하고 싶다면, nginx 공식 웹사이트에서 제공하는 몇 가지 플러그인을 확인해 보세요.

이것이 본문의 전부입니다. 여러분의 학습에 도움이 되길 바랍니다. 또한, 노래 튜토리얼에 많은 지지를 부탁드립니다.

성명: 본문 내용은 인터넷에서 가져왔으며, 저작권은 원작자에게 있으며, 인터넷 사용자가 자발적으로 기여하고 업로드한 내용입니다. 사이트는 소유권을 가지지 않으며, 인공 편집 처리를 하지 않았으며, 관련 법적 책임도 부담하지 않습니다. 저작권 침해 내용을 발견하면 notice#w로 이메일을 보내 주시기 바랍니다.3codebox.com（보고할 때는 #을 @으로 변경하십시오.）를 통해 신고하시고 관련 증거를 제공하시면, 사실을 확인하면 해당 사이트는 즉시 저작권 침해 내용을 삭제합니다.

기본 튜토리얼
좋아하는 것