Understanding network infrastructure · Introduction · Seeing the whole exchange first
What happens between entering a URL and seeing the website?
One round trip: endpoint setup, DNS, the first frame, transport, the route, and the response
From the moment you type a name in the address bar until the page appears, your endpoint and the network devices perform a series of tasks. The endpoint uses DNS to find the server's address, looks up the next hop's MAC address, and establishes TCP and TLS connections. Routers and NAT devices deliver packets to the server and carry the response back. We follow one request and response from start to finish, distinguishing each technology's role and the values that change along the way.
Before the browser sends a packet, what settings does the endpoint need?↑
Before sending an Ethernet frame for the web request, the browser needs to resolve the destination name. The endpoint must have its own IP address and prefix, a default gateway, and a DNS server. These values can be entered manually or obtained through mechanisms such as DHCP and IPv6 router advertisements.
Cached DNS results and connection information may let the system skip some queries. If a packet capture shows no DNS queries, that does not mean DNS played no part in the connection.
We will use the following example: endpoint 10.0.0.25/24, default gateway 10.0.0.1, and DNS server 10.0.0.53. When the browser passes the name to the resolver, the operating system first finds the DNS server's route and next hop. Although DNS prepares for the web connection, the DNS query itself already needs an IP route and Layer 2 delivery. A missing setting can stop this preparatory exchange before the first web packet is created.
A cache can hide these steps from view. A valid DNS cache entry removes the need for a query; an ARP cache entry can avoid the gateway lookup broadcast. Reusing an open HTTP/2 connection may also mean there is no new TCP handshake. When reading a packet capture, check the cache and connection state to distinguish a failed step from one whose earlier result is being reused.
A capture does not always show the preparatory exchanges. If a DHCP lease, DNS answer, ARP entry, or existing connection remains available in the cache, the browser can reuse it. Before treating a missing packet as evidence that a step never happened, check when the cache entries and connection state were created and when they expire.
Sources for this section IETF RFC 1034 · IETF RFC 2131 · IETF RFC 4861
Reading the diagram Compare automatic assignment and manual configuration as alternatives for the endpoint. Read the four DHCP DORA messages and the static IP, mask, and gateway values, noting that manually assigned address 10.0.0.25 must be excluded from the dynamic pool. No DNS value is shown separately in this diagram.
↔ Scroll horizontally to explore the diagram.
How does DNS turn the name you enter into an IP address?↑
The browser asks the operating system's resolver for the address of www.imbizcorp.com. The resolver checks its cache and, if needed, queries the configured DNS server. The answer may contain an IPv4 A record or an IPv6 AAAA record.
DNS does not deliver server-bound packets. It supplies the destination IP address for the next step. If several addresses are returned, the operating system and application decide which addresses to use and in what order to try them.
www.imbizcorp.com may resolve through a CNAME to several A or AAAA records. The resolver retains the answer for its TTL in the cache. The client chooses which address to try first according to its address-selection policy and whether connection attempts succeed. Two endpoints entering the same name at the same time can therefore choose different server IP addresses. That can be normal in a CDN or load balancer deployment.
Receiving a DNS answer does not establish that the service at that address is reachable. When checked on 2026-09-03, www.imbizcorp.com returned A records including 104.21.30.148. If that address is selected, the next step is to trace a new flow identified by that IP and port. An incorrect record can lead the network to deliver packets correctly to the wrong destination. Record the query name, record type, selected IP, and TTL so that a report of successful name resolution does not hide a wrong-destination problem.
DNS supplies the destination information needed for the next step; it does not handle server-bound packet delivery. The operating system and application decide which address to try first and when to try another after a failure. During troubleshooting, record the query name, returned addresses, TTL, response code, and the address the browser actually selected as separate facts.
Sources for this section IETF RFC 1034
Reading the diagram This separate example uses a router DNS proxy forwarding queries to 8.8.8.8, rather than the article's DNS server at 10.0.0.53. Follow the stub resolver to the recursive resolver, then through root, TLD, and authoritative servers in the DNS resolution process. Trace the three queries made on a cache miss and the return of A record 104.21.30.148 to the endpoint's cache.
↔ Scroll horizontally to explore the diagram.
Local or remote? The endpoint needs a different MAC address for each↑
In this IPv4 example, the endpoint compares a route's prefix with the destination IP address to select a next hop from its routing table. If a directly connected local prefix route is selected, it looks up the destination host's MAC address. When a route to a different prefix is selected, it does not look for the destination server's MAC address. It uses the next-hop router, which is the default gateway only when the default route is selected. The next hop's MAC address is resolved using ARP; IPv6 uses Neighbor Discovery.
The IP destination remains the server's address. Only the Ethernet destination MAC address points to the next device on the current link. Each router replaces the Layer 2 header, but in ordinary forwarding the IP destination continues to identify the final server.
Suppose the endpoint is 10.0.0.25/24 and the DNS-resolved server is 104.21.30.148. Their network addresses differ. The endpoint does not ask for 104.21.30.148's MAC address; it looks up 10.0.0.1's MAC address with ARP. The first frame's destination MAC identifies the gateway, while the enclosed IP destination still identifies the server. The Layer 2 destination is the receiving device on this link; the Layer 3 destination is the final communication peer.
For destination 10.0.0.80, however, the endpoint recognizes the same /24 and asks directly for that host's MAC address. The switch does not make this decision for it. If the endpoint has the wrong mask, it may query the wrong ARP target, so the gateway may never even receive the packet. Look at the queried IP in the ARP capture to see whether the endpoint considered the destination local or remote.
Keep the Layer 3 and Layer 2 destinations distinct. When sending to remote server 104.21.30.148, the IP destination stays the same, but the first Ethernet frame's destination MAC identifies the gateway. Every router creates a new link-appropriate Layer 2 header. There is no internet-wide search for the final server's MAC address.
Sources for this section IETF RFC 826
Server IP resolved? TCP and TLS still have work to do↑
For HTTPS, the browser typically connects to the server on TCP port 443. TCP exchanges SYN, SYN-ACK, and ACK to synchronize sequence numbers and establish connection state at both ends. Above that, TLS negotiates encryption algorithms and keys and validates the server certificate.
This stage can fail even after DNS succeeds. A firewall may block the port, or the server process may not be listening, preventing the TCP connection from completing. With a certificate-name or trust-chain mismatch, TCP may connect but TLS can still fail.
The client chooses temporary source port 51514 and sends 104.21.30.148:443 a SYN. The endpoints distinguish this flow by the two addresses, the two ports, and TCP as the protocol. The returning SYN-ACK and delivered ACK establish the TCP state needed to exchange application data reliably. An RST may indicate rejection by the destination or an intermediate device. Check the target port and policies along the path, but do not treat the reset alone as proof that the final destination was reached. No response calls for further checks for drops and return-path problems.
The TLS handshake exchanges the ClientHello server name and supported ciphers, the server certificate, and key-agreement information. A failure here may appear in a TCP capture as a successful connection followed by an alert or closure. Modern browsers may instead use HTTP/3 over UDP-based QUIC, but the central lesson of this TCP/TLS example still applies: DNS resolution, transport connectivity, and an encrypted application session each have their own completion conditions. Identify how far the exchange actually got.
Successful DNS resolution cannot carry the connection past a firewall blocking TCP/443 or a server process that is not listening. A successful TCP connection can still be stopped by certificate or TLS policy problems. HTTP/3 uses QUIC and UDP, a different transport arrangement. The TCP exchange here is a representative path, not a fixed sequence for every browser connection.
Sources for this section IETF RFC 9293 · IETF RFC 8446
Reading the diagram Compare the Seq and Ack values in the TCP three-way handshake messages with the server kernel's SYN and accept-queue processing. Locate where the application takes a socket from the accept queue and starts the TLS 1.3 handshake. This is a typical Linux/nginx example, not a verified diagram of the site's actual server configuration.
↔ Scroll horizontally to explore the diagram.
Packets passing through a router get ready for the next link↑
Each router looks up the destination IP in its forwarding table and selects a next hop and output interface. If a home or enterprise edge uses NAT/PAT, it establishes a mapping for the source address and port and may adjust the packet header and checksum.
A router does not write the entire internet path into the packet. It forwards one step at a time to the next hop it knows. Each intermediate device reduces the TTL or hop limit to prevent endless forwarding.
The first router looks up 104.21.30.148, finds the longest matching entry in its FIB, and selects an output interface and next hop. On an Ethernet link, it resolves the next hop's MAC address, creates a new frame, and discards the old frame header. The next router independently looks up the same IP destination in its own FIB. The packet carries no list of remaining routers, so an intermediate router choosing a different route can change the request's path.
If edge NAT changes the source from 10.0.0.25:51514 to 198.51.100.8:40001, an outside capture no longer shows the internal address. Destination 104.21.30.148:443 and the continuity of the TCP flow remain intact. Put the decreasing TTL, replaced Layer 2 headers, and edge NAT mapping on a timeline to see where and how the same packet changes. These records let you connect logs from several devices to one exchange.
At an edge using NAT/PAT, a mapping is created for the source IP and port, and the header and checksum may change. Even when the inside tuple differs from the outside tuple, matching the TCP sequence number, flags, and timestamp can identify the same packet. Route selection, Layer 2 re-encapsulation, and address translation may happen consecutively in one device, but they are separate decisions.
Sources for this section IETF RFC 3022 · IETF RFC 1812
Reading the diagram Follow the endpoint, gateway, DNS/ISP backbone, and web server along the end-to-end packet journey, with functions numbered 0–8. The numbers do not form a single chronological sequence. Layer 2/Layer 3 delivery and any required NAT translation apply repeatedly to packets in each exchange, including DNS queries and TCP connection setup. DNS address 8.8.8.8 is a separate example from the article's 10.0.0.53. In the router box, compare the 10.0.0.25:51514 ↔ 198.51.100.8:40001 mapping in the request source and response destination.
↔ Scroll horizontally to explore the diagram.
Server responses: which records guide them back to the browser?↑
The server processes the HTTP request and sends response bytes in TCP segments. The response need not take exactly the same path as the request, but it must reach the endpoint and satisfy the edge devices' state and policies. If NAT was used, the edge device looks up the existing NAT mapping and restores the original internal destination IP and port.
The browser interprets the received bytes as HTML, CSS, and JavaScript and may request more resources. The page you see can be the result of multiple DNS, TCP, TLS, and HTTP exchanges, not just one connection.
The server's response reaches the edge with source 104.21.30.148:443 and destination 198.51.100.8:40001. The NAT device matches this external tuple to an existing mapping and restores internal destination 10.0.0.25:51514. An accompanying firewall function may separately check whether the response fits the permitted flow direction and TCP state. Address translation and permission checking remain distinct questions even when one device handles both.
Different internet paths for requests and responses can work if the endpoints maintain compatible TCP state. However, a stateful device that sees only one direction, or ECMP paths that do not share NAT state, can cause a response to be dropped. After confirming that the server sent a response, compare captures outside the edge, inside the edge, and at the client, in that order. Find where the response packet disappears and inspect the last observed header values to narrow the investigation to return routing, policy, or mapping.
Receiving the first HTML document does not finish all the page's communication. CSS, JavaScript, fonts, images, and external APIs can require additional name resolution and connections. HTTP/2 and HTTP/3 can also multiplex several requests over one connection. To investigate a slow page, measure the initial connection separately from later resource requests and identify which flow took the time.
Sources for this section IETF RFC 9293 · IETF RFC 3022
Reading the diagram Follow the three boxes: server-side handling with a typical WAF/reverse proxy arrangement, response-direction PAT reverse mapping, and browser interpretation. Check the destination change from 198.51.100.8:40001 to 10.0.0.25:51514 and the DOM/CSSOM processing steps. The diagram does not verify the site's actual internal deployment.
↔ Scroll horizontally to explore the diagram.
Match the 5-Tuple and timestamps to trace a flow across captures↑
Scenario: Name resolution succeeds, but the HTTPS connection fails after a delay.
- From the DNS response, record the selected server IP address.
- In the endpoint capture, check for an outgoing IP flow to that address with a
TCP/443SYN. - Check for a returning SYN-ACK, RST, or ICMP error. Match TCP responses using the 5-tuple with source and destination reversed and the time; associate ICMP errors with the flow using the original packet headers quoted inside them.
- At the edge device, inspect the flows before and after translation and the firewall policy logs.
- After the change, capture again to see how far the TCP connection and TLS handshake proceed.
This process turns a vague report that the internet is slow into separate measurements of DNS time, TCP retransmissions, TLS negotiation, and server response time.
The 5-tuple consists of source IP, source port, destination IP, destination port, and protocol. Add the capture timestamp and TCP sequence number to compare packets seen at different devices much more precisely. At a NAT boundary, record the inside tuple and outside tuple side by side on one line. Searching only for port 443 mixes hundreds of simultaneous HTTPS flows; fixing these values lets you follow the one connection under investigation.
Break the timing down by stage too: DNS query to answer, first SYN to SYN-ACK, TCP completion to TLS completion, and application request to first response byte. A total of 5 seconds does not tell you which stage was slow. Compare the same test on a healthy endpoint and mark retransmissions and timeouts to distinguish network delay, packet loss, name resolution delay, and server processing delay on the evidence.
The 5-tuple is a starting point for finding a flow, but NAT changes its values. Use timestamps, sequence numbers, flags, and the translation entry together to connect observations at several points into one round trip.
Sources for this section IETF RFC 9293 · IETF RFC 3022
FAQ↑
If no DNS query appears in the capture, was name resolution skipped?
Do requests and responses always pass through the same routers?
Does opening one website use only one TCP connection?
Glossary↑
Sources and verification
- IETF RFC 1034 — DNS concepts and facilities
- IETF RFC 826 — IPv4 ARP operation
- IETF RFC 9293 — the current TCP specification
- IETF RFC 8446 — TLS 1.3 specification
- IETF RFC 3022 — traditional NAT and NAPT
- IETF RFC 2131 — DHCP configuration and lease procedures
- IETF RFC 4861 — IPv6 router advertisements and Neighbor Discovery
- IETF RFC 1812 — IPv4 router forwarding, one hop at a time
Real browsers may take some steps differently because of caching, HTTP/2, HTTP/3, IPv6, and connection reuse. This article presents a representative flow to show how the technologies depend on one another.