Nginx压缩和用作应用程序网关

最新推荐文章于 2024-08-22 09:54:05 发布

zsx0728

最新推荐文章于 2024-08-22 09:54:05 发布

阅读量236

点赞数

分类专栏： Nginx 文章标签： nginx uwsgi django

Nginx 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

文章目录

1. 压缩和解压缩

本节介绍如何配置响应的压缩或解压缩以及如何发送压缩文件。

1.1 介绍

压缩响应通常会大大减少传输数据的大小。但是，由于压缩是在运行时发生的，因此也会增加相当大的处理开销，这可能会对性能产生负面影响。NGINX在将响应发送到客户端之前执行压缩，但不会“双重压缩”已压缩的响应（例如，由代理服务器进行的响应）。

1.2 启用压缩

要启用压缩，请在gzip指令中包含on参数。

gzip on;

默认情况下，NGINX仅压缩MIME类型text/html的响应。要压缩其他MIME类型的响应，请添加gzip_types指令并列出其他类型。

gzip_types text/plain application/xml;

要指定要压缩的响应的最小长度，请使用gzip_min_length指令。默认值为20字节（此处调整为1000）：

gzip_min_length 1000;

默认情况下，NGINX不压缩对代理请求（来自代理服务器的请求）的响应。请求来自代理服务器的事实取决于请求中是否存在Via头部字段。要配置这些响应的压缩，请使用gzip_proxied指令。该指令具有许多参数，用于指定NGINX应该压缩哪些代理请求。例如，合理的做法是仅压缩部分响应，该类响应的请求不会缓存在代理服务器上。为此目的，gzip_proxied指令有参数来命令NGINX检查响应中的Cache-Control报头部分，如果值为no-cache, no-store, 或 private，则压缩响应。此外，您必须添加expired参数以检查Expires标头字段。这些参数以下示例中设置，与auth参数一起，用于检查Authorization标头字段是否存在（授权响应特定于最终用户，通常不缓存）：

gzip_proxied no-cache no-store private expired auth;

与大多数其他指令一样，配置压缩的指令可以包含在http上下文的server或location配置块中。
gzip压缩的总体配置可能如下所示：

server {
    gzip on;
    gzip_types      text/plain application/xml;
    gzip_proxied    no-cache no-store private expired auth;
    gzip_min_length 1000;
    ...
}

1.3 启用解压缩

某些客户端不支持gzip编码方法的响应。同时，可能希望存储压缩的数据，或者动态压缩响应并将其存储在缓存中。为了成功服务于接受和不接受压缩数据的两个客户端，NGINX可以在将数据发送到后一种类型的客户端时即时对其进行解压缩。
要启用运行时解压缩，请使用gunzip指令。

location /storage/ {
    gunzip on;
    ...
}

可以在与gzip指令相同的上下文中指定gunzip指令：

server {
    gzip on;
    gzip_min_length 1000;
    gunzip on;
    ...
}

请注意，此指令是在单独的ngx_http_gunzip_module模块中定义的，默认情况下可能未包含在NGINX开源版本中。

1.4 发送压缩文件

要将文件的压缩版本（而不是常规文件）发送到客户端，请在适当的上下文内将gzip_static指令设置on：

location / {
    gzip_static on;
}

    在这种情况下，为了满足对/path/to/file的请求，NGINX尝试查找并发送文件/path/to/file.gz。如果该文件不存在，或者客户端不支持gzip，则NGINX发送该文件的未压缩版本。
    注意，gzip_static指令不支持动态压缩。它只使用压缩工具预先压缩好的文件。要在运行时压缩内容（不仅仅是静态内容），请使用gzip指令。
    该指令在单独的ngx_http_gzip_static_module模块中定义，默认情况下可能未包含在NGINX开源构建中。

2. 使用uWSGI和Django将NGINX和NGINX Plus用作应用程序网关

2.1 介绍

    NGINX是高性能，可伸缩，安全和可靠的Web服务器和反向代理。NGINX支持所有主要的Web加速技术来管理HTTP连接和流量。多年来，NGINX功能（如负载平衡，SSL终止，连接和请求策略，静态内容卸载和内容缓存）帮助NGINX用户快速有效地构建可靠，快速的网站。
    NGINX还可以充当一个安全的应用程序网关，提供许多专门的内置接口来将流量从用户传递到应用程序。在这方面，NGINX不仅可以将HTTP和HTTPS流量代理到启用HTTP的应用程序容器，还可以与大多数流行的轻量级应用服务器、WEB框架直接通信，WEB框架由 FastCGI，Memcached，scgi，和 uwsgi模块提供优化的应用网关接口。
    大多数常用的应用程序容器都嵌入了具有某些路由功能的外部HTTP接口，但使用NGINX作为应用程序网关的一个重要原因是，NGINX为HTTP连接管理、负载平衡、内容缓存和流量安全提供了一体式解决方案。应用程序后端安全地位于NGINX后面，以获得更好的可伸缩性和性能。在NGINX后面集群应用实例来构建高可用的应用程序也是非常容易的。

