NETWORKING · INTRO

A web request’s journey: DNS, TCP, TLS and HTTP

Follow a newly established HTTPS connection and separate name resolution, transport, encryption and application response. Success at one layer establishes only that layer’s work.

After this lesson, you can
  • Describe each layer in an HTTPS request using TCP.
  • Choose the next diagnostic check from synthetic error records.
  • Explain why HTTP/3 and caching can change the sequence.

Define the scope of the map

This map describes HTTPS using HTTP/1.1 or HTTP/2 when a new connection is required. Browsers may cache DNS or reuse connections; HTTP/3 uses QUIC instead of TCP. The map explains responsibilities rather than a fixed sequence repeated on every click.

A URL’s hostname helps locate a destination, while its path identifies a resource on that service. In https://docs.example.test/guide/, docs.example.test is the host and /guide/ is the path. They answer different questions.

Further reading: MDN: Overview of HTTP

What the four layers provide

DNS obtains resource records for a name. TCP provides reliable byte transport in this scenario. TLS negotiates protected communication and verifies appropriate peer identity. HTTP expresses methods, paths, status and content. DNS success does not guarantee TCP reachability, and TCP success does not establish application authorization.

Each layer has its own failures. A nonexistent name, connection timeout, certificate mismatch and HTTP 404 are different evidence. Calling all of them “the network is broken” makes the next step ambiguous.

Further reading: RFC 1034: Domain names, concepts and facilities·MDN: Transport Layer Security·MDN: Overview of HTTP

Start with the nearest failure evidence

Receiving HTTP 404 means an HTTP service responded to that request. First check the host, path and routing configuration. It does not guarantee the expected origin produced the response, particularly when proxies or caches are involved.

If the browser shows a certificate security warning, check identity, time and configuration with the responsible owner instead of bypassing the warning to finish a test. Diagnosis should establish a verifiable cause while preserving the security boundary.

Example: a 404 points first to the path

A synthetic trace shows DNS resolved, TCP connected, TLS verified and GET /guied/ → 404. The intended path is /guide/.

An HTTP response makes spelling and routing a more direct next check than assuming complete DNS failure. After correcting it, obtain the expected response before claiming a fix.

Conclusion: Correct the observed path typo, then verify status and content.

Offline exercise: next checks for three errors

Use synthetic text traces without sending network requests or changing DNS.

  1. List A: name not found, B: certificate mismatch and C: HTTP 404.
  2. For each, name the relevant layer and one next check.
  3. For C, add one unsupported conclusion, such as “the entire domain does not exist.”

Expected result

For A, check the name and DNS. For B, check certificate identity and configuration without bypassing warnings. For C, check host, path and routing.

Check your work

If the connection uses HTTP/3, which transport protocol label changes?

Finish and clean up

Save the layered notes; no network settings require restoration.

Q&A · Check your reasoning

Choose an answer and confidence, then read every explanation. Answers stay in this browser.

net-request-q1 · Original practice

After HTTP 404, what is the most direct initial check?

After HTTP 404, what is the most direct initial check?
net-request-q2 · Original practice

What is appropriate when TLS raises a certificate warning?

What is appropriate when TLS raises a certificate warning?
net-request-q3 · Original practice

Is “all HTTPS must first establish TCP” accurate?

Is “all HTTPS must first establish TCP” accurate?

Connect the next idea

Terms: DNS·TLS·HTTP·Evidence boundary

Sources & scope

These sources support the technical principles. Examples, questions and exercises are original to this series.