# Request and Response Lifecycle

> Learn how HTTP requests travel from browser to server and back. Understand DNS resolution, TCP connections, request/response flow, and the complete lifecycle.

Source: https://howhttpworks.com/guides/request-lifecycle
Last reviewed: 2026-10-04

> **TL;DR:** HTTP requests go through DNS lookup, TCP connection, TLS handshake (HTTPS), request transmission, server processing, and response delivery. Understanding each step helps optimize performance and debug issues.

Understanding the HTTP request lifecycle is fundamental to web development. Every time you click a link, submit a form, or load a webpage, your browser executes a complex sequence of steps to communicate with web servers. This guide walks through each phase of this process, from the initial DNS lookup to the final connection close.

## Introduction

When you type `https://api.example.com/users` into your browser or make an API call, what actually happens behind the scenes? The HTTP request lifecycle involves multiple layers of networking protocols working together to deliver data across the internet. Each step has specific timing characteristics and potential failure points that developers need to understand.

The complete lifecycle typically takes 100-500 milliseconds for a typical web request, but can vary dramatically based on network conditions, server location, and resource size. Understanding each phase helps you optimize performance, debug issues, and build more resilient applications.

## Step-by-Step Lifecycle Breakdown

### 1. DNS Lookup (10-100ms)

The journey begins when your browser needs to convert the human-readable domain name into an IP address that computers can use to route traffic.

**Process:**

1. Browser checks local DNS cache
2. If not found, queries the operating system's DNS resolver
3. OS resolver checks its cache, then queries configured DNS servers
4. DNS servers perform recursive lookups through the DNS hierarchy
5. Final IP address is returned and cached

**Example DNS Resolution:**

```http
Query: api.example.com
Response: 203.0.113.42
Cache TTL: 300 seconds
```

**Timing Considerations:**

- Cache hit: ~1ms
- Local network DNS: 10-50ms
- Public DNS (8.8.8.8): 20-100ms
- First-time lookup: 50-200ms

### 2. TCP Connection Establishment (20-100ms)

Once the IP address is known, the browser initiates a TCP connection using the three-way handshake.

**Three-Way Handshake:**

1. **SYN**: Client sends synchronization packet to server
2. **SYN-ACK**: Server acknowledges and sends its own synchronization
3. **ACK**: Client acknowledges server's response

**Example TCP Handshake:**

```text
Client → Server: SYN (seq=1000)
Server → Client: SYN-ACK (seq=2000, ack=1001)
Client → Server: ACK (seq=1001, ack=2001)
Connection established
```

**Timing Factors:**

- Geographic distance (round-trip time)
- Network congestion
- Server load and connection limits

### 3. TLS Handshake (50-200ms)

For HTTPS requests, an additional TLS handshake establishes encrypted communication.

**TLS 1.3 Handshake Process:**

1. **Client Hello**: Supported cipher suites and random value
2. **Server Hello**: Selected cipher suite, certificate, and key exchange
3. **Key Exchange**: Both sides derive shared encryption keys
4. **Finished**: Handshake completion and verification

**Example TLS Negotiation:**

```text
Client Hello:
- TLS version: 1.3
- Cipher suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
- Extensions: SNI (api.example.com)

Server Hello:
- Selected cipher: TLS_AES_256_GCM_SHA384
- Certificate chain: [api.example.com cert, intermediate CA, root CA]
- Key exchange: X25519
```

### 4. HTTP Request Transmission (1-10ms)

With the secure connection established, the browser sends the actual HTTP request.

**Request Structure:**

```http
GET /users?page=1&limit=10 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Connection: keep-alive
```

**Key Components:**

- **Request line**: Method, path, and HTTP version
- **Headers**: Metadata about the request and client capabilities
- **Body**: Data payload (for POST, PUT, PATCH requests)

### 5. Server Processing (10-1000ms)

The server receives the request and processes it through multiple layers.

**Server-Side Processing Steps:**

