隆重推出 NGINX 1.10 和 1.11 版本

Owen Garrett of F5

产品管理高级总监

2016-04-26

Today we’re pleased to announce NGINX Open Source 1.10 and 1.11. These version numbers define our stable and mainline branches – the open source releases that we will focus on developing and improving for the next 12 months.

NGINX version 1.10.0 was released today, and the next feature release of our mainline branch will be numbered 1.11.0.

Explaining NGINX’s Version Numbering

NGINX, Inc. manages two branches of the well‑known NGINX Open Source web server and accelerating proxy:

• The odd‑numbered version (1.11) is the mainline branch. This branch is actively developed; new minor releases (1.11.1, 1.11.2, etc.) are made approximately every 4 to 6 weeks, regularly introducing new features.
• The even‑numbered version (1.10) is our stable branch. This branch is provided for users who don’t want to stay at the forefront of NGINX development, and is updated only when critical issues need to be fixed. For example, last year only one minor update was made to the 1.8 stable branch.

Each year, we deprecate the current stable branch and fork the current mainline branch to create a new stable branch that is supported for the following 12 months:

Choose the branch that best suits your needs. If you want to stay on top of new features, performance improvements, and updates, select the mainline branch, which (ironically) is generally more reliable than the stable branch. If you want to minimize the number of updates you need to deploy and don’t anticipate an urgent need for any of the features planned for the next 12 months, the stable branch is a good choice.

A best‑of‑both‑worlds option is NGINX Plus, with its quarterly release schedule, rigorous testing, and support from the NGINX team. NGINX Plus tracks the mainline branch, and benefits from in‑the‑field testing and user feedback on mainline branch features.

Looking Back on NGINX 1.9

Last year was one of the busiest years for development in NGINX’s history. It saw a number of new features and capabilities added to our mainline branch. HTTP/2, TCP and UDP proxying and load balancing, and dynamic modules were all added to the open source release in the last 12 months:

• HTTP/2 support: The SPDY module was replaced by the HTTP/2 module. HTTP/2 support was recently updated to support unbuffered reads for requests.
• The new stream module: The stream module lets you proxy and load balance UDP and TCP traffic. For example, you can now use NGINX to load balance DNS and MySQL servers.
• Support for dynamic modules: This allows modules to be distributed in separate packages with their associated dependencies, and allows you to install, update and maintain modules separately from the NGINX core. For example, in our official repositories we provide some features as dynamic modules, including our njs module which allows the use of JavaScript in NGINX configuration.
• The new slice module: The slice module improves the efficiency of caching large files that are accessed using byte‑range requests, by separating them into fragments that can be cached individually.
• sub_filter improvements: The sub_filter module was extended to support variables and multiple replacements in the response body.
• SO_REUSEPORT support: The new reuseport option in the listen directive provides significant performance improvements on multiprocessor systems during periods of high request rates.
• TCP support for DNS resolution: NGINX’ integrated DNS resolver now makes TCP lookups, failing back to TCP if a UDP response is truncated.
• Better handling of idempotent requests: added explicit controls to prevent the retry of non‑idempotent requests in the event of an upstream server failure, in the proxy_next_ustream, fastcgi_next_upstream, uwsgi_next_upstream and scgi_next_upstream directives.
• AIO and thread pools: Thread pools can now be used to asynchronously write files to the cache, configured using the directive aio_write. Check out the article “Improving performance using Thread Pools” for more information.
• Improved cache management: better tracking and management of in‑memory use as well as on‑disk use.
• Improved CPU affinity: the worker_cpu_affinity directive now has an automatic mode to bind worker processes to CPU cores, and now supports more than 64 processors.
• Include directive: The include directive can now be used inside an upstream{} block, giving you more options to template and build your configuration.
• Support for HEAD caching: The new proxy_cache_convert_head directive gives you control over whether HEAD requests are cached, or converted to and from GET requests.
• SYSLOG extensions: the new nohostname parameter prevents the hostname from being added to messages when logging to syslog.
• The realip module: The realip module now provides a $realip_remote_addr variable which contains the source address of the client TCP connection.
• Upstream conect times: The new $upstream_connect_time variable provides the time spent on the connect() to the upstream and the TLS handshake (if used).
• Memcached module: The memcached module now supports byte range requests.
• Shared data for upstreams: The upstream server block‘s state is now shared using a shared‑memory segment, allowing internal enhancements such as better sharing of health state between worker processes.
• Shared memory support in Windows build: Added support for shared memory to the Windows build of NGINX, enabling all functionality that depended on shared memory to be used on Windows.
• Mail proxy server: Support for the error_log directive in the mail{} block as well as the server{} block, allowing for different log settings.

Check out the release notes for a full list of changes in 1.9 – making this series of releases the most extensive development of NGINX in its recent history. The small number of changes that needed to be backported to the 1.8 stable release is a clear testament to the high standards of quality and reliability that our engineering team maintains.

We also hit a major milestone in NGINX adoption in 2015. Although we don’t set out to compete or take market share from other web servers, it’s gratifying to see a continued steady growth in the use of NGINX, and now more than 50% of the world’s 10,000 busiest websites rely on NGINX to deliver their applications and content to their audience.

Looking Forward to NGINX 1.11

The NGINX 1.11 release series also promises to bring significant advances. Work is already ongoing with a prototype JavaScript implementation, nginScript, specifically designed for the unique demands of the NGINX core. [Editor – nginScript is now called the NGINX JavaScript module.] We’re going to continue to foster an NGINX developer community, building on the milestone dynamic modules feature and the first part of the recently published developer documentation. The demands of modern, distributed, microservices applications are also driving part of our roadmap, and more will be shared at our annual user conference, nginx.conf, in September 2016.

What About NGINX Plus?

NGINX Plus is our commercially supported product, and adds a number of enhanced features that extend NGINX into the role of a frontend load balancer and application delivery controller (ADC). NGINX Plus tracks the mainline branch of NGINX and is generally released on a three‑month cycle. New features in the mainline branch are merged into NGINX Plus and released after they have passed full integration testing and have been proven in field deployments of NGINX:

Each NGINX Plus release is based on a specific version from the open source mainline branch, as noted at NGINX Plus Releases. To display the version number for an NGINX or NGINX Plus binary, run the nginx -v command:

$ /usr/sbin/nginx -v
nginx version: nginx/1.9.13 (nginx-plus-r9)

NGINX Plus gives you an ideal balance of the cutting‑edge features in NGINX Open Source, proven in the field, additional load‑balancing and enterprise‑focused features, and full 24×7 support and updates from our engineering team and product experts. Try it out for yourself – start your free 30-day trial today or contact us to discuss your use cases.