Nginx基本优化一

时间 2019-11-11

标签 nginx 基本优化栏目 Nginx 繁體版

原文原文链接

NGINX基本优化javascript

更改nginx服务默认用户
优化nginx进程对应配置
优化绑定不一样的nginx进程到不一样cpu，
nginx事件处理模型优化，采用epoll模型
调整优化单个worker进程并发链接数
配置nginx worker进程最大打开文件数
优化服务器域名的hash表大小
开启高效文件传输模式sendfile，设置tcp_nopush参数
优化nginx链接参数调整链接超时时间
上传文件大小（http Request body size）的限制
fastcgi相关参数调优，fastcgi buffer/cache
配置nginx gzip压缩实现性能优化
配置nginx expires缓存实现性能优化
访问日志轮询，不记录某些日志，代理不开访问日志
Nginx站点目录及文件URL访问控制
限制网站来源IP访问php

1、隐藏版本号优化css

http://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
Syntax: server_tokens on | off | string;
Default: server_tokens on;
Context: http, server, location
Enables or disables emitting nginx version in error messages and in the “Server” response header field.

# curl -I 192.168.0.82
HTTP/1.1 200 OK
Server: nginx/1.8.1
Date: Sun, 10 Jul 2016 08:30:40 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Sun, 15 May 2016 23:28:20 GMT
Connection: keep-alive
ETag: "57390614-264"
Accept-Ranges: bytes

# vi /usr/local/nginx/conf/nginx.conf
在http标签内加入参数server_tokens off;
# curl -I 192.168.0.82
HTTP/1.1 200 OK
Server: nginx

二、隐藏软件名称html

# vi /home/tools/nginx-1.8.1/src/core/nginx.h
13 #define NGINX_VERSION      "1.8.1"   　　　　　　　　　　 #显示的版本号，修改成想要显示的版本号
14 #define NGINX_VER          "nginx/" NGINX_VERSION  　　#将nginx修改成想要的软件名称，如GWS
22 #define NGINX_VAR          "NGINX" 　　　　　　　　　　　　#显示的软件名称如如GWS(GTMSWEB SERVER)
23 #define NGX_OLDPID_EXT     ".oldbin"

# vi /home/tools/nginx-1.8.1/src/http/ngx_http_header_filter_module.c
49 static char ngx_http_server_string[] = "Server: nginx" CRLF;    改==> "Server: GTMSWS" CRLF;

# vi /home/tools/nginx-1.8.1/src/http/ngx_http_special_response.c
     21 static u_char ngx_http_error_full_tail[] =
     22 "<hr><center>" NGINX_VER "</center>" CRLF
     23 "</body>" CRLF
     24 "</html>" CRLF
     25 ;
     26 
     27 
     28 static u_char ngx_http_error_tail[] =
     29 "<hr><center>nginx</center>" CRLF   ==》修改成/GTMS WEB SERVER /
     30 "</body>" CRLF
     31 "</html>" CRLF
[root@test83 core]# /usr/local/nginx/sbin/nginx -V  取到编译参数后从新编译安装
nginx version: nginx/1.8.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) 
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx-1.8.1 --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module


三、更改nginx服务的默认用户

编译时未指定user和group，默认nobody
编译时指定，默认即为nginx用户
root@test83 conf]# ps -ef | grep nginx | grep -v grep 
root       1873      1  0 16:45 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx      1874   1873  0 16:45 ?        00:00:00 nginx: worker process    
默认主进程是root，在高标准环境通常设置为普通用户，防止提权。也能使普通用户对服务进行重启等管理

4、优化nginx进程对应配置（worker进程数）前端

# vi /usr/local/nginx/conf/nginx.conf
worker_processes  1;    #通常cpu核数，后续继续调整，最高通常为2倍 
查看cpu个数信息   top按1 能够看到核数
# grep processor /proc/cpuinfo | wc -l  或者# grep processor -c /proc/cpuinfo    （查看核数）
1    ==>1颗单核
# grep "physical id" /proc/cpuinfo | sort|uniq|wc -l    (cpu个数)
1

