【Nginx13】Nginx学习：HTTP核心模块（十）Types、AIO及其它配置

Nginx学习：HTTP核心模块（十）Types、AIO及其它配置

今天学习的内容也比较简单，主要的是 Types 相关的配置，另外还会了解一下 AIO 以及部分没有特别大的分类归属的配置指令的使用。后面的内容都是 HTTP 核心模块中比较小或者比较简单的部分了。有很多配置项其实我们平常并不常用，甚至很多在学习之前我都不知道有它们的存在。做为扩展知识眼界来说，非常有意义，也能够学习到很多之前并不了解或者概念模糊的内容。

Types

这是啥？类型？是的，真的就是类型的意思，不过它指的是我们请求访问的资源类型。大家应该都了解，最初的互联网就是静态页面，而静态页面对应的就是一个个的实实在在的文件。只不过随着技术的发展，动态页面通过各种后端语言占据了主导地位。但对于很多资源来说，比如图片、视频这类大型资源，还有 js、css 这类文件，以及前后端分离的前端部分，还是会通过普通文件的形式进行部署访问。

那么在请求资源的时候，浏览器是怎么知道要以何种方式解析某个文件呢？比如说，我们访问一个 .mp3 结尾的链接，现在的浏览器都会直接展示一个播放器让大家可以直接听歌。这就是通过 MIME 类型来实现的。

最典型的就是对于普通网页，响应头中会返回一个 Content-Type: text/html; 的内容。它就是告诉浏览器要用什么方式来处理当前响应返回的数据。

类似的还有 text/css、image/gif、image/jpeg、image/gif、text/plain、application/javascript、application/json、application/octet-stream、audio/mpeg、video/mp4 等等。具体都是什么意思就不多解释了，大家应该都多少有过了解。这些内容，其实在 Nginx 的配置文件中就有。

……
http{
……
include       mime.types;
……
}

在大部分默认的 nginx.conf 文件中，应该都可以找到这样一个 include 语句。之前我们已经学习过 include 可以加载一个文件进来，这个文件的配置信息就会被嵌入到 include 的这个位置。那么我们就再来看看这个 mime.types 文件是啥。

在 nginx.conf 所在的同级目录中找到 mime.types 文件，打开它就会发现它定义了很多内容。

types{text/html                                        html htm shtml;text/css                                         css;text/xml                                         xml;image/gif…………video/x-ms-asf                                   asx asf;video/x-ms-wmv                                   wmv;video/x-msvideo                                  avi;
}

可以看到，它也是一个类似于小模块一样的配置，有一对花括号。里面定义的其实是文件扩展名与响应的 MIME 类型的映射表。也就是说，后面对应的文件后缀名，在返回响应的时候就会响应成前面的 MIME 码。如果有特殊需要，你也可以自己修改或者添加不同的 MIME 。

default_type

定义响应的默认MIME类型。

default_type mime-type;

默认值是 text/plain ，但直接安装后都会给一个 application/octet-stream 。其实也就是在 types 中找不到类型，就会走这个默认值。我们可以来简单测试下。

location /mimetest/ {alias /usr/local/nginx/html/;types {}default_type text/plain;
}

配置一个 /mimetest 的 location ，然后将 types{} 设置为 空的。types 可以设置在 http、server、location 下，以最下层的为准。然后设置 default_type 为 text/plain 。现在访问 /mimetest ，就会发现默认的 index.html 会以文本的形式直接输出出来 ，包括 html 标签。

另外，假如有专门的下载路径，我们也可以这样配置，强制走这个路径的所有请求都走下载。

location /download/ {alias /usr/local/nginx/html/;types        { }default_type application/octet-stream;
}

types_hash_bucket_size

设置MIME类型哈希桶大小，其默认值取决于处理器的缓存线长度。

types_hash_bucket_size size;

默认值取决于处理器缓存线的大小，将来学习哈希表的时候再说。

types_hash_max_size

设置MIME类型哈希表的最大size(容量)。

types_hash_max_size size;

