Nginx 액세스 주파수 제어

Nginx 액세스 주파수 제어
HTTP 서버 의 스루풋 (단위 시간 스루풋) 은 보통 상한 선 이 있 습 니 다. 특히 일반 설정 한 기 계 는 대역 폭 이 충분 한 상황 에서 압력 측정 도구 로 서버 를 자주 날 릴 수 있 습 니 다. 온라인 환경 안정성 을 위해 악의 적 인 공격 이 다른 사용자 에 게 영향 을 주지 않도록 클 라 이언 트 의 방문 빈 도 를 합 리 적 으로 제한 할 수 있 습 니 다.
제한 원리
제한 원 리 는 어렵 지 않 습 니 다. 한 마디 로 '클 라 이언 트 특징 에 따라 방문 빈 도 를 제한 합 니 다' 라 고 요약 할 수 있 습 니 다. 클 라 이언 트 특징 은 주로 IP, UserAgent 등 을 말 합 니 다.IP 를 사용 하 는 것 이 UserAgent 보다 더 믿 을 수 있 습 니 다. IP 를 조작 할 수 없 기 때문에 UserAgent 는 마음대로 위조 할 수 있 습 니 다.
IP 는 조작 할 수 없 지만 악의 적 인 사람 은 대 리 를 이용 할 수 있 기 때문에 IP 액세스 빈 도 를 제한 하 는 것 만으로 대량의 대리 상황 에 대응 할 수 없다. 또한 IP 액세스 빈 도 를 제한 할 때 도 다 중 사용자 가 네트워크 수출 을 공유 하 는 상황, 예 를 들 어 캠퍼스 네트워크, 기업 랜 네트워크 등 을 고려 해 야 한다.
실천 하 다.
사각 지대 가 존재 해 Nginx 에 액세스 제어 모듈 이 있 는 지 모 르 고 애플 리 케 이 션 코드 에서 Redis 를 사용 해 IP 기반 액세스 주파수 제 어 를 실현 하려 고 했 는데, 코드 작성 을 준비 하기 전에 Nginx 에 IP 기반 액세스 주파 수 를 제한 할 수 있 는 모듈 limit_req 이 있 음 을 알 고 Nginx 를 선택 한 것 은 자신 보다 훨씬 편리 하고 성능 도 우수 할 것 이다.
limit_req_zone

Syntax:  limit_req_zone key zone=name:size rate=rate;
Default: —
Context: http

key 는 제 한 된 요청 특징 으로 텍스트 와 변 수 를 포함 할 수 있 음 을 나타 낸다. IP 장면 사용 $binary_remote_addr

name, zone 의 이름, limit_req 사용 할 수 있 습 니 다

size, zone 의 크기, 1M 크기 는 64 비트 시스템 에 8000 개의 state (ip, count...) 를 저장 할 수 있 습 니 다. 새 state 를 추가 할 때마다 60 초 전에 사용 하지 않 았 던 state 를 삭제 할 수 있 습 니 다. 새 state 를 추가 할 때 zone 크기 가 부족 하면 오래된 state 를 삭제 하고 빈 칸 을 방출 한 후에 도 503

으로 돌아 가지 못 합 니 다.

rate, 접근 속도, 지원 초 또는 분 단위 이지 만 nginx 내부 에 서 는 밀리초 추적 요청 수 를 사용 합 니 다. 10r / 1s 로 제한 하면 실제 1r / 100 ms

입 니 다.
limit_req

Syntax:  limit_req zone=name [burst=number] [nodelay];
Default: —
Context: http, server, location

name, limit_req_zone 에 설 정 된 이름

burst 는 버퍼 슬롯 으로 이해 할 수 있 습 니 다. 설정 하면 모든 요청 이 버퍼 슬롯 을 통 해 upstream 에 전달 되 며, 동시에 받 을 수 있 는 요청 수 는 number + 1 이지 만, number 가 0 일 때 모든 요청 을 거부 합 니 다

.

nodelay, 버퍼 슬롯 에서 upstream 에 전송 을 요청 하 는 시기 입 니 다. 설정 하지 않 으 면 zone 의 속도 에 따라 하나씩 전송 합 니 다. nodelay 로 설정 되 었 을 때 버퍼 슬롯 에 도착 하면 바로 upstream 에 전송 을 요청 합 니 다. 그러나 슬롯 의 차지 위 치 는 주파수 에 따라 방출 됩 니 다

