LAB / 02

HTTP Lifecycle

dns / tcp / tls / application / database

Press SEND REQUEST and follow one packet through the layers that stand between Enter and 200 OK. Click any layer to learn what it actually does.

Educational simulationOne HTTPS round trip, simplified — not a packet-level trace. Addresses and timings are simulated.
  1. Compose the request
  2. DNS lookup
  3. TCP handshake
  4. TLS handshake
  5. Send the request
  6. Server accepts
  7. Application logic
  8. Database query
  9. Result back to app
  10. Response prepared
  11. Response received
  1. Compose the requestGET https://api.example.com/projects — method, path, headers, body.
  2. DNS lookupapi.example.com → 192.0.2.10 (simulated). The name is resolved to an address.
  3. TCP handshakeSYN → SYN-ACK → ACK. A reliable connection opens before traffic flows.
  4. TLS handshakeCipher agreement + certificate check. The channel is now encrypted.
  5. Send the requestGET /api/projects travels over the encrypted tunnel.
  6. Server acceptsConnection accepted, request parsed, route matched.
  7. Application logicThe handler validates input and asks the database for data.
  8. Database querySQL executed — matching rows are returned to the application.
  9. Result back to appRows are shaped into the response inside the application.
  10. Response prepared200 OK — headers and body are assembled at the server.
  11. Response received200 OK — round trip complete (educational simulation).

Compose the requestGET https://api.example.com/projects — method, path, headers, body.

This is an educational simulation of one HTTPS round trip. The addresses and timings are simulated — 192.0.2.10 is a documentation range, deliberately not a real host. Real requests re-use the TCP and TLS connection, keep DNS answers cached, and reach the application in reverse order server-side; none of that nuance is shown here, only the layers in play.