默认值是 1024， 将来学习哈希表的时候再说。

AIO

AIO 是啥东西？它是 Linux 和 FreeBSD 这类操作系统下的一种异步 IO 功能。它的作用是可以允许进程发起很多 IO 操作，而不用阻塞或等待任何操作完成。稍后在收到 IO 操作完成的通知时，进程就可以检索 IO 操作的结果。注意，它和 epoll 不是一个东西，是操作系统的 aio 系列函数调用。而且 Nginx 中可以组合 aio 和 epoll 来一起使用。AIO 相关的配置项都可以用于 http、server、location 各个模块中。

aio

aio on | off | sendfile;

这个配置的默认值是 off 。另外还可以设置为 on 和 sendfile 。sendfile 只能用于 FreeBSD 5.2.1 之后的系统中，之前的版本和 Linux 下需要关闭 sendfile 。在 FreeBSD 第5版和第6版，静态启动 AIO ，或者在系统启动时动态加载 AIO ，都会触发网络子系统使用一把大锁，进而对整个系统的性能造成负面影响。这个限制在 2009 年发布的 FreeBSD 6.4稳定版和 FreeBSD 7 中被消除。虽然如此，仍有方法在 5.3 及以上版本的 FreeBSD 中开启 AIO 而不触发网络子系统的大锁，那就是在内核启动以后加载AIO模块。

如果是在 Linux 系统中，使用 AIO 需要同时开启 directio 配置项，并且 directio 的配置必须是 512 才有效，启用了 directio 会自动关闭 sendfile。为什么它们两个不兼容呢？其实 AIO 是将数据读到缓冲区，而 sendfile 则是直接将数据发送走，因此，这俩货是对头，没法一起使用。FreeBSD 系统从来没用过，也不知道它为什么可以让 AIO 和 sendfile 并存，这个也不在我们的讨论范围内了。

aio_write

aio_write on | off;

这个指令是 aio 的一个附属指令，表示如果启用 aio 的话，则指定它是否用于写入文件。目前，这仅在使用aio线程时有效，并且仅限于使用从代理服务器接收的数据写入临时文件。

如果开启了 AIO ，那么 Nginx 中会将 aio 和 epoll 事件模型（假设 Nginx 使用 epoll 事件模型）组合起来使用，当请求的 IO 操作完成时调用 epoll 相关函数通知应用程序来读取。根据 Nginx 官网论坛来看，在 Linux 系统的大部分场景下，目前因使用 AIO 功能附加的限制而带来的实际效果并不太理想。而且这个我也不知道咋测，直接压力测试嘛？算了，咱们也不测了，平常保持默认的关闭好了。

关于 AIO 更详细的资料还是需要去深入的学习一下操作系统相关的知识，在这里我也就不深究了，记下这一笔，将来深入的学习操作系统时再进行详细的学习。

其它

这些配置指令没有大的归属，不过也有一些是比较常见的，下篇文章也会继续讲一些其它配置指令，今天先来看一部分。

auth_delay

主要是权限配置相关的，当我们配置并使用了 auth_basic、auth_request 或者 auth_jwt 相关的模块时，定义一个超时时间，用于防止定时攻击。

auth_delay time;

默认 0s ，其实也就是没有开启。定时攻击其实也叫时序攻击，根据加密的不同，我们在加密过程中的返回速度是不一样，但是也已经有很多加密算法是可以预防时序攻击的，之前在 PHP的Hash信息摘要扩展框架https://mp.weixin.qq.com/s/1qAkPkMWcxq_kIoq8b2vOw 这篇文章中我们就已经学习过，这里就不多说了。

Nginx 可以通过这个命令来保证超过指定加密时间直接返回一个 401 错误，具体就不演示了，因为我也不知道咋演示。

chunked_transfer_encoding

允许关闭HTTP/1.1中的分块传输编码。

chunked_transfer_encoding on | off;

默认值是 on ，在客户端软件不支持分块传输编码或者不希望使用分块传输的时候，这条指令可以关掉它。自己试了半天，也不知道咋测，有了解的小伙伴可以留言哦！