2.2 关于uWSGI和Django

    关于“专用接口”的几句话。尽管HTTP非常有用，但它从未针对现代轻量级应用程序部署方案进行过优化。近年来，一些标准化的接口已经演变为可与各种应用程序框架和应用程序容器一起使用。其中一个接口是Web服务器网关接口（WSGI），它是Web服务器/WEB代理和基于Python的应用程序之间的接口。
    提供uwsgi协议的最常用的应用服务器之一，自己实现WSGI协议，是
uWGSI应用服务器容器。
    除此之外，uWSGI应用程序服务器还支持HTTP，FastCGI和SCGI –建议使用uwsgi协议作为与应用程序进行通讯的最快方式。

2.3 配置NGINX和NGINX Plus以与uWSGI和Django一起使用

    本文档提供了一个示例，说明如何配置NGINX和NGINX Plus（NGINX的商业版本）与uWSGI服务器和Python开发环境一起使用。
    NGINX 0.8.40和更高版本都提供了本机支持，可通过uwsgi协议将流量从用户传递到Python应用程序。如果您从官方资源库中下载了NGINX，则无需执行任何操作即可启用对uwsgi协议的支持。默认情况下，NGINX和NGINX Plus支持uswgi。
    配置uWSGI应用程序容器本身不在本文讨论范围之内；有关更多信息，请参阅出色的Python/WSGI程序快速入门。
    Django可能是最常用的Python Web框架，因此，为简单起见，该示例为Python应用程序使用了基于Django的设置。在Django文档提供了有关如何配置一个Django环境的大量信息。
    仅出于说明目的，这是您可以使用Django调用uWSGI服务器的一种方式：

# /usr/local/sbin/uwsgi \
     --chdir=/var/django/projects/myapp \
     --module=myapp.wsgi:application \
     --env DJANGO_SETTINGS_MODULE=myapp.settings \
     --master --pidfile=/usr/local/var/run/uwsgi/project-master.pid \
     --socket=127.0.0.1:29000 \
     --processes=5 \
     --uid=505 --gid=505 \
     --harakiri=20 \
     --max-requests=5000 \
     --vacuum \
     --daemonize=/usr/local/var/log/uwsgi/myapp.log

有了这些选项后，以下是用于Django项目的示例NGINX配置：

http {
    # ...
    upstream django {
        server 127.0.0.1:29000;
    }

    server {
        listen 80;
        server_name myapp.example.com;
        root /var/www/myapp/html;

        location / {
            index index.html;
        }

        location /static/  {
            alias /var/django/projects/myapp/static/;
        }

        location /main {
            include /etc/nginx/uwsgi_params;
            uwsgi_pass django;
            uwsgi_param Host $host;
            uwsgi_param X-Real-IP $remote_addr;
            uwsgi_param X-Forwarded-For $proxy_add_x_forwarded_for;
            uwsgi_param X-Forwarded-Proto $http_x_forwarded_proto;
        }
    }
}

请注意，该配置定义了一个名为django的upstream。组中服务器上的端口号29000与uWSGI服务器绑定的端口号匹配，如示例uwsgi命令中socket部分指定的那样。
静态内容的服务被转移到NGINX或NGINX Plus，直接从/var/django/projects/myapp/static提供服务。到应用程序的 /main 流量被由HTTP代理和桥接到uwsgi协议，并传递到运行在uwsgi应用程序容器内的Django App。

2.4 结论

轻量级、异构的应用程序环境正在成为构建和部署现代web应用程序的一种越来越流行的方式。更新的、标准化的应用程序接口协议，如uwsgi和FastCGI，支持用户和应用程序之间更快的通信。
在应用程序容器前使用NGINX和NGINX Plus已成为一种常见的方法，可以使应用程序摆脱HTTP流量管理的负担，并保护应用程序免受意外的用户流量峰值、恶意行为、拒绝服务（DoS）攻击等。脱离现实世界，来自实际应用程序的外部HTTP流量允许开发人员充分关注应用程序逻辑，并将web加速和基本HTTP流量安全任务留给NGINX或NGINX Plus。