我对使用乘客/铁路的Nginx进行速率限制没有任何困难.

部分混淆是区分配置的哪些方面基于每个客户端以及哪些是全局限制.

我在解决Nginx的limit_req和limit_req_zone配置的理想设置时遇到了问题.它似乎模糊地在语言之间翻转,暗示这是用户特定的或全局适用的.

在文档中,limit_req_zone行的工作方式非常模糊.这个“区域”是全球用户还是每用户？鉴于以下几行,我对以下结论是正确的：

limit_req_zone $binary_remote_addr zone=update_requests:1m rate=20r/s;

> $binary_remote_addr表示用户的IP地址
>特别是这种表示是优选的,因为它比$remote_addr占用更少的空间？为什么这很重要或更可取？
>“区域”(在这种情况下)充满了他们的IP地址的表示……？
>’rate’是允许请求离开队列的速率？
>这个“费率”和“区域” – 它们是客户特定的还是全球的？

我也不确定limit_req行,例如为了这：

limit_req zone=main_site burst=10 nodelay;

>不完全确定爆发意味着什么.这里的文档也很模糊.我想这是一些请求.当其余的请求系统使用这个奇怪的“区域”系统时,为什么请求数量？
>’爆发’请求是每个….什么时间框架？
>’nodelay’,据我所知,如果队列中有其他请求,则意味着立即服务503错误,而不是等待队列完成. a)等多久？ b)这是否意味着在这种情况下忽略’爆发’设置？

谢谢.

一些背景信息,以防任何人真的很无聊,并想看看我们试图解决的配置和一般问题：

目前我有这个(摘录)：

limit_req_zone $binary_remote_addr zone=main_site:10m rate=40r/s;
limit_req_zone $binary_remote_addr zone=update_requests:1m rate=20r/s;

server {
  listen        80;
  server_name   [removed];
  root          [removed];
  include       rtmp_proxy_settings;

  try_files $uri /system/maintenance.html @passenger;
  location @passenger {
    passenger_max_request_queue_size 0; # 256;
    limit_rate_after 2048k;
    limit_rate 512k;
    limit_req zone=main_site burst=10 nodelay;
    limit_conn addr 5;
    passenger_enabled on;
    passenger_min_instances 3;
  }

  location ~ ^/update_request {
    passenger_enabled on;
    limit_req zone=update_requests burst=5 nodelay;
  }


  gzip on;
  gzip_min_length 1000;
  gzip_proxied expired no-cache no-store private auth;
  gzip_types text/plain application/xml application/javascript text/javascript text/css;
  gzip_disable "msie6";
  gzip_http_version 1.1;
}

我们定义了两个区域：

a)“main_site”,旨在捕捉一切
b)“update_request”,当小(缓存)文件中的时间戳发生变化时,客户端上的JS通过AJAX轮询此更新内容

就其本质而言,这意味着我们在1或2分钟内拥有相当低的流量,但是当可能有10,000个客户端同时为这个更新的内容点击服务器时会出现大量峰值(根据过滤器以稍微不同的方式从数据库提供服务),访问权限等)

我们发现,在负载很重的时候,当cpu核心被最大化时,站点正在停止 – 我们的更新代码中有一些错误,这意味着当连接被丢弃时,查询排队等待并且一直在阻塞服务器直到我们不得不临时关闭网站并迫使用户注销并刷新他们的浏览器…有效地我们DDoS自己：PI认为这最初是由我们托管公司的一些连接问题引起的,导致一堆请求在用户的浏览器中排队.

虽然我们解决了这些错误,但我们警告客户他们可能会收到奇怪的503“重负载”消息,或者看到内容未及时更新.速率限制的最初目的是确保即使在重负载期间网站的日常页面也可以继续导航,同时限制更新的内容.

然而,我们现在看到的主要问题是,即使在更新代码中的错误已经(希望)解决之后,我们也无法在速率限制方面取得良好的平衡.无论何时将新内容添加到网站(并由我们的用户同时提取),我们设置的所有内容似乎都会在访问日志中生成不健康数量的503错误

我们在缓存方面考虑了各种解决方案,但理想情况下我们仍然希望受到某种速率限制的保护,这种速率限制在日常操作中不会影响用户.