iptables端口映射详解

搞了一天,终于搞定iptables了,,开头就对着人家配对了的配置对抄,但怎也不对,在网上搜了N多文章也不对,终于找到了一篇比较详细的,看了二次,终于配置成功,现在可以用端口映射访问内网的SSH和VNC等等的了

本文作者:张天成    zhangtiancheng#gmail.com 转发请注明出处。

iptables是一个Linux下优秀的nat+防火墙工具,我使用该工具以较低配置的传统pc配置了一个灵活强劲的防火墙+nat系统,小有心得,看了网上也有很多这方面的文章,但是似乎要么说的比较少,要么就是比较偏,内容不全,容易误导,我研究了一段时间的iptables同时也用了很久,有点滴经验,写来供大家参考,同时也备日后自己翻阅。
首先要说明的是,iptables操作的是2.4以上内核的netfilter.所以需要linux的内核在2.4以上。其功能与安全性远远比其前辈 ipfwadm,ipchains强大,iptables大致是工作在OSI七层的二、三、四层,其前辈ipchains不能单独实现对tcp/udp port以及对mac地址的的定义与操作,所以我想ipchains应该是仅仅工作在三层上的。

我们先简单介绍一下netfilter的大致工作流程,也就是一个数据包(或者叫分组、packet,我个人习惯叫包)在到达linux的网络接口的时候(网卡)如何处理这个包,然后再介绍一下如何用iptables改变或者说控制对这个数据包进行操作。netfilter内部分为三个表,分别是 filter,nat,mangle,每个表又有不同的操作链(Chains)。在filter(过滤)表中,也就是他的防火墙功能的这个表,定义了三个 Chain。分别是INPUT,FORWARD,OUTPUT。也就是对包的入、转发、出进行定义的三个过滤链。对于这个filter表的操作和控制也是我们实现防火墙功能的一个重要手段;在nat(Network Address Translation、网络地址翻译)表中,也就是我们用以实现地址转换和端口转发功能的这个表,定义了PREROUTING, POSTROUTING,OUTPUT三个链,下面我们会对这三个链作详细的说明;而netfilter的mangle表则是一个自定义表,里面包括上面的filter以及nat表中的各种chains,它可以让我们进行一些自定义的操作,同时这个mangle表中的chains在netfilter对包的处理流程中处在一个比较优先的位置,下面有一张图清晰的描绘了netfilter对包的处理流程(该图摘自网上,不知作者是谁,在此深表敬意!),一般情况下,我们用不到这个mangle表,在这里我们就不做介绍了。

大家可以看到,PREROUTING这个chain在最前面,当一个包来到linux的网络接口的时候先过mangle的PREROUTING,然后是 nat的PREROUTING,从这个chain的名字我们可以看出,这个chain是在路由之前(pre-routing)要过的。为什么要在路由之前过呢?大家可以看到这个图上,上面有一个菱形的部分叫ROUTING,这个ROUTING部分就是Linux的route box,也就是路由系统,它同样有很高深的功能,可以实现策略路由等等一些高级特性,此处我们不做详细解释。单说这个PREROUTING链,因为在这个链里面我们对包的操作是DNAT,也就是改变目的地址和(或端口),通常用在端口转发,或者nat到内网的DMZ区,也就是说当一个包过来的时候我们要改变它的目的地址,大家可以想想,如果一个包在改变目的地址之前就被扔进了route box,让系统选好路之后再改变目的地址,那么选路就可能是错的,或者说毫无意义了,所以,PREROUTING这个Chain一定要在进Routing 之前做。比如说,我们的公网ip是60.1.1.1/24,位于linux中的eth0,内网ip是10.1.1.1/24位于linux中的eth1, 我们的内网有一台web服务器,地址是10.1.1.2/24,我们怎么样能让internet用户通过这个公网ip访问我们内部的这个web服务器呢?我们就可以在这个PREROUTING链上面定义一个规则,把访问60.1.1.1:80的用户的目的地址改变一下,改变为10.1.1.2:80,这样就实现了internet用户对内网服务器的访问了,当然了,这个端口是比较灵活的,我们可以定义任何一个端口的转发,不一定是80–>80,具体的命令我们在下面的例子中介绍,这里我们只谈流程与概念上的实现方法。

好了,我们接着往下走,这个包已经过了两个PREROUTING链了,这个时候,出现了一个分支转折的地方,也就是图中下方的那个菱形(FORWARD),转发!这里有一个对目的地址的判断(这里同样说明了PREROUTING一定要在最先,不仅要在route box之前,甚至是这个对目的地址的判断之前,因为我们可能做一个去某某某ip的地方转到自己的ip的规则,所以PREROUTING是最先处理这个包的 Chain)!如果包的目的地是本机ip,那么包向上走,走入INPUT链处理,然后进入LOCAL PROCESS,如果非本地,那么就进入FORWARD链进行过滤,我们在这里就不介绍INPUT,OUTPUT的处理了,因为那主要是对于本机安全的一种处理,我们这里主要说对转发的过滤和nat的实现。

这里的FORWARD我简单说一下,当linux收到了一个目的ip地址不是本地的包,Linux会把这个包丢弃,因为默认情况下,Linux的三层包转发功能是关闭的,如果要让我们的linux实现转发,则需要打开这个转发功能,可以改变它的一个系统参数,使用sysctl net.ipv4.ip_forward=1或者echo “1” > /proc/sys/net/ipv4/ip_forward命令打开转发功能。好了,在这里我们让linux允许转发,这个包的目的地址也不是本机,那么它将接着走入FORWARD链,在FORWARD链里面,我们就可以定义详细的规则,也就是是否允许他通过,或者对这个包的方向流程进行一些改变,这也是我们实现访问控制的地方,这里同样也是Mangle_FORWARD然后filter_FORWARD,我们操作任何一个链都会影响到这个包的命运,在下面的介绍中,我们就忽略掉mangle表,我们基本用不到操作它,所以我们假设它是透明的。假设这个包被我们的规则放过去了,也就是ACCEPT了,它将进入POSTROUTING部分,注意!这里我注意到一个细节问题,也就是上面的图中数据包过了FORWARD链之后直接进入了POSTROUITNG 链,我觉得这中间缺少一个环节,也就是route box,对于转发的包来说,linux同样需要在选路(路由)之后才能将它送出,这个图却没有标明这一点,我认为它是在过了route box之后才进入的POSTROUITNG,当然了,这对于我们讨论iptables的过滤转发来说不是很重要,只是我觉得流程上有这个问题,还是要说明一下。

同样的,我们在这里从名字就可以看出,这个POSTROUTING链应该是路由之后的一个链,也就是这个包要送出这台Linux的最后一个环节了,这也是极其重要的一个环节!!这个时候linux已经完成(has done..^_^)了对这个包的路由(选路工作),已经找到了合适的接口送出这个包了,在这个链里面我们要进行重要的操作,就是被Linux称为 SNAT的一个动作,修改源ip地址!为什么修改源ip地址?很多情况需要修改源地址阿,最常见的就是我们内网多台机器需要共享一个或几个公网ip访问 internet,因为我们的内网地址是私有的,假如就让linux给路由出去,源地址也不变,这个包应该能访问到目的地,但是却回不来,因为 internet上的N多个路由节点不会转发私有地址的数据包,也就是说,不用合法ip,我们的数据包有去无回。有人会说:“既然是这样,我就不用私有 ip了,我自己分配自己合法的地址不行吗?那样包就会回来了吧?”答案是否定的,ip地址是ICANN来分配的,你的数据包或许能发到目的地,但是回来的时候人家可不会转到你那里,internet上的路由器中的路由信息会把这个返回包送到那个合法的获得ip的地方去,你同样收不到,而你这种行为有可能被定义为一种ip欺骗,很多设备会把这样的包在接入端就给滤掉了,可能都到不了你要访问的那个服务器,呵呵。