5、优化绑定不一样的nginx进程到不一样cpu，使平均运行（ngx_core_module）,实测差很少java

默认状况nginx的多个进程有可能跑在某一个或某一核的CPU上,致使nginx进程使用的硬件的资源不均,
本节优化是尽量地分配不一样的nginx进程给不一样的CPU处理,达到充分有效利用硬件的多CPU多核资源的目的优化nginx进程对应不一样的CPU配置
在优化不一样的nginx进程对应不一样CPU配置时,四核CPU服务器的参考配置参考以下
worker_processes    4;
worker_cpu_affinity 0001 0010 0100 10000;
#worker_cpu_affinity就是配置nginx进程CPU亲和力的参数,即把不一样的进程分配给不一样的CPU处理,0001等掩码,分别表明CPU核心,因为worker_processes进程为4,所以,上述配置会把每一个进程分配一核CPU处理,默认不会绑定,参数配置为main段

# man taskset   分配cpu功能
NAME
       taskset - retrieve or set a process?[7m<80><99>s CPU affinity
SYNOPSIS
       taskset [options] mask command [arg]...
       taskset [options] -p [mask] pid
举例   task -c 1,2,3 /etc/init.d/mysql start  (多实例能够指定）

6、nginx事件处理模型优化node

nginx的链接处理机制在于不一样的操做系统会采用不一样的I/O模型,在Linux下,nginx使用epoll的I/O多路复用模型,
在freebsd中使用kqueue的I/O多路复用模型,在solaris中使用/dev/poll方式的I/O多路复用模型,在windows使用的是icop,等等.
要根据系统类型选择不一样的事件处理模型,可供使用的选择有use [kqueue|rtsig|epoll|dev/poll/select|poll];
本次用的是centos6.6,所以咱们将nginx的事件处理模型调整为epoll模型
events {               加到main区块event标签，通常nginx已经自动用epoll模式
    worker_connections  1024;
    use epoll;
}

7、调整优化单个worker进程并发链接数及worker进程最大打开文件数python

worker_connections是个时间模块指令，用于定义nginx每一个进程的最大并发链接数，默认1024，最大客户端链接数等于worker_processes* worker_connections。
进程的最大链接数也受linux系统进程的最大打开文件数限制，在执行“ulimit -HSn 65535”或配置相应文件后，此设置才生效
events {
    worker_connections 1024;
}
说明：这个链接数包括了全部链接(一个用户请求是两个连接)例如：代理服务器的链接、客户端的链接等，
实际的并发链接数受此参数控制外，还和最大打开文件数worker_rlimit_nofile有关

配置nginx进程最大打开文件数
worker_rlimit_nofile 65535;
==>可设置为系统优化后的ulimit -HSn的结果
Syntax: worker_rlimit_nofile number;
Default: —

8、优化服务器域名的hash表大小mysql

确切名字和通配符名字存储在哈希表中。哈希表和监听端口关联，每一个端口都最多关联三张表:确切的名字的哈希表，以星号（*）起始的通配符名字的哈希表和以星号结束的通配符名字的哈希表。
哈希表的尺寸在配置阶段进行了优化，能够以最小的CPU缓存命中失败来找到名字。nginx首先搜索切确名字的的哈希表，若是没有找到，则搜索以星号（*）其实的通配符名字的哈希表，若是仍是没有找到，继续搜索以星号结束的通配符名字的哈希表。
由于名字是按照域名的节点来搜索的。因此搜索通配符名字的哈希表比搜索确切名字的哈希表慢。注意:nginx.org存储在通配符名字的哈希表中，而不在确切名字的哈希表中。正则表达式是一个一个串行的测试，因此是最慢的，并且不可扩展。
因为上述缘由，咱们通常尽量的使用确切的名字。好比若是使用nginx.org和www.nignx.org来访问服务器是最频繁的，那么咱们明确的定义出来对访问搜索域名的速度效率来讲更有效:

若是定义了大量名字，或者定义了很是长的名字，那就须要在php配置模块中调整server_names_hash_max_size    默认512kb，通常是cpu L1的4-5倍，
存放server name的最大哈希表大小server_names_hash_bucket_size  Sets the bucket size for the server names hash tables.
server_names_hash_bucket_size的默认值多是32，或者是64，或者是其余值，取决于CPU的缓存行的长度。若是这个值是32，那么定义“too.long.server.name.nginx.org”做为虚拟机主机名就会失败，显示以下错误信息：
 could not build the server_names_hash,
 you should increase server_names_hash_bucket_size;32
出现这种状况，那就须要设置值扩大一倍：
 http{
  server_names_hash_bucket_size 64;
 }

9 、开启高效文件传输模式sendfilelinux

sendfile参数用于开启文件的高效传输模式。同时将tcp_nopush和tcp_nodely两个指令设置为on，可防止网络及磁盘IO阻塞，提高nginx工做效率
http://nginx.org/en/docs/http/ngx_http_core_module.html#sendfile
Syntax: sendfile on | off;
Default: sendfile off;
Context: http, server, location, if in location
参数做用：激活或者禁用sendfile()功能。sendfile()做用是用于两个文件描述符之间的数据拷贝函数，这个拷贝函数在内核中的，被称为“零拷贝”，
sendfile()比read和write函数要高效不少，由于read和write函数要把数据拷贝到应用层进行操做。相关控制参数还有sendfile_max_chunk

设置tcp_nopush参数
tcp_nopush on
http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nopush
Syntax: tcp_nopush on | off;
Default: tcp_nopush off;
Context: http, server, location
参数做用：激活或者禁用linux上的TCP_CORK scoket选项，此选项仅仅当开启sendfile才生效，
激活tcp_nopush参数能够容许把http response header和文件的开始放在一个文件里发布，积极的做用是减小网络报文的数量

10、优化nginx链接参数调整链接超时时间

先来个比喻，饭店请了服务员招待顾客，可是饭店不景气，此时为了节约开支，须要解雇服务员
这里的服务员就至关于nginx服务器创建的链接，当服务器创建的链接没有接收处理请求时，在指定时间内就让它超时自动退出，
还有当nginx和fastcgi服务创建链接请求PHP时，由于有些缘由（负载高，中止响应）fastcgi服务没法给nginx返回数据，
此时能够经过配置nginx服务参数，使其不会等死，由于前面用户还等着它返回数据。例如，可设置为若是请求fastcgi，10秒内不能返回数据，
那么nginx就中断本次请求，向用户汇报取不到数据的错误

链接超时的做用：简单来讲是一种自我管理，自我保护的重要机制
1、设置将无用的链接尽快超时，能够保护服务器的系统资源（cpu、内存、磁盘）
2、当链接不少时。及时断掉那些已经创建好的可是长时间不作事的链接，减小其占用服务器资源，由于服务器维护链接也是消耗资源的
3、有时黑客或恶意用户攻击网站，就会不断地和服务器创建多个链接，消耗链接数，可是啥也不干，只是持续创建链接，就会大量消耗服务器资源，此时就应该及时断掉这些恶意占用资源的链接
4、lnmp环境中，若是用户请求了动态服务，则nginx就会创建链接请求fastcgi服务以及mysql服务，此时这个nginx链接就要设定一个超时时间，
　　在用户容忍的时间内返回数据，或者再多等一会后端服务返回数据，具体策略按具体业务分析，固然，后端的fastcgi服务以及mysql服务也有对链接超时的控制

链接超时带来的问题 1、服务器创建新链接也是要消耗资源的，所以，超时设置的过短，就会致使服务器瞬间没法响应用户的请求，致使体验降低
2、企业生产有些PHP程序站点但愿设置短链接，由于PHP程序创建链接消耗的资源和时间要少。
　　而JAVA程序站点通常创建设置长链接，由于java程序创建的链接消耗的资源和时间更多，这是语言运行的机制决定的
nginx链接超时的参数设置 1、keepalive_timeout 60;  
设置客户端链接保持会话的超时时间为60秒，超事后，服务器会关闭该链接，此数值为参考值
http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests
Syntax: keepalive_timeout timeout [header_timeout];
Default: keepalive_timeout 75s;
Context: http, server, location


2、tcp_nodelay on;
激活tcp_nodelay功能，提升IO性能
http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nodelay
Syntax: tcp_nodelay on | off;
Default: tcp_nodelay on;
Context: http, server, location 
参数做用：默认状况下数据发送时，内核并不会立刻发送，可能会等待更多的字节组成一个数据包，这样能够提升IO性能，可是，在每次发送不多字节的业务场景，
使用此功能，等待时间会比较长
生效条件：激活或禁用tcp_nodelay选项，当一个链接进入到keep_alive状态时生效


3、client_header_timeout 15s;
设置读取客户端请求头部数据的超时时间。若是超过这个时间客户端还没发送完整的header数据，服务端将返回“Request time out （408）”错误。经验参考值15秒，指定一个超时时间防止客户端利用http协议进行攻击
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeout
Syntax: client_header_timeout time;
Default: client_header_timeout 60s;
Context: http, server


4、client_body_timeout 15s;
设置读取客户端请求主体的超时时间，默认60
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout
Syntax: client_body_timeout time;
Default: client_body_timeout 60s;
Context: http, server, location 
参数做用：读取客户端请求主题的超时时间，这个超时仅仅为两次成功的读取操做之间的一个超时，非请求整个主题数据的时间，如在这个超时时间内，客户端没有发送任何数据，nginx将返回“Request time out （408）”错误


5、send_timeout 25s;
http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeout
Syntax: send_timeout time;
Default: send_timeout 60s;
Context: http, server, location 
参数做用：设置服务器端传送http响应信息到客户端的超时时间，这个超时时间仅仅为两次成功握手后的一个超时，非请求整个数据的超时时间，在这个超时时间内，客户端没有接受任何数据，链接将被关闭


client_max_body_size

十一、nginx fastcgi相关参数调优（配合PHP引擎动态服务）

fastcgi_connect_timeout
Syntax: 	fastcgi_connect_timeout time;
Default: 	fastcgi_connect_timeout 60s;
Context: 	http, server, location
Defines a timeout for establishing a connection with a FastCGI server. It should be noted that this timeout cannot usually exceed 75 seconds.
表示nginx服务器和后端fastcgi服务器服务器链接的超时时间默认60s，这个参数值一般不要超过75s，由于创建的链接越多消耗的资源就越多

fastcgi_send_timeout
Syntax: 	fastcgi_send_timeout time;
Default: 	fastcgi_send_timeout 60s;
Context: 	http, server, location
Sets a timeout for transmitting a request to the FastCGI server. The timeout is set only between two successive write operations, not for the transmission of the whole request.
 If the FastCGI server does not receive anything within this time, the connection is closed.
设置nginx容许fastcgi服务器端返回数据的超时时间，即在规定时间以内后端服务器必须传完全部数据，不然，nginx将断开这个链接，默认为60s

fastcgi_read_timeout
Syntax: 	fastcgi_read_timeout time;
Default: 	fastcgi_read_timeout 60s;
Context: 	http, server, location
Defines a timeout for reading a response from the FastCGI server. The timeout is set only between two successive read operations, not for the transmission of the whole response.
 If the FastCGI server does not transmit anything within this time, the connection is closed.
设置nginx从fastcgi服务器端读取响应信息的超时时间，表示链接创建成功后，nginx等待后端服务器的响应时间，是nginx已经进入后端的排队之中等待处理的时间

fastcgi_buffer_size
Syntax: 	fastcgi_buffer_size size;
Default: 	fastcgi_buffer_size 4k|8k;
Context: 	http, server, location
Sets the size of the buffer used for reading the first part of the response received from the FastCGI server. This part usually contains a small response header. 
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform. It can be made smaller, however.
这个是nginx fastcgi的缓冲区大小参数，设定用来读取从fastcgi服务器收到的第一部分响应信息的缓冲区大小，这里的第一部分一般会包含一个小的响应头部，默认状况，这个参数的大小是由fastcgi_buffers指定的一个缓冲区大小。


fastcgi_buffers
Syntax: 	fastcgi_buffers number size;
Default: 	fastcgi_buffers 8 4k|8k;
Context: 	http, server, location
Sets the number and size of the buffers used for reading a response from the FastCGI server, for a single connection. 
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform.  
指定本地须要用多少和多大的缓冲区来缓冲FastCGI的应答请求。若是一个PHP脚本所产生的页面大小为256KB，那么会为其分配4个64KB的缓冲区来缓存；
若是页面大小大于256KB，那么大于256KB的部分会缓存到fastcgi_temp指定的路径中，可是这并非好方法，由于内存中的数据处理速度要快于硬盘。
通常这个值应该为站点中PHP脚本所产生的页面大小的中间值，若是站点大部分脚本所产生的页面大小为256KB，那么能够把这个值设置为“16 16k”、“4 64k”等。

fastcgi_busy_buffers_size
Syntax: 	fastcgi_busy_buffers_size size;
Default: 	fastcgi_busy_buffers_size 8k|16k;
Context: 	http, server, location
When buffering of responses from the FastCGI server is enabled, limits the total size of buffers that can be busy sending a response to the client while the response is not yet fully read. 
In the meantime, the rest of the buffers can be used for reading the response and, if needed, buffering part of the response to a temporary file. 
By default, size is limited by the size of two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives.

fastcgi_temp_file_write_size
Syntax: 	fastcgi_temp_file_write_size size;
Default: 	fastcgi_temp_file_write_size 8k|16k;
Context: 	http, server, location
Limits the size of data written to a temporary file at a time, when buffering of responses from the FastCGI server to temporary files is enabled. 
By default, size is limited by two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives. The maximum size of a temporary file is set by the fastcgi_max_temp_file_size directive.

fastcgi_temp_path
Syntax: 	fastcgi_temp_path path [level1 [level2 [level3]]];
Default: 	fastcgi_temp_path fastcgi_temp;
Context: 	http, server, location
Defines a directory for storing temporary files with data received from FastCGI servers. Up to three-level subdirectory hierarchy can be used underneath the specified directory. 
For example, in the following configuration  fastcgi_temp_path /spool/nginx/fastcgi_temp 1 2;
a temporary file might look like this:
    /spool/nginx/fastcgi_temp/7/45/00000123457
See also the use_temp_path parameter of the fastcgi_cache_path directive.

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
fastcgi_temp_path /usr/local/nginx/fastcgi_tmp 1 2;

fastcgi_cache(buffer一份给用户，一份写到缓存)
表示开启FastCGI缓存并为其指定一个名称。开启缓存很是有用，能够有效下降CPU的负载，而且防止502错误的发生，可是开启缓存也会引发不少问题，要视具体状况而定。
为FastCGI缓存指定一个文件路径、目录结构等级、关键字区域存储时间和非活动删除时间
Syntax: 	fastcgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] 
[manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] 
[loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];
Default: 	—
Context: 	http

12、配置nginx gzip压缩实现性能优化

nginx gzip压缩功能介绍
Syntax: 	gzip on | off;
Default: 	gzip off;
Context: 	http, server, location, if in location

nginx gzip压缩模块提供了对文件内容压缩的功能,nginx服务器将用户请求的内容在发送给用户客户端以前会根据一些具体的策略实施压缩,以节约网站出口带宽,同时加快了数据数据传输效率,提高了用户访问体验
nginx gzip压缩的优势
1、提高网站用户体验
因为发给用户的内容小了，因此用户访问单位大小的页面就快了，用户体验提高了，网站口碑就行了。
2、节约网站带宽成本
因为数据是压缩传输的，所以，此举节省了网站的带宽流量成本，不过压缩时会稍微消耗些CPU资源，这个通常能够忽略
此功能既让用户舒服了，公司也少花钱了，一举多得，对于全部web服务器来讲，这是个很是重要的功能

须要(大于1k的纯文本)和不须要压缩的对象
1、    纯文本内容压缩比很高，所以纯文本的内容最好要压缩，例如html、js、css、xml、shtml等各式的文件
2、    被压缩的纯文本文件必须大于1kb，因为压缩算法的特殊缘由，极小的文件压缩可能反而变大
3、    图片、视频（流媒体）等文件尽可能不要压缩，由于这些文件大多都是通过压缩的，若是再压缩极可能不会减少或减少不少，或者有可能增大，而在压缩时还会消耗大量的CPU、内存资源
完整的配置以下
gzip on;
gzip_min_length  1k;      # 1k以上进行压缩
gzip_buffers  4  32k;       # 4个32k的buffer
gzip_http_version 1.1;         #压缩版本
gzip_comp_level 9;          #压缩级别9最大，传输速度最快，但处理最慢，也比较消耗cpu资源。
gzip_types  text/css/  test/html  text/xml  application/javascript;   #cat mime.types
gzip_vary on;   #vary header支持。该选项可让前端的缓存服务器缓存通过gzip压缩的页面，例如用squid缓存通过nginx压缩的数据

使用firefox 安装yslow firebug检验

配置nginx expires缓存实现性能优化

nginx expires功能介绍
简单的说，nginx expires功能就是为用户访问的网站内容设定一个过时时间，当用户第一次访问这些内容的时，会把这些内容存储在用户浏览器本地，
这样用户第二次之后继续访问网站，浏览器会检查加载已经缓存在用户浏览器本地的内容，就不会去服务器下载了，直到缓存的内容过时或被清除为止。
深刻一点理解，expires功能就是容许经过nginx配置文件控制HTTP的“Expires”和“Cache-Control”响应头部内容，告诉客户端浏览器是否缓存以及缓存多久访问内容，
这个expire模块控制nginx服务器应答时的Expires头内容和Cache-Control头max-age指令。缓存的有效期能够设置为相对于源文件的最后修改时刻或者客户端的访问时刻。
这些HTTP头向客户端代表了内容的有效性和持久性，若是客户端本地有内容缓存，则内容能够从缓存（除非已通过期）而不是从服务器读取，而后客户端会检查缓存中的副本，看看是否过时或者失效，以决定是否从新从服务器得到内容更新

nginx expires做用介绍
在网站开发和运营中，对于视频、图片、CSS、JS等网站元素的更改机会较少，特别是图片，这时能够将图片设置在客户浏览器本地缓存365天或3650天，而将CSS、JS、html等代码缓存10-30天，这样用户第一次打开页面后，会在本地的浏览器按照过时日期缓存相应的上述内容，下次用户再打开相似的页面，重复的元素就无需下载了，从而加快了用户访问速度，因为用户访问请求和数据减小了，所以节省了服务期端大量的带宽。此功能同apache的expires。

nginx expires功能优势
1、expires 能够下降网站的带宽，节约成本。
2、加快用户访问网站的速度，提高了用户访问体验。
3、服务器访问量下降了，服务器压力就减轻了，服务器成本也会下降，甚至能够节约人力成本。
对于几乎全部web服务来讲，这都是很是重要的功能之一，Apache服务也有此功能
Server {
    listen  80;
    root    html/www;
    server_name www.gmts.org;
    location / {
        index index.html index.htm;}
    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
        {expires      10y;}
    location ~ .*\.(js|css)$
        {expires      30d;}
        }
    location ~ ^/(images|javascript|js|css|flash|media|static)/ {
    expires 360d
    }     #也能够针对目录

root@test80 ~]# curl  -I http://d1.leju.com/ia/2016/10/14/f580042c2895a2img.gif
HTTP/1.1 200 OK
Date: Sat, 22 Oct 2016 17:28:08 GMT
Content-Type: image/gif
Content-Length: 15073
Connection: keep-alive
Expires: Thu, 12 Jan 2017 02:37:09 GMT     缓存过时时间
Server: Apache
Last-Modified: Fri, 14 Oct 2016 02:28:18 GMT
Accept-Ranges: bytes
Cache-Control: max-age=7776000    缓存的总时间(毫秒）
X-Ser: BC18_dx-hebei-shijiazhuang-1-cache-1, BC26_dx-jiangsu-xuzhou-1-cache-3

nginx expire 功能的缺点及解决方法
几乎全部事物都有两面性，没有十全十美的人和事。nginx expire也会给企业带来一些困惑
当网站被缓存的页面或数据更新了，此时用户看到的可能仍是旧的已经缓存的内容，这样会影响用户体验
解决办法有以下几个：
1、对于常常须要变更的图片等文件，能够缩短对象缓存时间，例如谷歌和百度的图片常常根据不一样的日期换成一些节日的图，因此这里能够将这个图片设置为缓存期1天
2、当网站改变或更新内容时，能够在服务器将缓存的对象更名（网站代码程序）。
a、对于网站的图片、附件，通常不会被用户直接修改，用户层面上修改的图片其实是从新传到服务器，虽然内容同样可是是个新的图片名了
b、网站改版升级会修改JS、CSS元素，若改版的时候对这些元素改了名，会使得前端的CDN以及用户端须要的从新缓存内容


企业网站缓存日期曾经的案例参考
不一样的企业的业务和网站访问量不一样，网站的缓存期时间设置也是不一样的，好比，以下企业所用的缓存日期就是不同的
51cto  1周   sina 15天    京东 25年    淘宝 10年

企业网站有可能不但愿被缓存的内容
1、广告图片，用于广告服务，都缓存了就很差控制展现了
2、网站流量统计工具（js代码），都缓存了流量统计就不许了
3、更新频繁的文件（goole的logo），若是这个按天，缓存效果仍是显著的

nginx日志相关优化与安全

nginx没有相似Apache的cronolog日志分割处理的功能，可是，能够经过nginxNginx的信号控制功能或者reload重载，而后利用脚原本实现日志的自动切割。
1、配置日志切割脚本: 
mkdir -p /server/scripts/  
cd /server/scripts/
cat cut_nginx_log.sh
cd /application/nginx/logs && \
/bin/mv www_access.log www_access_$(date +%F -d -1day).log
/application/nginx/sbin/nginx -s reload
提示：实际上脚本的功能很简单，就是改名日志，而后从新加载nginx，从新生成文件记录日志

2、将这段脚本保存后加入到Linux的crontab守护进程，让此脚本在天天凌晨0点执行，就能够实现日志的天天分割功能了，操做结果以下：
crontab -l |tail -2
#cut nginx log on 00:00 everynight
00  00 * * * /bin/sh  /server/scripts/cut_nginx_log.sh >/dev/null 2>&1


不记录不须要的访问日志
在实际工做中，对于负载均衡器健康检查节点或某些特定文件（图片，js，css）的日志，通常不须要记录下来，由于在统计PV时时按照页面计算的。并且日志写入太频繁会大量消耗磁盘I/O，下降服务的性能
具体配置方法为：
location ~ .*\.(js|jpg|jpeg|JPEG|css|bmp|gif|GIF)$ {
access_log off;
}
访问日志的权限设置
假如日志目录为/app/logs，则受权方法为：
chown –R root.root /app/logs
chmod –R 700 /app/logs
#不须要在日志目录上给nginx用户读或者写许可，不必给大权限，nginx有master进程root用户，控制能够写入日志

Nginx站点目录及文件URL访问控制

根据扩展名限制程序和文件访问
Web2.0时代，绝大多数网站都是以用户为中心，例如：bbs、blog、sns产品，这几个产品有个共同的特色，就是不但容许用户发布内容到服务器，还容许用户发图片甚至附件到服务器上，因为为用户开了上传功能，所以给服务器带来了很大的安全风险，虽然不少程序在上传前会作必定的控制。例如：文件的大小、类型等，可是，一不当心就会被黑客钻了空子，上传了木马程序
安全的权限： 
1、全部站点目录的用户和组都应该为root，
2、全部目录默认权限是755；
3、全部文件默认权限为644；
注意：网站服务的用户不能用root，
以上权限的设置能够作到防止黑客上传木马，以及修改站点文件，可是，合理的用户上传内容也被拒之门外了，那么如何解决可让合法的用户上传文件又不至于被黑客利用攻击呢？
这就是对业务进行分离，在比较好的网站业务架构中，应该把资源文件，包括用户上传的图片，附件等的服务和程序
大多数公司的不安全的受权以下：
1）chmod -R 777 /sitedir（最不安全）
2) chmod -R nginx.nginx /sitedir（最不安全）
若是大多数公司受权通常的受权，会给网站带来最大的安全隐患
下面是利用Nginx配置禁止访问上传资源目录下的PHP、shell、perl、python程序文件，这样用户即便上传了木马文件也无法去执行，从而增强了网站的安全
范例1: 配置nginx限制指定目录下的指定程序被解析，须要写在PHP配置的前面
location ~ ^images/.*\.(php|php5|.sh|.pl|.py)$
{    deny all;  }

