02. Fundamentals of Networking

Client-Server Architecture

The client-server architecture represents the foundational revolution in distributed computing. Its core innovation was the ability to separate server and client components into different physical locations, allowing different pieces of code to execute remotely rather than on a single machine. This departure from the era of large, expensive mainframes meant that workloads could now be distributed between cheap commodity hardware on the client side and more powerful servers handling computationally intensive operations.

The fundamental problem this architecture solved was straightforward: machines were expensive and applications were growing increasingly complex. By decomposing a single monolithic application into multiple components that could communicate across a network, the architecture enabled a more efficient allocation of resources. This concept of breaking down monolithic systems into smaller, communicating components would later resurface in modern microservices architectures. Where monolithic services once ran entirely on single machines, microservices decompose them into multiple smaller services that call one another—essentially applying the same principle at a different scale.

The division of labor in client-server systems is based on computational expense. Expensive operations—those consuming significant RAM, CPU cycles, or disk I/O—are offloaded to servers equipped with robust resources. The client, meanwhile, can remain lightweight, functioning as a thin interface that delegates heavy lifting to the server. This elegant separation allows clients to initiate requests for expensive tasks while the server performs the actual computation.

This model gave rise to Remote Procedure Call (RPC), a concept dating back to the 1960s and 1970s. Early remote communication lacked standardization; as long as data could somehow reach the server across the wire, the implementation details were left to individual developers. Over time, standards emerged to formalize these interactions. Modern RPC frameworks like gRPC have built upon these foundational concepts, providing a universal communication protocol between distributed components.

Benefits of Client-Server Architecture

The client-server model offers several key advantages. By centralizing expensive operations on powerful servers while distributing lightweight clients across commodity hardware, the architecture enables better scalability. Multiple clients can connect to a single server, efficiently sharing computational resources. Clients benefit from faster startup times and smaller binary sizes because they no longer carry the full application logic and dependencies—the server handles these responsibilities.

Importantly, clients retain the ability to perform lightweight local tasks. This principle has experienced renewed interest with edge computing, where even Internet of Things (IoT) devices—traditionally viewed as simple sensors transmitting data remotely—can execute local computation. The flexibility to place logic on either the client or server side allows architects to optimize for different performance and resource constraints.

Dependency management also improves under this model. In a monolithic application, every dependency—database drivers, system libraries, and external interfaces—must be installed alongside the application. In a client-server architecture, the server assumes responsibility for these dependencies. If the server needs to communicate with a database, it alone requires the appropriate database driver. The client, freed from these dependencies, simply makes remote calls to the server without needing to understand the underlying implementation details.

The three-tier architecture, which explicitly separates presentation, application logic, and data storage layers, can be understood as a specialized form of the client-server model, with the server tier further decomposed into application and database components.

The Need for Standardization

Despite its advantages, the client-server architecture introduces a critical requirement: a well-defined communication model. Without standardization, distributed systems would devolve into incompatible implementations where each client-server pair uses proprietary protocols. While developers could theoretically transmit data using any medium—radio waves, electrical signals, or custom wire protocols—the absence of common standards would make interoperability impossible. For client-server architecture to realize its full potential, the industry needed universal communication standards that all systems could adopt, ensuring that clients and servers could understand one another regardless of their specific implementations.

OSI Model

The Open Systems Interconnection (OSI) model represents a fundamental framework for understanding networked systems. For any engineer working with networking—whether in software development, infrastructure, or system design—understanding the OSI model’s seven layers is essential. The critical question is not merely what these layers are, but where your application operates within them. Different applications exist at different layers: some examine MAC addresses at layer two, others work with IP packets at layer three, still others operate on TCP segments and ports at layer four, or manipulate encrypted content at layer seven. Content delivery networks, reverse proxies, API gateways, and load balancers all occupy specific positions within this layered architecture, and understanding their placement determines what data they can access and how they function.

Why Communication Models Are Necessary

Agnostic Applications

Without a standardized communication model, building networked applications would be impossible. If no standard existed, servers and clients would have no common language—no agreed-upon method for converting digital bits into analog signals and back, no consistent way to interpret received data. The absence of standards would force every application to implement its own handling of the underlying network medium. This would be catastrophic: developers would need separate versions of their applications for Wi-Fi, Ethernet, LTE, and fiber optic networks, each handling the physical transmission medium differently. Modern developers take this abstraction for granted. When building a Node.js application that sends HTTP requests, the code is identical whether those requests traverse satellite links, Wi-Fi radio waves, Ethernet electrical signals, LTE cellular networks, or fiber optic light pulses. This universality exists because standardized protocols operate globally—indeed, these standards extend even to space-based communications. The OSI model provides this abstraction, allowing developers to write applications without worrying about the physical medium carrying their data. Smart engineers built these layers so that subsequent generations could focus on application logic rather than signal propagation.

