Computer Networking: A Complete Guide to How Networks Work

Suppose you enter a cloud application's address into a browser. The browser prepares an application exchange, but the network does not normally carry it as one uninterrupted object. With TCP, application data becomes a stream of bytes that is transported in segments; IP carries those segments inside packets. On the local link, each packet is carried inside a frame suited to Ethernet or Wi-Fi. This wrapping process is called encapsulation. Headers supply information needed at each stage, such as transport ports and source and destination IP addresses. At the receiving endpoint, the corresponding layers interpret and remove these wrappers in reverse order.

The OSI model organises networking concepts into seven layers: physical, data link, network, transport, session, presentation and application. It is a reference model, not a requirement that every implementation expose seven separate components. The practical TCP/IP model usually groups functions into link, internet, transport and application layers. Ethernet and Wi-Fi operate at the lower layers, IP handles network addressing, and TCP or UDP supports transport. HTTP supplies web application semantics, with TLS commonly securing the exchange. These models help distinguish a broken radio connection from a routing failure or application error, even though real protocols do not always fit neatly into one box.

Before sending application traffic, the laptop needs a destination IP address. DNS, the Domain Name System, lets applications look up information associated with names such as app.example.com. The browser or operating system may already have a cached answer. Otherwise, it typically asks a recursive resolver, which can consult other DNS servers and return the relevant records. A records contain IPv4 addresses, while AAAA records contain IPv6 addresses. A name can resolve to several addresses, and the answer may vary with location or service design. DNS provides naming information; it does not itself carry the subsequent web request to the service.

Caching reduces repeated lookups, but it also explains why DNS changes are not always visible immediately. Records have time-to-live values that guide how long resolvers can reuse them. A cached answer may remain in use until it expires, while applications can maintain additional connection state. For a cloud service, the returned address might belong to a content delivery network or load balancer rather than the machine running the application. Some clients use encrypted DNS transports such as DNS over HTTPS or DNS over TLS. These protect the lookup in transit to the resolver, but they do not replace HTTPS protection for application traffic.

The laptop also needs its own network configuration: an IP address, a subnet prefix, routing information and usually DNS resolver settings. IPv4 settings are often supplied by DHCP; IPv6 can use router advertisements, stateless address autoconfiguration and DHCPv6, depending on the network. An IP address identifies an interface within an addressing context, not permanently a person or physical device. IPv4 addresses are 32 bits long, while IPv6 addresses are 128 bits long. Private IPv4 addresses are intended for private networks and are not globally routed across the public internet. Public addressing still does not automatically make a service reachable through its firewalls.

Subnetting divides an address space into smaller logical networks. For example, 192.168.10.25/24 belongs to the IPv4 subnet 192.168.10.0/24, where the prefix identifies the first 24 bits as the network portion. In a conventional /24 subnet, addresses ending in .0 and .255 serve network and broadcast roles rather than ordinary host assignments. Using its routing table, the laptop determines whether a destination is reachable directly on the local link or through a router. More-specific matching routes take priority over less-specific ones. For the public cloud address in this example, the laptop will typically use its default route and send traffic towards the local gateway.

On an Ethernet-based local network, the laptop needs the link-layer address of the next hop before sending its packet. For IPv4, Address Resolution Protocol, or ARP, resolves a local IP address to a MAC address. IPv6 uses Neighbour Discovery for this and related functions. If the cloud destination is outside the local subnet, the laptop resolves the gateway's local address, not the remote server's MAC address. The resulting frame targets that gateway, while the IP packet inside still targets the cloud service. This distinction explains how a packet can cross many links without the sender knowing every intermediate device's hardware address.

A conventional Layer 2 switch learns source MAC addresses from incoming frames and associates them with ports within a VLAN. It then forwards known unicast frames towards the appropriate port, rather than sending every frame everywhere. Broadcast traffic and unknown destinations may be flooded within that VLAN. A wireless access point usually bridges client traffic into the local network, although business deployments can use more complex forwarding designs. VLANs separate Layer 2 broadcast domains; communication between them requires routing. Routing and switching are therefore complementary functions, and a multilayer switch can perform both. The device label matters less than the forwarding decision it makes.