那么Linux如何做SNAT呢?比如一个内网的10.1.1.11的pc访问202.2.2.2的一个web服务器,linux的内网接口10.1.1.1在收到这个包之后把原来的PC的 ip10.1.1.11改变为60.1.1.1的合法地址然后送出,同时在自己的ip_conntrack表里面做一个记录,记住是内网的哪一个ip的哪个端口访问的这个web服务器,自己把它的源地址改成多少了,端口改成多少了,以便这个web服务器返回数据包的时候linux将它准确的送回给发送请求的这个pc.

大体的数据转发流程我们说完了,我们看看iptables使用什么样的参数来完成这些操作。
在描述这些具体的操作之前,我还要说几个我对iptables的概念的理解(未必完全正确),这将有助于大家理解这些规则,以实现更精确的控制。上文中我们提到过,对包的控制是由我们在不同的Chain(链)上面添加不同的规则来实现的,比如我们对过滤表(filter table)添加规则来执行对包的操控。那么既然叫链,一定就是一条或者多条规则组成的了,这时就有一个问题了,如果多个规则对同一种包进行了定义,会发生什么事情呢?在Chain中,所有的规则都是从上向下来执行的,也就是说,如果匹配了第一行,那么就按照第一行的规则执行,一行一行的往下找,直到找到符合这个类型的包的规则为止。如果找了一遍没有找到符合这个包的规则怎么办呢?itpables里面有一个概念,就是Policy,也就是策略。一说这个东西大家可能就会觉得比较麻烦,什么策略阿,我对于它的理解就是所谓这个策略就是chain中的最后一条规则,也就是说如果找了一遍找不到符合处理这个包的规则,就按照policy来办。这样理解起来就容易多了。iptables 使用-P来设置Chain的策略。

好了,我们言归正传,来说说iptables到底怎样实现对包的控制

先介绍一下iptables如何操作链
对链的操作就那么几种,-I(插入) -A(追加) -R(替换) -D(删除) -L(列表显示)
这里要说明的就是-I将会把规则放在第一行,-A将会放在最后一行。
比如我们要添加一个规则到filter表的FORWARD链
iptables -t filter -A FORWARD -s 10.1.1.11 -d 202.1.1.1 -j ACCEPT
上面的命令意思为:追加一个规则至filter表中的FORWARD链尾,允许(-j ACCEPT)源地址为10.1.1.11目的地址为202.1.1.1的数据包通过。其中-t后面跟的是表名,在-A后面跟Chain名,后面的小写的 -s为源地址,-d为目的地址,-j为处理方向。
在iptables中,默认的表名就是filter,所以这里可以省略-t filter直接写成:iptables -A FORWARD -s 10.1.1.11 -d 202.1.1.1 -j ACCEPT

iptables中的匹配参数:
我们在这里就介绍几种常用的参数,详细地用法可以man iptables看它的联机文档,你会有意外的收获。
-s匹配源地址
-d匹配目的地址
-p协议匹配
-i入接口匹配
-o出接口匹配
–sport,–dport源和目的端口匹配
-j跳转,也就是包的方向
其中还有一个!参数,使用!就是取反的意思。下面我们简单举几个例子介绍一下。
-s这个参数呢就是指定源地址的,如果使用这个参数也就是告诉netfilter,对于符合这样一个源地址的包怎么去处理,可以指定某一个单播ip地址,也可以指定一个网络,如果单个的ip地址其实隐含了一个32位的子网掩码,比如-s 10.1.1.11 其实就是-s 10.1.1.11/32 同样我们可以指定不同的掩码用以实现源网络地址的规则,比如一个C类地址我们可以用-s 10.1.1.0/24来指定。
-d参数与-s格式一样。
-i参数是指定入接口的网络接口,比如我仅仅允许从eth3接口过来的包通过FORWARD链,就可以这样指定iptables -A FORWARD -i eth3 -j ACCEPT
-o是出接口,与上同.

我们下面用一些简单的实例来step by step看看iptables的具体配置方法。

实例一:简单的nat路由器
环境介绍:
linux 2.4 +
2个网络接口
Lan口:10.1.1.254/24 eth0
Wan口:60.1.1.1/24 eth1
目的:实现内网中的节点(10.1.1.0/24)可控的访问internet。

首先将Lan的节点pc的网关指向10.1.1.254
确定你的linux的ip配置无误,可以正确的ping通内外的地址。同时用route命令查看linux的本地路由表,确认指定了可用的ISP提供的默认网关。
使用sysctl net.ipv4.ip_forward=1打开linux的转发功能。

iptables -P FORWARD DROP
将FORWARD链的策略设置为DROP,这样做的目的是做到对内网ip的控制,你允许哪一个访问internet就可以增加一个规则,不在规则中的ip将无法访问internet.

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
这条规则规定允许任何地址到任何地址的确认包和关联包通过。一定要加这一条,否则你只允许lan IP访问没有用,至于为什么,下面我们再详细说。

iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -j SNAT –to 60.1.1.1
这条规则做了一个SNAT,也就是源地址转换,将来自10.1.1.0/24的地址转换为60.1.1.1

有这几条规则,一个简单的nat路由器就实现了。这时你可以将允许访问的ip添加至FORWARD链,他们就能访问internet了。

比如我想让10.1.1.9这个地址访问internet,那么你就加如下的命令就可以了。
iptables -A FORWARD -s 10.1.1.9 -j ACCEPT

也可以精确控制他的访问地址,比如我就允许10.1.1.99访问3.3.3.3这个ip
iptables -A FORWARD -s 10.1.1.99 -d 3.3.3.3 -j ACCEPT

或者只允许他们访问80端口。
iptables -A FORWARD -s 10.1.1.0/24 -p tcp –dport http -j ACCEPT
更多的控制可以自己灵活去做,或者查阅iptables的联机文档。

实例二:端口转发

环境介绍:
linux 2.4 +
2个网络接口
Lan口:10.1.1.254/24 eth0
Lan内web server: 10.1.1.1:80
Lan内ftp server: 10.1.1.2:21
Wan口:60.1.1.1/24 eth1
目的:对内部server进行端口转发实现internet用户访问内网服务器

同样确认你的linux的各项配置正常,能够访问内外网。
iptables -P FORWARD DROP
iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
也需要加入确认包和关联包的允许通过

如果你要把访问60.1.1.1:80的数据包转发到Lan内web server,用下面的命令
iptables -t nat -A PREROUTING -d 60.1.1.1 -p tcp –dport 80 -j DNAT –to 10.1.1.1:80
ftp服务也同样,命令如下:
iptables -t nat -A PREROUTING -d 60.1.1.1 -p tcp –dport 21 -j DNAT –to 10.1.1.2:21

好了,命令完成了,端口转发也做完了,本例能不能转发呢?不能,为什么呢?我下面详细分析一下。对于iptables好像往外访问的配置比较容易,而对内的转发似乎就有一些问题了,在一开始的时候我就先说了一些关于netfilter的流程问题,那么我就简单说说做了这些配置之后为什么有可能还不行呢?

