隆重推出 NGINX Plus R7

NGINX, Inc. is proud to announce the availability of NGINX Plus Release 7 (R7), the latest release of our application delivery platform. The update provides a fully supported implementation of the new HTTP/2 web standard, the first of its kind for a leading web server. NGINX Plus can be deployed as a frontend HTTP/2 gateway and accelerator for both new and existing web services.

[Editor – This post has been updated to refer to the NGINX Plus API, which replaces and deprecates the separate status module mentioned in the original version of the post.]

The latest update also adds dramatic improvements and additional capabilities to ensure organizations can deliver their applications with the performance, security, and reliability required for enterprise applications. These include significant enhancements to make application monitoring, management, and debugging easier, and additional security and performance‑optimizing features.

Editor – For more details about key new features in NGINX Plus R7, see these related blog posts:

• HTTP/2 Now Fully Supported in NGINX Plus
• Thread Pools in NGINX Boost Performance 9x!
• Socket Sharding in NGINX
• The New NGINX Plus Dashboard in Release 7
• TCP Load Balancing in NGINX Plus R7

Also check out our on‑demand webinar, What’s New in NGINX Plus R7?

Key features in this release include:

• Fully supported implementation of HTTP/2 – NGINX Plus now provides a fully supported implementation of the new HTTP/2 web standard. NGINX Plus can be deployed as a frontend HTTP/2 gateway and accelerator for both new and existing web services.
  
  HTTP/2 support is available in the optional nginx-plus-http2 package only. The nginx-plus and nginx-plus-extras packages provide SPDY support and are currently recommended for production sites because of wider browser support and code maturity.

  Note: Based on user testing of the alpha‑level patch, and with the early support from corporate co‑sponsors Automattic and Dropbox, the final open source version of HTTP/2 will become available following the release of R7.

• Significantly improved performance – NGINX Plus R7 supports thread pools for asynchronous I/O. This accelerates workloads that involve high levels of disk I/O, such as content caching. Our benchmarks indicate thread pools can drive as much as 9x performance improvement for certain workloads.
  
  NGINX Plus R7 also supports socket sharding optimizations to increase performance on multicore servers. Our benchmarking indicates that this can increase requests per second and reduce latency by more than 3x each. Socket sharding uses the SO_REUSEPORT option and currently requires Linux 3.9+ or DragonFly BSD.
• Access control and security enhancements – New and extended features in NGINX Plus help improve the security and reliability of your applications. Access controls and connection limits for TCP services enable you to apply protection rules to all of your NGINX‑managed services, while support for NT LAN Manager (NTLM) authentication means that you can deploy NGINX Plus in front of legacy Microsoft applications.
• Improved monitoring and diagnostics – NGINX Plus adds even more detailed monitoring and statistics data to the existing status and dashboard tools. Track client errors, internal NGINX activity, and the SSL load on your services to help identify problems and tune your configuration.
• Updated, interactive NGINX Plus dashboard – NGINX Plus’ live activity monitoring dashboard has been significantly extended, now providing a tabbed interface to provide more detailed views of your NGINX performance and health. You can drill down to identify and understand problems with your infrastructure and make rapid changes to your configurations.

“We have helped hundreds of new customers deploy their applications with NGINX Plus in the past year, and our latest release is really about providing them with even more tools to ensure the best possible experience for their users,” states Gus Robertson, CEO at NGINX, Inc. “We are the fabric of our customer’s infrastructure, and that puts us in a unique place to be able to provide unparalleled visibility and control over the applications they deploy. We take our critical role in our customer’s business seriously, and the new capabilities in NGINX Plus R7 reflect that.”

Adoption of NGINX has grown considerably in recent months. NGINX is the #1 web server at the top 100,000 websites, with nearly half of the world’s busiest sites using NGINX to deliver their applications to billions of users. NGINX, Inc. continues to invest heavily in both our open source and commercially supported tools to make flawless application delivery easy for everyone – from the smallest, lightest apps up to the world’s largest platforms.

