The Evolution of Nginx

The Evolution of Nginx

The brainchild of a Russian software engineer by the name of Igor Sysoev, Nginx is a free, open-source web server that was created with one primary purpose – to solve the C10K problem. The “C” in “C10K” stands for “concurrent,” and the “10K” denotes 10 thousand connections. The concept is used to describe the unpredictable behavior servers displayed when they had to process a large number of simultaneous connections back in the early 2000s.

Compared to the competition, Nginx had a completely different approach to solving the problem, and it became immediately apparent that it had cracked it. An asynchronous event-driven architecture meant that instead of creating a new process for every new connection, Nginx handled thousands of connections under a single thread. As a result, it could handle a much larger number of requests while significantly reducing the stress on the server’s hardware.

The following review includes essential information, such as:

From a small open-source project to one of the most popular web servers in the world

More than just a web server

Nginx’s quirky versioning scheme

Staying up-to-speed with the major shifts in the online world

What’s new in Nginx’s latest version?

Conclusion

The history of Nginx


From a small open-source project to one of the most popular web servers in the world

Nginx was launched in 2004, and initially, its adoption was relatively slow. The rising popularity of mobile devices, however, meant that soon, the number of simultaneous connections servers had to deal with was going up. Quite a few administrators saw Nginx’s performance benefits and started using it.

By 2011, Igor Sysoev was overwhelmed with the support requests he had to process. He left his job at Rambler, and he founded Nginx, Inc. A couple of years later, Nginx Plus, a paid version of the web server with a few additional features, was released, and the commercial success was so big that last year, Nginx, Inc. was acquired by F5 Networks for $670 million.

The popularity Nginx enjoys at the moment is remarkable. Although some sources claim that Apache is still clinging onto the lead, there’s no shortage of usage statistics according to which Nginx is the most widely used web server in the world at the moment.

Despite the fact that Nginx is notoriously capricious on Windows servers and despite the higher level of technical expertise required to set it up and configure properly, it has clearly won favors with many hosting companies and server administrators. Let’s see if we can figure out why.

More than just a web server

The same asynchronous architecture that makes Nginx such a well-performing web server also makes it incredibly versatile and perfect for a number of other tasks. Ever since the very beginning, Nginx has been used as a supplement to another web server.

In addition to serving content, Nginx has proven its worth as a load balancer, a reverse proxy, a mail proxy, and an HTTP cache. In other words, even when its use as a main web server is not possible for one reason or another, Nginx can still be very useful when you’re trying to improve the security and performance of your online projects.

Nginx’s quirky versioning scheme

Compared to some of its competitors, Nginx is a bit harder to install and set up. In addition to this, people trying to get to grips with it might be a bit confused by the peculiar versioning scheme.

At any given moment, administrators who want to download Nginx for their production servers can choose from one of two options. There is the Stable version (currently, the latest one is 1.18.0), and there is also the Mainline version (currently, the latest Mainline is 1.19.1).

The Stable version gets very few updates during its lifecycle. Only critical bug fixes and security patches are pushed to it. The Mainline version, on the other hand, gets all the exciting new features and changes as soon as they come out.

Every April, the Mainline version, along with all the updates it has received over the last twelve months, is forked and turned into the new Stable version. At the same time, a new Mainline version is created, and the developers start a new cycle of adding features and improvements to it.

The minor number (that’s the number after the first dot) of the Stable version is always even. The odd numbers are reserved for Mainline versions. In other words, the previous Stable version was 1.16, and the next one will be 1.20. In the same way, the previous Mainline version was 1.17, and the next one will be 1.21.

Ask which one you’re better off using, and you’ll get contradictory answers. What has come to be considered common sense in computer science dictates that you should always stick with the stable version, and many system administrators prefer it.

At the same time, however, Nginx’s developers themselves say that in addition to introducing new features, they have extensive debugging and quality assurance procedures for their Mainline version, which make it perfect for your production environment. Some system administrators agree and are pretty happy with the regular updates they receive.

Staying up-to-speed with the major shifts in the online world

Whichever version you pick, you can be pretty sure that your server will support the technology that a modern website needs to run. For example, Nginx started supporting HTTP/2 in September 2015, just a few months after the revision of the protocol was standardized. HTTP/2 Server Push support was introduced in 2018, and although HTTP/3 is still far from being ready, F5 Networks is already working on implementing it into Nginx.