Network Equipment Management

Beyond application portability, standardization enables network equipment management and innovation. Without common standards, different routers and switches couldn’t communicate with one another. Each vendor’s equipment would use proprietary protocols, making network upgrades nearly impossible. The OSI model decouples the physical medium from higher-level protocols, allowing network infrastructure to evolve independently. When new physical layer technologies emerge—such as improvements beyond current fiber optic speeds—they can be integrated without redesigning protocols at higher layers.

Decoupled Innovation

The layered architecture also permits independent innovation at each level. Physical layer improvements—faster transmission media or more efficient encoding schemes—don’t require changes to IP routing at layer three or TCP reliability mechanisms at layer four. Similarly, application-level protocols can evolve without modifying the underlying network infrastructure. This independence accelerates technological progress across the entire networking stack. However, this flexibility has limits: certain changes, particularly to widely deployed protocols, encounter “protocol ossification,” where intermediary devices that parse packets in specific ways prevent modifications to header formats or packet structures without breaking existing infrastructure.

The Seven Layers

The OSI model defines seven distinct layers, each describing specific network components and responsibilities.

Layer 7: Application Layer

The application layer represents the highest level of abstraction, though its boundaries can be ambiguous. To a network engineer, layer seven is simply data flowing into the system. To a backend engineer, this layer encompasses libraries, serialization formats, and protocols like gRPC that sit atop lower-level transports. Anything above TCP or UDP—HTTP, FTP, gRPC, custom application protocols—falls into the application layer. Different engineers view this layer from different perspectives depending on their role, but fundamentally, layer seven is where application-specific logic resides.

Layer 6: Presentation Layer

The presentation layer handles encoding, serialization, and data representation. When a JavaScript application sends a JSON object using fetch() or a Python script serializes a dictionary, this conversion from in-memory data structures to byte streams occurs at layer six. The object must be serialized—transformed from language-specific representations into UTF-8 encoded strings or other wire formats that can traverse the network. While developers often think of serialization as part of their application code, the OSI model treats it as a distinct concern. Some engineers argue this distinction is overly granular, questioning whether serialization deserves its own layer, but the separation reflects the fact that encoding and decoding are conceptually distinct from application logic.

Layer 5: Session Layer

The session layer manages stateful connections between endpoints. This is where TLS handshakes occur, where connection establishment takes place, and where session state is maintained on both client and server. The distinction between stateful and stateless protocols manifests at this layer. TCP is a stateful protocol—it maintains session state on both endpoints, tracking connection status, sequence numbers, and flow control windows. If the session is destroyed, the connection must be reestablished or invalidated. UDP, by contrast, is stateless and has no session layer involvement—it simply sends datagrams without maintaining any connection state.

Some engineers question whether the session layer warrants separation from the application layer, but practical systems demonstrate its importance. Proxies like Linkerd operate primarily at layer five, performing connection pooling and session management without examining application-level content. These are layer five applications—they intercept connections, manage their lifecycle, and make routing decisions based solely on session state, not application semantics.

Layer 4: Transport Layer

The transport layer is one of the most critical for backend engineers. Layer four introduces the concept of ports and segments (for TCP) or datagrams (for UDP). As a backend developer, the majority of work occurs at layers four and seven. DevOps engineers working with routing protocols, BGP sessions, and keepalive mechanisms may occasionally work at layer three, but application developers primarily inhabit layer four and above.

At the transport layer, applications become aware of TCP and UDP protocols. TCP segments carry sequence numbers, acknowledgments, and flow control information. UDP datagrams provide minimal overhead with no reliability guarantees. Modern protocols like QUIC also operate at this layer, though QUIC is built atop UDP rather than implemented directly in the kernel like TCP. The transport layer provides port-based multiplexing—port 80 for HTTP, port 443 for HTTPS—allowing multiple applications on a single host to share a network interface. Layer three, by contrast, has no concept of ports, only IP addresses.

Layer 3: Network Layer

