出于各种需要,经常需要限速
- 针对进程限速
- 针对ip、port限速
- 针对一组进程限速
- 模拟低速环境
- 程序上实现限速
- 针对下载限速
- 针对上传限速
真实需求:
调用第三方接口发邮件,经常会有很大的附件,当发送大量这类邮件时,就会将带宽占满。(第三方出口带宽还挺大)
限速工具:
- tc
- tc只能控制发送的速率,不能控制收包的速率(来了就收呗,干嘛要限速)
- iptables
- iptables + tc
- pv (pipe view)
- chrome开发者工具直接限速
- 程序自身支持限速 ,如:curl
- 通过特定编程语言实现
- PHP: https://github.com/bandwidth-throttle/bandwidth-throttle (利用了stream_filter_append )
- PHP: https://packagist.org/search/?tags=rate%20limit
- Go: https://github.com/juju/ratelimit
通过nginx限速
nginx可以做http代理、tcp代理,而程序上设置代理也都比较方便,如果能在nginx上限速,会比较通用一些,目前发现有2个nginx限速模块:
- http://nginx.org/en/docs/http/ngx_http_limit_req_module.html 限制单个IP每秒最大请求数
- http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html 限制单个IP每秒最大并发
但是目前还没有一个限制流量的模块
(注:这些模块提供的时间段为‘秒’是不够灵活的,应该允许指定n秒,参考限速方面知识的其他参数)
通过apache限速
apache是一个老牌的web server,模块很多,果然有限速模块:
- http://bwmod.sourceforge.net/ 这是是实现带宽限制的
- http://dembol.org/blog/mod_cband/ 这个支持对单个虚拟主机限速,主要用于卖服务的
- http://www.zdziarski.com/blog/?page_id=442 这个类似于nginx的那两个模块
- http://dominia.org/djao/limitipconn.html 这个只是限制连接数的
- http://www.topology.org/src/bwshare/README.html
参考: http://serverfault.com/questions/540743/how-to-rate-limit-apache-server-on-ip-basis
注意: 一般来讲,这些模块都是针对下行进行限速,很少对上行也限速的;如果对上行也要限速,则未必好使。对于代理的情况呢?
通过haproxy限速
参考文章: http://blog.serverfault.com/2010/08/26/1016491873/
haproxy 是代理,不是隧道,如果仅仅作为一个限速的隧道或许还不行
注意:有些限制策略是超过限制就加入黑名单,并且直接返回错误(或许这不是你想要的)
通过squid限速
参考: http://wiki.squid-cache.org/Features/DelayPools
squid.conf 中添加:
1 2 3 4 5 6 |
acl only128kusers src all delay_pools 1 delay_class 1 3 delay_access 1 allow only128kusers delay_access 1 deny all delay_parameters 1 64000/64000 -1/-1 16000/64000 |
测试发现: 这个限速也是针对下行的限速,上行不限速
自定义proxy
goproxy( https://github.com/elazarl/goproxy ) 是一个开发proxy的golang库,在此基础上开发自定义功能的proxy是很方便的
关于iptables限速
- 至少两条规则
- 允许的速度
- 默认的丢弃
- 问题
- 如果发快了,则系统调用不是被阻塞,而是“Operation not permitted”, 这可能导致进程逻辑异常,尤其是tcp三次握手时候,可能会导致连接失败
其他:
关于phpmailer的发邮件限速:
php 的curl限速:
http://php.net/manual/en/function.curl-setopt.php
CURLOPT_MAX_RECV_SPEED_LARGE
CURLOPT_MAX_SEND_SPEED_LARGE
http://m.blog.csdn.net/tianyaleixiaowu/article/details/74942405