标签：serve 地址 释放 服务器 搜索 开始 修改 性能 伪造
HTTP服务器的吞吐率（单位时间吞吐量）通常有一个上限，尤其是普通配置的机器，在带宽够的情况下，用压测工具经常能把服务器压出翔，为了线上环境稳定性，防止恶意攻击影响到其他用户，可选择对客户端访问频率进行合理限制。
限制原理并不难，可一句话概括为：“根据客户端特征，限制其访问频率”，客户端特征主要指IP、UserAgent等。使用IP比UserAgent更可靠，因为IP无法造假，UserAgent可随意伪造。
虽然IP无法造假，但恶意人员可以利用代理，因此仅依靠限制IP访问频率并不能应对大量代理的情况，另外在限制IP访问频率时也要考虑多用户共享网络出口的情况，比如校园网、企业局域网网络之类。
由于存在盲区，不知道Nginx中有访问控制模块，想着自己在应用代码中使用Redis实现基于IP的访问频率控制，在准备写代码之前发现Nginx有limit_req模块可限制基于IP的访问频率，因此选择Nginx，这肯定比自己实现更省事，性能也更优秀。
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/100ms
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/100ms，配合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包含该功能。
ref https://amsimple.com/blog/article/47.html
标签：serve 地址 释放 服务器 搜索 开始 修改 性能 伪造
原文地址：https://www.cnblogs.com/zhangeamon/p/9341807.html