能引起这个配置失败的原因有很多,我们一个个的来说:
第一,本例中,我们的FORWARD策略是DROP,那么也就是说,没有符合规则的包将被丢弃,不管内到外还是外到内,我们在这里依然不讨论那个确认包和关联包的问题,我们不用考虑他的问题,下面我会详细说一下这个东西,那么如何让本例可以成功呢?加入下面的规则。
iptables -A FORWARD -d 10.1.1.1 -p tcp –dport 80 -j ACCEPT
iptables -A FORWARD -d 10.1.1.2 -p tcp –dport 21 -j ACCEPT
有没有觉得有一些晕?为什么目的地址是10.xxx而不是60.xxx人家internet用户不是访问的60.xxx吗?呵呵,回到上面看看那个图吧, FORWARD链在什么位置上,它是在PREROUTING之后,也就是说当这个包到达FORWARD链的时候,目的地址已经变成10.xxx了,假如 internet用户的请求是这样202.1.1.1:1333–>60.1.1.1:80,在经过了我们的PREROUTING链之后将变成 202.1.1.1:1333–>10.1.1.1:80,这个时候如果你设置一个目的地址为60.xxx的规则有用吗?呵呵,这是问题一。这个时候应该可以完成端口转发的访问了,但是有一些时候还是不行?为什么?看问题二。
第二,内网server的ip配置问题,这里我们以web server为例说明一下(ftp情况有一些特殊,下面我们再详细讨论,说确认包和关联包的时候讨论这个问题),上面说到,有的时候可以访问了,有的时候却不行,就是这个web server的ip设置问题了,如果web server没有指定默认的网关,那么在作了上面的配置之后,web server会收到internet的请求,但是,他不知道往哪里回啊,人家的本地路由表不知道你那个internet的ip,202.1.1.1该怎么走。如果你使用截包工具在web server上面察看,你会发现server收到了来自202.1.1.1:1333–>10.1.1.1:80的请求,由于你没有给web server配置默认网关,它不知道怎么回去,所以就出现了不通的情况。怎么办呢?两个解决方法:一就是给这个server配置一个默认网关,当然要指向这个配置端口转发的linux,本例是10.1.1.254,配置好了,就一定能访问了。有一个疑问?难道不需要在FORWARD链上面设置一个允许 web server的ip地址访问外网的规则吗?它的包能出去?答案是肯定的,能出去。因为我们那一条允许确认包与关联包的规则,否则它是出不去的。第二种方法,比较麻烦一些,但是对服务器来说这样似乎更安全一些。方法就是对这个包再作一次SNAT,也就是在POSTROUTING链上添加规则。命令如下:
iptables -t nat -A POSTROUTING -d 10.1.1.1 -p tcp –dport 80 -j SNAT –to 10.1.1.254
ftp的方法相同。这条命令不太好懂??其实很简单,如果使用这条命令,那么你的web server不需要再设置默认网关,就能收到这个请求,只要他和linux的lan ip地址是能互访的(也就是说web server和Linux的Lan ip在一个广播域),我们在根据上面的netfilter流程图来分析这个包到底被我们怎么样了,首先一个请求202.1.1.1:1333–> 60.1.1.1:80被linux收到了,进入PREROUTING,发现一个规则(iptables -t nat -A PREROUTING -d 60.1.1.1 -p tcp –dport 80 -j DNAT –to 10.1.1.1:80)符合,好了,改你的目的地址,于是这个包变成了202.1.1.1:1333–>10.1.1.1:80,继续往前走,进入FORWARD链,okay,也有一条规则允许通过(iptables -A FORWARD -d 10.1.1.1 -p tcp –dport 80 -j ACCEPT),进入route box选路,找到合适的路径了,继续进入POSTROUTING链,耶?又发现一个符合的规则(iptables -t nat -A POSTROUTING -d 10.1.1.1 -p tcp –dport 80 -j SNAT –to 10.1.1.254),原来是一个SNAT,改你的源地址,于是这个包变成了10.1.1.254:xxxx–>10.1.1.1:80。为什么用xxxx了,这里的端口是随机的,我也不知道会是什么。而整个的两次变化的过程都会记录在linux的ip_conntrack中,当web server收到这个包的时候,发现,原来是一个内网自己兄弟来的请求阿,又在一个广播域,不用找网关,把返回包直接扔给交换机了,linux在收到返回包之后,会根据他的ip_conntrack中的条目进行两次变换,返回真正的internet用户,于是完成这一次的访问。

看了上面的两个例子,不知道大家是否清楚了iptables的转发流程,希望对大家有所帮助,下面我们就说说我一直在上面提到的关于那个 ESTABLISHED,RELATED的规则是怎么回事,到底有什么用处。说这个东西就要简单说一下网络的数据通讯的方式,我们知道,网络的访问是双向的,也就是说一个Client与Server之间完成数据交换需要双方的发包与收包。在netfilter中,有几种状态,也就是new, established,related,invalid。当一个客户端,在本文例一中,内网的一台机器访问外网,我们设置了规则允许他出去,但是没有设置允许回来的规则阿,怎么完成访问呢?这就是netfilter的状态机制,当一个lan用户通过这个linux访问外网的时候,它发送了一个请求包,这个包的状态是new,当外网回包的时候他的状态就是established,所以,linux知道,哦,这个包是我的内网的一台机器发出去的应答包,他就放行了。而外网试图对内发起一个新的连接的时候,他的状态是new,所以linux压根不去理会它。这就是我们为什么要加这一句的原因。还有那个 related,他是一个关联状态,什么会用到呢?tftp,ftp都会用到,因为他们的传输机制决定了,它不像http访问那样,Client_IP: port–>server:80  然后server:80–>Client_IP:port,ftp使用tcp21建立连接,使用20端口发送数据,其中又有两种方式,一种主动 active mode,一种被动passive mode,主动模式下,client使用port命令告诉server我用哪一个端口接受数据,然后server主动发起对这个端口的请求。被动模式下, server使用port命令告诉客户端,它用那个端口监听,然后客户端发起对他的数据传输,所以这对于一个防火墙来说就是比较麻烦的事情,因为有可能会有new状态的数据包,但是它又是合理的请求,这个时候就用到这个related状态了,他就是一种关联,在linux中,有个叫 ftp_conntrack的模块,它能识别port命令,然后对相应的端口进行放行。

一口气写了这么多东西,不知道质量如何,大家凑和着看吧,希望多多交流共同进步,我还是一个linux的初学者,难免很多谬误,希望高手赐教指正,以期不断进步。

对了,还有几个在实际中比较实用(也比较受用:-))的命令参数,写出来供大家参考

iptables -L -n
这样的列表会跳过linux的domain lookup,有的时候使用iptables -L会比较慢,因为linux会尝试解析ip的域名,真是罗嗦,如果你的dns server比较不爽的话,iptables -L就会让你很不爽,加一个-n参数就好了。列表刷的就出来。当然了,如果你的linux就是做防火墙,建议把nameserver去掉,在 /etc/resolve.conf里面,因为有时候使用route命令也会比较慢列出来,很是不爽。

iptables -L -v
这个命令会显示链中规则的包和流量计数,嘿嘿,看看哪些小子用的流量那么多,用tc限了他。

cat /proc/net/ip_conntrack
查看目前的conntrack,可能会比较多哦,最好加一个|grep “关键字”,看看你感兴趣的链接跟踪

wc -l /proc/net/ip_conntrack
看看总链接有多少条。

iptables-save >/etc/iptables
把当前的所有链备份一下,之所以放到/etc下面叫iptables,因为这样重起机器的时候会自动加载所有的链,经常地备份一下吧,否则如果链多,万一掉电重启,你还是会比较痛苦。

request请求数据包组成:请求行(request line)消息头(header)实体内容(Body)

HTTP客户请求数据格式

大多数servlet程序都是和浏览器客户以HTTP协议进行通信的,这需要编程人员对程序的基本功能和HTTP协议的具体操作有深入的理解。在学习servlet和Jsp编程时,有两点值得注意:首先是对HTTP协议的操作过程和数据格式足够熟悉,其次要灵活应用servlet的API中的有关方法正确高效地处理有关数据。

一、HTTP客户请求的数据格式说明
HTTP请求包括三部分:请求行(Request Line),头部(Headers)和实体内容(Body)。其中,请求行由请求方法(method),请求网址Request-URI和协议 (Protocol)构成,而消息头包括多个属性,实体内容(数据体)则可以被认为是附加在请求之后的文本或二进制文件,只有请求方式为post的时候,实体内容才会有数据(即请求参数)。

