nginx非法请求(nginx请求限流)

nginx请求限流

答：可以实现视频和图文混发限流，具体实现方式如下：

1、使用限流算法：可以使用令牌桶算法或漏桶算法来实现视频和图文混发限流，这两种算法都可以控制流量速率，从而达到限流的目的。

2、使用限流工具：可以使用一些开源的限流工具，如Nginx、HAProxy等，这些工具可以控制视频和图文混发的流量，从而达到限流的目的。

3、使用限流服务：可以使用一些云服务提供商提供的限流服务，如阿里云的流量限制服务，可以根据视频和图文混发的流量大小，来设置限流的策略，从而达到限流的目的。

扩展：

限流的目的是为了防止系统被恶意攻击或者流量突然增加而导致的服务器崩溃，从而保证系统的稳定性和可用性。限流的方式有很多种，除了以上提到的限流算法、限流工具和限流服务外，还可以使用限流插件、限流代理等方式来实现限流。

nginx 限流10000每秒

拥堵攻击往往是大量IP地址，每个IP地址少量消耗带宽，最终形成难以区分正常业务与恶意流量而拒绝服务。

渗透攻击不会消耗太大带宽。

长期自外向内的流量消耗，而且集中于某几个IP，不一定就是攻击，首先要分析业务情景。

长期自内向外的流量消耗，可以考虑病毒或者业务调用不合理。

解决方法

于内

使用抓包工具检查大流量所访问的具体业务和访问细节，检查各进程资源消耗情况。

于外

如果是自建机房，则考虑采购DDoS、WAF等设备；如果是托管机房或云服务器，具备一定安全设施，则只需要考虑分析业务。

或自建Nginx，根据业务情景，进行一定的防护和限流。

若是正常业务导致的，则购买CDN。

nginx如何实现限流

分布式系统服务保护

一、熔断

熔断一般是指依赖的外部接口出现故障的时断绝和外部接口的关系；例如你的A服务里面的一个功能依赖B服务，这时候B服务出问题了，返回的很慢。这种情况可能会因为这么一个功能而拖慢了A服务里面的所有功能，因此我们这时候就需要熔断！即当发现A要调用这B时就直接返回错误(或者返回其他默认值啊啥的)，就不去请求B了。

雪崩效应：在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

熔断机制是应对雪崩效应的一种微服务链路保护机制。在微服务架构中，当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

二、降级

降级也就是服务降级，当我们的服务器压力剧增为了保证核心功能的可用性 ，而选择性的降低一些功能的可用性，或者直接关闭该功能。这就是典型的丢车保帅了。就比如贴吧类型的网站，当服务器吃不消的时候，可以选择把发帖功能关闭，注册功能关闭，改密码，改头像这些都关了，为了确保登录和浏览帖子这种核心的功能。

熔断与降级的区别：触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；

三、限流

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。

漏桶算法：漏桶算法思路是请求先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。

令牌桶算法：令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。相比于漏桶算法令牌桶的优点是可以改变放令牌的速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量。Guava的RateLimiter就是采用该算法进行限流控制。

计数器算法：计数器算法的核心就是在规定的时间内限制请求次数；例如：对于A接口来说，我们1分钟的访问次数不能超过100个。在一开 始的时候，我们可以设置一个计数器counte=0，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个 请求的间隔时间还在1分钟之内，那么说明请求数过多，拒绝请求；如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter=0；

Semaphore限流：可以控制某个资源可被同时访问的个数，acquire()获取一个许可，如果没有就等待，而release()释放一个许可。

四、常用的web服务器

Nginx主要有两种限流方式：

按连接数限流(ngx_http_limit_conn_module)（令牌算法实现）

按请求速率限流(ngx_http_limit_req_module)（漏桶算法实现）

tomcat 通过以下三个配置参数来进行限流操作：

maxThreads（最大线程数）：每一次HTTP请求到达Web服务，tomcat都会创建一个线程来处理该请求，那么最大线程数决定了Web服务可以同时处理多少个请求，默认200.

accepCount（最大等待数）：当调用Web服务的HTTP请求数达到tomcat的最大线程数时，还有新的HTTP请求到来，这时tomcat会将该请求放在等待队列中，这个acceptCount就是指能够接受的最大等待数，默认100.如果等待队列也被放满了，这个时候再来新的请求就会被tomcat拒绝（connection refused）。

maxConnections（最大连接数）：这个参数是指在同一时间，tomcat能够接受的最大连接数。一般这个值要大于maxThreads+acceptCount。

在实际工作中对于流量入口的限流一般都是采用Nginx，tomcat一般会设置为适合当前操作系统的最大连接数，具体的业务限流（某个服务接口）一般使用sentinel和hystrix。

五、hystrix

提供了线程池隔离(默认)与信号量隔离

六、sentinel

古之学者为己，今之学者为人

分类: 中间件

标签: 分布式

nginx的限流原理