The network layer implements the Internet Protocol (IP), handling packet routing across networks. At layer three, the concept of ports doesn’t exist—only source and destination IP addresses. Routing decisions occur here: routers examine IP headers to determine where packets should be forwarded. While applications can theoretically operate directly on raw IP packets, bypassing the transport layer entirely, this is uncommon. Layer three provides best-effort delivery: the network attempts to deliver packets but makes no guarantees about success or ordering. The network layer introduces IP addressing and routing as fundamental concepts, which subsequent sections of this material will explore in depth.

Layer 2: Data Link Layer

The data link layer handles physical network addressing through MAC addresses. At this layer, data travels in frames rather than packets. Ethernet, Wi-Fi (802.11), and other link-layer protocols operate here. Layer two devices see only MAC addresses, not IP addresses. Switches—the classic layer two devices—use MAC address tables to forward frames to the correct physical ports, avoiding the broadcast behavior of hubs that wastefully transmit frames to all ports. The data link layer is the last stop before physical transmission, encapsulating layer three packets into frames appropriate for the local network segment.

Layer 1: Physical Layer

The physical layer represents the actual transmission medium: electrical signals over copper Ethernet cables, light pulses through fiber optic strands, or radio waves for Wi-Fi and LTE. At this layer, frames are converted into raw bits—sequences of ones and zeros—that are then encoded as physical signals. The receiving end performs the reverse transformation, converting incoming signals back into digital bits, then reassembling those bits into frames at layer two. The physical layer’s sole concern is the reliable transmission of raw bitstreams over the physical medium.

Terminology Across Layers

Each layer uses specific terminology for its data units. At layer two, data travels in frames. At layer three, data units are packets. At layer four, TCP transmits segments while UDP sends datagrams (though “segments” is sometimes used for both). These distinctions matter when discussing network behavior, as they indicate which layer is being referenced.

Data Flow: Sender Perspective

Consider a client sending a POST request with JSON data to an HTTPS web server.

Layer 7: Application

At the application layer, the code uses a library like fetch(), axios, or Python’s requests to construct an HTTP POST request containing a JSON payload.

Layer 6: Presentation

The presentation layer takes the JavaScript object or Python dictionary and serializes it into a flat byte string. Objects are only meaningful within their source language; to transmit them, they must be converted to a language-agnostic byte representation.

Layer 5: Session

The session layer establishes the TLS connection. Before any application data can be sent, a TCP connection must be established through the three-way handshake (SYN, SYN-ACK, ACK), and then TLS negotiation must complete. The session layer pauses application data transmission until this connection is ready. Once established, the encrypted JSON payload can proceed.

Layer 4: Transport

The transport layer wraps the application data in TCP segments, adding source and destination ports. For HTTPS, the destination port is 443. The transport layer manages flow control, retransmission, and ordering of segments.

Layer 3: Network

The network layer encapsulates the TCP segment within an IP packet, adding source and destination IP addresses. If the destination hostname was provided (e.g., api.example.com), a DNS lookup resolves it to an IP address, which is then inserted into the IP header.

Layer 2: Data link

The data link layer places each IP packet into a frame, adding source and destination MAC addresses. The MAC address of the next hop (often the default gateway) is determined through ARP (Address Resolution Protocol).

Layer 1: Physical

Finally, the physical layer converts each frame into a stream of bits—ones and zeros—that are transmitted as radio signals, electrical voltages, or light pulses, depending on the medium.

Data Flow: Receiver Perspective

The receiver processes these layers in reverse.

Layer 1: Physical

The physical layer receives radio waves, electrical signals, or light pulses and converts them into digital bits.

Layer 2: Data link

The data link layer assembles these bits into frames.

Layer 3: Network

The network layer extracts IP packets from the frames, checking whether the destination IP matches the local address.

Layer 4: Transport & Layer 5: Session

The transport layer reassembles TCP segments, potentially reordering them and requesting retransmission of lost segments through flow control mechanisms. If the segment is a SYN packet initiating a new connection, processing stops at the session layer—no need to proceed further until the connection handshake completes. After the three-way handshake finishes, subsequent segments carrying application data progress through all remaining layers.

Layer 6: Presentation

The presentation layer deserializes the byte stream back into structured data—importantly, the receiving language need not match the sender’s; a JavaScript client can send JSON that a Python server deserializes, or a C# client can communicate with a Go backend.

Layer 7: Application

The application layer finally delivers the parsed data to the appropriate handler—in an Express.js application, this triggers the registered POST route handler, which can then process the request, query databases, and return a response.