request请求数据包组成:请求行(request <wbr>line)消息头(header)实体内容(Body)
下面这个例子显示了一个HTTP请求的Header内容,这些数据是真正以网络HTTP协议从IE浏览器传递到Tomcat服务器上的。
GET /icwork/? search=product HTTP/1.1
Accept:image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,application/vnd.ms-powerpoint,application/vnd.ms-excel,application/msword,*.*
Accept-Language:en-us
Accept-Encoding:gzip,deflate
User-Agent:Mozilla/4.0(compatible;MSIE 5.01;Windows NT 5.0;DigExt)
Host:www.icconcept.com:8080
Referer:http://www.yoursite.com/header.html
Connection:Keep-Alive
这段程序使用了6个Header,还有一些Header没有出现。我们参考这个例子具体解释HTTP请求格式。
1.HTTP请求行:请求行格式为Method Request-URI Protocol。在上面这个例子里,“GET /icwork/? search=pruduct HTTP/1.1”是请求行。
2.Accept:指浏览器或其他客户可以接爱的MIME文件格式。Servlet可以根据它判断并返回适当的文件格式。
3.Accept-Charset:指出浏览器可以接受的字符编码。英文浏览器的默认值是ISO-8859-1.
4.Accept-Language:指出浏览器可以接受的语言种类,如en或en-us,指英语。
5.Accept-Encoding:指出浏览器可以接受的编码方式。编码方式不同于文件格式,它是为了压缩文件并加速文件传递速度。浏览器在接收到Web响应之后先解码,然后再检查文件格式。
6.Authorization:当使用密码机制时用来标识浏览器。
7.Cache-Control:设置关于请求被代理服务器存储的相关选项。一般servlet用不到。
8.Connection:用来告诉服务器是否可以维持固定的HTTP连接。HTTP/1.1使用Keep-Alive为默认值,这样,当浏览器需要多个文件时(比如一个HTML文件和相关的图形文件),不需要每次都建立连接。
9.Content-Type:用来表名request的内容类型。可以用HttpServletRequest的getContentType()方法取得。
10.Cookie:浏览器用这个属性向服务器发送Cookie。Cookie是在浏览器中寄存的小型数据体,它可以记载和服务器相关的用户信息,也可以用来实现会话功能。
11.Expect:表时客户预期的响应状态。
12.From:给出客户端HTTP请求负责人的email地址。
13.Host:对应网址URL中的Web名称和端口号。
14.If-Match:供PUT方法使用。
15.If-Modified-Since:客户使用这个属性表明它只需要在指定日期之后更改过的网页。因为浏览器可以使用其存储的文件而不必从服务器请求,这样节省了Web资源。由于Servlet是动态生成的网页,一般不需要使用这个属性。
16.If-None-Match:和If-Match相反的操作,供PUT方法使用。
17.If-Unmodified-Since:和If-Match-Since相反。
18.Pragma:这个属性只有一种值,即Pragma:no-cache,表明如果servlet充当代理服务器,即使其有已经存储的网页,也要将请求传递给目的服务器。
19.Proxy-Authorization:代理服务器使用这个属性,Servlet一般用不到。
20.Range:如果客户有部分网页,这个属性可以请求剩余部分。
21.Referer:表明产生请求的网页URL。如比从网页/icconcept/index.jsp中点击一个链接到网页/icwork/search,在向服务器发送的GET/icwork/search中的请求中,Referer是http://hostname:8080/icconcept/index.jsp。这个属性可以用来跟踪Web请求是从什么网站来的。
22.Upgrage:客户通过这个属性设定可以使用与HTTP/1.1不同的协议。
23.User-Agent:是客户浏览器名称。
24.Via:用来记录Web请求经过的代理服务器或Web通道。
25.Warning:用来由客户声明传递或存储(cache)错误。
补充.Transfer-Encoding:
当不能预先确定报文体的长度时,不可能在头中包含Content-Length域来指明报文体长度,此时就需要通过Transfer-Encoding域来确定报文体长度。
通常情况下,Transfer-Encoding域的值应当为chunked,表明采用chunked编码方式来进行报文体的传输。chunked编码是HTTP/1.1 RFC里定义的一种编码方式,因此所有的HTTP/1.1应用都应当支持此方式。
chunked编码的基本方法是将大块数据分解成多块小数据,每块都可以自指定长度

nginx应用总结(2)–突破高并发的性能优化

在日常的运维工作中,经常会用到nginx服务,也时常会碰到nginx因高并发导致的性能瓶颈问题。今天这里简单梳理下nginx性能优化的配置(仅仅依据本人的实战经验而述,如有不妥,敬请指出~)

一、这里的优化主要是指对nginx的配置优化,一般来说nginx配置文件中对优化比较有作用的主要有以下几项:
1)nginx进程数,建议按照cpu数目来指定,一般跟cpu核数相同或为它的倍数。
worker_processes 8;
2)为每个进程分配cpu,上例中将8个进程分配到8个cpu,当然可以写多个,或者将一个进程分配到多个cpu。
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
3)下面这个指令是指当一个nginx进程打开的最多文件描述符数目,理论值应该是系统的最多打开文件数(ulimit -n)与nginx进程数相除,但是nginx分配请求并不是那么均匀,所以最好与ulimit -n的值保持一致。
worker_rlimit_nofile 65535;
4)使用epoll的I/O模型,用这个模型来高效处理异步事件
use epoll;
5)每个进程允许的最多连接数,理论上每台nginx服务器的最大连接数为worker_processes*worker_connections。
worker_connections 65535;
6)http连接超时时间,默认是60s,功能是使客户端到服务器端的连接在设定的时间内持续有效,当出现对服务器的后继请求时,该功能避免了建立或者重新建立连接。切记这个参数也不能设置过大!否则会导致许多无效的http连接占据着nginx的连接数,终nginx崩溃!
keepalive_timeout 60;
7)客户端请求头部的缓冲区大小,这个可以根据你的系统分页大小来设置,一般一个请求的头部大小不会超过1k,不过由于一般系统分页都要大于1k,所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。
client_header_buffer_size 4k;
8)下面这个参数将为打开文件指定缓存,默认是没有启用的,max指定缓存数量,建议和打开文件数一致,inactive是指经过多长时间文件没被请求后删除缓存。
open_file_cache max=102400 inactive=20s;
9)下面这个是指多长时间检查一次缓存的有效信息。
open_file_cache_valid 30s;
10)open_file_cache指令中的inactive参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在inactive时间内一次没被使用,它将被移除。
open_file_cache_min_uses 1;

11)隐藏响应头中的有关操作系统和web server(Nginx)版本号的信息,这样对于安全性是有好处的。
server_tokens off;
12)可以让sendfile()发挥作用。sendfile()可以在磁盘和TCP socket之间互相拷贝数据(或任意两个文件描述符)。Pre-sendfile是传送数据之前在用户空间申请数据缓冲区。之后用read()将数据从文件拷贝到这个缓冲区,write()将缓冲区数据写入网络。sendfile()是立即将数据从磁盘读到OS缓存。因为这种拷贝是在内核完成的,sendfile()要比组合read()和write()以及打开关闭丢弃缓冲更加有效(更多有关于sendfile)。
sendfile on;
13)告诉nginx在一个数据包里发送所有头文件,而不一个接一个的发送。就是说数据包不会马上传送出去,等到数据包最大时,一次性的传输出去,这样有助于解决网络堵塞。
tcp_nopush on;
14)告诉nginx不要缓存数据,而是一段一段的发送–当需要及时发送数据时,就应该给应用设置这个属性,这样发送一小块数据信息时就不能立即得到返回值。
tcp_nodelay on;
比如:
http {
server_tokens off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
……
}
15)客户端请求头部的缓冲区大小,这个可以根据系统分页大小来设置,一般一个请求头的大小不会超过1k,不过由于一般系统分页都要大于1k,所以这里设置为分页大小。
client_header_buffer_size 4k;
客户端请求头部的缓冲区大小,这个可以根据系统分页大小来设置,一般一个请求头的大小不会超过1k,不过由于一般系统分页都要大于1k,所以这里设置为分页大小。
分页大小可以用命令getconf PAGESIZE取得。
[root@test-huanqiu ~]# getconf PAGESIZE
4096
但也有client_header_buffer_size超过4k的情况,但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。
16)为打开文件指定缓存,默认是没有启用的,max 指定缓存数量,建议和打开文件数一致,inactive 是指经过多长时间文件没被请求后删除缓存。
open_file_cache max=65535 inactive=60s;
17)open_file_cache 指令中的inactive 参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在inactive 时间内一次没被使用,它将被移除。
open_file_cache_min_uses 1;
18)指定多长时间检查一次缓存的有效信息。
open_file_cache_valid 80s;

