Network Protocols

One tap becomes many conversations

Networking layers in simple language

Encapsulation means that each layer wraps the information from the layer above it. An HTTP request becomes bytes in a TCP stream; TCP segments carry portions of those bytes, IP packets carry the segments, and link-layer frames carry packets across each local hop. The receiving side removes those wrappers in reverse. A router normally forwards using IP information without interpreting your application’s JSON.

The layers provide different promises. IP attempts to move packets to a destination. TCP reconstructs an ordered byte stream using sequence numbers, acknowledgments, and retransmission. HTTP gives those bytes application meaning. None of those steps alone proves that a database transaction committed, so an application acknowledgment and a retry strategy are still necessary.

Think of layers as a way to follow one request from your app all the way down to signals on a wire or radio. When something breaks, layers help you ask: is this an app problem, a delivery problem, or a routing problem?

What actually happens across the layers

IPv4 vs IPv6: how devices get addresses

Every device needs an address so packets know where to go. IPv4 is the older, still-common system. IPv6 is the newer one with far more addresses.

Routers, IP addresses, and load balancers

Routers read the destination on each packet and choose the next step. A public IP is like a street address on the internet. A private IP is like a room number inside one building.

How a TCP conversation starts and ends

Before useful data can move, TCP spends a short hello exchange so both sides agree they are ready. When the conversation is over, each side says goodbye carefully so nothing is lost mid-sentence. That setup cost is the price of reliability.

A simple web request, end to end

One browser click feels like a single GET. Underneath, it is a short story: find the address, say hello, exchange the HTTP request and response, then say goodbye. Many packets hide behind one conceptual request.

sequenceDiagram
    autonumber
    participant Browser
    participant DNS
    participant Server

    Browser->>DNS: Resolve example.com
    DNS-->>Browser: Destination IP
    Browser->>Server: SYN
    Server-->>Browser: SYN-ACK
    Browser->>Server: ACK (TCP ready)
    Browser->>Server: HTTP request (GET / path, headers)
    Server-->>Browser: HTTP response (status, headers, body)
    Browser->>Server: FIN
    Server-->>Browser: ACK
    Server->>Browser: FIN
    Browser-->>Server: ACK (connection closed)

How TCP learns a safe sending speed

The internet is shared. If every app blasts data as fast as possible, routers overflow and everyone slows down.TCP tries to find a safe speed: send a bit more when the path looks healthy, and back off when the network starts struggling.

TCP: the careful default for most traffic

Most of the internet prefers TCP because missing data is usually worse than waiting a little. If every byte must arrive in order, TCP is the usual starting point.

TCP vs UDP in plain words

Think of two ways to send news across town.TCP is careful and checks that every piece arrived in order.UDP is quick and light: it sends each piece and moves on, even if a few never arrive.

When UDP is the better story

UDP is useful when waiting for a missing packet would hurt more than skipping it. There is no long hello, and the protocol itself does not promise delivery. Your app decides what to do if something never arrives.

How to choose UDP (and when to mix)

Choose UDP when late data is worse than missing data. Even then, browsers and mixed systems often still use TCP for setup, auth, and control.

How HTTP got faster: 1.1 → 2 → 3

The meaning of HTTP stayed familiar: methods, paths, headers, status codes. What changed is how those requests share a connection and how quickly encryption can start, especially on busy pages and mobile networks.

HTTP/2: many requests, one conversation

HTTP/2 breaks traffic into small frames so several requests can share one TCP connection. A slow response no longer has to block every other response on that same pipe.

HTTP/3 and QUIC: fewer freezes on bad networks

QUIC runs over UDP but provides its own reliable streams, encryption, loss recovery, and congestion control. Consequently, HTTP/3 is suitable for reliable API traffic; “uses UDP” does not mean “loses application requests without recovery.” Stream independence prevents missing bytes in one stream from blocking delivery of unrelated streams, although all streams still share connection-level resources and congestion conditions.

HTTP/3 still feels like HTTP to your app, but it rides on QUIC over UDP. That matters most when the network is lossy or a phone switches networks mid-session.

Where QUIC fits in the story

QUIC provides reliable streams, congestion control, and encryption over UDP. HTTP/3 uses these streams to carry HTTP requests and responses. The useful distinction is between losing data within one stream and making unrelated streams wait for that same loss.

TLS 1.3: the lock starts sooner

TLS is how the client and server agree on secret keys and prove the server is real. Newer TLS spends fewer round trips on that hello, so encrypted data can begin sooner. That is why HTTPS feels snappier with TLS 1.3.

DNS: turning a name into an address

The client usually asks a recursive resolver, which answers from cache or queries the DNS hierarchy until it reaches an authoritative server for the name. A hostname can map to several addresses and those answers can change. The TTL tells caches how long an answer can be reused; it does not force an already-open TCP connection to reconnect. During a migration, account for cached answers and existing connections separately.