connection_pool_size

允许微调为每个连接分配的内存。

connection_pool_size size;

这条指令对 Nginx 的性能影响非常小，一般不应该使用。默认情况下，该大小在 32 位平台上等于 256 字节，在 64 位平台上等于 512 字节。在 1.9.8 版本之前，所有平台上的默认值均为 256 。

log_not_found

开启或者关闭在 error_log 中记录文件不存在的错误。

log_not_found on | off;

默认值是 on ，这个配置主要就是我们访问一个不存在的页面，找不到对应的文件，一般会报出一个 404 错误，并且对应的 error_log 日志文件中会记录一条信息。

2022/08/07 20:52:41 [error] 868#0: *1 open() "/usr/local/nginx/html/123.html" failed (2: No such file or directory), client: 192.168.56.1, server: core.nginx.test, request: "GET /123.html HTTP/1.1", host: "192.168.56.88"

但如果我们将它设置为 off ，则在错误日志中就不会记录这条信息了，只会在 access_log 中记录那个 404 的请求。

log_subrequest

开启或者关闭在 access_log 中记录子请求的访问日志

log_subrequest on | off;

默认值是 off ，查了半天也没查到怎么发子请求，使用 addition、auth_request 之类的文档中写着可以发子请求的模块测试也没效果。网上搜的很多是自己写模块或者使用一些第三方模块，有了解的小伙伴可以留言哈，这个咱们就先不测试了。

merge_slashes

开启或者关闭将请求 URI 中相邻两个或更多斜线合并成一个的功能。

merge_slashes on | off;

默认值是 on ，比如说我们经常可能在输入 URL 的时候多打了一个斜杠，比如 /slashes/aaa.html 打成了 //slashes/aaa.html 。这种情况下，如果 merge_slashes 的配置是 off 的话，那么对于 location /slashes/这个配置就无法匹配成功了。查看日志，会报出这样的错误。

2022/08/07 22:26:19 [error] 1611#0: *87 open() "/usr/local/nginx/html//slashes/aaa.html" failed (2: No such file or directory), client: 192.168.56.1, server: core.nginx.test, request: "GET //slashes/aaa.html HTTP/1.1", host: "192.168.56.88"

也就是说，访问的 URI 按照普通的路径 /usr/local/nginx/html//slashes/aaa.html 来进行访问了。在 Linux 中，这种访问方式也是不被允许的。

[root@localhost html]# ll /usr/local/nginx/html//slashes/aaa.html
ls: cannot access '/usr/local/nginx/html//slashes/aaa.html': No such file or directory

另外还需要注意的是，如果URI中包含 base64 编码的内容，必须将斜线压缩调整成 off ，因为 base64 编码本身会使用 “/” 字符。出于安全方面的考虑，最好还是不要关闭压缩。这条指令可以指定在默认虚拟主机的 server 配置级别。这样的话，这个配置可以覆盖监听同一地址和端口的所有虚拟主机。

msie_padding

msie_padding on | off;

默认 on ，在响应状态码大于等于 400 时，在响应正文中添加一段注释，使响应正文达到512字节。本指令可以为 MSIE 客户端开启或关闭这个功能。IE 相关的配置咱们就不试了，我这也没有现成的 IE 浏览器。

msie_refresh

msie_refresh on | off;

默认 off ，为 MSIE 客户端开启或者关闭用页面刷新取代页面重定向的功能。IE 相关的配置咱们就不试了，我这也没有现成的 IE 浏览器。

总结

是不是感觉大开眼界了？平常我们以为多打两个斜杠没事，但其实是 Nginx 默认帮我们处理了。响应类型的概念相信也让大家对浏览器如何处理响应头有了新的认识，原来 Nginx 也是根据文件的后缀名来进行判断的。最后，还有一大堆配置指令等着我们呢，别急，下篇文章见。

参考文档：

http://nginx.org/en/docs/http/ngx_http_core_module.html