The Internet - The Gateway

Let's break down the process and understand what happens when a request flows through Nginx (acting as a reverse proxy and SSL terminator) to a NetGet gateway, which then handles the application routing.

Step 1: Request Reaches Nginx

When a user visits https://this.neurons.me/hello, the request first reaches the Nginx server. Nginx is configured to listen for incoming traffic on ports 80 (HTTP) and 443 (HTTPS). Since the user is accessing the site over HTTPS, the request comes in on port 443.

Step 2: SSL Termination

Upon receiving the request at port 443, Nginx decrypts the traffic. This process is known as SSL termination. Nginx uses the SSL certificate configured for this.neurons.me to decrypt the request, ensuring that the communication between the user's browser and the Nginx server is secure.

The main benefits of SSL termination at the Nginx level are:

• Offloading the encryption and decryption process from the backend (NetGet Gateway), which can now handle more requests without dealing with SSL overhead.

• Centralized management of SSL certificates, especially beneficial when you have multiple applications or services behind the same Nginx instance.

Step 3: Request Forwarding to NetGet Gateway

After decrypting the request, Nginx forwards it to the NetGet Gateway. This forwarding is typically done over HTTP within the same server or network, and it's directed to the specific port where the NetGet Gateway is listening (let's say port 3000).

The forwarding rules are defined in Nginx's configuration, using the proxy_pass directive. Here, Nginx acts as a reverse proxy, directing the incoming request from this.neurons.me to the appropriate application or service based on the request URI and host headers.

Step 4: NetGet Gateway Handles the Request

The NetGet Gateway receives the request on port 3000. It examines the hostname (this.neurons.me) and path (/hello) to determine which application or handler should process the request.

Assuming you have a configuration that maps this.neurons.me to a specific handler or application, the NetGet Gateway invokes this handler, passing the request data. The application processes the request and generates a response.

Step 5: Response Travels Back to the User

The response from the application is sent back to the NetGet Gateway, which forwards it to Nginx. Nginx, in turn, sends the response back to the user's browser over the secure HTTPS connection. Even though the internal communication between Nginx and the NetGet Gateway might be over HTTP, the user sees a secure HTTPS connection because the SSL encryption is reapplied by Nginx when sending the response back to the user.

Domain Names and HTTPS:

• Domain Names: Nginx uses the server_name directive to match the incoming requests to the configured server blocks. It allows Nginx to route requests for this.neurons.me to the appropriate proxy_pass destination (the NetGet Gateway).

• HTTPS: The user's browser maintains a secure connection with Nginx, not directly with the NetGet Gateway. As far as the user is concerned, they have a secure HTTPS connection with this.neurons.me. The SSL certificate details, including the issuer, expiration, and the secure lock icon, will all be visible in the browser, assuring the user that their connection is secure.

By setting up your infrastructure this way, you benefit from centralized SSL management, reduced complexity in application servers (which don't need to handle SSL), and a clear separation of concerns, where Nginx handles web serving and SSL, while the NetGet Gateway focuses on application routing and logic.