Courses Developer Fundamentals for Builders The HTTP Request Lifecycle

How Your Stack Actually Works

The HTTP Request Lifecycle

What actually happens when someone visits your Laravel app

12 min read · Lesson 1 of 18

The Invisible Journey

Every time someone types your URL into a browser and hits Enter, an intricate chain of events fires off. It happens in milliseconds, but understanding each step transforms you from someone who deploys code and hopes it works into someone who can diagnose why it doesn't.

Let's trace the full journey of a request to your Laravel app at https://yourapp.com/dashboard.

Step 1: DNS Resolution — Finding the Server

The browser doesn't know what yourapp.com means. It needs an IP address — the actual numerical address of your server. This is where the Domain Name System (DNS) comes in.

DNS works like a phone book. The browser asks a series of DNS servers: "What's the IP address for yourapp.com?" The query cascades through multiple levels:

  • Browser cache — Did we look this up recently? If yes, use the cached answer.
  • OS cache — The operating system maintains its own DNS cache.
  • Router cache — Your home router caches DNS responses too.
  • ISP's recursive resolver — Your internet provider's DNS server does the heavy lifting.
  • Root → TLD → Authoritative — If nobody has it cached, the query walks down from root nameservers (.com) to your domain's authoritative nameserver (e.g., Cloudflare, DigitalOcean).

The result: an IP address like 159.65.218.100. Your browser now knows where to send the request.

When you update DNS records (like pointing a domain to a new server), the delay you experience is DNS caches expiring. The TTL (Time To Live) value on your DNS records controls how long caches hold stale data.

Step 2: TCP Connection — Establishing the Channel

Now the browser needs to establish a reliable connection to the server. This uses the Transmission Control Protocol (TCP), which guarantees that data arrives in order and without corruption.

TCP uses a three-way handshake:

  1. SYN — Client says: "I'd like to connect."
  2. SYN-ACK — Server says: "Acknowledged, I'm ready."
  3. ACK — Client says: "Great, let's go."

This takes one round trip. On a server 50ms away, that's 50ms just to shake hands. This is why server location matters — a server in New York responding to a user in Tokyo has significant latency just from the physics of the speed of light through fiber optic cables.

Step 3: TLS Handshake — Encrypting the Connection

Since you're using HTTPS (you are using HTTPS, right?), there's another handshake on top of TCP: the TLS handshake. This is where the browser and server agree on encryption.

In simplified terms:

  1. The browser says hello and lists which encryption methods it supports.
  2. The server responds with its SSL certificate (proving it is who it claims to be) and its chosen encryption method.
  3. Both sides derive a shared secret key using asymmetric cryptography.
  4. All further communication is encrypted with this key.

TLS adds another round trip (or sometimes two). With TLS 1.3 (the current standard), this has been optimized to a single round trip. This is why your Let's Encrypt certificate and modern TLS configuration matter — they're not just about security, they affect performance.

Step 4: The HTTP Request

Finally, the browser sends the actual HTTP request. It looks something like this:

GET /dashboard HTTP/1.1
Host: yourapp.com
Accept: text/html
Cookie: laravel_session=abc123...
User-Agent: Mozilla/5.0 ...

The key components:

  • Method — GET, POST, PUT, PATCH, DELETE. GET retrieves data, POST sends data. Laravel routes map directly to these.
  • Path — /dashboard. This is what Laravel's router matches against.
  • Headers — Metadata: cookies (session info), content types, authentication tokens.
  • Body — For POST/PUT requests, the actual data being sent (form fields, JSON payloads).

Step 5: The HTTP Response

Your server processes the request (we'll cover exactly how in the next two lessons) and sends back a response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Set-Cookie: laravel_session=xyz789...

<!DOCTYPE html>
<html>...

The status code is the first thing to check when debugging:

  • 200 — OK. Everything worked.
  • 301/302 — Redirect. The resource moved (permanently or temporarily).
  • 403 — Forbidden. You're authenticated but not authorized.
  • 404 — Not Found. The route doesn't exist or the model wasn't found.
  • 419 — Page Expired. In Laravel, this almost always means a CSRF token mismatch.
  • 422 — Unprocessable Entity. Laravel validation failed.
  • 429 — Too Many Requests. Rate limiting kicked in.
  • 500 — Internal Server Error. Your code threw an unhandled exception.
  • 502 — Bad Gateway. Nginx couldn't reach PHP-FPM (process crashed or isn't running).
  • 503 — Service Unavailable. Laravel is in maintenance mode, or the server is overloaded.
Memorize the Laravel-specific status codes: 419 (CSRF), 422 (validation), 429 (throttle). When you see these in production logs, you'll know exactly what happened without digging through code.

Key Takeaways

  • A single page load involves DNS lookup → TCP handshake → TLS handshake → HTTP request → HTTP response.
  • Each step adds latency. Server location, DNS TTL, and TLS version all affect performance.
  • HTTP status codes are your first debugging tool — learn what Laravel's specific codes mean.
  • Understanding this lifecycle helps you diagnose issues that have nothing to do with your PHP code — DNS misconfiguration, expired certificates, firewall rules, and load balancer problems.

Next →

Nginx, PHP-FPM, and OPcache
Back to Course Overview
Ask about this lesson