NGINX 101: Web Server and Reverse-Proxy Cache

Editor's Notes

• #2 Hello everyone and welcome to this 101 level NGINX webinar! My name is Alessandro Fael Garcia and I am a Senior Solutions Engineer and I am accompanied by Amir Rawdat, Technical Marketing Engineer! In today’s webinar, we will cover how to use NGINX as a web server and reverse proxy cache at a very basic level. So let’s get to it, shall we?
• #3 You all probably have heard about NGINX before, that’s why you are here! But just to give a brief recap – NGINX was created in 2004 and quickly gained popularity as the fastest web server within the community. Over the years, its popularity has kept on increasing, and as of today, it’s the number 1 webserver in the world. But over time, besides its popularity, its feature set has also exponentially increased. Today, NGINX is used for a wide range of use cases, one of them being proxy caching.
• #4 And there’s good reason for it! NGINX is like the Formula One car of web servers and reverse proxies. Its performance is unparalleled!
• #5 With one of our most recent third-party benchmarks indicating that when configured as a reverse proxy, NGINX outperforms competitors by over a 1500%! NGINX vs AWS API Gateway vs Kong Fully Managed Solutions at 5,000 rps. Single Node – One API Endpoint. https://www.nginx.com/blog/benchmarking-api-management-solutions-nginx-kong-amazon-real-time-apis/
• #6 Now that you know a little bit more about NGINX, let’s switch gears to the main topic of the webinar and let’s start by covering what exactly is a web server. When you go to nginx.com, what actually happens behind the scenes is that your browser, say Chrome, finds the IP of the nginx.com url and then queries the web server hosted at that IP. The web server in turn returns all the content necessary to display the nginx.com website. This content can be static such as HTML/CSS and image files, or dynamic, such as is the case with PHP scripts.
• #7 A reverse proxy is an intermediary system that forwards and routes requests to multiple servers across the internet. They are  It provides additional traffic control in between clients and servers. Common use cases for a reverse-proxy server include:  Load-balancing and path-based routing:A reverse-proxy server can act as a load balancer where it can distribute traffic to a pool of upstream servers. Reverse-proxy servers can also route traffic based on HTTP attributes (such as path uris and headers)  Security and anonymity:  When your upstream applications are fronted by a reverse-proxy thenall incoming requests go through the reverse proxy. Client requests don’t have direct access to the upstream servers and their respective addresses, adding an additional layer of defense against security attacks, and masking client identities originating the requests. Go through your personal use case. Web acceleration: Reverse-proxy can cache commonly requested content (We will get into caching in the next slide). It can also compress inbound and outbound data, both of which can speed up traffic flow in between client and server. They can also perform other important tasks (such as TLS encryption) and offload the task of having to decrypt the data from your upstream applications.
• #8 Caching refers to storing data in a location (closer to the client that is requesting the information) to speed up communication between that client (say a web browser) and upstream applications (whether that be your web servers or application servers).  Caching can be especially useful for serving repetitive requests that return static or infrequently changing data (such as an image, html/css file, etc...). By storing that information locally on the reverse-proxy, it can be delivered to the client considerably faster than if it had to be retrieved from the origin backend server (reducing one hop for the request).   Caching can also help insulate clients from upstream server outages, by delivering previously cached content.  If the data the client requested is not available in the cache, it will be retrieved from the origin upstream server and added to the cache so that the next user requesting the same data, will be able to retrieve it from the cache. Once data is cached, it may become stale over a certain period of time.  The reverse-proxy cache can refresh the content with the latest data from the origin server. This is to ensure that the client will receive the most up to date content from applications.  A cache can be located anywhere in between the client and upstream applications. Caching dynamic/static content originating from the upstream applications will require configuration of NGINX caching on the system fronting those upstream applications (Which will be the reverse-proxy cache).     
• #9 You can significantly reduce operational complexity by consolidating app delivery capabilities into one NGINX deployment (The intermediary system in the middle here). NGINX can be deployed in such a way that accomplishes multiple use cases at a time. Reverse-proxy and load balancing: Route and distribute traffic to upstream applications Caching: Improving performance and availability of content provided by upstream applications WAF: Protect your upstream applications from layer 7 attacks (SQL injection, Cross-Site Scripting, Information leakage vulnerabilities, etc...) API Gateway: monetizing and publishing your native APIs running in hybrid environments (Both internal and external running services if the cluster) Web Server: Host your static and dynamic web content
• #10 Time for a demo!
• #12 While almost all we’ve covered today will work if you use NGINX Open Source, if you'd like to take NGINX Plus for a spin and check out some of it’s more useful features such as the live activity dashboard, you can request a 30 days free trial for NGINX Plus at nginx.com/free-trial-request!
• #13 Thanks for attending!