At the gateway, a router examines the destination IP address and consults its routing table to select a next hop and outgoing interface. It removes the incoming link-layer framing and creates suitable framing for the next link. Each router repeats a similar decision, reducing the IPv4 time to live or IPv6 hop limit to prevent indefinite circulation. Internet providers exchange reachability information using routing protocols, including BGP between autonomous systems. Your packet does not necessarily follow the geographically shortest path, and the response can take a different route. Congestion, commercial arrangements and network policy all influence the paths that traffic takes.

Many IPv4 gateways also perform network address translation, often translating transport ports so multiple private devices can share one public address. NAT is distinct from routing and is not a substitute for firewall policy. Above IP, TCP provides an ordered byte stream with retransmission and congestion control, but it cannot guarantee that a failed connection will recover. UDP supplies datagrams without built-in delivery or ordering guarantees. Applications can add those features themselves: HTTP/3 uses QUIC over UDP, for example. An HTTPS connection commonly uses TCP plus TLS for HTTP/1.1 or HTTP/2, whereas QUIC integrates TLS security into its own transport design.

A VPN creates a logical connection across another network. In a typical remote-access VPN, the laptop encrypts and encapsulates selected traffic inside packets addressed to a VPN gateway. The underlying network routes those outer packets, while the original traffic emerges after the gateway processes the tunnel. With full tunnelling, most traffic goes through the VPN; with split tunnelling, only specified destinations do. The exact behaviour depends on client configuration, routes and organisational policy. A VPN can provide access to private services or protect traffic across an untrusted local network, but it changes the path rather than removing the need to understand it.

VPN protection ends where the tunnel terminates, so HTTPS remains important for application traffic beyond that point. A VPN also does not make someone anonymous: the VPN operator may observe connection metadata, and websites can still recognise signed-in users. Routing and DNS deserve particular attention when troubleshooting tunnels. A private service might require a resolver available only through the VPN, while overlapping home and corporate subnets can send traffic towards the wrong destination. Tunnel headers also reduce the space available for the original packet within a link's maximum transmission unit. Incorrect MTU handling can cause connections that start successfully but stall during larger transfers.

Cloud networking applies familiar addressing and forwarding principles through provider-managed infrastructure and software-defined controls. Resources commonly sit inside a virtual private cloud or virtual network, divided into subnets with associated routes and security rules. Public-facing services may receive traffic through a load balancer, reverse proxy or content delivery network. Private workloads can remain unreachable directly from the internet while accepting approved traffic through these entry points. The cloud provider implements the underlying fabric, but customers still need coherent address plans, access policies and connectivity designs. A subnet's name alone does not determine exposure; its routes, address assignments and security configuration do.

When the request reaches a load balancer, it may be forwarded at the transport layer or processed as application traffic, depending on the service. TLS might terminate there, with a separate protected connection continuing to the backend. The application then processes the request and returns data through the relevant connections and routes. Security groups, network access controls and host firewalls can each affect delivery, with details varying by provider. Private endpoints and dedicated connections offer alternatives to public internet access for supported services. Troubleshooting therefore requires following the actual architecture, including proxies and translation points, rather than assuming one uninterrupted connection reaches a single server.

Start by defining the symptom: does one application fail, one device fail, or everything on the network fail? Check the physical or wireless connection, then inspect the device's address, prefix, gateway and routes using tools such as ipconfig on Windows or ip addr and ip route on Linux. Test name resolution with nslookup or dig where available, and compare the result with the expected service configuration. Ping can test some aspects of IP reachability, but blocked ICMP does not prove that a website is unavailable. Traceroute can expose intermediate hops, although filtering and different forwarding paths can leave gaps or misleading results.

Next, test the application protocol: curl can show HTTP responses and TLS failures, while browser developer tools reveal request timing and status. Check proxy, VPN and firewall settings before changing them, and use packet capture only on systems and networks you are authorised to inspect. A successful TCP connection does not prove the application is healthy, just as successful DNS resolution does not prove the destination is reachable. For structured study of this complete journey, the Erudex [Computer Networking: From TCP/IP to Cloud Networks](/courses/computer-networking) course and [practice tests](/practice) provide learning and review options. Certificate and career decisions belong in the companion article.