nginx
查看Nginx当前连接数
netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
进程
nginx有一个主进程与几个工作进程,主进程用来读取配置与管理工作进程
配置
位置
名为nginx.conf,放置在/usr/local/nginx/conf或/etc/nginx或/usr/local/etc/nginx
结构
指令分为普通指令与块指令
普通指令包含用空格分隔的名与若干个值,以;结尾
块指令与普通指令类似,但结尾用{}包围,如果一个块指令可以包含其它指令,就叫Context(上下文)
配置文件内在任意上下文外的指令都在main上下文内
#到行尾的内容被认为是注释
指令
location
如果有多个location匹配一个链接,则取最长的前缀那个
一次实际的带宽分析
今天用阿里云做试验,测试带宽时发现结果很奇怪,研究了好长时间才研究透,特记下来,以防遗忘.
条件:
- 装有centos7的阿里云服务器,开了1M的出网带宽
- 服务器上用iftop命令来实时监控带宽情况
- 服务器上装有nginx,连接后端tomcat(实际上tomcat在本次测试中并不重要)
过程:
- 本地用代码循环5000次发送http get请求(使用异步发送,以达到不阻塞的目的)到阿里云服务器
- 观察服务器上iftop命令界面的带宽使用情况
现象:
- 请求发送时,服务器上iftop命令界面出现很多的连接
- 请求发送时,服务器上iftop命令界面显示出去的带宽超过了1M/s,达到3M/s或更多,进入的带宽也类似
- 所有请求结束,在经过一段足够长的时间后,所有5000个请求都有结果了,成功了30多个,失败了4700个左右(总之加起来正好是5000)
分析:
- 请求发送时,服务器上出现很多连接,是因为客户端每次都异步发送get请求,互相是独立的,因此每次请求理论上应该都会建立新连接(但nginx有没什么策略会利用旧的连接就不清楚了)
- 请求发送时,服务器上iftop命令界面显示出去的带宽超过了1M/s,这是为什么呢?原来以为是阿里云提供了更多的带宽,或iptop显示有问题,但仔细一分析,发现并非如此:
- 首先,要清楚各部分之间的联系,即
tomcat <--> nginx <--(iftop监听)--> 阿里云网关 <--(网络)--> 客户端,就是说,客户端请求先进入阿里云网关,因为阿里云并未限制进入的带宽,因此请求进入可以看做无限制的,然后请求到达nginx,并被iftop监听到,这之间都是没有限制没有问题的.所以iftop监听到的进入流量超过1M也是正常情况的反应. - 然后,请求在nginx处理后(不管是被nginx发到tomcat再从tomcat返回,还是被nginx限制并抛弃掉,从nginx角度看都一样,都是nginx返回了http响应),再经过阿里云网关到客户端,iftop监听到超过1M的流量出去也是正确的,因为实际就是这么多出去了,但这么多响应同时从阿里云网关返回给客户端时,却被阿里云限制了,因为只开了1M的出网带宽,因此出去的速度被限制在1M,再从结果看(5000个请求全部返回了),连接或包并没有被阿里云网关丢弃,而是延迟了,因为1M的速度限制,它们会慢慢地出去,最终还是全部正常出去了.
- 因此,结论是iftop监听的流量并没有问题,但流量出去时,还要受到阿里云网关的速度限制,因此如果有大量客户端连接,则响应的速度受阿里云出网带宽限制,客户端可能会有延迟.
- 首先,要清楚各部分之间的联系,即
漏桶与令牌桶
漏桶算法与令牌桶算法都是网络世界中流量整形(Traffic Shaping)或速率限制(Rate Limiting)时经常使用的算法.漏桶算法不允许突发数据,令牌桶则允许.
它们的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。
漏桶可以看作是一个带有常量服务时间的单服务器队列，如果漏桶（包缓存）溢出，那么数据包会被丢弃。
大小固定的令牌桶可自行以恒定的速率源源不断地产生令牌。如果令牌不被消耗，或者被消耗的速度小于产生的速度，令牌就会不断地增多，直到把桶填满。后面再产生的令牌就会从桶中溢出。最后桶中可以保存的最大令牌数永远不会超过桶的大小。 传送到令牌桶的数据包需要消耗令牌。不同大小的数据包，消耗的令牌数量不一样。
在某些情况下，漏桶算法不能够有效地使用网络资源。因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突（没有发生拥塞），漏桶算法也不能使某一个单独的流突发到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。而令牌桶算法则能够满足这些具有突发特性的流量。通常，漏桶算法与令牌桶算法可以结合起来为网络流量提供更大的控制。