—————————————————————-
下面是一个本人使用的简单的nginx配置文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
[root@dev-huanqiu ~]# cat /usr/local/nginx/conf/nginx.conf
user www www;
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000;
error_log /www/log/nginx_error.log crit;
pid /usr/local/nginx/nginx.pid;
worker_rlimit_nofile 65535;

events
{
use epoll;
worker_connections 65535;
}

http
{
include mime.types;
default_type application/octet-stream;

charset utf-8;

server_names_hash_bucket_size 128;
client_header_buffer_size 2k;
large_client_header_buffers 4 4k;
client_max_body_size 8m;

sendfile on;
tcp_nopush on;

keepalive_timeout 60;

fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2
keys_zone=TEST:10m
inactive=5m;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 16k;
fastcgi_buffers 16 16k;
fastcgi_busy_buffers_size 16k;
fastcgi_temp_file_write_size 16k;
fastcgi_cache TEST;
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
fastcgi_cache_min_uses 1;
fastcgi_cache_use_stale error timeout invalid_header http_500;
open_file_cache max=204800 inactive=20s;
open_file_cache_min_uses 1;
open_file_cache_valid 30s;

tcp_nodelay on;

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;

server
{
listen 8080;
server_name huan.wangshibo.com;
index index.php index.htm;
root /www/html/;

location /status
{
stub_status on;
}

location ~ .*\.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$
{
expires 30d;
}

log_format access ‘$remote_addr – $remote_user [$time_local] “$request” ‘
‘$status $body_bytes_sent “$http_referer” ‘
‘”$http_user_agent” $http_x_forwarded_for’;
access_log /www/log/access.log access;
}
}
二、关于FastCGI的几个指令

1)这个指令为FastCGI缓存指定一个路径,目录结构等级,关键字区域存储时间和非活动删除时间。
fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;
2)指定连接到后端FastCGI的超时时间。
fastcgi_connect_timeout 300;
3)向FastCGI传送请求的超时时间,这个值是指已经完成两次握手后向FastCGI传送请求的超时时间。
fastcgi_send_timeout 300;
4)接收FastCGI应答的超时时间,这个值是指已经完成两次握手后接收FastCGI应答的超时时间。
fastcgi_read_timeout 300;
5)指定读取FastCGI应答第一部分 需要用多大的缓冲区,这里可以设置为fastcgi_buffers指令指定的缓冲区大小,上面的指令指定它将使用1个 16k的缓冲区去读取应答的第一部分,即应答头,其实这个应答头一般情况下都很小(不会超过1k),但是你如果在fastcgi_buffers指令中指 定了缓冲区的大小,那么它也会分配一个fastcgi_buffers指定的缓冲区大小去缓存。
fastcgi_buffer_size 16k;
6)指定本地需要用多少和多大的缓冲区来 缓冲FastCGI的应答,如上所示,如果一个php脚本所产生的页面大小为256k,则会为其分配16个16k的缓冲区来缓存,如果大于256k,增大 于256k的部分会缓存到fastcgi_temp指定的路径中, 当然这对服务器负载来说是不明智的方案,因为内存中处理数据速度要快于硬盘,通常这个值 的设置应该选择一个你的站点中的php脚本所产生的页面大小的中间值,比如你的站点大部分脚本所产生的页面大小为 256k就可以把这个值设置为16 16k,或者4 64k 或者64 4k,但很显然,后两种并不是好的设置方法,因为如果产生的页面只有32k,如果用4 64k它会分配1个64k的缓冲区去缓存,而如果使用64 4k它会分配8个4k的缓冲区去缓存,而如果使用16 16k则它会分配2个16k去缓存页面,这样看起来似乎更加合理。
fastcgi_buffers 16 16k;
7)这个指令我也不知道是做什么用,只知道默认值是fastcgi_buffers的两倍。
fastcgi_busy_buffers_size 32k;
8)在写入fastcgi_temp_path时将用多大的数据块,默认值是fastcgi_buffers的两倍。
fastcgi_temp_file_write_size 32k;
9)开启FastCGI缓存并且为其制定一个名称。个人感觉开启缓存非常有用,可以有效降低CPU负载,并且防止502错误。但是这个缓存会引起很多问题,因为它缓存的是动态页面。具体使用还需根据自己的需求。
fastcgi_cache TEST
10)为指定的应答代码指定缓存时间,如上例中将200,302应答缓存一小时,301应答缓存1天,其他为1分钟。
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
11)缓存在fastcgi_cache_path指令inactive参数值时间内的最少使用次数,如上例,如果在5分钟内某文件1次也没有被使用,那么这个文件将被移除。
fastcgi_cache_min_uses 1;
12)不知道这个参数的作用,猜想应该是让nginx知道哪些类型的缓存是没用的。
fastcgi_cache_use_stale error timeout invalid_header http_500;

———————————–
以上为nginx中FastCGI相关参数,
另外,FastCGI自身也有一些配置需要进行优化,如果你使用php-fpm来管理FastCGI,可以修改配置文件中的以下值:
1)同时处理的并发请求数,即它将开启最多60个子线程来处理并发连接。
<value name=”max_children”>60</value>
2)最多打开文件数。
<value name=”rlimit_files”>65535</value>
3)每个进程在重置之前能够执行的最多请求数。
<value name=”max_requests”>65535</value>

三、关于内核参数的优化,在/etc/sysctl.conf文件内
1)timewait的数量,默认是180000。(Deven:因此如果想把timewait降下了就要把tcp_max_tw_buckets值减小)
net.ipv4.tcp_max_tw_buckets = 6000
2)允许系统打开的端口范围。
net.ipv4.ip_local_port_range = 1024 65000
3)启用TIME-WAIT状态sockets快速回收功能;用于快速减少在TIME-WAIT状态TCP连接数。1表示启用;0表示关闭。但是要特别留意的是:这个选项一般不推荐启用,因为在NAT(Network Address Translation)网络下,会导致大量的TCP连接建立错误,从而引起网站访问故障。
net.ipv4.tcp_tw_recycle = 0
———————————————————————————————————————————-
实际上,net.ipv4.tcp_tw_recycle功能的开启,要需要net.ipv4.tcp_timestamps(一般系统默认是开启这个功能的)这个开关开启后才有效果;
当tcp_tw_recycle 开启时(tcp_timestamps 同时开启,快速回收 socket 的效果达到),对于位于NAT设备后面的 Client来说,是一场灾难!
会导致到NAT设备后面的Client连接Server不稳定(有的 Client 能连接 server,有的 Client 不能连接 server)。
也就是说,tcp_tw_recycle这个功能,是为内部网络(网络环境自己可控 ” ——不存在NAT 的情况)设计的,对于公网环境下,不宜使用。
通常来说,回收TIME_WAIT状态的socket是因为“无法主动连接远端”,因为无可用的端口,而不应该是要回收内存(没有必要)。
即:需求是Client的需求,Server会有“端口不够用”的问题吗?
除非是前端机,需要大量的连接后端服务,也就是充当着Client的角色。