location ~ ^/static/.*\.(php|php5|.sh|.pl|.py)$
{    deny all;  }

location ~* ^/data/(attachment|avatar)/.*\.(php|php5)$
{    deny all;  }
范例2：Nginx下配置禁止访问*.txt文件，实际配置信息以下：
location ~* \.(txt|doc)$
if (-f $request_filename) {
root /data/www/www;
#rewrite …… 能够重定向到某个URL
break;
}
location ~* \.(txt|doc)$ {
    root /data/www/www;
    deny all;
    }
配置禁止访问指定的单个或多个目录。单目录
location ~ ^/(static)/ {
    deny all;
    }
location ~ ^/static {
    deny all;
    }
多个目录：
location ~ ^ /(static|js){
     deny all;
}

范例2：禁止访问目录并返回指定的http状态码
server {
    listen        80;
    server_name     www.gmts.org
    root        /data0/www/www;
    index        index.html index.htm;
    access_log  /app/logs/www_access.log  commonlog;
    location /admin/ { return 404; }
    location /templates/ { return 403;}
    }

限制网站来源IP访问

下面介绍如何使用ngx_http_access_module限制网站来源ip访问
案例环境：phpmyadmin数据库的web客户端，内部开发人员用的。
范例1：禁止某目录让外界访问，可是容许某IP访问该目录，且支持PHP解析
location ~ ^/gtms/ {
    allow 202.111.12.211;
    deny all;
}

