Nginx静态资源服务器的实现示例

目次

• 静态资源
• 基本配置
• 文件读取配置
• 文件压缩配置
• Nginx 配置 gzip
• Webpack 的 gzip 配置
• 欣赏器缓存
• 设置绝对过期时间
• 设置相对过期时间
• 资源最后修改时间
• 资源缓存计谋
• 配置 CORS 跨域访问
• 反向署理办理跨域
• 配置 header 办理跨域
• 防盗链
• 图片处置惩罚

静态资源

静态资源即非服务器动态天生的文件。
常见静态资源类型：

• 欣赏器端渲染：HTML、CSS、JS
• 图片：JPEG、GIF、PNG
• 视频：FLV、MPEG
• 文件：TXT 等任意下载文件

基本配置

Web 服务器一个紧张的功能是服务静态文件（图像或静态 HTML 页面）。例如，Nginx 可以很方便的让服务器从 [code]/data/www[/code] 获取 [code]html[/code] 文件，从 [code]/data/images[/code] 获取图片来返回给客户端，这只需要在 [code]http[/code] 块指令中的 [code]server[/code] 块指令中设置两个 [code]location[/code] 块指令。

起首，创建 [code]/data/www[/code] 目次，并放入 [code]index.html[/code]，创建 [code]/data/images[/code] 目次并在其中放置一些图片。

接下来，打开配置文件。 创建一个 server 块：

通常，配置文件可以包罗多个 [code]server[/code] 块，它们以 端口 和 服务器名称 来区分。当 Nginx 决定某一个 [code]server[/code] 处置惩罚请求后，它将请求头中的 [code]URI[/code] 和 [code]server[/code] 块中的 [code]location[/code] 块举行对比。

参加 [code]location[/code] 块指令到 [code]server[/code] 中：

将以下 [code]location[/code] 块添加到 [code]server[/code] 块：

上面的 [code]location[/code] 块指定 [code]/[/code] 前缀与请求中的 [code]URI[/code] 对比。对于匹配的请求，[code]URI[/code] 将被添加到 [code]root[/code] 指令中指定的路径，即 [code]/data/www[/code]，以此形成本地文件系统的路径，如访问 [code]http://localhost/bog/welcome.html[/code]，对应服务器文件路径为 [code]/data/www/bog/welcome.html[/code]。 假如 [code]URI[/code] 匹配多个 [code]location[/code] 块，Nginx 采用 最长前缀匹配原则（雷同盘算机网络内里的 IP 匹配）， 上面的 [code]location[/code] 块前缀长度为 1，因此只有当全部其他 [code]location[/code] 块匹配时，才使用该块。

接下来，添加第二个位置块：

它将匹配以 [code]/images/[/code]（[code]/[/code] 也匹配如许的请求，但具有较短的前缀）开始的请求。

[code]server[/code] 块的最终配置如下：

到现在为止，这已经是一个可以正常运行的服务器，它监听端口 80，而且可以在本地盘算机上访问 [code]http://localhost/[/code]。 对于 [code]/images/[/code] 开头的请求，服务器将从 [code]/data/images[/code] 目次发送文件。 如，对于 [code]http://localhost/images/example.png[/code] 请求，nginx 将相应 [code]/data/images/example.png[/code] 文件。 假如不存在，Nginx 将返回 404。[code]URI[/code] 不以 [code]/images/[/code] 开头的请求将映射到 [code]/data/www[/code] 目次。 例如，对于 [code]http://localhost/some/example.html[/code] 请求，Nginx 将相应 [code]/data/www/some/example.html[/code] 文件。

浅显配置

说明相关配置字段：

• [code]server[/code]：配置虚拟主机的相关参数，可以有多个
• [code]server_name[/code]：通过请求中的 host 值，找到对应的虚拟主机的配置
• [code]location[/code]：配置请求路由，处置惩罚相关页面情况
• [code]root[/code]：查找资源的路径

配置完成后执行 [code]nginx -t[/code] 看是否有错误，假如看到的是下面这种就是乐成：

然后执行 [code]nginx -s reload[/code] 更新 Nginx 配置文件

文件读取配置

在 Keep-Alive 毗连下，进步网络包的传输实时性。

文件压缩配置

开发过程中难免用到一些成熟的框架，或者插件，这些外部的依赖，有时间体积比较大，导致页面相应迟钝，我们可以用打包工具（Webpack、rollup），将代码举行压缩，以缩小代码体积。 开启 Nginx Gzip 压缩功能。需要留意的是 Gzip 压缩功能需要欣赏器跟服务器都支持，即服务器压缩，欣赏器解析。

Nginx 配置 gzip

