YanoSec
Progress0 of 152 lessons complete

Course / 06 Web basics / Lesson 02 of 08

What happens when you load a page

Estimated time: 15 min reading · 15 min activity

When a page fails to load, the browser may not have reached the web server at all. Loading involves several jobs: reading an address, finding its host, connecting, exchanging messages, and displaying the result. You will put those jobs in order for one stated case.

A URL, Uniform Resource Locator, is an address with named parts. In http://note.lab.invalid/note, http is the scheme, which identifies the kind of access. note.lab.invalid is the host, the name of the destination. /note is the path identifying the resource requested there. A port selects the service at that host. HTTP, Hypertext Transfer Protocol, defines the request and response exchange. When an http URL omits a port, this TCP-based example uses the default 80.

The model assumes no usable cached answer, connection, or page content. A cache is saved information that can be reused; real browsers may reuse several kinds. Here, follow the supplied fresh sequence rather than adding an unstated cached result.

Before you begin

Estimated time
15 min reading, 15 min activity. Setup and optional practice may take longer.
Where you work
Use the complete printed cards with paper or a text editor for notes. No account, external target, or installation is required. A local HTML file can be read as source; that reading does not perform an HTTP exchange. The curl lesson gives a separate optional loopback-lab procedure.
Without a lab
The cards provide the names, byte counts, requests, responses, and stored records needed for the activity. Make a prediction and compare with the supplied reasoning; a practical run can wait. Reading works without JavaScript. Answer checking needs JavaScript and a secure context, normally HTTPS or a local preview. Saving additionally needs usable browser storage.

After this lesson you can:

  • Label scheme, host, port, and path on a printed URL.
  • Order name lookup, TCP, HTTP, and rendering for an uncached load.
  • Stop a trace when name lookup fails, before an HTTP response exists.

01Example

Follow the worked URL through a successful, uncached HTTP-over-TCP load. The hostname and address lookup are fictional. No browser loaded this URL. The path belongs in the later HTTP request, while the host address and port identify the connection destination.

1. Read scheme http, host note.lab.invalid, port 80, path /note.
2. DNS resolves the host.
3. TCP connects to the address and port.
4. HTTP sends GET /note and receives the response.
5. The browser renders the response.

02The order on an uncached load

DNS resolves the host name to an address. TCP then establishes a connection to that address and port and carries an ordered byte stream. HTTP, Hypertext Transfer Protocol, gives the browser’s request and the server’s response their shared meaning. Rendering is the browser’s work of interpreting the returned content and drawing the page.

A page can request more files, such as images or scripts, after its first response. This model follows only the one URL. A successful DNS answer is therefore an early result, not a complete page load.

An https URL requests HTTP protected with TLS, Transport Layer Security. Its default port is 443. In the TCP-based HTTPS model introduced later, TLS protection is established after TCP and before the HTTP exchange. HTTP/3 uses QUIC, a different transport protocol with TLS protection built in, so this simple order does not describe every modern browser connection.

Follow URL → DNS → TCP → HTTP → render in the uncached model, with a visible stop before HTTP if resolution fails.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Playback is optional. Step through at your own pace.

Browser: http, note.lab.invalid, port 80, /noteURL parts establish the request target in this model.
DNS resolutionNot yet resolved.
Server at the resolved addressNot yet connected.
  1. Browser: http, note.lab.invalid, port 80, /note → DNS resolutionResolve note.lab.invalidName resolution precedes TCP in this uncached model; address unspecified.
  2. Browser: http, note.lab.invalid, port 80, /note → Server at the resolved addressTCP to resolved address, port 80Connection is a dependency before this HTTP exchange.
  3. Browser: http, note.lab.invalid, port 80, /note → Server at the resolved addressHTTP GET /noteThe supplied sequence includes request and response; body content is unspecified.
  4. Server at the resolved address → Browser: http, note.lab.invalid, port 80, /noteHTTP response before renderResponse contents unspecified; this model does not invent a body.
DNS must resolve before TCP
pending
TCP before HTTP
pending

Read scheme http, host note.lab.invalid, port 80 and path /note.

Follow the explanation

  1. Read scheme http, host note.lab.invalid, port 80 and path /note.
  2. Resolve the host before attempting TCP.
  3. Connect TCP before the HTTP exchange.
  4. GET /note and a response precede rendering.
  5. If DNS failed, stop before TCP and HTTP; this is a dependency rule, not an observed failure.
Read every state and value

1. Read scheme http, host note.lab.invalid, port 80 and path /note.

Messages shown
None
Current message
Not established
Policy decisions
Status: pending · Status: pending
Participant roles
Actor: Browser: http, note.lab.invalid, port 80, /note; Text: URL parts establish the request target in this model. · Actor: dns; Text: Not yet resolved. · Actor: Server at the resolved address; Text: Not yet connected.

2. Resolve the host before attempting TCP.

