Networking Fundamentals: Trace DNS, TCP, UDP, TLS, and HTTP End to End
Trace a cold HTTPS request from hostname resolution through TCP, TLS, and HTTP. This reference explains each protocol’s contract, shows where setup and recovery add latency, compares TCP with UDP and QUIC, and highlights operational failure modes such as expired DNS records and TLS termination at a load balancer.
Why a Web Request Needs Several Protocols
A browser cannot solve every networking problem with one mechanism. If it starts with a hostname, it needs a way to find the machine behind that name. If packets are lost or reordered, it needs a delivery contract. If the network is untrusted, it needs protection against eavesdropping and tampering. Finally, the server and client need a shared format for asking for a resource and returning the result. Treating these as one concern makes failures hard to diagnose: a slow first request may be name resolution, connection setup, security negotiation, or the application exchange itself.
DNS handles naming: it translates a human-readable hostname into the IP address a client can use to connect. TCP or UDP handles transport: TCP establishes an ordered, acknowledged byte stream, while UDP sends datagrams without TCP's delivery guarantees. The choice is not simply “slow versus fast”; it is a decision about whether correctness requires delayed recovery or whether a newer update can replace a missing one.
TLS handles trust and confidentiality on top of a TCP connection. The server presents a certificate, and the connection negotiates cryptographic protection before application data crosses the network. Without that layer, HTTP traffic can be viewed or modified by a network attacker; Mozilla describes ordinary HTTP as transferred “in the clear,” while HTTPS carries HTTP over TLS. handles application meaning: methods, headers, status codes, and the request–response exchange that browsers and APIs understand.
Design a platform-scale distributed rate limiter55 min
Critique: find the failure modes in a given design45 min
HTTP
A web request passes through distinct layers, each adding a capability and a potential source of setup work.
Read upward from the hostname: each layer solves a different problem, but each also represents another step before application data can be processed.
These responsibilities compose in sequence rather than compete. DNS must produce an address before transport can connect; TLS must establish protection before HTTPS can carry the HTTP exchange. TCP's three-way handshake itself uses SYN, SYN-ACK, and ACK before data transmission, so a new connection pays setup latency that a reused connection avoids. The benefit is separation: you can investigate naming, delivery, confidentiality, and application behavior independently instead of calling every delay “the network.”
The job of this stack is to turn a human-facing web request into a correctly addressed, appropriately reliable, authenticated, confidential application exchange.
DNS Resolution: Turning a Hostname into an Address
Every connection starts with a name, not an IP address. Before a client can open a socket to api.example.com, the operating system needs an address for that hostname. DNS, the Domain Name System, translates human-readable hostnames into IP addresses before connection establishment. It behaves like a distributed phone book: local caches can answer quickly, while name servers provide progressively more authoritative information when a cache misses.
The client checks its browser cache first, then the OS cache. A valid entry in either cache returns the address without contacting a DNS server. On a miss, the client asks a recursive resolver, commonly operated by an ISP or corporate network. The resolver may already have the answer cached. Otherwise, it follows referrals: a root name server identifies the relevant top-level-domain (TLD) name server, the TLD server identifies the authoritative name server for the domain, and the authoritative server returns the record. The resolver passes the address back to the client and caches it.
The lookup checks the browser cache for a non-expired answer, then checks the OS cache. If both miss, the client sends the hostname to a recursive resolver. When the resolver lacks a cached answer, it queries the root name server for a referral, then the relevant TLD name server for a referral, and finally the authoritative name server for the record. The recursive resolver caches the returned address for its TTL and returns the address to the client.
The important branch in the lookup algorithm is not merely “cache or server.” Each cache entry carries a TTL, or time to live. While the TTL has not expired, the cached address can be reused; after expiry, the resolver must obtain a fresh answer. A lower TTL makes record changes visible sooner, but it also causes more cache misses, more resolution round-trips, and therefore more lookup latency. The decision is operational: use longer caching when stability matters more than rapid change propagation, and investigate the cost of repeated resolution when records need to change quickly.
For github.com, a cold path can look like this: the OS checks its cache and misses, then asks the ISP's recursive resolver. That resolver fans out through the root, the relevant TLD, and the authoritative name server, which returns an address such as 140.82.121.4; the answer then travels back through the resolver to the client. DNS lookup is therefore a hidden cost before TCP, TLS, or HTTP begins. A connection kept open can avoid repeating the full connection setup, but TTL expiry still means the name may need to be resolved again while the client continues operating.
A cache hit returns locally; a cold miss follows referrals through the DNS hierarchy before returning an address.
Follow the two short cache-hit paths to the client, then trace the cold miss from the recursive resolver through the root, TLD, and authoritative name servers before the address returns.
TCP and UDP: Two Delivery Contracts
TCP and UDP make different delivery promises at the transport layer. TCP is connection-oriented: it establishes a connection before application data is sent, then provides an ordered, reliable byte stream. UDP is connectionless: it sends independent datagrams without first establishing a connection, so delivery, order, and duplication are the application's concern.
A new TCP connection begins with three messages. The client sends SYN; the server answers SYN-ACK; the client completes setup with ACK. Only then can application data flow. That setup costs one round-trip time before the first byte of application data arrives. At scale, connection reuse matters because a reused connection avoids paying that handshake before each exchange.
text
TCP:
client -> server: SYN
server -> client: SYN-ACK
client -> server: ACK
connection established
send data with sequence numbers
if acknowledgment is missing:
retransmit lost packets
deliver data in the correct order
UDP:
send datagram without establishing a prior connection
send the next datagram
do not wait for acknowledgments
do not retransmit lost packets
application handles loss, order, and duplication
TCP establishes a connection and recovers lost data; UDP sends datagrams without a prior connection or built-in recovery.
After setup, TCP attaches sequence numbers to the data and acknowledgments to received data. If an acknowledgment is missing, TCP retransmits the lost segment, and the receiving side delivers bytes in the correct order. The operating system handles these mechanics beneath the application, so a file download can behave like one continuous stream even when the network loses packets.
UDP removes the setup and acknowledgment path. The sender can transmit the next datagram immediately rather than waiting for delivery confirmation, but packets may arrive out of order, be duplicated, or not arrive at all. If the application needs ordering, deduplication, or recovery, it must add those behaviors itself. That can be the right trade when a delayed packet is less useful than a missing one.
TCP spends a round trip establishing reliable delivery; UDP sends immediately and leaves recovery to the application.
Compare the setup cost on the TCP side with UDP's immediate datagrams, then follow where retransmission and acknowledgment exist.
Consider two streams. In live video, a dropped UDP frame may appear as a brief glitch; retransmitting an old frame after the playback position has moved can be less useful than sending the next frame. In a file download, correctness matters: a dropped TCP segment stalls the ordered stream until TCP retransmits it. TCP therefore spends time and network capacity preserving the byte sequence, while UDP leaves the application free to decide whether a lost update is worth recovering.
CHECK YOUR UNDERSTANDING
Why can connection reuse reduce latency for a TCP-based exchange?
SHOW ANSWERHIDE ANSWER
A new TCP connection requires the client and server to complete SYN → SYN-ACK → ACK before application data flows, costing one round-trip time. Reusing an established connection avoids that setup for subsequent exchanges.
TLS and HTTP: Authenticating and Protecting the Request
HTTP is the request–response protocol that browsers and APIs use to exchange structured messages over the web. A request carries application-level semantics such as methods and headers; the response carries a status code and data. HTTPS does not replace those semantics. It carries HTTP through TLS, so the application still sends an HTTP request and receives an HTTP response, but the bytes are protected while crossing the network.
TLS adds authentication and encryption
After TCP completes its three-way handshake, TLS establishes the security layer before HTTP data flows. The TLS handshake negotiates cipher suites and lets the server present a certificate signed by a trusted certificate authority (CA). The certificate lets the client authenticate the server’s identity based on that trusted signature. The client accepts the certificate only when it is trusted according to its configured trusted-CA set. Mozilla describes the key property directly: carrying HTTP over TLS “enables the browser to authenticate the identity of the web server to the browser” and keeps messages confidential.
TLS inserts authentication and key negotiation between TCP establishment and encrypted HTTP request–response data.
Follow the sequence from the completed TCP connection through TLS negotiation and certificate verification, then across the boundary where encrypted HTTP application data begins.
The certificate is about identity; the negotiated TLS session is what protects the subsequent exchange. Once the handshake completes, HTTP data is encrypted in both directions. A network attacker cannot read the protected HTTP messages from the encrypted connection. Mozilla characterizes HTTPS as “a secure and encrypted connection between the browser and the website,” while plain HTTP transfers data in the clear.
The cost is an additional handshake boundary on top of TCP. Traditional TLS setup adds another 1–2 round trips before application data flows. TLS 1.3 reduces the normal handshake to 1-RTT; a returning client can use 0-RTT resumption, allowing it to send encrypted application data without waiting for that extra round trip. The trade-off is why connection reuse matters: a reused secured connection avoids repeating TCP and TLS setup for every HTTP request.
text
client -> server: TCP SYN
server -> client: TCP SYN-ACK
client -> server: TCP ACK
new connection: negotiate TLS and verify the server certificate
TLS 1.3 can reduce the handshake to 1-RTT
returning client: use TLS 0-RTT resumption before sending an encrypted HTTP request
client -> server: HTTP GET over TLS
server -> client: encrypted HTTP response
The wire order places TCP establishment before TLS protection and HTTP application data.
Read the wire order from top to bottom. TCP establishment happens first. On a new connection, the client and server then negotiate TLS, the server sends its CA-signed certificate, and the client verifies it against the trusted CA set before sending the HTTP GET. The returning-client branch is different: TLS 0-RTT resumption is followed by an encrypted GET. In either case, the response travels back as encrypted HTTP data.
CHECK YOUR UNDERSTANDING
What does a TLS certificate prove, and who decides whether to trust it?
SHOW ANSWERHIDE ANSWER
It carries the server’s identity in a certificate signed by a certificate authority. The client decides whether to trust it using its trusted CA set; the server’s certificate is not trusted merely because the server presented it.
Worked Example: From `github.com` to an HTTP/2 Request
Consider a user who enters github.com in a browser on a cold cache. The browser and OS do not yet have an address, so the OS asks the ISP's recursive resolver. That resolver fans the query through the DNS hierarchy: a root nameserver identifies the .com TLD nameserver, which identifies GitHub's authoritative nameserver, which returns 140.82.121.4. The resolver passes that address back to the browser. On this cold path, DNS takes approximately 20–120 ms.
The cold request, with arithmetic
The browser can now open a TCP connection to 140.82.121.4. TCP performs its three-way handshake—SYN, SYN-ACK, ACK—before application data flows. A new HTTPS connection then performs the TLS handshake, including server authentication and key negotiation. Only after those steps does the browser send the HTTP request and receive the response. The connection can remain open for later requests or be closed. The complete cold HTTPS path on a new domain can take approximately 200–400 ms before the server processes the request.
text
Cold DNS range: 120 ms / 20 ms = 6×
Complete path range: 400 ms / 200 ms = 2×
DNS share, low end: 20 ms / 400 ms = 5%
DNS share, high end: 120 ms / 200 ms = 60%
The divisions show both the spread in observed cold-path costs and DNS's possible share of the total.
These calculations put the first request in context: the cold-DNS range spans 6×, while the complete cold-path range spans 2×. DNS alone can therefore account for roughly 5%–60% of the full-path range, depending on which endpoints you compare. A warm cache removes much of that lookup work, and reusing the established connection avoids repeating the TCP and TLS setup. The latency is not one monolithic “network” delay; it is the sum of name resolution, transport setup, encryption setup, and application exchange.
The practical trace is therefore: resolve github.com to 140.82.121.4; complete TCP's three-way handshake; complete TLS; exchange the HTTP request and response; then keep the connection alive or close it. When a page is slow only on its first load, inspect the cold DNS path and connection setup before treating the server handler as the bottleneck. When many API calls follow, HTTP/2's multiplexing lets them proceed concurrently on the one secured connection.
CHECK YOUR UNDERSTANDING
A user presses Enter on `https://api.example.com`. What happens before the server receives the HTTP GET, and which protocol is responsible at each step?
SHOW ANSWERHIDE ANSWER
The browser first resolves api.example.com: browser and OS caches are checked, and a cache miss is sent to a recursive DNS resolver, which obtains the address through the DNS hierarchy. The client then opens a TCP connection with SYN, SYN-ACK, and ACK. After TCP is established, TLS authenticates the server and creates the encrypted channel. Finally, HTTP sends the GET over that TLS-protected TCP connection; the connection is then kept alive for reuse or closed.
Choosing TCP, UDP, and Modern Variants
The transport choice follows one question: does a stale or missing packet hurt more than a delayed one? TCP and UDP are not absolute speed tiers. They are different delivery contracts. TCP spends setup and recovery overhead to provide an ordered, reliable stream; UDP sends datagrams without first establishing a connection and leaves loss, duplication, and ordering decisions to the application.
Compare the transport choices by setup, delivery semantics, recovery cost, and the workload they fit.
Handshake
Delivery/order guarantee
Loss behavior
Application responsibility
Best-fit workload
TCP: connection-oriented; establishes a connection before data
Reliable delivery in the correct order; acknowledgments, error checking, and data recovery
Retransmits lost or corrupted packets
TCP handles delivery, ordering, error checking, and recovery
File transfers, emails, web pages, financial transactions, and database updates
UDP: connectionless; sends data without establishing a prior connection
No guarantee of delivery, order, or error-checking
Packets may be lost, duplicated, or received out of order
The application handles any reliability or ordering it needs
Live video streaming, online gaming, VoIP, and video conferencing
QUIC: built on UDP; selective reliability
Recovers only the packets the application needs
Avoids treating every lost packet as a reason to recover the whole stream
The protocol provides selective recovery above UDP
HTTP/3 and latency-sensitive applications
The table's most important contrast is the cost of loss. With TCP, a missing packet triggers retransmission and the ordered stream waits for it. That is the right behavior for a file, database update, financial transaction, or web page: the application needs the complete result in the correct order. With UDP, a lost packet can simply disappear. That fits live video, online gaming, VoIP, video conferencing, and DNS queries, where waiting for an obsolete packet can hurt the experience more than dropping it.
A multiplayer game illustrates the decision. Suppose it sends frequent updates about a player's position. If one position packet is lost, the next update supersedes it. Retransmitting the obsolete position can make the game feel laggier, so accepting the loss is preferable. The same reasoning applies to live media and voice: a late frame or audio sample is often less valuable than the next one. If every byte must arrive, UDP's lower setup cost only moves the reliability work into your application.
QUIC changes the choice without making UDP reliable in the TCP sense. Used by HTTP/3, it builds selective reliability above UDP: it recovers only the packets the application needs instead of treating every loss as a reason to recover the whole stream. That is useful when independent pieces of traffic should not all wait behind one missing packet. The design review should therefore name the required freshness, ordering, and recovery behavior—not just ask whether TCP or UDP is faster.
CHECK YOUR UNDERSTANDING
You are designing a live sports score app that pushes updates every second. A colleague suggests TCP. What is your counter-argument, and what would you use instead?
SHOW ANSWERHIDE ANSWER
Ask whether a delayed update is worse than a missing one. If each new score supersedes the previous value, retransmitting an old update can add latency without improving what the user sees. UDP is a candidate because it avoids connection setup and does not force delivery of obsolete packets; the application must handle any reliability or ordering it actually needs. If the score history must be complete and ordered, TCP is the safer choice.
Failure Mode: Cold DNS, Expired TTLs, and Hidden Latency
A warm DNS cache makes the name-to-address step nearly invisible. The browser, operating system, or recursive resolver can answer from its cached record, so the client proceeds directly to its connection. A cold cache exposes DNS as a latency cost: the recursive resolver must query the DNS hierarchy before it can return an address. NIST describes a recursive resolver as a server that queries authoritative and other servers on behalf of the client; those queries contribute to perceived latency.
The failure appears later, after the service has been running normally. A client uses the cached answer while its TTL remains valid. When that TTL expires, the next connection attempt cannot use the stale answer: the cache misses, the recursive resolver performs the hierarchy lookup again, and the request waits before TCP or TLS can begin. A low TTL makes record changes visible sooner, but buys that freshness with more resolution round-trips and added latency. In a design review, ask explicitly whether the DNS path is warm or cold; otherwise a fast steady-state request can hide a slow first request or post-expiry request.
A cached DNS answer keeps the normal path fast until TTL expiry forces the recursive resolver back through the hierarchy.
Follow the cached answer through TTL expiry, then compare the immediate cache hit with the recursive lookup that delays the next connection.
The operational defence is to treat cache state as part of the request path. Account for browser, OS, and recursive-resolver caching when the freshness requirement permits it, and choose the record's TTL deliberately: longer TTLs reduce hierarchy lookups and their latency but keep old addresses in caches longer; shorter TTLs reduce that staleness window but increase lookup work. Measure warm-cache and cold-cache DNS latency separately, and include an expiry or resolver-outage case in capacity and latency reviews. DNS is a distributed system rather than a one-time lookup: authoritative servers hold zone data, while recursive resolvers obtain answers for clients and cache them only for the record's permitted lifetime.
Failure Mode: TLS Termination Creates a Trust Boundary
TLS termination is an architectural boundary, not merely a performance setting. The client establishes HTTPS with the load balancer; the load balancer decrypts the request and forwards it to a backend pod over plain HTTP inside the VPC. That choice offloads TLS work from every backend service, but it also changes what “encrypted in transit” means: encryption ends at the load balancer unless you deliberately add another protected leg.
The failure appears when the external security property is mistaken for an internal one. A client, dashboard, or compliance checklist may show HTTPS while an observer able to inspect the internal leg can see the load balancer’s backend traffic in plaintext. The HTTP request and response are no longer protected on that leg. This can be acceptable when the internal network is an explicit trust boundary and the data policy permits it; it becomes a compliance problem when policy requires encryption between services or assumes that sensitive data remains encrypted throughout the data centre.
Terminating TLS at the load balancer protects the external leg but leaves the default internal leg plaintext; internal mTLS extends the boundary.
Compare the encrypted client-to-load-balancer leg with the plaintext default path, then follow the alternative mTLS path to see where the trust boundary moves.
The concrete defence is to establish mutual TLS between the load balancer and backend services, or between services after the load balancer. The backend then receives a TLS-protected connection and participates in identity authentication rather than trusting every caller that can reach the VPC. You pay for additional certificate and identity lifecycle management, TLS processing on the internal connections, and configuration of trust between services. The important design decision is where that cost buys a required security property; adding mTLS only at one hop does not protect later plaintext hops.
CHECK YOUR UNDERSTANDING
A load balancer terminates TLS and forwards requests to backend pods. What security property does the client have, and what remains unprotected unless you add mTLS?
SHOW ANSWERHIDE ANSWER
The client has an HTTPS connection protected up to the load balancer. The load balancer-to-backend leg uses plain HTTP and is therefore unencrypted unless mTLS or another internal TLS connection protects it.
How to Discuss Networking in a System Design Interview
A strong design answer locates each delay and reliability decision at a protocol layer. Trace the request in order: resolve the hostname with DNS, establish TCP, negotiate TLS, send the HTTP request, and then reuse or close the connection. When a first request is slow, ask which of those phases is cold: DNS cache, TCP connection, TLS session, or application-level HTTP processing. “The system is slow” is not a diagnosis; “cold DNS added a lookup, then a new TCP and TLS connection delayed the first byte” tells you where to measure and what to change.
DNS: use caching or DNS prefetch when lookup latency is on the critical path; verify whether the observed request had a warm or cold cache.
TCP: use connection pooling and keep-alive to avoid repeating the connection handshake.
TLS: use session resumption when returning clients reconnect, and state where TLS terminates.
HTTP: use HTTP/2 multiplexing when several requests can share one connection instead of paying setup costs separately.
Tie the transport choice to the value of a late packet. If delayed data is worse than stale or missing data, TCP’s ordered recovery may be the wrong contract; UDP can let the application discard obsolete updates and accept the next one. If every byte must arrive correctly, choose a reliable path and say who owns recovery. Modern protocols can add selective reliability above UDP, but that does not remove the need to define which data may be dropped.
Defend the trust boundary explicitly. If a load balancer terminates TLS, the client-to-load-balancer leg is protected, but the next leg needs its own protection if plaintext inside the data centre is unacceptable. State whether internal services use TLS or mutual TLS, how certificates are trusted, and why the boundary belongs there. DNS ownership and cache lifetime deserve the same treatment: ask who controls the records, how warm the caches are, and what happens when a TTL expires.
CHECK YOUR UNDERSTANDING
A user reports that the first page load is slow but later loads are fast. Which layers do you investigate first?
SHOW ANSWERHIDE ANSWER
Compare cold and warm DNS resolution, then check whether later requests reuse TCP and TLS connections. If those phases are warm, investigate HTTP request processing and response generation rather than blaming the network generically.
KEY TAKEAWAYS
DNS resolves a hostname before the client can open a transport connection; cache state and TTL determine whether that lookup is immediate or requires the DNS hierarchy.
TCP spends a handshake and retransmission work to provide an ordered, reliable byte stream, while UDP sends datagrams without built-in delivery, ordering, or recovery guarantees.
TLS authenticates the server through a trusted certificate and protects HTTP messages after the handshake; HTTPS remains HTTP carried over TLS.
Connection reuse avoids repeating TCP and TLS setup, while HTTP/2 multiplexes API requests over one secured connection.
TLS termination protects only the leg up to the terminating component unless subsequent internal legs use their own TLS or mTLS.