Networking Fundamentals: Trace DNS, TCP, UDP, TLS, and HTTP End to End

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. HTTP handles application meaning: methods, headers, status codes, and the request–response exchange that browsers and APIs understand.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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%

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.

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.

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.

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.

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.

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.

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.