正确的解决这个总是办法应该是:
net.ipv4.ip_local_port_range = 9000 6553 #默认值范围较小
net.ipv4.tcp_max_tw_buckets = 10000 #默认值较小,还可适当调小
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 10
———————————————————————————————————————————-

4)开启重用功能,允许将TIME-WAIT状态的sockets重新用于新的TCP连接。这个功能启用是安全的,一般不要去改动!
net.ipv4.tcp_tw_reuse = 1
5)开启SYN Cookies,当出现SYN等待队列溢出时,启用cookies来处理。
net.ipv4.tcp_syncookies = 1
6)web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128,而nginx定义的NGX_LISTEN_BACKLOG默认为511,所以有必要调整这个值。
net.core.somaxconn = 262144
7)每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目。
net.core.netdev_max_backlog = 262144
8)系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字,孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS攻击,不能过分依靠它或者人为地减小这个值,更应该增加这个值(如果增加了内存之后)。
net.ipv4.tcp_max_orphans = 262144
9)记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言,缺省值是1024,小内存的系统则是128。
net.ipv4.tcp_max_syn_backlog = 262144
10)时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。
net.ipv4.tcp_timestamps = 1
——————————————————————————————————————————————————-
有不少服务器为了提高性能,开启net.ipv4.tcp_tw_recycle选项,在NAT网络环境下,容易导致网站访问出现了一些connect失败的问题
个人建议:
关闭net.ipv4.tcp_tw_recycle选项,而不是net.ipv4.tcp_timestamps;
因为在net.ipv4.tcp_timestamps关闭的条件下,开启net.ipv4.tcp_tw_recycle是不起作用的;而net.ipv4.tcp_timestamps可以独立开启并起作用。
——————————————————————————————————————————————————-
11)为了打开对端的连接,内核需要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK包的数量。
net.ipv4.tcp_synack_retries = 1
12)在内核放弃建立连接之前发送SYN包的数量。
net.ipv4.tcp_syn_retries = 1
13)如果套接字由本端要求关闭,这个参数 决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接,甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒,你可以按这个设置,但要记住的是,即使你的机器是一个轻载的WEB服务器,也有因为大量的死套接字而内存溢出的风险,FIN- WAIT-2的危险性比FIN-WAIT-1要小,因为它最多只能吃掉1.5K内存,但是它们的生存期长些。
net.ipv4.tcp_fin_timeout = 30
14)当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时。
net.ipv4.tcp_keepalive_time = 30

———————————————————————-
下面贴出一个本人常用的内核参数的标准配置
[root@dev-huanqiu ~]# cat /etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1 //这四行标红内容,一般是发现大量TIME_WAIT时的解决办法
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net.ipv4.tcp_wmem = 4096 16384 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 1 //在net.ipv4.tcp_tw_recycle设置为1的时候,这个选择最好加上
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1 //开启此功能可以减少TIME-WAIT状态,但是NAT网络模式下打开有可能会导致tcp连接错误,慎重。
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.ip_conntrack_max = 6553500

————————————-记一次小事故—————————————————-
net.ipv4.tcp_tw_recycle = 1 这个功能打开后,确实能减少TIME-WAIT状态,习惯上我都会将这个参数打开。
但是也因为这个参数踩过一次坑:
公司的一个发布新闻的CMS后台系统,采用haproxy+keepalived代理架构,后端的real server服务器外网ip全部拿掉。
现象:在某一天早上发文高峰期,CMS后台出现访问故障,重启php服务后会立刻见效,但持续一段时间后,访问就又出现故障。
排查nginx和php日志也没有发现什么,后来google了一下,发现就是net.ipv4.tcp_tw_recycle这个参数捣的鬼!
这种网络架构对于后端的realserver来说是NAT模式,打开这个参数后,会导致大量的TCP连接建立错误,从而引起网站访问故障。
最后将net.ipv4.tcp_tw_recycle设置为0,关闭这个功能后,后台访问即刻恢复正常
—————————————————————————————————–

——————————-Nginx安全配置小提示————————————
下面是一个常见安全陷阱和解决方案的列表,它可以辅助来确保你的Nginx部署是安全的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
1)禁用autoindex模块。这个可能在你使用的Nginx版本中已经更改了,如果没有的话只需在配置文件的location块中增加autoindex off;声明即可。

2)禁用服务器上的ssi (服务器端引用)。这个可以通过在location块中添加ssi off; 。

3)关闭服务器标记。如果开启的话(默认情况下)所有的错误页面都会显示服务器的版本和信息。将server_tokens off;声明添加到Nginx配置文件来解决这个问题。

4)在配置文件中设置自定义缓存以限制缓冲区溢出攻击的可能性。
client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;

5)将timeout设低来防止DOS攻击。所有这些声明都可以放到主配置文件中。
client_body_timeout 10;
client_header_timeout 10;
keepalive_timeout 65;
send_timeout 10;

6)限制用户连接数来预防DOS攻击。
limit_zone slimits $binary_remote_addr 5m;
limit_conn slimits 5;

7)试着避免使用HTTP认证。HTTP认证默认使用crypt,它的哈希并不安全。如果你要用的话就用MD5(这也不是个好选择但负载方面比crypt好) 。

nginx 配置open_cache_file 静态文件的缓存

open_file_cache max=65535 inactive=30s

最多缓存多少个文件,缓存多少时间
open_file_cache_min_uses 1

在30S中没有使用到这个配置的次数的话就删除
open_file_cache_valid 40s

多少时间检查一次,如果发现30s内没有用过一次的删除

Nginx使用教程(四):提高Nginx网络吞吐量之buffers优化

请求缓冲区在NGINX请求处理中起着重要作用。 在接收到请求时,NGINX将其写入这些缓冲区。 这些缓冲区中的数据可作为NGINX变量使用,例如$request_body。 如果缓冲区与请求大小相比较小,则数据将写入磁盘上的文件,因此将涉及I/O操作。 NGINX提供了可以改变请求缓冲区的各种指令。

client_body_buffer_size

<br\>
此指令设置用于请求主体的缓冲区大小。 如果主体超过缓冲区大小,则完整主体或其一部分将写入临时文件。 如果NGINX配置为使用文件而不是内存缓冲区,则该指令会被忽略。 默认情况下,该指令为32位系统设置一个8k缓冲区,为64位系统设置一个16k缓冲区。 该指令在NGINX配置的http,server和location区块使用。如下:

  1. server{
  2.       client_body_buffer_size 8k;
  3. }

client_max_body_size

<br\>
此指令设置NGINX能处理的最大请求主体大小。 如果请求大于指定的大小,则NGINX发回HTTP 413(Request Entity too large)错误。 如果服务器处理大文件上传,则该指令非常重要。

默认情况下,该指令值为1m。 如下:

  1. server{
  2.       client_max_body_size 2m;
  3. }

client_body_in_file_only

<br\>
此指令禁用NGINX缓冲区并将请求体存储在临时文件中。 文件包含纯文本数据。 该指令在NGINX配置的http,server和location区块使用。 可选值有:
off:该值将禁用文件写入
clean:请求body将被写入文件。 该文件将在处理请求后删除。
on: 请求正文将被写入文件。 处理请求后,将不会删除该文件。
默认情况下,指令值为关闭。 如下:

  1. http{
  2.       client_body_in_file_only clean;
  3. }

client_body_in_single_buffer

<br\>
该指令设置NGINX将完整的请求主体存储在单个缓冲区中。 默认情况下,指令值为off。 如果启用,它将优化读取$request_body变量时涉及的I/O操作。如下例子:

  1. server{
  2.       client_body_in_single_buffer on;
  3. }