1. **Load balancer**: Routes request to available server instance
2. **Web server**: Parses HTTP request and applies routing rules
3. **Application server**: Executes business logic and database queries
4. **Database**: Retrieves or modifies data as needed
5. **Response generation**: Formats data and adds appropriate headers

**Example Processing Flow:**

```text
Load Balancer (nginx) → Application Server (Node.js) → Database (PostgreSQL)
                     ↓
Request validation → Authentication → Authorization → Data retrieval → Response formatting
```

### 6. HTTP Response Transmission (1-50ms)

The server sends back the HTTP response with status code, headers, and body.

**Response Structure:**

```http
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1247
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Cache-Control: max-age=300, public
Last-Modified: Fri, 18 Jan 2026 10:30:00 GMT
Connection: keep-alive

{
  "users": [
    {"id": 1, "name": "Alice", "email": "alice@example.com"},
    {"id": 2, "name": "Bob", "email": "bob@example.com"}
  ],
  "pagination": {
    "page": 1,
    "limit": 10,
    "total": 156
  }
}
```

### 7. Connection Management

Modern HTTP implementations use connection reuse to optimize performance.

**HTTP/1.1 Keep-Alive:**

- Reuses TCP connection for multiple requests
- Reduces overhead of connection establishment
- Configurable timeout and request limits

**HTTP/2 Multiplexing:**

- Multiple requests over single connection
- Server push capabilities
- Header compression (HPACK)

**Connection Close:**

```http
Connection: close
```

## Timing Diagram (Text Representation)

```text
Time →  0ms    50ms   100ms  150ms  200ms  250ms  300ms
        |      |      |      |      |      |      |
DNS     [████]
TCP           [████]
TLS                  [████████]
Request                      [█]
Server                        [████████████]
Response                                   [██]
Total   [████████████████████████████████████████]
```

## Performance Optimization Examples

### Connection Reuse

```javascript
// Bad: Creates new connection for each request
const responses = await Promise.all([
  fetch('https://api.example.com/users'),
  fetch('https://api.example.com/posts'),
  fetch('https://api.example.com/comments')
])

// Good: Reuses connection with HTTP/2
const agent = new https.Agent({ keepAlive: true })
const responses = await Promise.all([
  fetch('https://api.example.com/users', { agent }),
  fetch('https://api.example.com/posts', { agent }),
  fetch('https://api.example.com/comments', { agent })
])
```

### DNS Prefetching

```html
<!-- Resolve DNS before user clicks -->
<link rel="dns-prefetch" href="//api.example.com" />
<link rel="preconnect" href="https://api.example.com" />
```

## Getting Request and Response Lifecycle right

### Client-Side Optimization

- **DNS prefetching**: Resolve domains before they're needed
- **Connection prewarming**: Establish connections early
- **Request batching**: Combine multiple API calls when possible
- **Caching strategies**: Use browser and application caches

### Server-Side Optimization

- **Connection pooling**: Reuse database connections
- **Response compression**: Use gzip/brotli encoding
- **CDN deployment**: Serve content from edge locations
- **HTTP/2 adoption**: Enable multiplexing and server push

### Monitoring and Debugging

- **Network timing**: Use browser DevTools Network tab
- **Server metrics**: Track response times and error rates
- **Real User Monitoring**: Measure actual user experience
- **Synthetic testing**: Automated performance checks

## Related Concepts

Understanding the request lifecycle connects to several other HTTP concepts:

- **[Caching](https://howhttpworks.com/guides/headers-and-caching)**: How responses are stored and reused
- **[Status Codes](https://howhttpworks.com/guides/status-codes-overview)**: Server response indicators
- **[Headers](https://howhttpworks.com/headers/cache-control)**: Metadata that controls behavior
- **[Methods](https://howhttpworks.com/methods/get)**: Different types of HTTP operations
- **[Cookies](https://howhttpworks.com/cookies/secure)**: State management across requests

The request lifecycle forms the foundation for all HTTP communication. Mastering these concepts enables you to build faster, more reliable web applications and effectively troubleshoot network issues when they arise.