Nginx-요청을 제한 할 때 nodelay 옵션은 무엇을합니까?

nginx를 사용하면 HttpLimitReq 모듈 요청을 IP로 제한 할 수 있습니다. 그러나 "nodelay"옵션의 기능을 이해하지 못합니다.

한계 버스트 지연 내에서 초과 요청이 필요하지 않은 경우 nodelay를 사용해야합니다

limit_req   zone=one  burst=5  nodelay;

여기 문서 에는 알고 싶은 것 같은 설명이 있습니다.

지시문은 영역 (영역) 및 가능한 최대 요청 버스트 (버스트)를 지정합니다. 비율이 영역에 요약 된 요구를 초과하면 요청이 지연되어 쿼리가 지정된 속도로 처리됩니다.

내가 이해 한 바에 따르면 버스트를 통한 요청은 지연됩니다 (더 많은 시간이 걸리고 서비스가 제공 될 때까지 기다립니다) nodelay. 지연이 사용되지 않고 초과 요청은 503 오류로 거부됩니다.

이 블로그 게시물 ( archive.org )은 nginx에서 속도 제한이 작동하는 방법에 대한 좋은 설명을 제공합니다.

당신이 저와 같다면 아마도 도대체 파열이 실제로 무엇을 의미하는지 궁금 할 것입니다. 트릭은 '버스트'라는 단어를 '버킷'으로 바꾸고 모든 사용자에게 5 개의 토큰이있는 버킷이 있다고 가정합니다. 그들이 초당 1 요청의 비율을 초과 할 때마다, 그들은 토큰을 지불해야합니다. 모든 토큰을 사용한 후에는 HTTP 503 오류 메시지가 표시되며 이는 본질적으로 'back off, man!'의 표준이되었습니다.

TL; DR : nodelay 옵션은 요청 사이의 허용 간격을 제한하지 않고 속도 제한을 적용하려는 경우에 유용합니다.

나는 다른 답변을 소화하는 데 어려움을 겪고 나서 Nginx에서 https://www.nginx.com/blog/rate-limiting-nginx/

여기에 적절한 부분이 있습니다. 주어진:

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

location /login/ {
  limit_req zone=mylimit burst=20;
  ...
}

burst 매개 변수는 클라이언트가 영역에 지정된 속도를 초과하여 수행 할 수있는 요청 수를 정의합니다 (샘플 mylimit 영역의 경우 속도 제한은 초당 10 회 요청 또는 100 밀리 초마다 1 회). 이전 요청이 큐에 들어간 후 100 밀리 초보다 빨리 도착하는 요청은 큐 크기를 20으로 설정합니다.

즉, 21 개의 요청이 주어진 IP 주소에서 동시에 도착하면 NGINX는 첫 번째 요청을 즉시 업스트림 서버 그룹으로 전달하고 나머지 20 개를 대기열에 넣습니다. 그런 다음 100 밀리 초마다 대기중인 요청을 전달하고 들어오는 요청으로 대기중인 요청 수가 20 개를 초과하는 경우에만 503을 클라이언트에 반환합니다.

nodelay를 추가하는 경우 :

location /login/ {
  limit_req zone=mylimit burst=20 nodelay;
  ...
}

nodelay 매개 변수를 사용하면 NGINX는 여전히 버스트 매개 변수에 따라 큐에 슬롯을 할당하고 구성된 비율 한계를 부과하지만 큐된 요청의 전달 간격을 두지 않습니다. 대신 요청이“너무 빨리”도착하면 NGINX는 대기열에 사용 가능한 슬롯이있는 한 즉시 전달합니다. 해당 슬롯을 "취득한"것으로 표시하고 적절한 시간이 지날 때까지 (예 : 100 밀리 초 후) 다른 요청에 의해 사용하기 위해 사용하지 않습니다.

내가 보는 방식은 다음과 같습니다.

1. 지역 요율을 초과 할 때까지 요청이 최대한 빨리 처리됩니다. 영역 속도는 "평균"이므로 속도가 1r/s높고 버스트 인 경우 1010 초 동안 10 개의 요청을 가질 수 있습니다.

2. 존 속도를 초과 한 후 :

   ㅏ. 가 없으면 nodelay추가 요청 burst이 지연됩니다.

   비. 을 (를) 사용 nodelay하면 추가 요청 burst을 최대한 빨리 처리 할 수 ​​있습니다.

3. 를 burst초과하면 버스트 창이 만료 될 때까지 서버가 오류 응답을 반환합니다. 예를 들어 rate 1r/s및 burst의 10경우 클라이언트는 다음 수락 요청을 최대 10 초 동안 기다려야합니다.