• [code]gzip_types[/code]：要采用 [code]gzip[/code] 压缩的 MIME 文件类型，其中 [code]text/html[/code] 被系统强制启用；
• [code]gzip_static[/code]：默认 off，该模块启用后，Nginx 起首查抄是否存在请求静态文件的 gz 结尾的文件，假如有则直接返回该 [code].gz[/code] 文件内容；
• [code]gzip_proxied[/code]：默认 off，Nginx 做为反向署理时启用，用于设置启用或禁用从署理服务器上收到相应内容 [code]gzip[/code] 压缩；
• [code]gzip_vary[/code]：用于在相应消息头中添加 [code]Vary：Accept-Encoding[/code]，使署理服务器根据请求头中的 [code]Accept-Encoding[/code] 辨认是否启用 [code]gzip[/code] 压缩；
• [code]gzip_comp_level[/code]：[code]gzip[/code] 压缩比，压缩级别是 1-9，1 压缩级别最低，9 最高，级别越高压缩率越大，压缩时间越长，发起 4-6；
• [code]gzip_buffers[/code]：获取多少内存用于缓存压缩结果，16 8k 表示以 [code]8k*16[/code] 为单位获得；
• [code]gzip_min_length[/code]：允许压缩的页面最小字节数，页面字节数从 [code]header[/code] 头中的 [code]Content-Length[/code] 中举行获取。默认值是 0，不管页面多大都压缩。发起设置成大于 1k 的字节数，小于 1k 大概会越压越大；
• [code]gzip_http_version[/code]：默认 1.1，启用 [code]gzip[/code] 所需的 HTTP 最低版本；

查看配置是否生效，查看相应头中的 [code]Content-Encoding[/code] 字段，值为 [code]gzip[/code]。

留意：一般 [code]gzip[/code] 的配置发起加上 [code]gzip_min_length 1k[/code]，否则会因为文件太小，压缩后体积还比压缩之前体积还大，以是最好设置 [code]1kb[/code] 的文件就不要 [code]gzip[/code] 压缩了。

Webpack 的 gzip 配置

当前端项目使用 Webpack 举行打包的时间，也可以开启 gzip 压缩：

因为假如全都是使用 Nginx 来压缩文件，会淹灭服务器的盘算资源，假如服务器的 [code]gzip_comp_level[/code] 配置的比较高，就更增加服务器的开销，相应增加客户端的请求时间，得不偿失。假如压缩的动作在前端打包的时间就做了，把打包之后的高压缩品级文件作为静态资源放在服务器上，Nginx 会优先查找这些压缩之后的文件返回给客户端，相当于把压缩文件的动作从 Nginx 提前给 Webpack 打包的时间完成，节约了服务器资源，以是一般推介在生产环境应用 Webpack 配置 [code]gzip[/code] 压缩。

欣赏器缓存

欣赏器缓存是为了加快欣赏，欣赏器在用户磁盘上，对迩来请求过的文档举行存储。当访问者再次请求这个页面时，欣赏器就可以从本地磁盘表现文档，如许，就可以加快页面的阅览，缓存的方式节约了网络的资源，进步了网络的服从。

欣赏器缓存可以通过添加 [code]expires[/code] 和 [code]cache-control[/code] 头来实现。

HTTP 协议的 Cache -Control 指定请求和相应遵循的缓存机制。在请求消息或相应消息中设置 Cache-Control 并不会影响另一个消息处置惩罚过程中的缓存处置惩罚过程。

• 请求时的缓存指令：[code]no-cache[/code]、[code]no-store[/code]、[code]max-age[/code]、[code]max-stale[/code]、[code]min-fresh[/code]、[code]only-if-cache[/code] 等
• 相应消息中的指令：[code]public[/code]、[code]private[/code]、[code]no-cache[/code]、[code]no-store[/code]、[code]no-transform[/code]、[code]must-revalidate[/code]、[code]proxy-revalidate[/code]、[code]max-age[/code]。

设置绝对过期时间

设置以分钟为单位的绝对过期时间, 优先级比 Cache-Control 低, 同时设置 Expires 和 Cache-Control 则后者生效。也就是说要留意一点: Cache-Control 的优先级高于 Expires。

[code]expires[/code] 起到控制页面缓存的作用，合理配置 [code]expires[/code] 可以减少许多服务器的请求，[code]expires[/code] 的配置可以在 HTTP 段中或者 server 段中或者 location 段中。比如控制图片等过期时间为 30 天, 可以配置如下:

设置相对过期时间

Cache-Control 通用消息头字段被用于在 HTTP 请求和相应中通过指定指令来实现缓存机制。缓存指令是单向的, 这意味着在请求设置的指令，在相应中不肯定包含相同的指令。

指令不区分大小写，而且具有可选参数，可以用令牌或者带引号的字符串语法。多个指令以逗号分隔。