先不考虑服务器资源是否够，瓶颈会首先出现在数据库读写，假设现在有34W并发，而且根据访问性质来看应该是报名操作，而报名操作是带有数据库CRUD的，Mysql的最大连接数是2000(假设没做分库分表，5W rmb让开发商做分库分表显然是不可能的)，一般用到80%就很不错了，所以连接数用1600来算。然后假设数据库能在100ms内返回(想必也不是什么好机器)，那么一个连接1s能进行10次操作，那么1600连接用满，能进行1.6W次数据库操作。

但这个也只是理论上的峰值，在实际项目中，单库是绝达不到1.6W写入的，并且还是涉及到多表操作的情况下。

实际上根据《高性能MySQL》第三版 1.5小节，在如下的测试环境中

测试机器Cisco UCSC250

内存384GB

存储引擎是InnoDB

测试的数据集2.5GB

MySQL的buffer pool设置为4GB

所以在内存为384G的机器上，吞吐量不会超过8000。那么384G机器要多少钱呢？

这是64G机器的价格，因此384=64*6 6*1.8W=10.8W/年

因此，如果要并发支持到8000，光数据库就至少需要10W/Y。当然，这是假设请求在1s内返回的情况，假设我们允许服务能在5s内返回，那么此时并发能支持到4W。还是在不考虑服务器，网络损耗的情况下，实际上是远远达不到的。

所以，用5w来支持38w并发，是绝不可能的。

回到我们刚才的计算，假设数据库吞吐量到达理论峰值，能支持8000用户同时访问，如果每个客户能等待5s的化，能支持4w用户(前提是这些用户不可以同时访问，需要在5s内做到均匀分布，此时需要通过限流等手段来实现)

要支持8000用户同时访问，又需要多少个应用服务器呢？

假设我们使用tomcat服务，每个线程所占空间为8M，那么光tomcat线程就需要: 8000*8=64000=64G，当然还需要有主机内存，损耗啥的，按照一倍计算就是128G，那么需要是2*1.8W=3.6W

所以，如果需要支持4w个用户5s延时的访问，需要3.6+10.8= 14.4w rmb

这还只是服务器的钱，不算开发成本在内

那么，如果要支持38w的并发报名呢？这已经是一个相当大的并发量了，首先需要考虑的是抛弃掉一部分流量，可以在cdn就直接抛弃，或是nginx，或者直接在应用服务器上，比如在这种情况下就只能保持8000/380000 = 2%，只能有2%的请求允许进来。

可以通过nginx+redis的方式抛弃掉98%的请求，这样可以不用浪费应用服务器资源。或者直接在应用服务器上做操作，抛弃掉无法响应的请求，避免流量拖垮整个系统。

nginx限制请求次数

　　情况一：由于nginx默认的fastcgi进程响应缓冲区太小造成：　　这种情况下导致fastcgi进程被挂起，如果fastcgi服务队这个挂起处理不是很好的话，就可能提示“504 Gateway Time-out”错误。　　情况一解决办法：　　默认的fastcgi进程响应的缓冲区是8K，可以设置大一点，在nginx.conf里，加入：fastcgi_buffers 8 128k　　这表示设置fastcgi缓冲区为8块128k大小的空间。　　情况一解决办法（改进）：　　在上述方法修改后，如果还是出现问题，可以继续修改nginx的超时参数，将参数调大一点，如设置为60秒：　　send_timeout 60;　　经过这两个参数的调整，结果没有再提示“504 Gateway Time-out”错误，说明效果还是挺不错的，问题基本解决。　　情况二：PHP环境的配置问题　　这里需要对php-fpm和nginx进行配置修改。因为这种情况下，也会出现“504 Gateway Time-out”错误提示。　　情况二解决办法（ php-fpm配置修改）：　　将max_children由之前的10改为30，这样操作是为了保证有充足的php-cgi进程可以被使用。　　将request_terminate_timeout由之前的0秒改成60秒，这样使php-cgi进程处理脚本的超时时间提高到60秒，可以防止进程被挂起以提高利用效率。　　情况二解决办法（nginx配置修改）：　　为了减少fastcgi的请求次数，尽量维持buffers不变，要更改nginx的几个配置项，如下：　　将fastcgi_buffers由4 64k改为2 256k;　　将fastcgi_buffer_size 由64k改为128k;　　将fastcgi_busy_buffers_size由128k改为256k;　　将fastcgi_temp_file_write_size由128k改成256k。　　情况二解决办法修改完，需要重新加载php-fpm和nginx的配置，然后再进行测试。之后就没有发现“504 Gateway Time-out”错误，效果也还是不错的。

nginx对ip限流

一、限制访问频率（正常流量）Nginx中我们使用ngx_http_limit_req_module模块来限制请求的访问频率，基于漏桶算法原理实现。接下来我们使用 nginx limit_req_zone 和 limit_req 两个指令，限制单个IP的请求处理速率。

二、限制访问频率（突发流量）

在流量突然增大时，超出的请求将被拒绝，无法处理突发流量，那么在处理突发流量的时候，该怎么处理呢？Nginx提供了 burst 参数来解决突发流量的问题，并结合 nodelay 参数一起使用。burst 译为突发、爆发，表示在超过设定的处理速率后能额外处理的请求数。…