Visualizing Encapsulation

Data encapsulation resembles Russian matryoshka dolls, with each layer wrapping the previous layer’s data. Application data enters the presentation layer, which adds encoding information. The session layer may add connection state. The transport layer wraps this in a TCP segment, adding source and destination ports. The network layer encapsulates the segment in an IP packet with source and destination IP addresses. The data link layer places the packet in a frame with MAC addresses. Finally, the physical layer converts the entire frame into a bitstream for transmission.

Decapsulation proceeds in reverse: bits become frames, frames become packets, packets become segments, segments reveal application data. Each unpacking operation consumes a finite amount of time—typically nanoseconds—but in high-performance systems, these delays accumulate and matter.

Here’s a figure that highlights data units for each level:

Here’s another figure that highlights input and output “doors” for each segment:

• SPORT: source port
• DPORT: destination port
• SIP: source IP address
• DIP: destination IP address
• SMAC: source MAC address
• DMAC: destination MAC address

Intermediary Devices and Layer Processing (TODO: watch again. not perfectly clear)

Real networks contain intermediary devices that process traffic at specific layers. A client connecting to a server rarely connects directly; packets typically traverse switches, routers, firewalls, load balancers, and other middleboxes. Each device operates at particular layers and must process packets accordingly.

Switches operate at layer two. They receive frames, examine destination MAC addresses, and forward frames to the appropriate physical port based on learned MAC-to-port mappings. Switches don’t examine IP addresses—they stop processing at the data link layer. This makes them fast but limited in functionality; they simply connect different network segments without understanding higher-layer protocols.

Routers operate at layer three. They receive frames at layer two, extract IP packets at layer three, examine routing tables to determine the next hop, and forward packets toward their destination. Routers must process up to layer three to make routing decisions. A packet may traverse multiple routers, with each one processing up to layer three before forwarding the packet onward.

Firewalls typically operate at layer four, examining both IP addresses and port numbers to make filtering decisions. A firewall might block traffic to specific ports or from specific IP addresses. More sophisticated firewalls—sometimes called “application firewalls”—inspect layer seven content, though this requires decrypting encrypted traffic, which introduces complexity and performance overhead. Most firewalls remain at layers three and four, operating as transparent proxies that examine publicly visible headers without decrypting payload data.

Layer 4 Load Balancers distribute traffic based on IP addresses and ports. They examine TCP or UDP headers to make routing decisions—for example, directing traffic to different backend servers based on destination port. These load balancers can rewrite packet headers, changing destination IPs or ports to route requests to specific backends. Internet Service Providers (ISPs) can perform similar operations, potentially redirecting traffic or blocking specific destinations by examining layer three and four headers. This is why VPNs are effective: they encapsulate IP packets within other IP packets, hiding the original destination from the ISP.

Layer 7 Load Balancers, Reverse Proxies, and Content Delivery Networks (CDNs) operate at the application layer. To route traffic based on URL paths (e.g., /images vs. /api), these devices must decrypt HTTPS traffic, examine HTTP headers, and make routing decisions based on application-level content. This requires terminating the TLS connection from the client, decrypting the payload, inspecting it, potentially caching it, and then establishing a separate TLS connection to the backend server. Layer seven proxies are significantly slower than layer three or four devices because they must process data through all seven layers in both directions. They effectively act as the final destination from the client’s perspective—the client believes it has connected to the CDN or load balancer, unaware of the backend server handling the request. This is why these devices are called “reverse proxies”: they accept connections on behalf of backend servers, making routing decisions the client never sees.

The distinction between transparent and terminating proxies is significant. Transparent proxies operate at layers three and four, examining IP addresses and ports but not decrypting application data. They cannot inspect HTTPS content because decryption requires the server’s private key. ISPs and government censorship systems typically operate as transparent proxies, blocking traffic based on destination IP addresses or ports. Layers three and four are inherently public—IP addresses and ports must be visible for routing to function, and they are never encrypted.

To intercept and decrypt HTTPS traffic, a proxy must act as a terminating endpoint, presenting its own TLS certificate to clients. This only works if clients trust the proxy’s certificate authority—something most browsers and operating systems do not do by default. Kazakhstan famously attempted to mandate that all citizens install a government-controlled certificate authority, allowing the government to decrypt all HTTPS traffic, but this approach is rare. Most transparent proxies can only block traffic, not inspect encrypted payloads.

