静态资源WEB服务
Nginx作为静态资源WEB服务 , Nginx作为静态资源的HTTP WebServer它可以接收客户端类似于"jpg、html、css、js"这种静态资源的请求 , 然后直接通过静态资源的存储得到这些文件返回给客户端 , 这种方式是一种典型的非常高效的传输的模式 , 这种场景常常会用在我们的静态资源处理、请求以及动静分离场景下的应用。
请求一个网站的时候简单可以分为2类请求：静态请求、动态请求；
对于服务端接收静态请求和动态请求的处理是不一样的，动态请求是需要经过服务端的解析器进行一些比较复杂的逻辑运算然对然后对应的数据进行封装再返回给用户，这种数据是动态生成的叫做动态请求，对于无需服务端进行动态生成的，直接从文件系统可以找到返回给用户的这种叫做静态请求，这种文件也就叫做静态资源的文件。
静态资源服务场景-CDN
CDN是“内容分发网络”，这个“网络”不是我们常说的电信联通等网络，他是一个内容型的逻辑分发网络，Nginx在CDN这项技术里面扮演着一个非常重要的角色,Nginx作为每一个节点、资源存储中心节点以及代理前端的节点，起到一个承上启下的WebServer的作用
如下图:
Nginx静态资源WEB服务核心配置模块
sendfile
当应用程序传输文件时，内核首先缓冲数据，然后将数据发送到应用程序缓冲区。 应用程序反过来将数据发送到目的地。 Sendfile方法是一种改进的数据传输方法，其中数据在操作系统内核空间内的文件描述符之间复制，而不将数据传输到应用程序缓冲区。 这使操作系统资源的利用率提高。
该指令可用于http，server和location代码块：
http{
sendfile on;
}
此指令默认为off。
directio 直接I/O
操作系统内核通常尝试优化和缓存任何读/写请求。 由于数据在内核中缓存，对同一位置的任何后续读取请求将更快，因为不需要再从磁盘读取信息。
直接I/O是文件系统的一个功能，其从应用程序到磁盘直接读取和写入，从而绕过所有操作系统缓存。 这使得更好地利用CPU周期和提高缓存效率。
该方法用于数据具有较差命中率的地方。 这样的数据不需要在任何高速缓存中，并且可以在需要时加载。 它可以用于提供大文件。 directio指令启用该功能。 该指令可用于http，server和location区块：
location /video/ {
directio 4m;
}
任何大于指令中指定的文件将由直接I/O加载。 其它情况下禁用此参数。
直接I/O取决于执行数据传输时的块大小。NGINX有directio_alignment指令来设置块大小。 该指令可用于http，server和location区块：
location /video/ {
directio 4m;
directio_alignment 512;
}
除了XFS文件系统，默认值512字节在所有Linux版本运行良好。在此文件系统下，大小应增加到4 KB。
aio 异步I/O
异步I/O允许进程进行不受阻塞或不需要等待I/O完成的I/O操作。
aio命令可在NGINX配置的http，server和location区块下使用。 根据在指令所在区块，该指令将为匹配的请求执行异步I/O。 该参数适用于Linux内核2.6.22+和FreeBSD 4.3。 如下代码：
location /data {
aio on;
}
默认情况下，该参数设置为off。 在Linux上，aio需要启用direction，而在FreeBSD上，sendfile需要禁用以使aio生效。
该指令具有特殊的线程值，可以为发送和读操作启用多线程。 多线程支持仅在Linux平台上可用，并且只能与处理请求的epoll，kqueue或eventport方法一起使用。
为了使用线程值，在编译Nginx时使用–with-threads选项配置多线程支持。 在NGINX全局上下文中使用thread_pool指令添加一个线程池。 在aio配置中使用该线程池：
thread_pool io_pool threads=16;
http{
........
location /data{
sendfile on;
aio threads=io_pool;
} }
tcp_nopush
作为Nagle算法的替代方案，Linux提供了TCP_CORK选项。 该选项告诉TCP堆栈附加数据包，并在它们已满或当应用程序通过显式删除TCP_CORK指示发送数据包时发送它们。 这使得发送的数据分组是最优量，并且因此提高了网络的效率。
NGINX提供了tcp_nopush指令，在连接套接字时启用TCP_CORK。 该指令可用于http，server和location区块：
http{
tcp_nopush on;
}
该指令默认情况下禁用。
tcp_nodelay
TCP/IP网络存在“小包”问题，其中单字符消息可能在高负载网络上导致网络拥塞。 例如分组大小为41字节，其中40字节用于TCP报头，只有1字节是有用信息。 这些小包占用了大约4000％的巨大开销并且使得网络饱和。
ohn Nagle通过不立即发送小包来解决问题（Nagle的算法）。 所有这样的分组被收集一定量的时间，然后作为单个分组一次发送。 这改进了底层网络的的效率。 因此，典型的TCP/IP协议栈在将数据包发送到客户端之前需要等待200毫秒。
在打开套接字时可以使用TCP_NODELAY选项来禁用Nagle的缓冲算法，并在数据可用时立即发送。 NGINX提供了tcp_nodelay指令来启用此选项。 该指令可用于http，server和location区块：
http{
tcp_nodelay on;
}
该指令默认情况下启用。
ngx_http_gzip_module模块
Nginx实现资源压缩的原理是通过ngx_http_gzip_module模块拦截请求，并对需要做gzip的类型做gzip，ngx_http_gzip_module是Nginx默认集成的，不需要重新编译，直接开启即可。
gzip
这个没的说，打开或关闭gzip
syntax:gzip on | off;
default:
gzip off;
context:http, server, location, if in location
gzip_comp_level
设置gzip压缩级别，级别越底压缩速度越快文件压缩比越小，反之速度越慢文件压缩比越大( 不是压缩级别越高越好，其实gzip_comp_level 1的压缩能力已经够用了，后面级别越高，压缩的比例其实增长不大，反而很吃处理性能。 )
syntax:gzip_comp_level level;
default:gzip_comp_level 1;
context:http, server, location
gzip_http_version
用于识别http协议的版本，早期的浏览器不支持gzip压缩，用户会看到乱码，所以为了支持前期版本加了此选项。默认在http/1.0的协议下不开启gzip压缩。
syntax:gzip_http_version 1.0 | 1.1;
default:gzip_http_version 1.1;
context:http, server, location
使用GZIP例子:
1.我们这里请求index.html,在nginx默认配置未使用gzip的情况下网络传输的index.html文件大小是466KB
2.开启gzip,并且再次请求index.html,使用gzip的情况下网络传输index.html文件大小是5.5KB,区别很明显吧(为了测试,我试过gzip_comp_level 设置gzip压缩级别 6 ,网络传输index.html文件大小是2.7KB)
location / {
root /usr/share/nginx/html;
index index.html index.htm;
gzip on;
gzip_http_version 1.1;
gzip_comp_level 1;
}
优秀的博客文献:
Nginx配置性能优化之I/O和TCP配置
https://www.cnblogs.com/felixzh/p/6283821.html
TCP_NODELAY 和 TCP_NOPUSH的解释
https://www.cnblogs.com/wajika/p/6573014.html
Nginx开启Gzip详解
http://blog.itpub.net/31541037/viewspace-2156996/