Lesson 1 of 2Beginner⏱ 10 mins

The Request/Response Cycle

How Actix translates TCP bytes into HTTP objects.

0% of path

Learning Objectives

Understand HTTP structure

##What happens between click and page

When you open a URL or call an API, a precise sequence of steps runs. Knowing it helps you debug problems and explains why Actix Web is built the way it is.

#The cycle in seven steps

DNS lookup: the domain name is turned into an IP address.
TCP connection: the client opens a connection to the server (and TLS adds encryption for HTTPS).
Request sent: the client writes a request line, headers and an optional body.
Server accepts: a worker in your HttpServer takes the connection.
Routing and handling: Actix matches the path, runs extractors and middleware, then calls your handler.
Response sent: the status line, headers and body are written back.
Connection reuse or close: with HTTP keep-alive the same connection serves the next request.

#What a raw request looks like

code_blockstext

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 21

{"name":"Ada"}

And a matching response:

code_blockstext

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 25

{"id":1,"name":"Ada"}

#Where Actix Web fits

Inside the server, the journey of one request looks like this:

The worker reads and parses the bytes into an HttpRequest.
Middleware layers run (logging, auth) from the outside in.
The router finds the matching route and checks guards.
Extractors turn path, query, headers and body into typed arguments.
Your handler runs and returns a Responder.
The response flows back out through the middleware layers.

#Seeing it yourself

Use curl -v to watch the whole exchange:

terminalbash

curl -v http://127.0.0.1:8080/

Lines starting with > are what the client sent and lines starting with < are what the server answered.

#HTTP is stateless

Each request stands alone: the server does not remember earlier ones. Anything that must persist, such as a logged-in user, travels with the request (a cookie or an Authorization header) or lives in a database.

"What If?" Experiment

Learning by doing. Modify the code to see what happens.

Goal

Observe keep-alive.

Starting Code

curl -v http://127.0.0.1:8080/ http://127.0.0.1:8080/health

Suggested Modification

Run the command with two URLs.

Expected Result

curl reports re-using the existing connection for the second request.

Explanation: HTTP/1.1 keeps the TCP connection open, which avoids repeating the handshake.

Common Mistakes

Anticipate and avoid these frequent pitfalls when working with this concept.

Assuming the server remembers the previous request

HTTP is stateless, so each request is independent.

Incorrect Pattern

// handler expects "the user from the last call"

Correct Pattern

// identify the user on every request (token or session cookie)

Explanation: Send identity with every request and look it up each time.

Practical Exercise

Read a raw exchange

Task

Run your server and capture a request with curl -v, then label the request line, headers and body.

Requirements

Run curl -v against your server
Identify the status code
Identify at least two response headers

Need a hint?

Try solving the exercise in your local environment first. Once you have a solution, or if you get completely stuck, reveal the answer.

Real-World Application

Understanding this cycle is how engineers diagnose slow endpoints: they separate DNS and connect time from server processing time, and decide where caching or compression will help.

Key Takeaways

HTTP is a stateless request and response protocol over TCP.
Actix runs middleware, routing, extractors and then your handler for every request.
curl -v shows the exact request and response bytes.
State between requests must travel in cookies, headers or a database.

Finished reading?

Mark this lesson as done to track your progress and earn XP.

Next Lesson

2. HTTP Methods (GET, POST, PUT, DELETE)