Lucent Owl logo Lucent Owl

Networking Diagrams

Last updated:

3 related guides
diagrams tcp nat dns http2 http3

Encapsulation Down the Stack

Layering

Each layer adds its own header in front of the data from above.

An HTTP request wrapped by TCP, IP, and Ethernet Four rows. At the application layer the message is the HTTP request. At the transport layer a TCP header is added in front of it, making a segment. At the internet layer an IP header is added in front of that, making a packet. At the link layer an Ethernet header is added in front and a frame check trailer behind, making a frame. The Ethernet header carries MAC addresses that are rewritten at every hop, the IP header carries host addresses that stay the same end to end, and the TCP header carries ports that identify the process. Application message HTTP request Transport segment TCP header HTTP request Internet packet IP header TCP header HTTP request Link frame Ethernet header IP header TCP header HTTP request FCS MAC addresses, rewritten each hop host addresses, end to end ports, which process on the host

A Packet Crossing Two Routers

Flow

The IP addresses stay fixed end to end while each hop gets a new frame.

A packet forwarded hop by hop from a host to a server A host at 10.20.10.15 sends a packet to a server at 198.51.100.10. On the first link the frame goes from the host's MAC address to the gateway router's MAC address. The gateway builds a new frame from its own MAC address to the next router's MAC address. The next router builds a third frame to the server's MAC address. On every link the IP header stays the same: source 10.20.10.15, destination 198.51.100.10. Each router chooses the next hop from its own routing table. Host 10.20.10.15 Gateway router looks up next hop Next router looks up next hop Server 198.51.100.10 frame on link 1 MAC host to gateway IP 10.20.10.15 to 198.51.100.10 frame on link 2 MAC gateway to next IP 10.20.10.15 to 198.51.100.10 frame on link 3 MAC next to server IP 10.20.10.15 to 198.51.100.10 MAC addresses: rewritten on every link IP addresses: unchanged end to end (unless NAT rewrites them)

Port Address Translation

Flow

Two private hosts share one public address through a translation table.

NAT with port translation between a private network and a server Two hosts on a private network, 10.0.1.23 and 10.0.1.40, both open connections from source port 51514 to a server at 198.51.100.10 port 443. The NAT device rewrites each source to its public address 203.0.113.7 with a distinct port, 40001 and 40002, and records both mappings in its translation table. The server's reply to 203.0.113.7 port 40001 is translated back to 10.0.1.23 port 51514. A connection attempt arriving from the internet with no matching table entry is dropped. private network Host A 10.0.1.23 Host B 10.0.1.40 NAT device public address 203.0.113.7 Translation table inside outside 10.0.1.23:51514 :40001 10.0.1.40:51514 :40002 Server 198.51.100.10:443 src :51514 src :51514 src .7:40001 reply to :40001 Internet host unsolicited connection no table entry: dropped outbound, source rewritten reply, destination rewritten back

Public and Private Subnets

C4 · Deployment

The default route decides whether a subnet is public or private.

A cloud network with a public subnet and a private subnet A cloud network with an internet gateway at its edge and two subnets. The public subnet's route table sends 0.0.0.0/0 to the internet gateway, and it holds a load balancer and a NAT gateway. The private subnet's route table sends 0.0.0.0/0 to the NAT gateway, and it holds the application instances. Inbound requests come from the internet through the internet gateway to the load balancer and then to the instances. Outbound calls from the instances go to the NAT gateway, then the internet gateway, then the internet. Both route tables also route the network's own range, 10.20.0.0/16, locally. Internet cloud network 10.20.0.0/16 Internet gateway Public subnet Load balancer NAT gateway route table 10.20.0.0/16 local 0.0.0.0/0 internet gateway Private subnet App instances private addresses only route table 10.20.0.0/16 local 0.0.0.0/0 NAT gateway inbound request outbound call from a private instance

A New HTTPS Connection

C4 · Dynamic

TCP, TLS 1.3, and the first request each cost one round trip.

Round trips before the first response byte on a new HTTPS connection A sequence between a client and a server. First round trip, the TCP handshake: the client sends SYN and the server replies SYN-ACK. Second round trip, the TLS 1.3 handshake: the client sends ACK with the TLS ClientHello, and the server replies with ServerHello, its certificate, and Finished. Third round trip, the request: the client sends TLS Finished with the HTTP request, and the server replies with the first byte of the HTTP response. A request on a connection that is already open costs only the third round trip. Client Server SYN SYN-ACK ACK + TLS ClientHello ServerHello, certificate, Finished TLS Finished + HTTP request first byte of HTTP response TCP handshake 1 round trip TLS 1.3 1 round trip Request 1 round trip (the only one when reused)

TCP Congestion Window Over Time

Chart

The window doubles each round trip, then grows slowly and halves on loss.

Illustrative TCP congestion window across round trips A line chart of how much data a TCP sender allows in flight, across successive round trips. In slow start the window doubles every round trip, from one segment to thirty-two over five round trips. Growth then turns linear, adding a little each round trip. When a packet is lost the window is cut in half, and linear growth resumes from there. The shape is the classic Reno-style pattern; newer algorithms such as CUBIC and BBR grow differently. data allowed in flight (congestion window) round trips slow start: doubles every round trip then grows a little each round trip packet lost window halved Illustrative, classic Reno-style shape. CUBIC and BBR grow differently.

Resolving a Name

Flow