배치 하 다.
이해 limit_req_zone 와 limit_req 를 한 후에 이것 은 정말 좋 은 디자인 이 고 그 뒤의 이미지 의 이름 도 알 고 있다.
설정 방식 을 알 고 실제 작업 을 시작 합 니 다. Nginx 설정 의 http 에 추가 합 니 다.

limit_req_zone $binary_remote_addr zone=one:2m rate=10r/s;

제한 이 필요 한 server 에 추가:

limit_req zone=one burst=10 nodelay;

공식 문서 에 따 르 면 2M 크기 는 64 비트 시스템 에 약 16000 개의 상태 데 이 터 를 저장 할 수 있 습 니 다. 자신의 개인 사이트 에 충분 합 니 다. 10r / s 즉 1r / 100 ms 는 burst = 10 에 맞 춰 도 OK 이 고 Nginx 를 다시 시작 한 다음 에 압력 측정 도 구 를 사용 하여 검 사 를 해 야 합 니 다.
rate, burst, nodelay 의 서로 다른 특징:
다른 요 소 를 제외 하고 rate 의 크기 는 같은 클 라 이언 트 의 평균 삼투 율 에 결정적 인 역할 을 합 니 다. 한편, burst 와 nodelay 는 업무 수요 에 따라 선택 할 수 있 습 니 다. burst 가 클 수록 받 을 수 있 는 병행 요청 이 많 지만 rate 가 따라 가지 못 하면 대량의 클 라 이언 트 요청 이 시간 을 초과 할 수 있 습 니 다. nodelay 는 rate 가 시간 에 비해 업무 가 순간 적 인 삼투 율 표현 을 향상 시 킬 수 있 습 니 다.
화이트 리스트
IP 접근 주파 수 를 제한 하 는 이 유 는 외부 호출 자의 악성 행 위 를 막 기 위 한 것 이지 만 위 설정 을 거 쳐 시스템 내부 호출 자 에 게 도 제한 이 있 을 수 있 으 므 로 내부 호출 자 를 화이트 리스트 에 올 려 접근 빈도 에 제한 이 없 도록 하고 자 합 니 다.
이 는 주로 Nginx 의 geo 와 map 기능 을 통 해 geo 를 통 해 IP 를 값 으로 매 핑 한 다음 에 map 를 통 해 값 을 변수 나 상수 로 매 핑 합 니 다. 마침 limit_req_zone 에서 key 가 '' 이면 주파수 제한 을 하지 않 는 다 고 표시 하기 때문에 화이트 리스트 사용자 의 key 를 '' 로 설정 해 야 합 니 다.
설정 파일 의 http 내용 수정:

geo $limit {
    default 1;
    127.0.0.1 0;     #     
    172.31.0.0/16 0; #     
}

map $limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=one:2m rate=10r/s;

총결산
이로써 IP 제한 액세스 주파수 설정 이 완료 되 었 습 니 다. Nginx 에서 limit_req 와 유사 한 것 은 limit_conn 연결 차원 에서 제한 할 수 있 습 니 다. 또한 limit_req 에 대해 두 개의 설정 항목 limit_req_status 과 limit_req_log_level 이 있 습 니 다. 전 자 는 제한 에 이 르 렀 을 때 어떤 상태 코드 를 되 돌려 주 고 후 자 는 제한 에 이 르 렀 을 때 로 그 를 어떤 단계 로 설정 합 니까?제 한 된 정보 가 다른 로그 파일 에 나타 날 수 있 습 니 다.
스스로 실현 하려 고 할 때 부터 Nginx 를 사용 하여 실현 하기 까지 서버 에 대한 자신의 이해 가 향상 되 어야 한다 고 느 꼈 다. 검색 과정 에서 Nginx 가 이 기능 을 포함 하고 있 는 것 이 아니 라 합 리 적 인 측면 에서 Nginx 가 이러한 기능 을 포함 하고 있 는 것 으로 추정 할 수 있어 야 한다.
블 로그