Networking Fundamentals

The Network Stack

Before a client can talk to a server, several layers of networking infrastructure must cooperate. Every request you send travels through a stack of protocols, each handling a different concern: addressing, routing, reliability, and application logic. Understanding these layers is essential for diagnosing performance issues and making informed architectural decisions.

This session covers the protocols and components that make networked communication possible: IP, DNS, TCP, UDP, HTTP/HTTPS, WebSocket, and proxies.

IP: Addressing and Routing

The Internet Protocol (IP) is responsible for one thing: getting a packet from one machine to another. Every device on a network has an IP address. IPv4 addresses are 32-bit numbers written as four octets (e.g., 192.168.1.1), giving roughly 4.3 billion possible addresses. IPv6 addresses are 128-bit, written in hexadecimal groups (e.g., 2001:0db8::1), providing a vastly larger address space.

IP is a best-effort protocol. It routes packets toward their destination, but it does not guarantee delivery, ordering, or integrity. Those guarantees are the job of the transport layer above it.

DNS: Translating Names to Addresses

Humans use domain names (google.com, hibranwar.com). Machines use IP addresses. The Domain Name System, defined in RFC 1035, bridges that gap. DNS is a distributed, hierarchical database that maps domain names to IP addresses.

When you type a URL into your browser, a DNS resolution process begins. It follows a chain of servers, each responsible for a different level of the domain hierarchy.

The recursive resolver (often provided by your ISP or a service like Cloudflare's 1.1.1.1) does the heavy lifting. It contacts root servers, TLD servers, and authoritative servers on your behalf. Results are cached at multiple levels, so most lookups resolve quickly from cache rather than traversing the full chain.

TCP vs. UDP: The Transport Layer

Once DNS resolves the destination IP, the transport layer takes over. Two protocols dominate this layer: TCP and UDP. They represent fundamentally different trade-offs between reliability and speed.

TCP (RFC 793) provides a reliable, ordered, error-checked byte stream. Before any data flows, TCP establishes a connection using a three-way handshake (SYN, SYN-ACK, ACK). It guarantees that every byte arrives, in order, with no corruption. If a packet is lost, TCP retransmits it. This reliability comes at a cost: latency from the handshake, overhead from acknowledgments, and reduced throughput from congestion control.

UDP (RFC 768) is the opposite. No connection setup. No delivery guarantee. No ordering. No retransmission. A UDP packet is sent and forgotten. The entire UDP header is only 8 bytes, compared to TCP's minimum of 20 bytes. What you lose in reliability, you gain in speed and simplicity.

The choice between TCP and UDP depends on whether your application can tolerate packet loss. A bank transfer cannot lose data, so it uses TCP. A video call can tolerate a dropped frame (you will not even notice), so it uses UDP. Waiting for retransmission in a live video call would cause stuttering, which is worse than losing a single frame.

HTTP and HTTPS

HTTP (Hypertext Transfer Protocol) is the application-layer protocol that powers the web. It runs on top of TCP (or, in HTTP/3, on top of QUIC, which runs on UDP). HTTP defines how clients and servers structure their messages: request methods, headers, status codes, and bodies.

HTTPS is HTTP with TLS (Transport Layer Security) encryption. The client and server perform a TLS handshake to establish an encrypted channel before any HTTP data flows. This protects data from eavesdropping and tampering in transit. Every production web application should use HTTPS.

WebSocket

HTTP follows a strict request-response pattern: the client asks, the server answers. But some applications need the server to push data to the client without being asked. Chat applications, live dashboards, multiplayer games, and real-time collaboration tools all require this capability.

WebSocket solves this. It begins as a standard HTTP request with an Upgrade header. If the server agrees, the connection is upgraded to a persistent, full-duplex channel. Both client and server can send messages at any time, in either direction, without the overhead of establishing new connections.

Forward and Reverse Proxies

A proxy is an intermediary that sits between a client and a server, forwarding requests and responses. There are two types, and they serve very different purposes.

A forward proxy sits in front of clients. The client sends its request to the proxy, and the proxy forwards it to the destination server. The server sees the proxy's IP address, not the client's. Forward proxies are used for privacy, access control (blocking certain websites), and caching. Corporate networks often route all employee traffic through a forward proxy.

A reverse proxy sits in front of servers. The client sends its request to the proxy, thinking it is the actual server. The proxy forwards the request to one of several backend servers. Reverse proxies are used for load balancing, SSL termination, caching, and security (hiding the true server infrastructure). Nginx, HAProxy, and Cloudflare are common reverse proxies.

In systems thinking terms, a reverse proxy is a leverage point. It sits at a junction where many connections converge, making it an ideal place to implement cross-cutting concerns: rate limiting, authentication, logging, compression, and caching. Changing behavior at the proxy affects every request flowing through the system without touching any backend server.

Further Reading

• RFC 1035: Domain Names, Implementation and Specification. The foundational specification for the Domain Name System.
• RFC 793: Transmission Control Protocol. The original TCP specification.
• RFC 768: User Datagram Protocol. The UDP specification. Three pages. The shortest RFC you will ever read.
• Wikipedia: Domain Name System. A thorough overview of DNS architecture, record types, and resolution process.
• MDN: WebSockets API. Practical documentation on using WebSocket in web applications.