A recursive resolver follows referrals from the root down to the authoritative server.

DNS resolution of api.example.com on a cold cache The application asks the operating system's stub resolver, which asks one recursive resolver. The recursive resolver asks a root server, which refers it to the com servers. It asks a com TLD server, which refers it to the example.com servers. It asks the example.com authoritative server, which answers with an A record and its TTL. The answer returns through the recursive resolver and stub resolver to the application. The recursive resolver caches answers, and the stub resolver may too, and a recursive resolver with a warm cache answers without asking the other servers. Application api.example.com? Stub resolver in the OS, may cache Recursive resolver ISP, public, or VPC caches every answer Root server refers to the com servers com TLD server refers to example.com servers example.com authoritative A 203.0.113.10, TTL 300 1 2 3 Warm cache: answers at once, skipping steps 1 to 3

Lowering a TTL for a Cutover

Chart

How long caches can hold the old address when the TTL is lowered early or late.

Cache lifetimes around a DNS cutover, lowering the TTL early versus at the cutover A timeline, not to scale. In the first plan, the TTL is lowered from one day to 60 seconds a full day before the cutover. Answers cached just before the change can live for up to a day, but they have all expired by the cutover. Answers cached after the change live 60 seconds each, so after the cutover the old address lingers for at most 60 seconds. In the second plan, the TTL is lowered at the moment of the cutover. Answers cached shortly before it still carry the one-day TTL, so some clients keep the old address for up to a day after the cutover. Lower first cached just before the TTL change: up to 1 day cached after: 60 s each old address gone within 60 s Lower at cutover cached before the cutover with the 1-day TTL old address for up to a day TTL lowered (first plan) one old TTL later cutover time, not to scale

DNS Forwarding in a Hybrid Network

Flow

Each side forwards queries for the other side's zone.

Conditional forwarding between on-premises DNS and a cloud resolver Two networks. On premises, office clients query the corporate DNS servers, which serve corp.example.com and forward queries for internal.example.com to the cloud resolver. In the cloud network, workloads query the cloud resolver, which holds the private zone internal.example.com and forwards queries for corp.example.com to the corporate DNS servers. If either forwarding rule is missing, names from the other side return NXDOMAIN. on-premises network cloud network Office clients Corporate DNS servers serve corp.example.com forward internal.example.com Cloud workloads Cloud resolver private zone internal.example.com forwards corp.example.com queries for internal.example.com queries for corp.example.com A missing rule on either side leaves the other side's names returning NXDOMAIN.

Head-of-Line Blocking by Version

Flow

What a slow response or a lost packet holds up in each HTTP version.

Head-of-line blocking in HTTP/1.1, HTTP/2, and HTTP/3 Three rows showing data arriving on one connection over time. In HTTP/1.1, a slow response A occupies the connection and requests B and C queue behind it. In HTTP/2 over TCP, packets from streams 1, 2, and 3 interleave; when a packet for stream 2 is lost, every packet that arrives after it is held until the retransmission, whichever stream it belongs to. In HTTP/3 over QUIC, the same loss holds only the later stream 2 packet, and the packets for streams 1 and 3 are delivered. arrival order on one connection HTTP/1.1 over TCP response A (slow) B C B and C queue behind A HTTP/2 streams over TCP 1 2 3 1 3 1 2 3 every stream waits for the retransmission stream 2 packet lost HTTP/3 streams over QUIC 1 2 3 1 3 1 2 3 only stream 2 waits stream 2 packet lost delivered to the application received but held back lost

Discovering HTTP/3

Flow

Alt-Svc or a DNS HTTPS record tells the client to try QUIC.

Two ways a client learns a server supports HTTP/3 First way: the client connects to the server over TCP and TLS, offering h2 and http/1.1 through ALPN, and the server's response carries an Alt-Svc header advertising h3 on UDP port 443. Second way: the client looks up the domain's DNS HTTPS record, which lists h3 and h2 among its supported protocols. Either way, the client then connects over QUIC on UDP port 443, and falls back to TCP if the QUIC attempt fails. Client browser or library Server TCP 443 and UDP 443 DNS HTTPS record for the domain TCP + TLS, ALPN offers h2 and http/1.1 response header Alt-Svc: h3=":443" QUIC on UDP 443, HTTP/3 if it fails, the client stays on TCP look up the HTTPS record alpn: h3, h2 (QUIC on the first connection)

Two Protocol Hops Through a Load Balancer

C4 · Deployment

Clients negotiate a version with the balancer, which forwards over its own connections.

A load balancer terminating client connections and forwarding to services Clients on the internet connect to a load balancer over HTTP/2 with TLS, or HTTP/3 where the load balancer supports it. Client connections end at the load balancer, which is the trust boundary and enforces idle timeouts, stream limits, and connection-level defenses. Inside the private network, the load balancer opens its own connections to two service instances, over HTTP/1.1 by default or HTTP/2 or gRPC when configured. The services handle request-level concerns such as size limits, authentication, and per-user rate limits. Clients browsers, apps, API consumers your private network trust boundary: client connections end Load balancer terminates TLS idle timeouts, stream limits connection-level defenses Service instance size limits, auth, per-user rate limits Service instance size limits, auth, per-user rate limits HTTP/2, or HTTP/3 if the front end supports it HTTP/1.1 by default or HTTP/2, gRPC if set

Found this useful? Share it:

Share on LinkedIn