A website opens on your phone but fails on your laptop. Is the problem the domain name, the connection, the identity check, or the application? These failures can look similar even though they happen at different stages. Understanding how a web address becomes a visible page helps you troubleshoot systems and explain networking beyond memorized definitions.
The core idea: three different jobs
A protocol is a set of rules for communication. Three protocols handle different parts of loading a secure website:
Protocol Full name Main job
DNS Domain Name System Find network addresses for a name such as example.com. TLS Transport Layer Security Verify the server’s identity and protect exchanged data. HTTP Hypertext Transfer Protocol Carry requests for resources and the corresponding responses.
Think of calling an office for a document. DNS finds its phone number. The connection makes the call possible. TLS checks who answered and protects the conversation. HTTP defines how to request and receive the document.
The browser is the client, the program making the request. A server receives and answers it. HTTPS means HTTP protected by TLS.
From URL to page, step by step
Our example is https://example.com/. IANA, the Internet Assigned Numbers Authority, reserves it for documentation. Use it for learning, not as a production dependency.
First, we will follow a fresh connection using HTTP/1.1, one version of HTTP.
- Parse the URL
A URL, or Uniform Resource Locator, identifies a resource and how to access it.
Part Our example Meaning
Scheme https Use HTTP with TLS protection. Hostname example.com The name of the destination. Port 443, implied The default HTTPS service port. Path / Request the site’s root resource.
A port is a numbered endpoint identifying a service. Plain HTTP defaults to port 80.
If we add ?topic=http#overview, the query, topic=http, travels in the HTTP request. The fragment, overview, is interpreted by the browser and is not sent as part of the request target. DNS receives the hostname, not the path, query, or fragment.
- Resolve the hostname with DNS
The browser needs an IP address, an Internet Protocol address used to reach a network destination.
It checks a cache, a store of previous results, or uses its resolver, a service that finds DNS answers. The resolver may be configured by your internet service provider, organization, or browser.
A recursive resolver performs lookups for the client. Without cached information, it asks a root DNS server where to find .com servers. A .com server refers it to the authoritative servers responsible for example.com. Those servers provide the domain’s records. The root does not store every website’s address.
An A record contains an IPv4 address; an AAAA record contains an IPv6 address. IPv4 and IPv6 are two IP address formats. Multiple records can offer multiple destinations.
A record’s TTL, or time to live, specifies its allowed cache lifetime in seconds. A DNS answer does not guarantee a reachable web service.
- Establish the transport connection
For our HTTP/1.1 example, the browser opens a TCP, or Transmission Control Protocol, connection to an address on port 443.
TCP reliably delivers bytes in order, using packets, small units of network data. It retransmits missing data. Connection setup usually uses three messages:
Browser Server | -------- SYN ------------> | | <----- SYN + ACK --------- | | -------- ACK ------------> |
SYN synchronizes sequence numbers, which track positions in the byte stream. ACK acknowledges received information. TCP setup does not verify website identity or encrypt HTTP.
- Negotiate TLS and verify the server
A handshake is an initial exchange that establishes communication parameters. In a typical full TLS 1.3 handshake:
- The browser sends a ClientHello containing supported options and a key share, public material used to establish shared secrets.
- The server replies with its selected options and key share.
- The server presents a certificate and a digital signature, proof calculated with a secret private key and checked with its public key.
- Both sides derive shared encryption keys and exchange messages that verify the handshake.
TLS never sends the private key to the browser. In ordinary certificate-based TLS 1.3 connections, temporary key agreement establishes secrets; the certificate’s key authenticates the exchange. The resulting keys encrypt data and detect unauthorized changes.
A certificate binds an identity to a public key, a shareable key used to verify signatures. The browser checks the hostname, validity dates, and a certificate chain, signatures leading to a trusted certificate authority, an organization trusted to issue certificates. Without identity verification, you could have an encrypted conversation with an impostor.
SNI, Server Name Indication, tells the TLS server which hostname the client wants. This helps select a certificate when several sites share an address. SNI selects the site; certificate verification checks its identity.
ALPN, Application-Layer Protocol Negotiation, selects a protocol during TLS negotiation, such as HTTP/1.1 or the newer HTTP/2.
HTTPS protects communication with the TLS endpoint. A reverse proxy receives and forwards requests to another server. If it ends TLS, the onward connection needs separate protection where required.
- Send an HTTP request and receive a response
Inside the protected connection, an HTTP/1.1 request can look like this:
GET / HTTP/1.1 Host: example.com Accept: text/html
GET is a method, an action requesting resource data. A resource is an item such as a page or image. Headers describe the message: Host identifies the site; Accept specifies acceptable response formats.
A simplified successful response looks like:
HTTP/1.1 200 OK Content-Type: text/html
[HTML document follows]
200 is a status code indicating success. Content-Type identifies the body’s format. The body contains the resource data; here, HTML, Hypertext Markup Language, which describes page structure. The blank line separates headers from the body.
A redirect supplies another URL in its Location header, potentially requiring another lookup and connection. A 404 response means the resource was not found; DNS, TCP, and TLS may have succeeded.
- Turn the response into pixels
Receiving HTML is not the same as displaying a finished page.
The browser parses HTML into the DOM, Document Object Model, an in-memory tree of elements. CSS, Cascading Style Sheets, defines presentation. Layout calculates element positions; painting draws visible content.
External images, stylesheets (files of style rules), and JavaScript trigger more requests. JavaScript runs code in the browser and can change the document. Unlike our small example.com page, larger pages can involve many resources and hostnames. Parsing, fetching, and rendering can overlap.
Cached content can avoid network requests; existing connections can carry more requests. TLS resumption uses information from a previous connection to reduce later handshake work. A second visit can therefore behave differently.
Hands-on: inspect each layer
Use Bash, a command shell, on Linux, macOS, or Windows Subsystem for Linux, a Linux environment inside Windows. These examples target OpenSSL; older versions or other implementations may differ.
On Ubuntu or Debian, install the tools if needed:
sudo apt update sudo apt install curl dnsutils openssl
Outputs below are representative excerpts or shapes. Angle-bracket values vary; these are not measurements of your network.
Inspect DNS with dig
dig is a command-line DNS query tool:
dig example.com A +noall +answer dig example.com AAAA +noall +answer
Expected answer shapes:
example.com. <remaining-TTL> IN A <IPv4-address> example.com. <remaining-TTL> IN AAAA <IPv6-address>
+noall +answer shows the answer section. IN identifies the Internet category of records. Queries can return several records. For missing answers, plain dig example.com A also displays response status.
To inspect referrals yourself:
dig +trace example.com A
Expect root, .com, and authoritative-server responses. This makes iterative queries, following referrals itself. It is not a recording of your browser’s lookup and can fail where direct DNS traffic is blocked.
Inspect TLS with openssl
OpenSSL provides cryptographic tools; s_client acts as a diagnostic TLS client:
openssl s_client
-connect example.com:443
-servername example.com
-verify_hostname example.com
-verify_return_error
-brief </dev/null
A successful run commonly includes:
CONNECTION ESTABLISHED Protocol version: TLSv1.3 Ciphersuite: <negotiated-algorithm-set> Verification: OK
A cipher suite names selected cryptographic algorithms, mathematical procedures that protect data. TLS versions and algorithms depend on the client and server.
-servername sends SNI. -verify_hostname checks the certificate’s name. -verify_return_error aborts on verification errors; without it, this diagnostic tool can continue despite those errors. -brief reduces output, and </dev/null closes input instead of waiting for keyboard entry. This checks TLS, not page rendering.
Inspect HTTP with curl
curl transfers data using URLs:
curl --http1.1 --verbose --output /dev/null https://example.com/
Selected lines from a successful response look like:
GET / HTTP/1.1 Host: example.com < HTTP/1.1 200 OK < content-type: text/html
marks outgoing headers; < marks incoming headers. --http1.1 keeps the example consistent; --verbose exposes connection details. --output /dev/null discards the body; remove it to inspect HTML. Curl neither executes page JavaScript nor renders pages.
Verbose logs may expose cookies, stored values sent back to a site, or authorization headers. These can grant account access; remove sensitive values before sharing logs.
Locate delays with curl timings
curl --http1.1 --silent --show-error --output /dev/null
--write-out 'dns_end=%{time_namelookup}\ntcp_end=%{time_connect}\ntls_end=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n'
https://example.com/
Expected output shape:
dns_end=<seconds> tcp_end=<seconds> tls_end=<seconds> first_byte=<seconds> total=<seconds>
These are cumulative times measured from the operation’s start. For a fresh, direct TCP connection without redirects, interpret them approximately as follows:
Stage Calculation
Name lookup dns_end TCP establishment tcp_end - dns_end TLS handshake tls_end - tcp_end Request transmission and wait for first response byte first_byte - tls_end Remaining transfer total - first_byte
The first-byte wait includes network travel and server processing, not just application execution. Proxies and connection reuse change interpretation. These timings exclude browser rendering.
Test an address while preserving the hostname
To test one IPv4 address returned by dig, enter it when prompted:
read -r -p 'Paste an IPv4 address from dig: ' psc_test_ip
curl --http1.1 --verbose --output /dev/null
--resolve "example.com:443:$psc_test_ip" https://example.com/
Expect the same Host and response lines shown above. --resolve selects an address while preserving SNI and certificate verification. It overrides normal address selection for this hostname and port; public DNS stays unchanged.
Tradeoffs and alternatives
Use HTTPS for public websites and APIs, application programming interfaces through which programs exchange data. Plain HTTP suits isolated local exercises; avoid it for credentials or untrusted networks. TLS cannot make a malicious application trustworthy.
HTTP versions preserve request-and-response meaning while changing how messages travel:
Version Useful when Limitation or alternative
HTTP/1.1 Compatibility and readable diagnostics matter. Responses on one connection remain ordered; simultaneous requests often use multiple connections. HTTP/2 Many requests should share one TCP connection. A lost TCP packet can delay all streams, or independent request/response exchanges, on that connection. HTTP/3 Supported deployments benefit from independent transport streams. Uses QUIC, a transport over UDP with integrated TLS 1.3; blocked UDP or limited support can require HTTP/2 fallback.
UDP, User Datagram Protocol, sends individual messages without TCP’s ordered-delivery guarantees. QUIC supplies reliability and security above UDP. HTTP/3 changes our TCP-then-TLS sequence while retaining protection. Loss on one QUIC stream need not stall unrelated streams. Check network and client support before requiring HTTP/3.
Shorter DNS TTLs allow quicker changes but increase lookups. Longer TTLs reduce lookups but retain older answers longer. Lower TTLs before moving servers, allowing existing cached answers to expire.
Use dig for DNS, OpenSSL for TLS, and curl for HTTP. For scripts, styling, and visible behavior, use browser developer tools, especially the Network panel.
Common mistakes and fixes
- Assuming a DNS change is immediate
An older cached answer can remain valid after you edit a record. Fix: inspect TTLs and authoritative answers, and allow previous TTLs to expire. A browser refresh does not necessarily clear DNS caches.
- Replacing the hostname with an IP address
The server may select another site, or its certificate may not cover the IP. Fix: use curl’s --resolve to preserve the hostname while selecting an address.
- Fixing TLS errors with verification disabled
curl -k, also called --insecure, bypasses certificate verification. Fix: correct the hostname, certificate chain, system clock, or trust configuration. For a private certificate authority, configure trust explicitly, for example with --cacert, rather than disabling checks in production.
- Treating HTTPS as protection for every hop
A reverse proxy can decrypt traffic before forwarding it. Fix: identify where TLS ends and protect onward connections according to network and data requirements. Monitor certificate expiry and automate renewals.
- Loading insecure resources inside an HTTPS page
This is mixed content. Browsers may upgrade or block those HTTP resources. Fix: serve images, scripts, and stylesheets through HTTPS and inspect browser security messages.
- Confusing a successful transfer with a correct page
HTTP 200 can carry the wrong document, and curl cannot expose rendering failures. Fix: inspect the body and content type, then check the browser for script and resource errors.
Quick recap
- DNS finds addresses; it does not fetch the page.
- TCP establishes reliable transport for our HTTP/1.1 example.
- TLS verifies the server and protects exchanged data.
- HTTP carries requests, headers, status codes, and response bodies.
- The browser builds and draws the page; caching and reuse can skip earlier work.
Test yourself
- DNS succeeds, but connecting to port 443 times out. Is the page reachable?
Answer: Not necessarily. DNS returned an address, but the service, route, or firewall may prevent connection establishment.
- Does sending SNI prove the server’s identity?
Answer: No. SNI requests a hostname. Certificate and hostname verification establish whether the server is trusted for it.
- Does every HTTPS request require a new TCP and TLS handshake?
Answer: No. Requests can reuse connections. Cached content can avoid requests, and HTTP/3 uses QUIC rather than TCP.
Where to go next
- HTTP caching: learn how Cache-Control headers govern response reuse and prevent inappropriate caching of private data.
- DNS privacy and authenticity: distinguish encrypted DNS, which protects queries in transit, from DNSSEC, DNS Security Extensions, which authenticate signed DNS data.
- Browser performance: study resource loading and JavaScript execution to understand why a fast HTTP response can still produce a slow page.