Messages shown
dns
Current message
dns
Policy decisions
Status: permitted-model · Status: pending
Participant roles
Actor: Browser: http, note.lab.invalid, port 80, /note; Text: Uses the resolution dependency. · Actor: dns; Text: Resolved in the supplied successful model; address unspecified. · Actor: Server at the resolved address; Text: Not yet connected.

3. Connect TCP before the HTTP exchange.

Messages shown
dns · tcp
Current message
tcp
Policy decisions
Status: permitted-model · Status: permitted-model
Participant roles
Actor: Browser: http, note.lab.invalid, port 80, /note; Text: TCP is ready in the model. · Actor: dns; Text: Resolution already precedes connection. · Actor: Server at the resolved address; Text: Connected in the supplied successful model.

4. GET /note and a response precede rendering.

Messages shown
dns · tcp · http · HTTP response before render
Current message
HTTP response before render
Policy decisions
Status: permitted-model · Status: permitted-model
Participant roles
Actor: Browser: http, note.lab.invalid, port 80, /note; Text: Renders after response; body unspecified. · Actor: dns; Text: No additional lookup is invented. · Actor: Server at the resolved address; Text: Responds in the authored successful sequence.

5. If DNS failed, stop before TCP and HTTP; this is a dependency rule, not an observed failure.

Messages shown
None
Current message
Not established
Policy decisions
Status: stopped · Status: not-established
Participant roles
Actor: Browser: http, note.lab.invalid, port 80, /note; Text: Would stop before an HTTP response. · Actor: dns; Text: Failure is a hypothetical dependency condition. · Actor: Server at the resolved address; Text: No connection or response established in this branch.
Follow URL → DNS → TCP → HTTP → render in the uncached model, with a visible stop before HTTP if resolution fails.

03A failed name lookup

The guided activity is a different uncached attempt. Its DNS lookup fails, and the cards explicitly say the remaining stages have not started. Use that evidence to decide where the sequence stops.

Original fictional timelines. No browser was used. No cache was measured.

Worked successful load
URL: http://note.lab.invalid/note
Scheme: http
Host: note.lab.invalid
Port: omitted, so 80 on this card
Path: /note

Order when nothing is reused from a cache
1. Read the URL.
2. DNS: resolve the host.
3. TCP: connect to the address and port.
4. HTTP: send GET /note.
5. HTTP: receive the response.
6. Render: the browser turns the response into the page.

A cache can skip a step that it can reuse. This card does not record a cache hit.
The later TCP-based HTTPS model inserts TLS after TCP and before HTTP.
HTTP/3 uses QUIC instead; this card models the TCP case.

Activity cards, uncached, in the order they were started
Card N: DNS name lookup, and this lookup fails
Card R: TCP connection, not started
Card Q: HTTP request and response, not started
Card P: render, not started

The failure stops the sequence at card N.
Check: the last started step is name.

Independent failure trace, separate from the activity
URL: http://shelf.lab.invalid/page
Uncached.
Name lookup: failed
TCP: not started
HTTP: not started
Render: not started

Download the page timelines

  1. Label scheme http, host note.lab.invalid, default port 80, and path /note in the worked URL. Explain which part HTTP will request after connection setup.
  2. On the successful timeline, place DNS before TCP, HTTP before rendering, and the response after the request. Compare your order with the printed model.
  3. Read the activity cards. N starts the name lookup and fails; R, Q, and P are marked not started. Identify N as the last started card.
  4. Record the activity check as name and state that the later jobs have no evidence of starting. Stop with the cards; opening a real page would create a different attempt.

04Optional challenge

For about ten extra minutes, change the worked URL scheme in notes to https and leave its port omitted. In the stated TCP-based model, choose default port 443 and insert TLS between TCP setup and the HTTP exchange. Keep the HTTP/3 qualification in your explanation.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Page-load case AOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

URL: http://map.grove.invalid:8126/trails
An uncached HTTP-over-TCP attempt succeeds. DNS returns an address. No TLS is used for this http URL. The request and response then complete and the browser renders the returned content.

Page-load case B: independent failure logOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

URL: http://list.grove.invalid/catalog
L1: browser parses URL.
L2: DNS returns no address.
L3: no TCP connection has started.
L4: browser draws its own name-lookup error screen.
No HTTP response exists in this supplied attempt.

06Explain your prediction

Optional written self-check: Label URL components and trace the stated protocol model. Identify the first failed stage and distinguish a browser-generated error from a server response; HTTPS would add TLS in the taught TCP-based case.

07Common mistakes

If you continue after the failed lookup, reread the activity’s not-started labels. Its model supplies no destination connection or exchange afterward.

If you assume a remembered page appeared from cache, remove that assumption. This particular attempt explicitly rules out usable cached results.

If you use /note to identify the TCP service, separate the URL parts again. The connection uses address and port; HTTP uses the path to request the resource.

References