이 설정은 요청이 원하는 속도를 준수하도록 지연 될 것인지 또는 단순히 거부 될 것인지 여부를 정의합니다. 속도 제한이 서버에 의해 관리되는지 또는 책임이 클라이언트에 전달되는지에 따라 다릅니다.

nodelay 선물

요청은 가능한 빨리 처리됩니다. 지정된 한도를 초과하여 전송 된 모든 요청은 다음과 같은 코드 세트로 거부됩니다.limit_req_status

nodelay 결석 (일명 지연)

요청은 지정된 제한을 준수하는 속도로 처리됩니다. 예를 들어, 속도가 10 req / s로 설정되면 각 요청은> = .1 (1 / rate) 초 내에 처리되므로 속도를 초과하지 않고 요청을 백업 할 수 있습니다. 버킷을 오버플로하기 위해 충분한 요청이 백업되면 (동시 연결 제한으로도 방지 됨) 코드가로 설정되어 거부됩니다 limit_req_status.

피투성이의 세부 사항은 여기에 있습니다 : https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L263 어디 제한이 아직 통과되지 않은 경우에 그 논리 차기 지금 지연 선택적으로 요청에 적용됩니다. 의 응용 프로그램 nodelay이 지침에서 특히 여기에서 활동하기 시작 : https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_limit_req_module.c#L495 의 값의 원인이 delay위의 것은 0 트리거링을 할 수 처리기 NGX_DECLINED는 요청을 다음 처리기로 전달하여 NGX_AGAIN다시 처리하기 위해 효과적으로 다시 요청하지 않고 즉시 반환 합니다.

https://www.nginx.com/blog/rate-limiting-nginx/ 에서 소개를 읽을 때 처음에는 이해하지 못했습니다 .

이제 나는 이해하고 있으며 내 대답은 지금까지 최고입니다. :)

10r/s예 10000r/s를 들면, 서버의 최대 기능은 예 를 들어 10r/ms, 현재는 1 개의 클라이언트 만 있다고 가정 합니다 .

와의 주요 차이점은 다음 10r/s per IP burst=40 nodelay과 같습니다 10r/s per IP burst=40.

는 AS https://www.nginx.com/blog/rate-limiting-nginx/가 문서화 ( 난 강력하게 먼저 기사를 읽어 보시기 바랍니다 제외하고 ( 두 단계 속도 제한 이 동작을 수정 한 문제를) 섹션). 어느 것?:

이 예에서 큐의 20 번째 패킷은 2 초 동안 전달되기를 기다립니다.이 시점에서 이에 대한 응답이 더 이상 클라이언트에 유용하지 않을 수 있습니다.

내가 작성한 초안을 확인하고 40th요청은 응답 1s을 받고 다른 요청은에서 응답을 40th받습니다 4s.

이렇게하면 서버 기능을 최대한 활용할 수 있습니다 x r/s. 주어진 클라이언트 / IP에 대한 제약을 유지하면서 가능한 한 빨리 응답을 보냅니다 .

그러나 여기에도 비용이 있습니다. 비용은 다음과 같습니다.

당신은 서버하자 말 클라이언트에서 대기 많은 클라이언트가있는 경우 A, B그리고 C.

이 없으면 nodelay요청이와 유사한 순서로 제공됩니다 ABCABCABC.
를 사용 nodelay하면 순서가 더 높아질 수 있습니다 AAABBBCCC.

https://www.nginx.com/blog/rate-limiting-nginx/ 기사를 요약하고 싶습니다 .

무엇보다도 가장 중요한 구성은입니다 x r/s.

1. x r/s 초과 요청은 즉시 거부됩니다.

2. x r/s+ burst초과 요청이 대기 중입니다.

1.vs 2., 비용은 클라이언트 측에서 큐에 대기 한 요청이 나중에 서비스를받을 가능성이있는 나중에 reuqest의 기회를 차지한다는 것입니다.

예를 들어, 10r/s burst=20vs 10r/s는 11th요청이 후자의 조건에서 즉시 거부되어야하지만 이제는 대기하고 서비스를받습니다. 11th요청이 차지 21th요청의 기회를.

3. x r/s+ burst+ nodelay이미 설명했습니다.

PS 기사 의 2 단계 속도 제한 섹션은 매우 혼란 스럽습니다. 나는 이해하지 못하지만 그것은 중요하지 않습니다.

예를 들면 다음과 같습니다.

이 구성을 사용하면 8 r / s에서 연속적인 요청 스트림을 만드는 클라이언트는 다음 동작을 경험합니다.

8 r / s? 진심으로? 이미지에 3 초 내에 17 개의 요청이 있습니다. 17/3 = 8?