When it comes to the age-old web question, there should be the one that asks the differences between an Apache HTTP server and Nginx, the two most popular open source web servers powering the internet.
Both are solid and powerful, and both are built using any technology developed on any occurring time. But just like any products out there, there are advantages and also disadvantages.
Apache has been around longer that Nginx, but that didn't make it good enough in some criteria and circumstances. And Nginx that was built from ground up with speed in mind, doesn't manage things quite as good as Apache.
Apache was the backbone of the first generation of the World Wide Web. It became the industry standard for web serving, almost as soon as it debuted to the market. It was created when the web was still young and pages were simple. In short, Apache is more mature that Nginx.
But Nginx thrives from the limitation of Apache because it was specifically written to address the performance issues on servers running Apache. Nginx was designed for high concurrency - a scaling solution to help websites manage and maintain high volume of traffic using its event‑driven architecture that can work on connections simultaneously.
While Apache is more like a fully-loaded gun, Nginx is more like a combat knife that has a power to make a difference if used correctly.
So if you're considering to choose which is the best web server for you, the first thing to do is to know what they are and how they work. Both Apache and Nginx have their own limitations. And to correspond to the modern web, the two behaves differently when given a task.
Apache
Apache began its life at the end of February 1995 when eight core contributors including Robert McCool, started Apache as a fork of the NCSA codebase. Working loosely together, they eventually rewrote the entire original program to create Apache HTTP Server.
McCool was the author of the original NCSA HTTPd web server. He created Apache based on the NCSA HTTPd server after his work on the NCSA code stalled. Until Apache version 2.2, the httpd.conf files as distributed contained comments signed with his name. McCool was the one that wrote the first version while he was an undergraduate at the University of Illinois at Urbana–Champaign, where he was working with the original NCSA Mosaic team.
The "Apache" name was taken from a respect to the native American tribe Apache, and it was widely believed that it was also a pun on 'A Patchy Server'.
Apache is developed and maintained by an open community of developers under Apache Software Foundation (incorporated in 1999). The software is commonly used on Unix-like system. But besides Unix (usually Linux), Apache can also run on other operating systems, including Microsoft Windows.
Since the HTTP web server is the foundation's original project, Apache played a key role in the initial growth of the World Wide Web. Apache has become, and has remained the most popular web server software since April 1996.
In 2009, it became the first web server software to serve more than 100 million websites, and in 2016, it serves roughly 45 percent of all active websites in the world.
Because of this popularity, Apache benefits from great documentation and integrated support from other software projects.
Connection Handling
To handle connections, Apache has a variety of multi-processing modules called MPMs. These modules dictate how requests should be handled, and allows administrators to set up its connection handling architecture.
The MPMs include: mpm_prefork, mpm_worker and mpm_event.
Serving Contents
Apache handles static contents using its conventional file-based methods. For dynamic contents, it embeds a processor of the language the content uses, into its workers. This allows Apache to execute dynamic contents straight within itself without having to rely on external processor or components.
Its ability to handle both static and dynamic contents internally means that the setup and configuration is simpler to Nginx.
Configuration
Apache has an option to allow additional or customized configuration per-directory level. These are done using files known as .htaccess.
Residing inside directories, Apache will first check for the files' existence before serving any contents. If a .htaccess file is found, Apache will apply the directives within, to the path where the file exists. This allows Apache to run a decentralized configuration, away from the web server's default configuration.
By having the ability to understand directory-level configurations, Apache is more flexible if compared to Nginx. For certain web software, like Content Management Systems (CMS) for example, administrators can configure certain parts of the website behave from its server's path.
Interpreting Requests
Apache has the ability to interpret a request as a physical resource on the filesystem or as a URI location. For example, Apache can use
For Apache, the default to interpret requests is to have process them as filesystem resources. Because Apache was designed and built from ground up as a web server, it begins by taking the root of a document to then append the portion of the request following the host and the port number in order to find what it is looking for.
Here, Apache's filesystem hierarchy is represented as a document tree.
When a request doesn't match the underlying filesystem, Apache can use the Alias directive to map the request to an alternative location. Using the
Modules
Apache's modules can be loaded or unloaded dynamically. While the Apache's core is always on, additional functionality using modules can be turned on or off in the running server by hooking them into the main server.
Modules are used for a variety of tasks. And as Apache matures, the library of modules have been expanded to include more functionalities. From the ability to alter how the server work, to rewriting URLs, authenticating clients, logging, caching, compression, proxying, encrypting and more.
By using dynamic modules, administrators can extend Apache's core functionality by far, with ease and in no time.
Support And Documentation
Apache is the most popular web server, and it has hold that title for a long time. For that reason, Apache is fairly ubiquitous.
From its main website to many other third-party resources, documentations are plenty. There are also many tools and web projects that can bootstrap themselves with Apache in no time. T
In general, Apache is having more support from both the community and other third-party projects due to its massive popularity and the length of time it has been available.
Nginx
Its history began when Igor Sysoev began its development in 2002 to answer the C10K problem. The challenge was creating something for a web server to handle tens of thousands of concurrent connections. Originally, Nginx was a project developed to fill the needs of websites that include Rambler which was serving more than 500 requests per day.
The initial public release for Nginx was in 2004, meeting this goal by relying on an asynchronous, events-driven architecture. Nginx was then established as a company with the same name on July 2011.
Nginx has grown in popularity and is having its own fans, especially due to its light-weight resource utilization and its ability to scale easily on minimal hardware. For that reason, it's often the choice for administrators that aim for resource efficiency and responsiveness of website under load.
Nginx is released under the terms of a BSD-like license. It's a free and open source software that runs on Unix, Linux, BSD variants, OS X, Solaris, AIX, HP-UX, and Windows.
As a software for web servers, Nginx can act as a reverse proxy server for TCP, UDP, HTTP, HTTPS, SMTP, POP3, and IMAP protocols, as well as a load balancer and an HTTP cache.
Connection Handling
Nginx was designed from the ground up to use an asynchronous and non-blocking, event-driven connection handling algorithms.
To handle requests, Nginx has worker processes with each having the ability to handle thousands of connections. The worker processes requests by implementing a fast looping mechanism that continuously checks and process events. By decoupling the actual work from the connection, Each Nginx's worker can work all by itself by only needing a connection when there is an event triggered.
Because each connections are handled within an event loop, they can exist with other connection simultaneously. And because within the loop the events are processed asynchronously, they can be handled in a non-blocking manner.
For this reason, Nginx can scale and work faster even with limited resources. And because Nginx is single-threaded, the server isn't required to handle processes on each new requests, saving CPU and memory usage, even at heavy load.
Serving Contents
Nginx can serve static content in a straight-forward manner and the interpreter will only be contacted when needed. Apache can also function in this manner, but doing this will remove some of its benefits.
Where it excels in one place, it lacks in another. Nginx that is resource-friendly, doesn't have the ability to process dynamic content natively. To handle PHP and others that request dynamic contents, Nginx must first pass them to an external processor for execution.
Before anything can happen, Nginx should wait for the rendered contents to be sent back to it.
To make Nginx work with dynamic contents, administrators must first configure the communications between Nginx and the external processors to use the protocols that Nginx understands.
Setting this up requires more time that configuring Apache to do the same exact thing.
Configuration
Nginx is less flexible in terms of configuration. For example, it doesn't interpret .htaccess files. But that is for its own advantage.
Without having to understand the directory-level configuration, performance is increased. Typical Apache allows
Another advantage for not interpreting directory-level configuration, is security. Configuration access also poses security risks to individual users. A failed configuration can make others take control of the entire web server, or can prevent the access to third-parties that needed it.
Turning off the .htaccess interpretation in Apache is possible.
Interpreting Requests
Nginx was designed as a web server, and a proxy server. By having two architecture type, Nginx works with URIs, and also filesystem when needed. But because Nginx prioritizes URIs, Nginx doesn't provide the straight mechanism to specify the configuration for a filesystem directory because it parses the URI itself.
This way, Nginx can parse requests primarily as URIs instead of filesystem locations, and this allows it to function more easily on the web, mail and proxy servers.
Nginx is configured by laying out how to respond to different request patterns, and won't check for filesystems until it's ready to serve the request. This way, Nginx can work faster then Apache, and also doesn't need to interpret any .htaccess files.
Modules
Nginx has an array of modules, but they aren't dynamically loadable. To enable a module, administrators must first select and compile the module into the core software to run it.
Unlike Apache, this makes it less flexible. Especially to administrators that are already used to maintaining their certain types of software outside their distribution's conventional packaging system.
However, because Nginx's modules run inside the core software, administrators can dictate what they want straight inside the server by only including the functionality they are intending to use. Because the modules are not hooked, they tend to be more secure.
The functionalities of Nginx modules are similar to Apache's. For example, they can provide supports for proxying, compression, logging, rewriting, authentication and more.
Support And Documentation
Nginx is still growing, and it's experiencing an increased support as more users are using it. But if compared to Apache, Nginx has more to catch up.
Previously, documentations about Nginx weren't that comprehensive due to the fact that most of the early Nginx were Russian. But as interest to the project increases, the documentations have grown to include many more languages.
Administrators can get them on the Nginx website or from third-party websites.
As for support, Nginx can work straight out of the box with other software.
Conclusion
Apache is often chosen by administrators for its flexibility, power, and widespread support. It is extensible through a dynamically loadable module system and can process a large number of interpreted languages without connecting to separate software.
From the places it lacks, Nginx excels Apache at serving static content quickly. What's more, it was designed from ground up to pass dynamic requests off to other software that is better suited for those purposes.
So this is where the main differences between Apache and Nginx: the actual way they handle connections and traffic. This provides perhaps the most significant difference in the way that they respond to different traffic conditions.
Both Apache and Nginx are powerful and flexible. Deciding which server is best for you requires you to evaluate your specific and unique requirements, including the understanding and having test results with patterns you are expecting to see.
The differences between the two can create a big impact to your project's raw performance, capabilities and time needed to make things running. However, any advantage given by either one of the software, is the result of a trade off from another.
Comparing Apache to Nginx is like the equivalent to comparing a knife to a gun. It doesn't matter which one you choose because either can help you on the World Wide Web. But it does matter when you know what battle you're about to face and what items you need to bring with you.
In the end, there is no one-size-fits-all web server, so use the solution that best aligns with your objectives.
Apache and Nginx, Together
While the two works similar but differently, they can benefit each other by working together. This way, they can fill each other's limitation. The conventional configuration for making Apache and Nginx to work together, is by placing Nginx in front of Apache as a reverse proxy.
This configuration allows Nginx to to handle all requests from clients. Because Nginx's fast processing speed and ability, it can handle large number of requests and connections concurrently. This takes advantage of Nginx's fast processing speed and ability to handle large numbers of connections concurrently. For static contents, this is where Nginx's advantages can be put to the max.
As for Apache, it can work alongside Nginx by providing assistance in serving PHP files which are for dynamic contents. This way, Nginx will proxy the request to Apache, which will then process the results and return the rendered page. Nginx can then pass the content back to the client.
This configuration works for many websites because it allows Nginx to work as a sorting machine that handles all requests it can and pass the rest that it can't. This will reduce the requests Apache needs to handle.