client_body_temp_path

<br\>
此指令指定存储请求正文的临时文件的位置。 除了位置之外,指令还可以指定文件是否需要最多三个级别的文件夹层次结构。 级别指定为用于生成文件夹的位数。
默认情况下,NGINX在NGINX安装路径下的client_body_temp文件夹创建临时文件。 如下例子:

  1. server{
  2.       client_body_temp_pathtemp_files 1 2;
  3.       }

该指令生成的文件路径如temp_files/1/05/0000003051。

client_header_buffer_size

<br\>
此指令与client_body_buffer_size类似。 它为请求头分配一个缓冲区。 如果请求头大小大于指定的缓冲区,则使用large_client_header_buffers指令分配更大的缓冲区。如下例子:

  1. http{
  2.       client_header_buffer_size 1m;
  3.       }

large_client_header_buffers

<br\>
此指令规定了用于读取大型客户端请求头的缓冲区的最大数量和大小。 这些缓冲区仅在缺省缓冲区不足时按需分配。 当处理请求或连接转换到保持活动状态时,释放缓冲区。如下例子:

    1. http{
    2.       large_client_header_buffers 4 8k;
    3.       }

Nginx的client_header_buffer_size和large_client_header_buffers学习

之前看到有人写的一篇关于nginx配置中large_client_header_buffers的问题排查的文章,其中提到:

large_client_header_buffers 虽然也可以在server{}内生效,但是只有 低于 nginx主配置中的值才有意义。

对这个结论,我心存疑虑,总觉得这种设计很奇怪,于是自己做了个测试,希望能了解的更深入一些。

测试方法

nginx主配置中加入配置项:(在主配置中将header大小控制在1k)

http {
    include  mime.types;
    default_type  application/octet-stream;
    large_client_header_buffers  4 1k;
    ......
}

删除所有干扰vhost,仅留下一个:

server {
    listen 80;
    server_name  www.job360.com;
    large_client_header_buffers  4 1m;
    ......
}

构造请求的shell:(构造header超过1k的请求)

#!/bin/bash

url="http://www.job360.com/test.html?debug=1"

for i in {0..1000}
do
    var="v$i"
    url="${url}&$var=$i"
done

curl $url -x 127.0.0.1:80 -v

第一次测试结果

测试得到的结果和之前看到的文章的结果不同,该长url请求成功被nginx处理。

什么情况啊?于是查看和文章中环境上的不同,发现很重要的一点:我只有这一个vhost。

于是添加了另外一个vhost,添加vhost配置如下:(没有设置 large_client_header_buffers)

server {
    listen 80;
    server_name db.job360.com;
    ......}

第二次测试结果

测试发现,nginx依旧可以处理该长url请求。

再次思考不同点,想到:这些vhost是被主配置中include进来的,是否会和读取顺序有关呢?

于是再次调整配置,将两个vhost放到了一个conf文件中,配置如下:

server {
    listen 80;
    server_name db.job360.com;
    ......
}

server {
    listen 80;
    server_name  www.job360.com;
    large_client_header_buffers  4 1m;
    ......
}

第三次测试结果

得到和文章中相同的结果,nginx返回414 Request-URI Too Large

带着好奇心,我颠倒了下两个vhost的顺序,如下:

server {
    listen 80;
    server_name  www.job360.com;
    large_client_header_buffers  4 1m;
    ......
}

server {
    listen 80;
    server_name db.job360.com;
    ......
}

第四次测试结果

nginx成功处理该长url请求。

初步结论

通过上面的现象,我得到一个初步结论:在第一个vhost中配置的large_client_header_buffers参数会起作用。

好奇怪的现象啊,我对自己得出的结论也是心存疑惑,于是决定从手册中好好读下控制header_buffer相关的指令。

从手册上理解nginx有关header_buffer配置指令

从手册上找到有两个指令和header_buffer有关:

  1. client_header_buffer_size
  2. large_client_header_buffers

对nginx处理header时的方法,学习后理解如下:

  1. 先处理请求的request_line,之后才是request_header。
  2. 这两者的buffer分配策略相同。
  3. 先根据client_header_buffer_size配置的值分配一个buffer,如果分配的buffer无法容纳 request_line/request_header,那么就会再次根据large_client_header_buffers配置的参数分配large_buffer,如果large_buffer还是无法容纳,那么就会返回414(处理request_line)/400(处理request_header)错误。

根据对手册的理解,我理解这两个指令在配置header_buffer时的使用场景是不同的,个人理解如下:

  1. 如果你的请求中的header都很大,那么应该使用client_header_buffer_size,这样能减少一次内存分配。
  2. 如果你的请求中只有少量请求header很大,那么应该使用large_client_header_buffers,因为这样就仅需在处理大header时才会分配更多的空间,从而减少无谓的内存空间浪费。

为了印证自己对两个配置指令的理解,我把large_client_header_buffer换成client_header_buffer_size,重新跑上面的多种测试,得到了和之前各种场景相同的结论。

手册上也只是说明了这两个指令的使用场景,没有说更多的东西了,之前的疑惑还是没有得到解答,那么只有最后一招了,也是绝招:从源码中寻找答案

源码学习

这里从client_header_buffer_size指令入手,先查看这个指令的定义部分:

{ ngx_string("client_header_buffer_size"),
  NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_CONF_TAKE1,              //可以定义在http{}或server{}中,需要携带一个参数
  ngx_conf_set_size_slot,                                           //参数意义为size,使用nginx预定义的解析size参数方法解析
  NGX_HTTP_SRV_CONF_OFFSET,                                         //将参数值放到srv级别的conf中
  offsetof(ngx_http_core_srv_conf_t, client_header_buffer_size),    //解析后放到ngx_http_core_srv_conf_t结构体的client_header_buffer_size中
  NULL },

src/http/ngx_http_core_module.c

由定义看到,我们在server{}中解析到的值会和http{}中的值做一次merge,作为该server{}下的最终值。查看merge相关的逻辑:

ngx_conf_merge_size_value(conf->client_header_buffer_size,        //conf代表server{},prev代表http{}
                          prev->client_header_buffer_size, 1024); 

src/http/ngx_http_core_module.c
#define ngx_conf_merge_size_value(conf, prev, default)                       \
    if (conf == NGX_CONF_UNSET_SIZE) {                                       \
        conf = (prev == NGX_CONF_UNSET_SIZE) ? default : prev;               \
    }

src/core/ngx_conf_file.h

从这段逻辑中得到结论:如果我们在server{}中配置了client_header_buffer_size,那么针对这个server{}块的最终值应该就是我们配置的值。

为了印证我的结论,我重新写了vhost配置,并在代码中加入调试信息,把最终结果打印出来:

http {
    include  mime.types;
    default_type  application/octet-stream;
    large_client_header_buffers  4 1k;
    ......

    server {
        listen 80;
        server_name db.job360.com;
        ......
    }

    server {
        listen 80;
        server_name  www.job360.com;
        large_client_header_buffers  4 1m;
        ......
    }
}

调试代码:

    printf("buffer before merge:\nchild: %lu\nparent: %lu\n\n", conf->client_header_buffer_size, prev->client_header_buffer_size);
......
    ngx_conf_merge_size_value(conf->client_header_buffer_size,
                              prev->client_header_buffer_size, 1024);
......
    printf("buffer after merge:\nchild: %lu\nparent: %lu\n\n", conf->client_header_buffer_size, prev->client_header_buffer_size);

src/http/ngx_http_core_module.c

重新编译nginx,测试每个server{}中client_header_buffer_size的最终值为:

buffer before merge:
child: 18446744073709551615    //由于第一个server{}中没有配置,所以这个是-1(NGX_CONF_UNSET_SIZE)的unsigned long int表示
parent: 1024    //http{}中配置为1k