OSI Model Critiques and Alternatives

The OSI model has faced criticism for its complexity. Seven layers can seem excessive, and the boundaries between certain layers—particularly the session and presentation layers—are often debated. Some argue that layers five, six, and seven should be collapsed into a single application layer, as the TCP/IP model does.

The TCP/IP model simplifies the stack into four or five layers: application (combining OSI layers 5, 6, and 7), transport (OSI layer 4), internet (OSI layer 3), and link (combining OSI layers 1 and 2). This model is more pragmatic and aligns better with how protocols like TCP and IP actually work. However, referring to layer numbers becomes ambiguous when discussing the TCP/IP model: “layer 5” means application in TCP/IP but session in OSI.

Despite these criticisms, the OSI model remains valuable for its fine-grained distinctions. Real systems demonstrate the utility of separating concerns: proxies like Linkerd operate at the session layer, managing connections without examining application payloads. Layer six serialization is conceptually distinct from layer seven application logic, even if they’re implemented in the same codebase. The OSI model provides a shared vocabulary for engineers to discuss where systems operate and what data they can access.

Summary

Understanding the OSI model is essential for engineers working with networked systems. Knowing where your application operates—whether it’s a layer four proxy examining ports, a layer seven API gateway decrypting and routing HTTP requests, or a layer two switch forwarding frames—determines what data you can access, what optimizations are possible, and how the system behaves under load.

The boundaries between layers are sometimes blurred. Not every device maps cleanly to a single layer, and different engineers interpret layer responsibilities differently. The TCP/IP model offers a simpler alternative by collapsing the top three OSI layers into a unified application layer, but this loses the granularity that can be useful when designing and debugging complex systems.

Layers five and six receive the least attention in practice. Few engineers explicitly discuss the session layer, though systems like Linkerd and Envoy demonstrate its relevance. The presentation layer is rarely mentioned as a distinct concern, as serialization is typically viewed as part of application code. But layer five—the session layer—has concrete use cases in proxy design and connection management, making it more than just a theoretical distinction.

The OSI model provides a framework for reasoning about distributed systems, network protocols, and the division of responsibilities across software and hardware. Whether using the seven-layer OSI model or the simpler TCP/IP model, understanding these abstractions enables engineers to build, debug, and optimize networked applications effectively.

Host to Host Communication

Understanding how hosts communicate at the lowest network layers—primarily layer two (data link) and layer three (network)—is fundamental to grasping modern networking. When one host needs to send a message to another, whether to execute a remote procedure call or transfer data, multiple addressing mechanisms work together to ensure the message reaches its destination.

MAC Addresses and Layer Two Communication

Every host has a network interface card with a unique Media Access Control (MAC) address. This applies to physical machines, virtual machines (which receive virtual MAC addresses), and any networked device. MAC addresses represent the lowest level of network addressing used for direct communication between devices.

Consider a simple scenario: host A wants to send a message to host B in a mesh network where all devices are directly connected to one another:

When A transmits a frame, every device on the network receives it. Each recipient must examine the destination MAC address in the frame header at layer two and compare it against its own MAC address. Only the device whose MAC address matches the destination accepts and processes the frame, passing it up to layer three and beyond. All other devices discard the frame.

This broadcast approach is inherently wasteful and poses security risks. Public Wi-Fi networks exemplify this vulnerability: since Wi-Fi operates as a mesh where all connected devices can receive all frames, malicious actors can configure network sniffers to capture frames not addressed to them. This is how password sniffing on public Wi-Fi networks occurred historically—an attacker’s machine would accept and inspect frames it should have dropped, extracting sensitive information before encryption became ubiquitous.

The Limitations of MAC Addresses

While MAC addresses are globally unique—no two network interfaces should share the same MAC address—they suffer from a critical flaw: they lack hierarchical structure that enables efficient routing. If two machines on opposite sides of the globe want to communicate using only MAC addresses, the sending machine would need to scan the entire network to locate the destination. This is analogous to performing a full table scan in a database rather than using an index—it works in principle but becomes impossibly slow at scale.

MAC addresses provide no information about network topology or location. There’s no way to narrow the search space or eliminate entire regions of the network when looking for a destination. For global-scale communication, this flat addressing scheme is untenable.

IP Addresses: Hierarchical Addressing

The Internet Protocol (IP) address was invented specifically to solve this routing problem. An IP address consists of two logical parts: a network portion and a host portion. An IPv4 address occupies four bytes (32 bits), theoretically addressing up to four billion devices. However, the power of IP addressing lies not in its capacity but in its structure.