• 可缓存性
  • [code]public[/code]： 表明相应可以被任何对象（包罗：发送请求的客户端，署理服务器，等等）缓存。表示相应会被缓存，而且在多用户间共享。默认是 [code]public[/code]
  • [code]private[/code]：表明相应只能被单个用户缓存，不能作为共享缓存（即署理服务器不能缓存它）,可以缓存相应内容。相应只作为私有的缓存，不能在用户间共享。假如要求 HTTP 认证，相应会自动设置为 [code]private[/code]
  • [code]no-cache[/code]： 在释放缓存副本之前，强制高速缓存将请求提交给原始服务器举行验证。指定不缓存相应，表明资源不举行缓存。但是设置了 [code]no-cache[/code] 之后并不代表欣赏器不缓存，而是在缓存前要向服务器确认资源是否被更改。因此有的时间只设置 [code]no-cache[/code] 防止缓存照旧不敷保险，还可以加上 [code]private[/code] 指令，将过期时间设为已往的时间
  • [code]only-if-cached[/code]：表明客户端只接受已缓存的相应，而且不要向原始服务器查抄是否有更新的拷贝
• 到期
  • [code]max-age=<seconds>[/code]：设置缓存存储的最大周期，超过这个时间缓存被认为过期（单位秒）。与 [code]Expires[/code] 相反，时间是相对于请求的时间。[code]max-age[/code] 会覆盖掉 [code]Expires[/code]
  • [code]s-maxage=<seconds>[/code]：覆盖 [code]max-age[/code] 或者 [code]Expires[/code] 头，但是仅适用于共享缓存（比如各个署理），而且私有缓存中它被忽略。也就是说 [code]s-maxage[/code] 只用于共享缓存，比如 CDN 缓存（[code]s -> share[/code]）。与 [code]max-age[/code] 的区别是：[code]max-age[/code] 用于普通缓存，而 [code]s-maxage[/code] 用于署理缓存。假如存在 [code]s-maxage[/code]，则会覆盖 [code]max-age[/code] 和 [code]Expires[/code]
  • [code]max-stale[=<seconds>][/code]：表明客户端乐意吸收一个已颠末期的资源。 可选的设置一个时间（单位秒），表示相应不能超过的过时时间
  • [code]min-fresh=<seconds>[/code]： 表示客户端盼望在指定的时间内获取最新的相应
  • [code]stale-while-revalidate=<seconds>[/code]：表明客户端乐意接受陈旧的相应，同时在背景异步查抄新的相应。秒值指示客户乐意接受陈旧相应的时间长度
  • [code]stale-if-error=<seconds>[/code]：表示假如新的查抄失败，则客户乐意接受陈旧的相应。秒数值表示客户在初始到期后乐意接受陈旧相应的时间
• 重新验证和重新加载
  • [code]must-revalidate[/code]：缓存必须在使用之前验证旧资源的状态，而且不可使用过期资源。表示假如页面过期，则去服务器举行获取
  • [code]proxy-revalidate[/code]：与 [code]must-revalidate[/code] 作用相同，但它仅适用于共享缓存（例如署理），并被私有缓存忽略
  • [code]immutable[/code]：表示相应正文不会随时间而改变。资源（假如未过期）在服务器上不发生改变，因此客户端不应发送重新验证请求头（例如 [code]If-None-Match[/code] 或 [code]If-Modified-Since[/code]）来查抄更新，即使用户显式地革新页面
• 其他
  • [code]no-store[/code]：缓存不应存储有关客户端请求或服务器相应的任何内容。表示绝对禁止缓存!
  • [code]no-transform[/code]： 不得对资源举行转换或变化。[code]Content-Encoding[/code]、[code]Content-Range[/code] 和 [code]Content-Type[/code] 等 HTTP 头不能由署理修改。例如，非透明署理可以对图像格式举行转换，以便节省缓存空间或者减少迟钝链路上的流量。 [code]no-transform[/code] 指令不允许如许做。

设置相对过期时间, [code]max-age[/code] 指明以秒为单位的缓存时间. 若对静态资源只缓存一次, 可以设置 [code]max-age[/code] 的值为 315360000000（一万年）。比如对于提交的订单，为了防止欣赏器回退重新提交，可以使用 Cache-Control 之 [code]no-store[/code] 绝对禁止缓存，即便欣赏器回退依然请求的是服务器，进而判断订单的状态给出相应的提示信息！

特别区分：

• [code]no-cache[/code]：欣赏器和缓存服务器都不应该缓存页面信息
• [code]no-store[/code]： 请求和相应的信息都不应该被存储在对方的磁盘系统中

资源最后修改时间