Another significant shift observed over the last few years is the move towards HTTPS. The introduction of free SSL certificates meant that more people were willing to secure the connections between clients and servers, and Nginx has received the updates to ensure that these connections are fast and reliable. Support for OCSP Stapling, for example, was added back in 2012.

OCSP Stapling is a standard that allows clients to check whether or not a certificate is revoked without contacting the Certificate Authority (CA). This optimized communication flow can reduce connection speeds by up to 30%. In addition to this, Nginx has been optimized to work with the OpenSSL library and is constantly updated to ensure that all new features are supported.

What’s new in Nginx’s latest version?

Nginx hasn’t stopped evolving. Between April 2019 and April 2020, the Nginx team released 10 updates to the Mainline version, which carried 11 new features and 37 bug fixes. All these new updates are now available in the 1.18 Stable version.

Most of them are focused on giving administrators more flexible server management options. Changes to Nginx’s rate limiting functionality, for example, let admins process specific requests and connections even after the limit has been exceeded.

There’s also a Dry Run mode that allows them to accurately determine where the rate limit should be. In it, once the limit is reached, requests and connections are not blocked, but they are logged and stored for analysis later on.

Changes to the proxy directives give administrators more dynamic control over the speed with which Nginx reads and downloads data from a client or a proxy server, and a couple of updated directives let them capture useful proxy metadata.

Launched in May, Nginx’s latest Mainline version has already received a couple of updates of its own. In addition to a few bug fixes and minor tweaks, they brought client certificate validation with OCSP and a few new proxy features. The main milestone for Nginx 1.19 is the support for HTTP/3, which is expected to arrive before the next Stable version comes out in April of next year.

Conclusion

Nginx’s success is rooted in its radically different approach to the C10K problem, which also proved to be the answer to many other questions administrators had been asking for so long. The performance benefits and its versatility mean that it’s used by a number of large technology giants. And it’s really hard to beat that as a testament to its advantages over the competition.

The history of Nginx

  • Oct 2004 – Nginx 0.1.0 released
  • Jan 2005 – FastCGI module added to Nginx 0.1.14
  • May 2005 – SSI module added to Nginx 0.1.29
  • Jul 2005 – IMAP/POP3 Proxy module added to Nginx 0.1.38
  • Sep 2005 – IMAP/POP3 proxy support for SSL added to Nginx 0.1.44
  • Nov 2005 – Memcached module added to Nginx 0.3.12
  • Mar 2007 – Authenticated SMTP proxying support added to Nginx 0.5.15
  • Nov 2008 – Rate-limiting module added to Nginx 0.7.20
  • Feb 2009 – Preliminary IPv6 support added to Nginx 0.7.36
  • Mar 2009 – Preliminary cache support added to the proxy and FastCGI modules in Nginx 0.7.44 and 0.7.45
  • Apr 2009 – The first Nginx Windows binary release (version 0.7.52)
  • Jun 2010 – SCGI support added to Nginx 0.8.42
  • Apr 2011 – Nginx 1.0.0 released
  • Oct 2012 – OCSP Stapling support added to Nginx 1.3.7
  • Feb 2013 – Support for proxying WebSocket connections added to Nginx 1.3.13
  • Mar 2013 – Support for IPv6 backends by the mail proxy module added to Nginx 1.3.15
  • Apr 2014 -Backend SSL certificate verification and support for SNI while working with SSL backends added to Nginx 1.7.0
  • Mar 2015 – Client SSL certificate support in the mail proxy module added to Nginx 1.7.11
  • Apr 2015 – The Stream module (a key part of Nginx’s load-balancing functionality) added to Nginx 1.9.0
  • Sep 2015 – HTTP/2 support added to Nginx 1.9.5
  • Apr 2016 – OpenSSL 1.1.0 compatibility added to Nginx 1.9.14
  • Dec 2016 – Client SSL certificate verification in the Stream module added to Nginx 1.11.8
  • Aug 2017 – Support for mirroring requests added to Nginx 1.13.4
  • Feb 2018 – HTTP/2 Server Push support added to Nginx 1.13.9
  • Mar 2018 – gRPC support added to Nginx 1.13.10
  • Mar 2019 – Support for loading SSL certificates and secret keys from variables added to Nginx 1.15.10
  • Jun 2019 – Dry Run Mode added to Nginx’s rate-limiting module in Nginx 1.17.1
  • May 2020 – Client certificate validation with OCSP added to Nginx 1.19.0

 

Write a Comment

Required*