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协议头中)。

Nginx Header,实现对HTTP/S请求、响应进行添加、修改、删除等操作

删除Header

来源库:ngx_http_fastcgi_module、ngx_http_proxy_module

fastcgi_hide_header ‘Key’;

Syntax: fastcgi_hide_header field;
Default:
Context: httpserverlocation

proxy_hide_header ‘Key’;

Syntax: proxy_hide_header field;
Default:
Context: httpserverlocation

例如:反向代理和fastcgi区分不同的场景使用。

fastcgi_hide_header X-Powered-By;

proxy_hide_header X-Powered-By;

 

修改Header

通过内置的操作,修改header分为两步,先将其删除再增加。

例如:

fastcgi_hide_header Content-Type;

proxy_hide_header Content-Type;

add_header ‘Content-Type’ ‘text/css’;

 

添加请求Header

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

fastcgi_param  ‘HTTP-X-Forwarded-For’ $remote_addr;

删除请求Header

proxy_set_header X-Forwarded-For ”;

fastcgi_param  ‘HTTP-X-Forwarded-For’ ”;

 

通过第三方模块

headers-more-nginx-module

Github:https://github.com/openresty/headers-more-nginx-module

添加/设置Header

syntax: more_set_headers [-t <content-type list>]... [-s <status-code list>]... <new-header>...

default: no

context: http, server, location, location if

phase: output-header-filter

more_set_headers “Server: yunjiasu-nginx”;

清除Header

syntax: more_clear_headers [-t <content-type list>]... [-s <status-code list>]... <new-header>...

default: no

context: http, server, location, location if

phase: output-header-filter

more_clear_headers -s 404 -t ‘text/plain’ Foo Baz;

more_clear_headers ‘X-Hidden-*’;

 

添加请求Header

more_set_input_headers

syntax: more_set_input_headers [-r] [-t <content-type list>]... <new-header>...

default: no

context: http, server, location, location if

phase: rewrite tail

删除请求Header

more_clear_input_headers

syntax: more_clear_input_headers [-t <content-type list>]... <new-header>...

default: no

context: http, server, location, location if

phase: rewrite tail

例子:

more_clear_input_headers -t ‘text/plain’ Foo Baz;

more_clear_input_headers “Foo” “Baz”;
more_clear_input_headers ‘X-Hidden-*’;