buffer after merge:
child: 1024
parent: 1024

buffer before merge:
child: 1048576    //第二个server{}中配置为1m
parent: 1024

buffer after merge:
child: 1048576
parent: 1024

从值的最终结果看,的确是之前设置的1m,但是请求时却返回了414。

由于将两个server{}的位置颠倒后可以正常处理请求,所以在颠倒的情况下又测试了下最终值,输出如下:

buffer before merge:
child: 1048576
parent: 1024

buffer after merge:
child: 1048576
parent: 1024

buffer before merge:
child: 18446744073709551615
parent: 1024

buffer after merge:
child: 1024
parent: 1024

最终值的输出还是1m,但是这次就可以正常处理请求了。

看来nginx在实际处理请求的过程中,一定还有之前不知道的一套逻辑,用来判断client_header_buffer_size的最终值。

nginx处理请求时的相关代码如下:

    ngx_http_core_srv_conf_t   *cscf;
......
    /* the default server configuration for the address:port */
    cscf = addr_conf->default_server;
......
    if (c->buffer == NULL) {
        c->buffer = ngx_create_temp_buf(c->pool,
                                        cscf->client_header_buffer_size);

src/http/ngx_http_request.c

这里真相大白:

原来client_header_buffer_size的最终值,是nginx在解析conf后,default_server中经过merge的最终值。

而default_server在nginx中的定义为:在listen指令中定义:

The default_server parameter, if present, will cause the server to become the default server for the specified address:port pair. If none of the directives have the default_server parameter then the first server with the address:port pair will be the default server for this pair.

为了验证这一点,我修改vhost配置为:

server {
    listen 80;
    server_name db.job360.com;
    ......
}

server {
    listen 80 default;
    server_name  www.job360.com;

    large_client_header_buffers  1m;
    ......
}

重启nginx观察merge结果:

buffer before merge:
child: 18446744073709551615
parent: 1024

buffer after merge:
child: 1024
parent: 1024

buffer before merge:
child: 1048576
parent: 1024

buffer after merge:
child: 1048576
parent: 1024

merge结果没有不同。测试请求,这次nginx成功处理该请求,和预期的效果一致。

结束语

笔者又测试了large_client_header_buffers,得到和client_header_buffer_size同样的结果。可以得出结论:nginx在处理header时实际分配的buffer大小,是解析conf后,default_server中的最终值。

作者:ligang1109
链接:https://www.jianshu.com/p/20a687873bf0
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

nginx 设置client header 的大小与400错误

nginx默认的header长度上限是4k,如果超过了这个值

如果header头信息请求超过了,nginx会直接返回400错误
可以通过以下2个参数来调整nginx的header上限
client_header_buffer_size 16k;
large_client_header_buffers 4 16k;
下面讲讲这两个参数以及他们之间的关联关系:
对nginx处理header时的方法:

  1. 先处理请求的request_line,之后才是request_header。
  2. 这两者的buffer分配策略相同。
  3. 先根据client_header_buffer_size配置的值分配一个buffer,如果分配的buffer无法容纳 request_line/request_header,那么就会再次根据large_client_header_buffers配置的参数分配large_buffer,如果large_buffer还是无法容纳,那么就会返回414(处理request_line)/400(处理request_header)错误。
  1. 如果你的请求中的header都很大,那么应该使用client_header_buffer_size,这样能减少一次内存分配。
  2. 如果你的请求中只有少量请求header很大,那么应该使用large_client_header_buffers,因为这样就仅需在处理大header时才会分配更多的空间,从而减少无谓的内存空间浪费。

针对get请求,解决请求串过长的问题:

针对get请求,我们可以通过修改另外两个配置来解决请求串超长的问题:client_header_buffer_size语法:client_header_buffer_size size默认值:1k使用字段:http, server这个指令指定客户端请求的http头部缓冲区大小绝大多数情况下一个头部请求的大小不会大于1k不过如果有来自于wap客户端的较大的cookie它可能会大于1k,Nginx将分配给它一个更大的缓冲区,这个值可以在large_client_header_buffers里面设置。large_client_header_buffers语法:large_client_header_buffers number size默认值:large_client_header_buffers 4 4k/8k使用字段:http, server指令指定客户端请求的一些比较大的头文件到缓冲区的最大值,如果一个请求的URI大小超过这个值,服务器将返回一个”Request URI too large” (414),同样,如果一个请求的头部字段大于这个值,服务器将返回”Bad request” (400)。缓冲区根据需求的不同是分开的。默认一个缓冲区大小为操作系统中分页文件大小,通常是4k或8k,如果一个连接请求将状态转换为keep-alive,这个缓冲区将被释放。

那么有人就会觉得奇怪了,为什么修改http header的大小就能解决get请求串过长的问题呢,这就要从http协议的get请求说起了,其实GET提交,请求的数据会附在URL之后(就是把数据放置在HTTP协议头中)。

解决rpm conflicts with file from package的两个方法

1、卸载掉冲突的文件,安装新的文件。如果由于由于依赖关系导致要卸载很多软件,那可以优先考虑下一个方法。

yum y remove libstdc++4.4.711.el6.i686

注意,卸载的是软件,不是rpm包。可以使用rpm -qa|grep lisbstdc 查看已安装的包含lisbstadc的软件名

2、安装的时候增加–replacefiles参数,例如 rpm -ivh xxx.rpm –replacefiles

openssh 打rpm包问题

checking whether OpenSSL’s PRNG is internally seeded… yes
configure: error: PAM headers not found
error: Bad exit status from /var/tmp/rpm-tmp.45j1ZN (%build)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.45j1ZN (%build)

 

解决:

yum install –y pam-devel

 

其它相关链接:https://blog.csdn.net/qq_42609381/article/details/82855043

1、

错误:构建依赖失败:
openssl-devel < 1.1 被 openssh-7.8p1-1.el7.centos.x86_64 需要

解决方法:

注释掉BuildRequires: openssl-devel < 1.1 这一行,大多数都是第113行

2、

/root/rpmbuild/BUILDROOT/openssh-7.7p1-1.el7.centos.x86_64/usr/sbin/sshd -t -f /root/rpmbuild/BUILDROOT/openssh-7.7p1-1.el7.centos.x86_64/etc/ssh/sshd_config
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for ‘/etc/ssh/ssh_host_rsa_key’ are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
key_load_private: bad permissions
Could not load host key: /etc/ssh/ssh_host_rsa_key

解决方法:

chmod 600 /etc/ssh/ssh_host_rsa_key

2、

*** ERROR: No build ID note found in /root/rpmbuild/BUILDROOT/openssh-7.7p1-1.el7.centos.x86_64/usr/libexec/openssh/ssh-keysign
错误:/var/tmp/rpm-tmp.2YjX49 (%install) 退出状态不好

RPM 构建错误:
/var/tmp/rpm-tmp.2YjX49 (%install) 退出状态不好

解决方法:

在/usr/src/redhat/SPECS/openssh.spec 最后面加

%define __debug_install_post   \
%{_rpmconfigdir}/find-debuginfo.sh %{?_find_debuginfo_opts} “%{_builddir}/%{?buildsubdir}”\
%{nil}

3、

+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
错误:坏文件:/root/rpmbuild/SOURCES/x11-ssh-askpass-1.2.4.1.tar.gz: 没有那个文件或目录

RPM 构建错误:
坏文件:/root/rpmbuild/SOURCES/x11-ssh-askpass-1.2.4.1.tar.gz: 没有那个文件或目录

解决方法:

wget http://ftp.riken.jp/Linux/momonga/6/Everything/SOURCES/x11-ssh-askpass-1.2.4.1.tar.gz

cp x11-ssh-askpass-1.2.4.1.tar.gz  /root/rpmbuild/SOURCES/