NGINX Plus R7 Features in Detail

This section provides a detailed overview of all the new features and functionality in NGINX Plus R7.

Fully Supported Implementation of HTTP/2

NGINX Plus R7 delivers support for HTTP/2, the latest version of the HTTP protocol, via the new nginx-plus-http2 package. HTTP/2 brings increased performance and security to modern web applications. NGINX Plus support for HTTP/2 works seamlessly with your existing sites and apps, without requiring any changes to them and only very minimal changes to the NGINX Plus configuration. NGINX Plus R7 is fully backward compatible and can deliver both HTTP/1.x and HTTP/2 traffic in parallel, for the best experience no matter what browser your users choose.

To ease the transition to HTTP/2, NGINX Plus acts as an “HTTP/2 gateway”. On the front end, NGINX Plus talks HTTP/2 to client web browsers that support it, and on the back end it talks HTTP/1.x (or FastCGI, SCGI, uWSGI, etc.) just as before. This means that servers and applications proxied by NGINX Plus will be unaffected by the move to HTTP/2, and don’t really even need to know which HTTP version their clients are using.

To support HTTPS and HTTP/2 side by side, NGINX Plus supports both the Next Protocol Negotiation (NPN) and Application‑Layer Protocol Negotiation (ALPN) extensions in TLS. These extensions are used to seamlessly upgrade an HTTPS connection to HTTP/2 if both client and server support HTTP/2.

The only configuration change required is to add the http2 parameter to existing listen directives. Please note HTTP/2 is only supported when the ssl parameter is also included:

server {
    listen 443 ssl http2 default_server;
}

To enable HTTP/2 support, install the nginx-plus-http2 package from the NGINX Plus repository. This package does not support SPDY/3.1. The standard nginx-plus and nginx-plus-extras packages support SPDY/3.1 rather than HTTP/2, and are currently recommended for production sites due to wider browser support and code maturity. Note that we currently don’t build an HTTP/2‑enabled version of the nginx-plus-extras package.

To learn more about HTTP/2:

• Please read our white paper, which covers everything you need to know about HTTP/2.
• Download our special edition of the High Performance Browser Networking ebook by Ilya Grigorik of Google.

Significantly Improved Performance

NGINX Plus R7 includes a number of performance enhancements that can help your applications perform even better. It adds support for thread‑pool optimization, which offloads potentially blocking disk operations and improves the performance of workloads (such as content caching) that involve heavy disk I/O. NGINX Plus R7 also includes the socket sharding optimization (Linux 3.9+ or Dragonfly BSD required) that improves efficiency on large, multicore servers where large numbers of nginx processes handle traffic. They have been tested in the field in NGINX Open Source deployments, and are now fully supported as part of NGINX Plus.

Thread Pools

Using thread pools in NGINX Plus can give you 9x better performance. It’s well known that NGINX uses an asynchronous, event‑driven approach to handling connections. But the asynchronous, event‑driven approach still has a problem: blocking. On Linux, disk operations are blocking, so during operations that involve a lot of disk I/O NGINX can spend a lot of time blocking rather than doing productive work.

Allocating a pool of threads that handle disk I/O alleviates this problem. Instead of going to disk itself, the NGINX worker process hands off the I/O operation to an available thread in the pool and then goes back to processing traffic as usual. When the disk operation is complete, the NGINX worker process is notified and can continue whatever work remains to be done to satisfy the request.

To enable thread pools just add the aio threads directive to a location block:

location / {
    root /storage;
    aio threads;
}

For a thorough overview of thread pools in NGINX, please see this blog post.

Socket Sharding

Socket sharding was first introduced in NGINX 1.9.1. This feature leverages the SO_REUSEPORT socket option introduced in version 3.9 of the Linux kernel. When the option is enabled, the Linux kernel itself distributes new connections evenly across the NGINX worker processes in a round‑robin fashion. The worker processes then do the work of request limiting, caching, load balancing, and everything else you have configured.