方法1：使用if来控制
if  ($remote_addr = 10.0.0.7 ) {
return 403;
    }
if  ($remote_addr = 218.247.17.130 ) {
    set $allow_access_root  `true`;
}
注意事项：经过防火墙 效率高
1、deny 必定要加一个ip，不然403，不往下执行了，如在同一域名下，会形成死循环
2、ip段 127.0.0.    10.10.10.0/16
3、以deny all;结尾，表示除了上面allow的，其余都禁止，如
location / {
deny 192.168.1.1;
allow 127.0.0.0/24
allow .......
deny all;
}

Nginx如何防止用户IP访问网站(恶意域名解析,也至关因而直接IP访问企业网站)
方法一、让使用IP访问网站的，或者访问经恶意解析域名，收到501错误
说明：直接报501错误，从用户体验上不是很好
上述代码放到第一个虚拟主机前面
方法2：经过301跳转到主页
server {
listen 80 default_server;
server_name _;
return 501;
#经过ip访问返回501 Not Implemented
#nginx
#rewrite ^(.*) http://blog.gtms.org/$1 permanent
}
方法3：发现某域名恶意解析到公司的服务器IP，在server标签里添加如下代码便可，如有多个server要多处添加。
if ($host  !~ www/.gtms/.com$) {
    rewrite ^(.*) http://www.gtms.com/$1 permanent;
}