该资源的最后修改时间，在欣赏器下一次请求资源时，欣赏器将先发送一个请求到服务器上, 并附上 [code]If-Unmodified-Since[/code] 头来说明欣赏器所缓存资源的最后修改时间, 假如服务器发现没有修改, 则直接返回 304（Not Modified）回应信息给欣赏器（内容很少），假如服务器对比时间发现修改了，则照常返回所请求的资源。

需要留意：

• [code]Last-Modified[/code] 属性通常和 [code]Expires[/code] 或 [code]Cache-Control[/code] 属性配合使用, 因为即使欣赏器设置缓存, 当用户点击 革新 按钮时, 欣赏器会忽略缓存继续向服务器发送请求, 这时 [code]Last-Modified[/code] 将可以或许很好的减小回应开销
• ETag 将返回给欣赏器一个资源 ID, 假如有了新版本则正常发送并附上新 ID，否则返回 304，但是在服务器集群情况下，每个服务器将返回不同的 ID，因此不发起使用 [code]ETag[/code]

资源缓存计谋

欣赏器缓存 Header：[code]expires[/code]、[code]cache-control[/code]、[code]last-modified[/code]、[code]etag[/code]。

• 200 状态：当欣赏器本地没有缓存或者下一层失效时，或者用户强制革新时，欣赏器直接去服务器获取最新资源
• 304 状态：由 Last-Modified / Etag 控制。当下一层失效时活用户革新时，欣赏器就会发送请求给服务器，假如服务端没有变更，则返回 304 给欣赏器
• 200 状态（from cache）：由 Expires / Cache-Control 控制，Expires 是绝对时间，Cache-Control 是相对时间，两者都存在时，Cache-Control 覆盖 Expires 只要没有失效，欣赏器只访问自己的缓存

通用计谋：

• 对于 HTML 文件，[code]cache-control[/code] 设置为 [code]no-cache[/code]
• 对于 JS、图片、CSS、字体等，设置 [code]max-age=2592000[/code]，也就是 30 天

集群分布式摆设发起关闭 Etag，因为每台呆板天生的 Hash 是不同的。

配置 CORS 跨域访问

假设有两个域名 [code]mrsingsing.com[/code] 和 [code]api.mrsingsing.com[/code]，假如 [code]mrsingsing.com[/code] 域名想请求 [code]api.mrsingsing.com[/code] 域名下的资源会因为 [code]host[/code] 不同等存在跨域的问题。

反向署理办理跨域

为了绕开欣赏器的跨域安全限制，需要将请求的域名由 [code]api.mrsingsing.com[/code] 改为 [code]mrsingsing.com[/code]。同时约定 URL 规则来表明署理请求的身份，然后 Nginx 通过匹配该规则，将请求署理回原来的域。

这里对静态文件的请求和后端服务的请求都以 [code]mrsingsing.com[/code] 开始，不易区分，以是通常为了实现对后端服务请求的统一转发，通常我们会约定对后端服务的请求加上 [code]/api/[/code] 的前缀或者其他的 [code]path[/code] 来和静态资源的请求加以区分：

如许着实是通过 Nginx，用雷同于 Hack 的方式规避了欣赏器的跨域限制，实现了跨域访问。

如许，静态资源我们使用 [code]mrsingsing.com/index.html[/code]，动态资源我们使用 [code]mrsingsing.com/api/getOrderList[/code]，欣赏器页面看起来仍然访问的前端服务器，绕过了欣赏器的通源计谋，究竟我们看起来并没有跨域。

配置 header 办理跨域

在 Nginx 配置中配置对应二级域名 [code]api.mrsingsing.com[/code]：

防盗链

防盗链机制的目的是防止服务器上的资源（例如图片、文件等）被别的用户采用别的的技术手段来访问或下载。

实现方式：区别哪些请求是非正常的用户请求

基于 [code]http_refer[/code] 防盗链配置模块：

• 设置防盗链文件类型，自行修改，每个后缀用 [code]|[/code] 符号分隔
• 允许文件链出的域名白名单，自行修改成己方域名，域名与域名之间使用空格隔开

图片处置惩罚

在前端开发中，常常需要不同尺寸的图片。现在的云储存基本对图片都提供有处置惩罚服务（一般是通过在图片链接上加参数）。着实用 Nginx，可以通过几十行配置，搭建出一个属于自己的本舆图片处置惩罚服务，完全可以或许满足一样平常对图片的裁剪/缩放/旋转/图片品格等处置惩罚需求。要用到 [code]ngx_http_image_filter_module[/code] 模块。这个模块是非基本模块，需要安装。

下面是图片缩放功能部门的 Nginx 配置：

到此这篇关于Nginx静态资源服务器的实现示例的文章就先容到这了,更多相关Nginx静态资源服务器内容请搜索脚本之家从前的文章或继续欣赏下面的相关文章盼望大家以后多多支持脚本之家！