This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why do we need apache under Node.js express web framework?
I wonder why I should install a server such as Nginx or Apache with Node.js. I used to think that the server can help me to handle cache control or something more. But I found out that the Connect static middleware already does it, right?
If you don't know why you need Nginx or Apache on top of Node.js, then you don't need it.
Nginx does a few things faster (and in some cases easier to configure) than Node.js: proxying, url rewriting, http caching, redirection, static file serving, and load balancing.
If you experience that your Node.js code for any of these roles are growing complex, or turn out to be performance bottlenecks, it's worth investigating. Until then, no need to bother.
Using stable and solid web server software as front end can bring several advantages. For example, you can use Nginx for load balancing. Furthermore, security risks can be reduced by not presenting your application server directly to the internet.
Related
Looking at the CKAN deployment documentation, there are several web server options:
Apache with the modwsgi Apache module proxied with Nginx for caching
Apache with the modwsgi Apache module
Apache with paster and reverse proxy
Nginx with paster and reverse proxy
Nginx with uwsgi
I'm wondering what the merits are of using Apache/modwsgi over Nginx/uwsgi, and how much value Nginx's proxying adds.
The core question, I guess, is if I wanted to avoid using two separate web servers in a single installation, what should I consider when choosing one or the other?
The CKAN Tech Team document one particular config: apache/modwsgi + nginx reverse proxy. They encourage people to use that, so that when difficulties occur we can fix them as a community.
I'm not clued up enough to give technical arguments between uwsgi and modwsgi. I think there are some CKAN sites on uwsgi and it being more modern there may be some technical advantages. However the installs I've worked with have mostly been apache/modwsgi + nginx reverse proxy. That's probably more down to familiarity and the blessing of the CKAN tech team than anything else.
However I believe nginx is better than apache2 for SSL/TLS termination. We found it was far simpler to configure SSL/TLS, with plenty of new best practices to keep up with in the past few years. And last time I looked several years ago there was an argument that the asynchronous design avoided e.g. slow loris attacks. So I think having nginx on your front-end makes a lot of sense.
You suggest having two HTTP servers is too much, but I think nginx is pretty low overhead and isn't usually a concern.
paster is a toy - no-one uses it for servers.
I would like to setup mod_security as a stand alone instance protecting Tomcat instances against web application attacks. Would anyone know the pros and cons of doing this via installing mod_security as an Apache module versus installing mod_security on a reverse proxy? Has anyone implemented mod_security in either of these fashions? And if so is one preferred over the other?
There's really no difference in your two options. What non reverse proxy would you install the module on to protect Tomcat?
The question doesn't really make sense as they are both the same to you.
If you already have an Apache server, then you install ModSecurity in one of two ways:
In embedded mode by installing ModSecurity as module in the existing Apache instance you already have. The advantages are that you won't have to set up a separate Apache instance, and that the ModSecurity will have access to the environment that Apache runs under (so can see environment variables for example or log to same log files).
In a reverse proxy mode. This involves setting up a separate Apache instance, with ModSecurity on it only, and funnel all requests through it, before sending on the requests to your normal Apache. The advantages here are a dedicated web server just for ModSecurity, so you will not share resources with your existing version of Apache, if it is already resource hungry. Disadvantages are that it doubles your infrastructure and the complications that brings.
Personally I prefer option 1.
However, as you want to set up a dedicated web server in front of TomCat, the two options are identical for you. The new instance of Apache (or Nginx) that you set up will be running it in embedded mode and will act as a reverse proxy to your Tomcat server.
Personally I always think it's best to run a dedicated web server like Apache in front of any app server like Tomcat - especially on a public facing website. Granted Tomcat does include a pretty good web server (called Coyote), which may serve most of your web server needs, but a dedicated web server like Apache is more geared towards serving static content and contains other features for performance and security which make it a better end point server (including the ability to run ModSecurity for example!).
And just in case there is any confusion, Apache is actually short for Apache HTTP Server, and is sometimes called Apache httpd after the process that it runs. It is Apache's most popular bit of software hence why the name gets shortened, but Apache actually have lots of bits of software (including Apache Tomcat - usually shortened just to Tomcat).
I have an old apache web server, with some security issues, that running an old application exposed by internet. Before upgrading apache version, I must perform a lot of tests in a dev environment. During this time I would put a reverse proxy (with last apache web server version) in front of this application.
This temporary workaround can resolve some old apache security issues or it is totally useless?
Thanks in advice and I'm sorry for my bad english.
This temporary workaround can resolve some old apache security issues ... ?
Yes, with "can" and "some" emphasized. A reverse proxy handles incoming requests and rewrites them in a canonical form, which is safer for the application server to parse. A reverse proxy can also reject malformed requests so that they never reach the application.
It might not resolve every security issue, but you imagine one that this would resolve. For example, if a specially crafted causes the older version to execute arbitrary code, while the new version would drop the request, then having the reverse proxy would help prevent this bug from affecting the application server.
It's not as much of a defense as using a web application firewall, but it's kind of related.
For a SaaS running on Node.JS, is a web-server necessary?
If yes, which one and why?
What would be the disadvantages of using just node? It's role is to just handle the CRUD requests and serve JSON back for client to parse the date (like Gmail).
"is a web-server necessary"?
Technically, no. Practically, yes a separate web server is typically used and for good reason.
In this talk by Ryan Dahl in May 2010, at 37'30" he states that he recommends running node.js behind a reverse proxy or web server for "security reasons". To elaborate on that, hardened web servers like nginx or apache have had their TCP stacks evolve for a long time in terms of stability and security. Node.js is not at that same level yet. Thus, since putting node.js behind nginx is easy, doesn't have many negative consequences, and in theory increases the security of your deployment somewhat, it is a good choice. At some point in time, node.js may be deemed officially "ready for live direct Internet connections" but wait for Ryan/Joyent to make some announcement to that effect.
Secondly, binding to sub-1024 ports (like 80 and 443) requires the process to be root. nginx and others automatically handle binding as root and then dropping privileges to a safer user account (www-data or nobody typically). Although node.js has system call wrappers in the process module to drop root privileges with setgid and setuid, AFAIK other than coding this yourself the node community hasn't yet seen a convention emerge for doing this. More on this topic in this discussion.
Thirdly, web servers are good at virtual hosting and in general there are convenient things you can do (URL rewriting and such) that require custom coding in node.js to achieve otherwise.
Fourthly, nginx is great at serving static files. Better than node.js (at least by a little as of right now). Again as time goes forward this point may become less and less relevant, but in my mind a traditional static file web server and a web application server still have distinct roles and purposes.
"If yes, which one and why"?
nginx. Because it has great performance and is simpler to configure than apache.
I currently have one server with nginx that reverse_proxy to apache (same server) for processing php requests. I'm wondering if I drop apache so I'd run nginx/fastcgi to php if I'd see any sort of performance increases. I'm assuming I would since Apache's pretty bloated up, but at the same time I'm not sure how reliable fastcgi/php is especially in high traffic situations.
My sites gets around 200,000 unique visitors a month, with around 6,000,000 page crawls from the search engines monthly. This number is steadily increasing so I'm looking at perfomrance options.
My site is very optimized code wise and there isn't any caching (don't want that either), each page has a max of 2 sql queries without any joins on other tables, indexes are perfect as well.
In a year or so I'll be rewriting everything to use ClearSilver for the templates, and then probably use python or else c++ for extreme performance.
I suppose I'm more or less looking for any advice from anyone who is familiar with nginx/fastcgi and if willing to provide some benchmarks. My sites are one server with 1 quad core xeon, 8gb ram, 150gb velociraptor drive.
nginx will definitely work faster than Apache. I can't tell about fastcgi since I never used it with nginx but this solution seems to make more sense on several servers (one for static contents and one for fastcgi/PHP).
If you are really targeting performance -and even consider C/C++- then you should give a try to G-WAN, an all-in-one server which provides (very fast) C scripts.
Not only G-WAN has a ridiculously small memory footprint (120 KB) but it scales like nothing else. There's work ahead of you if you migrate from PHP, but you can start with the performance-critical tasks and migrate progressively.
We have made the jump and cannot consider to go back to Apache!
Here is a chart showing the respective performances of nginx, apache and g-wan:
g-wan.com/imgs/gwan-lighttpd-nginx-cherokee.png
apache does not seem to lead the pack (and that's a -Quad XEON # 3GHz).
Here is an independent benchmark for g-wan vs nginx, varnish and others http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/
g-wan handles much more requests per second with much less CPU time.
NGINX is the best choice as a webserver now a days.
The main difference between Apache and NGINX lies in their design
architecture. Apache uses a process-driven approach and creates a
new thread for each request. Whereas NGINX uses an event-driven
architecture to handle multiple requests within one thread.
As far as Static content is concerned, Nginx overpasses Apache.
Both are great at processing Dynamic content.
Apache runs on all operating systems such as UNIX, Linux or BSD and
has full support for Microsoft Windows & NGINX also runs on several
modern Unix-like systems and has support for Windows, but its
performance on Windows is not as stable as that on UNIX platforms.
Apache allows additional configuration on a per-directory basis via
.htaccess files. Where Nginx doesn’t allow additional configuration.
Request Interpretation-Apache pass file System location. Nginx
Passes URI to interpret requests.
Apache have 60 official dynamically loadable modules that can be
turned On/Off.Nginx have 3rd Party core modules (not dynamically
loadable).NGINX provides all of the core features of a web server,
without sacrificing the lightweight and high-performance qualities
that have made it successful.
Apache Supports customization of web server through dynamic modules.
Nginx is not flexible enough to support dynamic modules and loading.
Apache makes sure that all the website that runs on its server are
safe from any harm and hackers. Apache offers configuration tips for
DDoS attack handling, as well as the mod_evasive module for
responding to HTTP DoS, DDoS, or brute force attacks.
When Choose Apache over NGINX?
When needs .htaccess files, you can override system-wide settings on
a per-directory basis.
In a shared hosting environment, Apache works better because of its
.htaccess configuration.
In case of functionality limitations – use Apache
When Choose NGINX over Apache?
Fast Static Content Processing
Great for High Traffic Websites
When Use Both of them -Together
User can use Nginx in front of Apache as a server proxy.