The network portion identifies which network a host belongs to, while the host portion identifies the specific device within that network. When routing a packet, intermediary devices examine only the network portion to determine where to forward it. This immediately eliminates vast numbers of irrelevant destinations, allowing routers to make efficient forwarding decisions. Once the packet arrives at the destination network, the host portion is used to deliver it to the specific machine, at which point MAC addresses handle the final layer-two delivery.

MAC addresses remain necessary even with IP addresses because layer-two delivery within a local network still requires them. The IP layer handles routing between networks; the data link layer handles delivery within a network.

Network Addressing Example

Consider two networks: network N1 and network N2, connected by a router. Network N1 contains hosts A, B, and C. Network N2 contains additional hosts. Host A on N1 wants to communicate with host B on N2.

The IP addresses might be structured as follows:

• Network N1: 192.168.1.0/24 (where /24 indicates the first 24 bits (or the first 3 numbers) define the network)
• Network N2: 192.168.2.0/24

Within N1, hosts might have addresses like 192.168.1.1 and 192.168.1.2. The first three octets (192.168.1) represent the network portion (again, that’s the purpose of /24), while the final octet identifies the specific host within that network.

When host 192.168.1.3 wants to send a packet to 192.168.2.2, it applies the subnet mask (indicated by /24) to determine whether the destination is on the same network. The subnet mask effectively isolates the network portion of the address for comparison. If the network portions differ, the source host knows the destination lies on a different network and forwards the packet to its default gateway—the router connecting the networks.

The router, operating at layer three, examines the destination IP address, consults its routing table, and forwards the packet toward network N2. This routing decision happens without scanning every host on the internet—the hierarchical structure of IP addresses makes efficient routing possible.

Historical Note on Address Classes

Older IP addressing schemes used class-based addressing (Class A, Class B, Class C), which allocated fixed-size network and host portions based on the first few bits of the address. This rigid structure proved wasteful, as it couldn’t accommodate the diverse range of network sizes needed in practice. Modern networking uses Classless Inter-Domain Routing (CIDR), which allows arbitrary division between network and host portions using prefix length notation (e.g., /24, /16, /8). This flexibility eliminates the waste inherent in class-based addressing and better accommodates real-world network topologies.

Port Numbers: Application-Level Multiplexing

IP addresses identify hosts, but a single host typically runs many applications simultaneously. A server might handle HTTP requests on port 80, DNS queries on port 53, and SSH connections on port 22, all concurrently. Without additional addressing, the host wouldn’t know which application should receive incoming packets.

Ports provide this application-level multiplexing. The transport layer (layer four) adds source and destination port numbers to segments, allowing the operating system to demultiplex incoming traffic to the appropriate process. When a packet arrives at the correct IP address, the transport layer examines the destination port and delivers the segment to whichever application is listening on that port. Source ports enable bidirectional communication by telling the remote host where to send response traffic.

Ports complement IP addresses by adding fine-grained control within a single host, just as IP addresses complement MAC addresses by adding hierarchical structure across networks.

Summary

Host-to-host communication relies on three addressing layers working in concert. MAC addresses handle physical delivery within a local network segment at layer two. Their global uniqueness ensures no address collisions, but their lack of structure makes them unsuitable for routing beyond immediate neighbors.

IP addresses introduce hierarchy through network and host portions, enabling efficient routing across interconnected networks. Routers examine only the network portion to make forwarding decisions, dramatically reducing the search space compared to flat MAC addressing. The subnet mask determines how many bits constitute the network portion, with CIDR notation (e.g., /24) providing flexible network sizing.

Ports enable multiple applications on a single host to share a network interface. The transport layer uses destination ports to deliver segments to the correct process and source ports to enable replies.

Understanding the distinction between localhost (127.0.0.1 in IPv4, ::1 in IPv6) and routable addresses is also important. The localhost address is a loopback interface—traffic sent to it never leaves the local machine. Services listening on localhost are inaccessible from remote hosts, making localhost useful for development and inter-process communication on the same system.

These fundamental building blocks—MAC addresses, IP addresses with network/host divisions, and port numbers—form the foundation of modern networking. Backend engineers, network engineers, and even frontend developers interact with these concepts daily when specifying IP addresses and ports in network requests. Grasping why each addressing layer exists and what problem it solves provides essential context for understanding more complex networking topics.