CloudAcademy

NGINX Core - Server Selection

Developed with
NGINX

The course is part of this learning path

Getting Started With NGINX
course-steps 1 certification 1
play-arrow
Start course
Overview
DifficultyIntermediate
Duration50m
Students181

Description

Introduction
This course provides an overview of NGINX, it's primary use cases, and key features.

Intended Audience
This course is intended for people who need to be familiar with NGINX use cases and the high-level capabilities it brings to its end users.

Course Overview
We start by exploring the origins of NGINX in the "Getting Started Module". 
Next, we learn how to go about installing NGINX on various operating systems and with different options.  
In Module 2, 3, and 4 we explain the basics of the configuration language of NGINX  - and how to set up NGINX as a Web server.  

Prerequisites 
In order to get the most out of the course, you need to have a general understanding of Web servers and how they work.  To work with NGINX Plus on the command line, you need to be familiar with Linux and how to move between directories on the command line.  You also need to be able to edit files with a command-line editor such as nano, vi or vim.  Our labs use the vim editor.  You need to understand the basics of HTTP and TCP/IP, and you should also have a basic knowledge of networking.

Learning Objectives
After completing this course you will be able to: 

  • Describe the most common use cases of NGINX
  • Describe the differences between NGINX F/OSS and NGINX Plus
  • Execute basic NGINX commands
  • Locate your NGINX configuration file(s)
  • Describe the role of contexts, blocks, and directives in your configuration file(s).
  • Identify the server block that will respond to a request
  • Identify the location block that respond to requests, identify location processing rules, and configure a simple web server that serves static pages and images.

 

 

 

 

Transcript

- [Presenter] Welcome to module 3 of the NGINX Core e-learning course. This module covers the server context. After completing this module, you will be able to identify the server block that will respond to a request. Now that you understand the directive types and basic inheritance models, let's discuss how NGINX selects a server block to process a request and server response. The two main steps are server selection and request/response handling. For server selection, NGINX selects a server block based on the listen directive and/or the server name directive. The listen directive represents an IP address or port interface and the server name directive represents a domain or host name. The listen directive defines the listening IP address and port for a virtual server. 

NGINX applies default values where directives are missing values. When NGINX processes a request, it first looks at the IP and port definition of the request and attempts to match it against a listen directive. The listen directive can be set to a standalone port interface, an IP address and port combination, a standalone IP address, a UNIX socket. This last option generally only applies when passing requests between application servers. If no listen directive exists, the server will listen on port 80 by default. NGINX translates all incomplete listen directives by substituting missing values so that it can resolve each server directive by an IP and port. So some examples of these translations are a server with no listen directive uses the value 0.0.0.80. The 0.0.0.0 IP address means listen on all IP addresses. A server with a fully defined listen directive of 127.0.0.1:8080 uses that address. 

A listen directive set to an IP address, 127.0.0.2, with no port, becomes 127.0.0.2:80. A listen directive set to a port 80 with no IP address becomes 0.0.0.0:80. When using a UNIX socket, you must indicate an absolute path to that socket. NGINX attempts to collect a list of server definitions that match the HTTP request headers based on IP and port. A listen directive using 0.0.0.0 as the IP, which means it essentially matches any interface, is not selected if there are matching listen directives that list specific IP addresses. Note that if there are multiple listen directives, one specifying an IP, the other a port, the IP address always wins. In this example, imagine we have requests one through four as shown on the left side of the slide. Which server block will serve the correct response for each request? Answer, the first server block serves the response to the first request because it's an exact match and NGINX always chooses the highest level of specificity in terms of matching. The second server block serves the response to the second and third requests. Even though the third request specifies port 80, the IP is a match for the second server. And because NGINX substitutes default values, the second server block actually listens on port 80. The third server block serves the response to the fourth request only if the domain, example.com, doesn't resolve to the IP address, 192.168.1.10 when resolved through the domain name system. The server name directive examines the host header field of an HTTP request. 

The host header typically contains a domain name which resolves to an IP address stored in the domain name system. NGINX only evaluates the server name directive when the listen directive contains the same level of specificity in terms of IP and/or port definitions in its configuration file. For instance, if the client makes a request for example.com, but NGINX detects two virtual servers listening on the same IP, it then examines the host header field in order to determine a correct match. And in this example, it uses the second server block because its server name directive is an exact match for the host header, example.com. The server name directive is used to provide additional specificity. NGINX selects the longest-matching server name to respond to a request. If there is no match for a server name, NGINX cycles through its selection rules. In order, they are: an exact string match. If there are multiple exact string matches, NGINX selects the first one in the configuration file. If NGINX finds no exact match, it checks for leading wildcards in the server name, If NGINX finds no leading wildcard match, it checks for the trailing wildcards in the server name. If NGINX can't find a trailing wildcard match, it checks against the first Perl regular expression match. In this example, the request is host1.example.com. The host header field is an exact match of the second server's server name directive, so the second server block serves the response. However, if the request were www.example.com, then the first server block would serve the response. In this example, the request is www.example.org. There is no exact match, so NGINX uses the second server block because it contains a match for a leading wildcard. Even though the third server block is technically correct, the second server block is a more specific match than the third server block. If there is no leading wildcard match, NGINX then checks against trailing wildcards. If there are no exact or wildcard matches, NGINX checks next against Perl regular expressions. Regular expression matching behaves differently than exact or wildcard matches. Instead of finding the most specific or best match, regular expressions execute in the order they appear in the configuration. Therefore, in this example, even though the second server block is a more specific regular expression, the first server block is a valid match and serves the response as a result. The default server parameter is a parameter of the listen directive. It defines which server block acts as the default server block. The default server block serves a response when NGINX can't determine the correct server block based on either listen or server name directive values. If there is no default server parameter defined on any listen directive, NGINX selects the first server block in the configuration to serve the response. The reason default server is a parameter of the listen directive rather than the server name directive is that NGINX checks the host header field second. Therefore, NGINX needs an IP address to fall back to in case the host header field value is empty, or doesn't match any server name directive value. 

In summary, the listen directive defines the IP port combination the virtual server listens on. NGINX substitutes missing values in the listen directive. When the listen directive is evaluated, IP takes precedence over port. The server name directive examines the host header of a request and matches to the longest matching server name. The server name is only used when the IP port combination in the listen directive matches more than one server. The default server parameter is a parameter of the listen directive, and defines which server block acts as the default server. The default server block serves a response when NGINX can't match the correct server block based on either the listen or server name directive values. Thank you for watching module three of the NGINX Core e-learning course.

About the Author

Students50474
Courses76
Learning paths28

Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe.  His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups. 

Covered Topics