When you type a site name, your device asks DNS for the matching IP address. It usually checks nearby caches first, then asks farther helpers until an authoritative answer arrives.

Rough latency numbers that keep you honest

These are ballpark times, not exact lab measurements. Use them to ask: is this delay from memory, disk, the same region, or another continent?

UDP in the real world

The pattern is the same in different products: if waiting for a missing packet ruins the experience, send quickly and let the app decide what to do with gaps.

Which protocol fits which job?

Start from the job, not from the newest acronym. Ask whether you need perfect delivery, low delay, browser support, or control of both ends.

How to debug network problems calmly

Measure a timeline before changing protocols: DNS lookup, connection establishment, TLS negotiation, request upload, time to first response byte, and response download. A slow first byte with fast setup may indicate application queuing or database work; a slow large download may indicate bandwidth or loss. Compare cold and reused connections, and check whether a proxy introduces its own timeout. This separates a network symptom from a server bottleneck.

A vague "it is slow" becomes clearer when you split the path into names, connection setup, encryption, transport health, and the app itself.

Where time goes in one request

A user action is a chain of waits: find the name, open a connection, encrypt, send the request, do server work, download the response, then render.

sequenceDiagram
    autonumber
    participant Client
    participant DNS
    participant Edge as Edge or proxy
    participant App as Application tier
    participant Data as Cache or database

    Client->>DNS: Resolve host, often cached
    DNS-->>Client: Address from DNS records or traffic policy
    Client->>Edge: TCP 3-way handshake or QUIC setup
    Client->>Edge: TLS handshake and protocol negotiation
    Client->>Edge: Send headers and optional body
    Edge->>App: Reuse pooled upstream connection
    App->>Data: Read, write, or cache lookup
    Data-->>App: Result
    App-->>Edge: Status, headers, body
    Edge-->>Client: Compressed response bytes
    Client->>Client: Parse, execute, render, cache

Why reusing a connection feels so much faster

Saying hello once and keeping the pipe warm beats paying the hello tax on every request, especially when latency is high or you make many calls.

Your app vs the plumbing underneath

Your code talks in HTTP or gRPC meaning. Underneath, sockets, packets, and congestion control move the bytes. Keep those two stories separate and systems get easier to reason about.

Try it: watch one request in packets

A packet capture turns the story into evidence. You can see where time went: name lookup, hello, encryption, first response, or lost packets.

1. Run curl -v https://example.com/api/health once cold, then again within a minute while the connection is still warm.
2. Capture traffic with Wireshark or tcpdump, filtered to your host on tcp port 443.
3. Mark DNS, the TCP hello, the TLS hello, and the first HTTP request and response.
4. Compare cold vs warm: how many waits disappear when the connection is reused?
5. Look for retransmits. Loss often shows up in the capture before your app logs a timeout.

Quantitative example: handshake tax on a 100 ms path

Suppose client ↔ edge round trip is 100 ms. In a simplified loss-free model, a cold TCP connection costs about 1 RTT before the client can send its TLS handshake, then TLS 1.3 costs about 1 more RTT before ordinary application data: roughly 200 ms of setup. The request and first response byte add about another RTT, giving roughly 300 ms before server processing and DNS. Twenty sequential cold calls repeat that setup cost; parallel calls overlap it, so their wall times must not simply be added. Keep-alive / HTTP/2 multiplexing pays that tax once; QUIC 0-RTT on a resumed path can reduce setup waiting only for operations permitted by the application’s replay policy. Early data can be replayed and may be rejected by the server. By contrast, a live game tick over UDP may accept a 1–2% packet loss rather than adding one extra RTT of retransmit delay that makes the update stale.

Failure timeline: loss, HOL blocking, then timeout

T+0      Client sends HTTP/2 stream A (CSS) and stream B (API JSON) on one TCP
T+20ms   One TCP segment carrying stream-A bytes is lost on the path
T+40ms   Stream B's packets arrive at the kernel, but TCP holds them (HOL)
T+120ms  Illustrative loss-detection point; TCP retransmits the missing segment
T+140ms  Stream B reaches its application deadline while bytes are still blocked
T+160ms  Missing bytes arrive; transport delivery resumes after B has timed out
Outcome  One lost packet delayed an unrelated request; user sees timeout, not "CSS slow"

That is TCP head-of-line blocking under multiplexing.HTTP/3 / QUIC keeps per-stream loss from freezing sibling streams, but loss still costs retransmit delay on the affected stream.

Try it: TCP recovery versus UDP exposure to loss

Adjust loss, pick TCP or UDP, and send bursts. TCP pays extra round trips to repair the stream; UDP leaves gaps for your application to detect.

Exercises