The labs on this site need JavaScript to run. The same content is written out below.

Learn › Networking › The big picture

From URL to response

What happens when you type a URL in the address bar and press Enter

While a browser opens a single URL, a DNS lookup, a TCP connection, a TLS handshake, an HTTP request, a reverse proxy, an application server, and a database take part one after another. Some steps can be skipped thanks to a cache or connection reuse.

Partly checked against real execution · The order of the steps and connection reuse were checked with curl; the part behind the proxy was not verified

Concepts in this lab

DNS

The system that translates a domain name (example.com) into the IP address that computers use to communicate. When you enter an address in a browser, the browser first asks this system for the IP address of that name and then connects to that IP address. Lookup results are cached for a certain time.

Web server and application server

A web server is a program that receives HTTP requests and either responds with static files such as images and HTML or forwards the requests to another server (Nginx, Apache). An application server (web application server) is a program that runs program code and builds a result for each request (Tomcat). A common setup puts a web server in front and passes requests on to the application server.

Reverse proxy

A server that receives client requests on behalf of internal servers, forwards them to those servers, and returns their responses to the client. The client does not know the actual servers directly. Its roles include distributing requests across several servers, handling TLS, caching, and protecting the internal servers.

CDN

A network that keeps copies of content on servers placed in many regions around the world and has a server close to the user respond. Static files such as images, video, and scripts are delivered faster, and fewer requests go to the origin server.

HTTPS and TLS

HTTPS is HTTP communication encrypted with TLS. TLS keeps third parties from seeing the content (confidentiality), keeps it from being changed on the way (integrity), and uses a certificate to check that the server you connected to is the real one (authentication). SSL is the protocol that came before TLS. It is now deprecated and only TLS is actually used, but the name SSL is still used alongside it by habit.

Three-way handshake

The three-step process used to establish a TCP connection. The client sends a connection request (SYN), the server sends its acceptance together with its own connection request (SYN+ACK), and the client acknowledges it (ACK). After both sides have confirmed that they can send to and receive from each other, data transfer starts.

Try these

• Default settings — A first visit. The request goes through every step.
• Second request to the same site — The DNS lookup and the connection setup are skipped.
• Static file — The web server (nginx) responds directly. The request does not reach the application server.
• Static file from a CDN — A server close to the user responds.

Running with the default settings

1. The browser splits the URL https://shop.example/orders into the scheme (https), the host (shop.example), and the path. Because the scheme is https, the browser will connect to port 443.
2. The browser does not know the IP address of shop.example. It asks a DNS server and gets the IP address back. The result is kept in the cache for a set time (the TTL).
3. The browser opens a TCP connection to port 443 of that IP address (the three-way handshake). This takes one round trip to the server.
4. In the TLS handshake, the browser verifies the certificate of the server and the two sides agree on the encryption keys. This takes one more round trip.
5. The browser sends the HTTP request over the encrypted connection. The request line and the headers (Host, Cookie, User-Agent, and so on) go to the server.
6. nginx is the first to receive the request. It decrypts the TLS traffic, looks at the path, and decides where the request will be handled.
7. nginx passes the request to Tomcat behind it (port 8080). Tomcat assigns a thread from its thread pool, runs the request through the filters, and hands it to the Spring DispatcherServlet.
8. DispatcherServlet finds the controller that handles /orders and runs it. The controller calls a service, and the service calls a repository.
9. The application borrows a connection from the connection pool, runs the SQL, and receives the result. Of the time spent inside the server, this is the largest part.
10. The application turns the query result into JSON or HTML and builds the response. The response travels back through Tomcat and nginx.
11. The response arrives at the browser. If it is HTML, the browser parses it, finds the URLs of the CSS, scripts, and images in it, and repeats the same process for each of them.

Result of this run

• On a first request, the DNS lookup, the TCP connection, and the TLS handshake all happen before the actual request. However fast the server is, these round trips do not go away, so keeping a connection open and reusing it (keep-alive, HTTP/2) has a large effect on how fast the site feels.
• In this example, 20ms of the 31ms the server spends goes to the database query. The real share differs from request to request. This is why, when you look into a performance problem, you start by breaking the request down to see which part takes the time.

Code

# nginx (reverse proxy)
server {
    listen 443 ssl;
    server_name shop.example;

    location /static/ {                  # serve static files directly
        root /var/www;
    }
    location / {                         # pass everything else to the application server
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

Assumptions of this model

The times are examples chosen to show relative sizes (30ms to reach the server once, 5ms with a CDN, 40ms for a DNS lookup, 20ms for a database query). Real values vary widely with the distance, the network, and the query. The setup assumes a common arrangement in which nginx handles TLS in front and passes requests to Spring Boot (embedded Tomcat) behind it. That the steps really happen in this order, and that the first three steps disappear when a connection is reused, was checked by sending two requests in a row to a public site with curl. In the first request, the DNS lookup was done at 27ms, the TCP connection at 60ms, and TLS at 156ms, and the first byte arrived at 194ms. The second request, sent over the same connection, showed 0 for DNS, TCP, and TLS and took 40ms in total. The part behind the reverse proxy was not verified directly.

Next lab: Layers and encapsulation