Without SO_REUSEPORT, new connections are put up for grabs to all available worker processes. The first to take a connection off the queue gets it. As there is no algorithm for distributing the load evenly, it can easily get skewed, with a few worker processes taking the majority of the load while others are underutilized. Its also inefficient to have processes fight over packets, as this can lead to lock contention.

Socket sharding can improve performance up to 3x by ensuring work is distributed evenly among NGINX worker processes. To enable this functionality, add the new reuseport parameter to existing listen directives.

server {
    listen 12345 reuseport;
    # ...
}

To learn more about this feature, please refer to this blog post.

Note: This feature requires Linux kernel version 3.9 or later. Ubuntu 13.10 and later and Red Hat Enterprise Linux 7 and later include the required functionality.

Access Control and Security Enhancements

NGINX Plus R7 adds even more features to improve the security of your applications. This section provides an overview of those features.

TCP Access Control and Limiting

New features for TCP proxy and load balancing improve access control (limit by IP address), connection limiting (limit the number of concurrent connections per client or service), and bandwidth usage (limit the upstream or downstream bandwidth per connection). These features are already available for HTTP load balancing, and are used with great success for API metering and DDoS protection.

For more details, please see the related blog post, TCP Load Balancing in NGINX Plus R7.

NTLM Support

In response to popular demand, NGINX Plus R7 can proxy and load balance applications that use Microsoft NT LAN Manager (NTLM) for authentication. NTLM is an authentication protocol used by many Microsoft products, particularly with legacy applications.

Our support for NTLM fulfills the security requirement that connections to backend servers are kept alive but not multiplexed, so that each NTLM‑authenticated client has a unique dedicated connection to the backend server.

To enable NTLM support, add the ntlm directive in the configuration of HTTP upstream groups:

upstream backend {
    server 192.168.1.10;
    server 192.168.1.11;
    ntlm;
}

You can now confidently deploy NGINX as a proxy, load balancer, and HTTP/2 accelerator in front of Microsoft applications, supporting the widest possible range of client devices.

Improved Monitoring and Diagnostics

NGINX Plus provides detailed monitoring and statistics to make it easy to observe, optimize, and debug applications and infrastructure. Building on that capability, NGINX Plus R7 comes loaded with new counters and stats. These counters help you tune your NGINX Plus deployments, and make informed decisions about when you might need to scale up or out to handle more load. The new stats and counters are:

• 499 errors – Per‑server counter that tracks 499 errors, which occur when the client closes the connection before the backend server finishes processing its request. A few 499 errors are acceptable (people often close their web browsers in the middle of a session), but a large number can indicate that the server is overloaded and taking a long time to process requests.
• NGINX Plus worker restarts – The number of times the NGINX Plus worker restarted. This helps to detect crashes of the NGINX Plus worker process.
• NGINX Plus reloads – The number of times NGINX Plus was reloaded. This confirms that NGINX Plus was actually reloaded, or that a reload failed due to various reasons such as improper configuration.
• Queue overflows – Per‑server counter that measures how well a server handles load. A high number of queue overflows indicates a server that is struggling to keep up.
• SSL handshakes – The number of SSL handshakes completed.
• SSL sessions reused – The number of SSL sessions that were reused from an earlier session.
• New SSL sessions – The number of new SSL sessions negotiated.

Like all other counters, you enable the new counters by including the api directive in the configuration.

Updated, Interactive NGINX Plus Dashboard

The NGINX Plus dashboard is greatly improved in R7, displaying key system information in a concise format, even for large and complex configurations:

• A new Dashboard overview tab gives a complete, single‑page summary of NGINX Plus activity, and a summary of the health of your application.
• An interface on the dashboard enables you to temporarily add and remove servers in a load balancing pool, as well as temporarily mark servers as draining or inactive.
• New filters enable you to quickly drill down and find failed servers.
• A new tabbed view lets you quickly switch from the Dashboard tab to more detailed views of zones, upstreams, and cache information.
• Throughout the dashboard, new tool tips give more detailed information about upstream servers, configuration reloads, cache status, and any error messages.

