最前端nginx.conf配置

user www-data;   # 在debian/ubuntu上，www-data是默认运行web服务的用户/组，一般在通过apt安装web服务程序时生成。搭建web服务的文件夹/文件一般要设置成www-data的。
worker_processes 8;     #可以开worker进程的数量，通常该值与cpu的核心数是一致的
pid /var/run/nginx.pid; #记录nginx进行的id，用于关闭或者重启nginx
 
worker_rlimit_nofile 262144;       #一个worker可以打开的文件数的上限
 
events {                           #处理连接的属性会定义在此
    worker_connections 40000;  #一个worker进程可以同时处理的连接数
    # multi_accept on;
}
 
http {
    ##
    # Basic Settings
    ##
 
    sendfile on;               #开启高效文件传输模式，sendfile指令指定nginx是否调用sendfile函数来输出文件
    tcp_nopush on;             #也就是说tcp_nopush = on 会设置调用tcp_cork方法，这个也是默认的，结果就是数据包不会马上传送出去，等到数据包最大时，一次性的传输出去，这样有助于解决网络堵塞
    tcp_nodelay on;            #即数据包立即发送出去
    keepalive_timeout 65;      #保持长链接的时间
    types_hash_max_size 2048;  #为了优化比如server_name等的查找，会把这些值保持在一个内存的哈希表里边
    # server_tokens off;
 
    server_names_hash_bucket_size 64;  #这个要和types_hash_max_size相互配合使用，要优化这一大小使得在cpu的cache里边命中机会变大
    # server_name_in_redirect off;
 
    include /etc/nginx/mime.types;        #请求文件的文件扩展名与http头部文件类型的映射关系
    default_type application/octet-stream;#二进制格式
 
    ##
    # Logging Settings
    ##
 
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
 
    ##
    # Gzip Settings
    ##
 
    gzip on;                #该指令用于开启或关闭gzip模块(on/off)
    gzip_disable "msie6";   #对IE5与IE6禁用gzip，因为这两个浏览器对于gzip支持不太好
 
    gzip_vary on            #控制在头部是否要插入Vary: Accept-Encoding,目的是为不同的压缩格式提供不同的缓存详见 here
    gzip_proxied any;       #对于所有的返回都使用压缩
    gzip_comp_level 6;      #设置压缩强度，1-9,9最大
    gzip_buffers 16 8k;     #这里指定用于gzip压缩的内存大小，16表示16个，8k表示每块缓存大小，通常为8k一个内存页的大小
    gzip_http_version 1.1;  #http1.1协议以上的请求都使用gzip
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;   #压缩文件类型
 
    ##
    # nginx-naxsi config
    ##
    # Uncomment it if you installed nginx-naxsi
    ##
 
    #include /etc/nginx/naxsi_core.rules;
 
    ##
    # nginx-passenger config
    ##
    # Uncomment it if you installed nginx-passenger
    ##
     
    #passenger_root /usr;
    #passenger_ruby /usr/bin/ruby;
 
    ##
    # Virtual Host Configs
    ##
 
    fastcgi_temp_path /tmp/ngx_fcgi_tmp;   #从fast-cgi来的文件首先被存到临时目录，随后再被存到cache_path中
    fastcgi_cache_path /tmp/ngx_fcgi_cache levels=2:2 keys_zone=fcgi:128m inactive=1d max_size=256m;#key_zone:在内存中存储key的缓存区内存的名字，inactive:失效时间.max_size最大使用的硬盘空
    fastcgi_cache_key "$scheme$request_method$host$request_uri";#fastcgi_cache_key:key是由哪些参数组成的，最终的文件名是md5这个key产生的$scheme:http or https

    upstream backend
    {
       server xxx.xxx.xxx.xxx;
    }
 
    upstream db
    {
       server xxx.xxx.xxx.xxx;
    }
 
    upstream dota2
    {
       server xxx.xxx.xxx.xxx; #DOTA
    }
 
    upstream users
    {
       server xxx.xxx.xxx.xxx;
    }
 
    upstream lushi <br>        {
 
       server xxx.xxx.xxx.xxx; #User
    }
 
    upstream dota2ob
    {
       server xxx.xxx.xxx.xxx; #User
    }
 
    upstream lol
    {
       server server xxx.xxx.xxx.xxx;#lol1
    }
    upstream gousu
        {
       server server xxx.xxx.xxx.xxx;
    }
 
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

keep-alive

　　　　当然，在nginx中，对于http1.0与http1.1也是支持长连接的。什么是长连接呢？我们知道，http请求是基于TCP协议之上的，那么，当客户端在发起请求前，需要先与服务端建立TCP连接，而每一次的TCP连接是需要三次握手来确定的，如果客户端与服务端之间网络差一点，这三次交互消费的时间会比较多，而且三次交互也会带来网络流量。当然，当连接断开后，也会有四次的交互，当然对用户体验来说就不重要了。而http请求是请求应答式的，如果我们能知道每个请求头与响应体的长度，那么我们是可以在一个连接上面执行多个请求的，这就是所谓的长连接，但前提条件是我们先得确定请求头与响应体的长度。对于请求来说，如果当前请求需要有body，如POST请求，那么nginx就需要客户端在请求头中指定content-length来表明body的大小，否则返回400错误。也就是说，请求体的长度是确定的，那么响应体的长度呢？先来看看http协议中关于响应body长度的确定：

对于http1.0协议来说，如果响应头中有content-length头，则以content-length的长度就可以知道body的长度了，客户端在接收body时，就可以依照这个长度来接收数据，接收完后，就表示这个请求完成了。而如果没有content-length头，则客户端会一直接收数据，直到服务端主动断开连接，才表示body接收完了。

而对于http1.1协议来说，如果响应头中的Transfer-encoding为chunked传输，则表示body是流式输出，body会被分成多个块，每块的开始会标识出当前块的长度，此时，body不需要通过长度来指定。如果是非chunked传输，而且有content-length，则按照content-length来接收数据。否则，如果是非chunked，并且没有content-length，则客户端接收数据，直到服务端主动断开连接。

从上面，我们可以看到，除了http1.0不带content-length以及http1.1非chunked不带content-length外，body的长度是可知的。此时，当服务端在输出完body之后，会可以考虑使用长连接。能否使用长连接，也是有条件限制的。如果客户端的请求头中的connection为close，则表示客户端需要关掉长连接，如果为keep-alive，则客户端需要打开长连接，如果客户端的请求中没有connection这个头，那么根据协议，如果是http1.0，则默认为close，如果是http1.1，则默认为keep-alive。如果结果为keepalive，那么，nginx在输出完响应体后，会设置当前连接的keepalive属性，然后等待客户端下一次请求。当然，nginx不可能一直等待下去，如果客户端一直不发数据过来，岂不是一直占用这个连接？所以当nginx设置了keepalive等待下一次的请求时，同时也会设置一个最大等待时间，这个时间是通过选项keepalive_timeout来配置的，如果配置为0，则表示关掉keepalive，此时，http版本无论是1.1还是1.0，客户端的connection不管是close还是keepalive，都会强制为close。

如果服务端最后的决定是keepalive打开，那么在响应的http头里面，也会包含有connection头域，其值是”Keep-Alive”，否则就是”Close”。如果connection值为close，那么在nginx响应完数据后，会主动关掉连接。所以，对于请求量比较大的nginx来说，关掉keepalive最后会产生比较多的time-wait状态的socket。一般来说，当客户端的一次访问，需要多次访问同一个server时，打开keepalive的优势非常大，比如图片服务器，通常一个网页会包含很多个图片。打开keepalive也会大量减少time-wait的数量。

2. server_names_hash_max_siz, server_names_hash_bucket_size

To quickly process static sets of data such as server names, map directive’s values, MIME types, names of request header strings, nginx uses hash tables. During the start and each re-configuration nginx selects the minimum possible sizes of hash tables such that the bucket size that stores keys with identical hash values does not exceed the configured parameter (hash bucket size). The size of a table is expressed in buckets. The adjustment is continued until the table size exceeds the hash max size parameter. Most hashes have the corresponding directives that allow changing these parameters, for example, for the server names hash they are server_names_hash_max_size andserver_names_hash_bucket_size.

The hash bucket size parameter is aligned to the size that is a multiple of the processor’s cache line size. This speeds up key search in a hash on modern processors by reducing the number of memory accesses. If hash bucket size is equal to one processor’s cache line size then the number of memory accesses during the key search will be two in the worst case — first to compute the bucket address, and second during the key search inside the bucket. Therefore, if nginx emits the message requesting to increase either hash max size or hash bucket size then the first parameter should first be increased.

3. gzip_proxied

Sets the minimum HTTP version of a request required to compress a response.

Syntax:	`gzip_proxied off \| expired \| no-cache \| no-store \| private \| no_last_modified \| no_etag\| auth \| any ...;`
Default:	gzip_proxied off;
Context:	`http`, `server`, `location`

Enables or disables gzipping of responses for proxied requests depending on the request and response. The fact that the request is proxied is determined by the presence of the “Via” request header field. The directive accepts multiple parameters:

off: disables compression for all proxied requests, ignoring other parameters;
expired: enables compression if a response header includes the “Expires” field with a value that disables caching;
no-cache: enables compression if a response header includes the “Cache-Control” field with the “no-cache” parameter;
no-store: enables compression if a response header includes the “Cache-Control” field with the “no-store” parameter;
private: enables compression if a response header includes the “Cache-Control” field with the “private” parameter;
no_last_modified: enables compression if a response header does not include the “Last-Modified” field;
no_etag: enables compression if a response header does not include the “ETag” field;
auth: enables compression if a request header includes the “Authorization” field;
any: enables compression for all proxied requests.