To learn more, please see the related blog post, The New NGINX Plus Dashboard.

A Few More Goodies

NGINX Plus R7 has a number of additional enhancements that don’t fall into any of the above categories:

• Improved HLS streaming – NGINX Plus now supports the start, end, and offset arguments on HLS .m3u8 URIs. This allows content publishers to easily publish links to fragments of a video stream.

• Content modification – Previously, NGINX Plus could make just one simple content change to the content of a response, substituting one string for another. The sub_filter directive has been extended to support variables and chains of substitutions, making more complex changes possible.

  The expanded content‑modification capabilities make it easy to adapt web content, for example changing the method (https:// instead of http://), domain, or other path elements in hyperlinks in the message contents. You can also use it to insert content into HTML pages, such as boilerplate text or JavaScript snippets, without having to modify the original HTML content.

• $upstream_connect_time variable – A new NGINX variable that tracks the time it takes to connect to a backend server, making it easier to identify slow servers.
• Config dump – The new ‑T flag on the nginx command dumps the parsed NGINX configuration to stdout in a clear and standardized format. This is useful for archiving purposes or when filing a support ticket.
• More configurable TCP load balancing – The proxy_bind, proxy_protocol, and tcp_nodelay directives, and the backlog parameter to the listen directive, are now supported for TCP traffic (stream module) as well as for HTTP traffic. For more details, please see TCP Load Balancing in NGINX Plus R7.
• Redis support – The third‑party Redis module (lua-resty-redis) is now built into the nginx-plus-extras package. It enables NGINX Plus to interact with a Redis database (for example, to get and set values) and is fully supported as part of an NGINX Plus subscription.
• Updated Phusion Passenger module – The Phusion Passenger Open Source module has been updated to version 5.0.15.

Upgrading Phusion Passenger Open Source to Be Compatible with NGINX Plus

If you use Phusion Passenger Open Source with NGINX Plus (the passenger_root directive is included in your configuration), you must upgrade your Passenger runtime to version 5.0.15 at the same time you upgrade to the NGINX Plus R7 nginx-plus-extras package. Perform these steps (the commands are appropriate for Ubuntu):

1. Stop NGINX Plus:

   # service nginx stop

2. Upgrade your Phusion Passenger runtime to 5.0.15:

   # apt-get install passenger

3. Upgrade the NGINX Plus Extras package to R7:

   # apt-get install nginx-plus-extras

4. Make required updates to NGINX Plus configuration directives as described in the Phusion Passenger upgrade notes.

5. Start NGINX Plus:

   # service nginx start

Full installation and upgrade instructions are available at the NGINX Plus customer portal.

Upgrade or Try NGINX Plus

If you’re running NGINX Plus, we strongly encourage you to upgrade to Release 7 as soon as possible. You’ll pick up a number of fixes and improvements, and it will help us to help you if you need to raise a support ticket. Installation and upgrade instructions can be found at the customer portal.

If you’ve not tried NGINX Plus, we encourage you to try it out for web acceleration, load balancing, and application delivery, or as a fully supported web server with enhanced monitoring and management APIs. You can get started for free today with a 30‑day evaluation and see for yourself how NGINX Plus can help you scale out and deliver your applications.

Caveats

• NGINX Plus R7 no longer supports Debian 6, SLES 11 SP3, or Ubuntu 10.04 LTS or 14.10, because these distributions are no longer generally supported. Before upgrading to NGINX Plus R7, upgrade to a supported operating system distribution.
• NGINX Plus R7 is the last release that includes the nginx-plus-lua package; if you’re using that package, plan to migrate to the nginx-plus-extras package in NGINX Plus Release 8.
• Before installing the nginx-plus-http2 package, you must remove the spdy parameter on all listen directives in your configuration (replace it with the http2 and ssl parameters to enable support for HTTP/2). With the nginx-plus-http2 package, NGINX Plus fails to start if any listen directives have the spdy parameter.