Computer networks: how connected systems communicate

Follow information from an application to another computer—through addresses, packets, routing, transport protocols, and the web's request-response model.

A model for network communication

A computer network is a collection of devices that exchange information using agreed rules. Devices may be connected by cables, radio, or a mixture of links. A network can be a home Wi-Fi network, a campus, a data center, or a global system of interconnected networks.

Breaking communication into layers makes the system easier to design. An application can describe the message it wants to send without deciding which radio channel will carry each bit. Each layer uses services from the layer below and provides services to the layer above.

• Application: meaning and format of messages, such as web requests.
• Transport: communication between application endpoints.
• Internet: addressing and forwarding packets between networks.
• Link: delivery across one local network link.

Layer names and boundaries differ among reference models and protocols. They are teaching tools for understanding responsibilities, not physical boxes that must map one-to-one to hardware.

Layers and protocols

A protocol specifies message formats and rules that communicating systems follow. Protocols make interoperability possible: independent software and hardware can communicate when they implement compatible rules.

Layer or role	Example protocols	Typical responsibility
Application	HTTP, DNS, SMTP	Define useful messages and operations
Transport	TCP, UDP	Deliver data between processes on hosts
Internet	IP	Address and forward packets between networks
Link	Ethernet, Wi-Fi	Carry frames over a local link

As data moves down the layers, each protocol may add a header with information needed by the next step. At the receiver, layers interpret and remove their own headers to deliver the application message. This process is often called encapsulation.

Layering helps isolate changes, but it does not eliminate trade-offs. Headers consume bandwidth, choices at one layer can affect another, and debugging may require understanding the whole path.

Why packet switching is useful

Networks commonly divide data into packets instead of reserving one physical path for every conversation. Many users can share links, and routers can forward packets around changing conditions. Packet switching is flexible, but the network must carry addressing and control information and recover from loss where the application requires it.

Consider sending a photograph. The application or transport layer divides its data into units that can travel through the network. Each packet carries delivery information; routers forward it hop by hop. The receiver uses protocol rules to reassemble the useful data. If a link becomes unavailable, routing can change, though some packets may be delayed or lost during the transition.

Encapsulation, step by step

A browser prepares an application message. A transport protocol associates it with the correct connection or endpoint and adds its own header. IP adds source and destination addressing; the local link adds information needed to deliver the packet on the current network. At each router, the link-layer framing can change for the next link while the packet continues toward its destination.

This layered view is useful for troubleshooting: a working Wi-Fi link does not prove DNS is working, and a successful DNS lookup does not prove a server accepts a connection. Check one layer at a time while remembering that failures can cross layer boundaries.

Local networks and addressing

On a local network, devices need a way to deliver data to the correct nearby device. Link technologies use their own addressing and delivery rules. Wi-Fi and Ethernet are common local-link technologies; a router connects a local network to other networks.

An IP address identifies a network interface within the Internet Protocol system. IPv4 addresses are 32 bits and commonly written as four decimal octets; IPv6 addresses are 128 bits and written in hexadecimal groups. A network prefix indicates which portion identifies a network and which portion identifies an interface within it.

Private addresses and network configuration

Many home networks use private IPv4 address ranges internally. A router may use network address translation (NAT) so multiple local devices can share an external IPv4 address. NAT is common, but it is not itself a complete security boundary; firewall rules and service configuration still matter.

Devices also need configuration such as an address, a default gateway, and DNS resolvers. DHCP commonly provides these settings automatically on local networks. Misconfiguration can make a device reach local resources but fail to contact destinations elsewhere.

IP packets and routing

The Internet Protocol (IP) carries packets from a source address toward a destination address. A router examines the destination and forwards each packet toward another network according to routing information. Packets from one conversation can take different routes; applications should not assume the path is fixed.

IP is a best-effort delivery service: packets may be delayed, lost, duplicated, or delivered in a different order. Higher layers can add reliability or ordering when needed. Packet size is limited by the network path; large messages may be split into smaller pieces, and fragmentation or path-MTU problems can affect communication.

Subnets and gateways

A subnet groups IP addresses that can communicate directly at the local network layer. A device compares the destination with its own network prefix: if the destination is local, it sends on the local link; otherwise it forwards the packet to its default gateway. Routers use routing tables to choose where to send traffic next.

TCP, UDP, and ports

The transport layer lets applications communicate across hosts. A port identifies an application endpoint on a host, so traffic can be delivered to the correct service. Ports are not physical connectors; they are part of transport-layer addressing.

TCP: a reliable ordered byte stream

Transmission Control Protocol (TCP) establishes a connection and provides an ordered stream of bytes. It uses acknowledgments and retransmissions to recover from some packet loss and adjusts sending behavior to avoid overwhelming the network. The application sees a stream, not preserved message boundaries, so protocols must define how messages are framed.

UDP: datagrams with fewer guarantees

User Datagram Protocol (UDP) sends individual datagrams without TCP's built-in guarantee of delivery, ordering, or retransmission. Applications may use UDP when low latency or control over recovery behavior is important. They must handle any reliability needs themselves. DNS commonly uses UDP for ordinary queries, though it can also use TCP in specific circumstances.

Property	TCP	UDP
Communication shape	Connection-oriented byte stream	Connectionless datagrams
Ordering	Ordered delivery to the application	No ordering guarantee
Recovery	Built-in retransmission for lost data	Application decides whether recovery is needed
Good fit	Web pages, file transfer, many APIs	Real-time or query traffic with application-specific needs

DNS: names for network destinations

People use names such as example.com; networks deliver packets using IP addresses. The Domain Name System (DNS) is a distributed naming system that lets software look up records associated with domain names. A resolver may answer from a cache or ask DNS servers through a hierarchy.

DNS records have types and caching lifetimes. An A record maps a name to an IPv4 address; an AAAA record maps a name to an IPv6 address; other records support mail routing and aliases. DNS answers can change over time, so applications should respect cache rules rather than assuming a name always maps to one fixed machine.

Name resolution is not the same as connecting to a service. A successful DNS lookup only provides data; routing, firewalls, transport negotiation, and the application server can still fail.

Worked example: a secure web request

When you visit a secure web address, the browser may perform a sequence like this. Caches and existing connections can skip some steps, and details vary by browser, network, and protocol version.

1. Parse the URL: identify the scheme, host name, port, and requested path.
2. Resolve the name: use DNS or a cache to find an address.
3. Reach the host: send packets through the local gateway and routers toward the server.
4. Establish transport: create or reuse a connection, commonly TCP for HTTP/1.1 and HTTP/2.
5. Protect the channel: TLS authenticates the server using certificates and encrypts the connection.
6. Send an HTTP request: include method, path, headers, and possibly a body.
7. Receive the response: the server returns a status, headers, and content; the browser renders it.

HTTP/3 uses QUIC over UDP and provides transport features such as reliable streams and encryption within that protocol. This illustrates that protocol stacks evolve; the central ideas—naming, routing, transport, and application messages—remain useful for understanding them.

Requests, methods, and responses

HTTP requests include a method that describes the requested action, a path that identifies a resource, headers with metadata, and sometimes a body. GET commonly requests a representation; POST commonly submits data for processing; PUT and DELETE are used for other resource operations. Exact behavior depends on the service's API contract.

Responses include a status code, headers, and possibly a body. Broad status-code families indicate success, redirection, client-side problems, or server-side errors. The status code is useful evidence but not a full explanation: a client still needs to interpret the API's documented response.

Some methods are designed to be idempotent: repeating the same request has the same intended effect as doing it once. Idempotency matters when clients retry after a timeout because the server may have completed an operation even if the response was lost. Payment and other state-changing APIs often use request identifiers or other safeguards to avoid accidentally applying one user action multiple times.

Caching reduces repeated work

A cache stores a copy of data so a later request can be answered faster or closer to the user. HTTP caching headers describe whether a response can be reused and for how long. Caching improves performance and can reduce server load, but stale or incorrectly shared data can expose information or show the wrong version. Private user-specific responses need particularly careful cache rules.

Latency, bandwidth, and reliability

• Latency: time for a message or request to travel and receive a response.
• Bandwidth: the maximum data rate a link can carry under stated conditions.
• Throughput: the rate of useful data actually delivered.
• Jitter: variation in packet delay over time.
• Loss: packets that do not arrive at the destination.

A large file transfer is often limited by throughput; an interactive action may be limited by latency. A high-bandwidth connection can still feel slow if each page requires many sequential round trips. Caching, compression, and parallel requests can help, but should be chosen with freshness, privacy, and server load in mind.

Retries are useful for transient failures, but unlimited retries can overwhelm a service or delay user feedback. Use bounded retries and backoff where appropriate. For operations that change state, consider whether repeating the request could accidentally repeat the action.

Diagnose a connection one step at a time

When a service is unreachable, start with the exact error and the scope of the failure. Does the device have a local connection? Can it reach other sites? Does the host name resolve? Can a connection be established to the intended service? Does the service respond with an application-level error? These questions separate local configuration, name resolution, routing, transport, and application problems.

Time measurements help distinguish a slow response from a failed response. Compare a warm request with the first request, test from more than one network when authorized, and inspect service status and logs where available. Do not assume that a single failed test proves a remote system is down; transient routes, firewalls, and local caches can change the evidence.

Distributed systems have partial failures

In a networked application, one component can fail while others continue. A client may time out even though the server completed its work; a database may be healthy while the application cannot reach it. This is called a partial failure. Robust systems use timeouts, bounded retries, health checks, and clear error states rather than waiting forever or claiming success without confirmation.

Network security foundations

Networks carry data across equipment and organizations that an application may not control. Encryption protects confidentiality from observers; authentication helps verify who is communicating; integrity checks help detect unauthorized changes. TLS combines these ideas for many web connections when configured and validated correctly.

Encryption does not automatically make a service safe. Applications still need authorization, input validation, secure secret handling, and safe error behavior. Do not send sensitive information over protocols that lack appropriate protection, and do not ignore certificate warnings.

Compact glossary

Protocol

Rules and formats that define communication between systems.

Packet

A unit of network-layer data forwarded toward a destination.

Router

A device that forwards packets between networks.

Port

A transport-layer number used to identify an application endpoint.

DNS

A distributed system for looking up records associated with domain names.

Latency

Delay between sending a message and receiving a response.

References and further reading

1. James F. Kurose and Keith W. Ross. Computer Networking: A Top-Down Approach. Author resources.
2. Internet Engineering Task Force. RFC 9293: Transmission Control Protocol. RFC Editor.
3. Internet Engineering Task Force. RFC 1034: Domain Names—Concepts and Facilities. RFC Editor.
4. Cloudflare Learning Center. What is the Internet? Learning resource.

Try it yourself

1. Draw a request from a laptop to a web server and label the work done by DNS, IP, transport, and HTTP.
2. Explain why an IP address is not the same thing as a domain name.
3. Choose TCP or UDP for a reliable file download and justify your choice.
4. Give an example where latency matters more than bandwidth.
5. List three distinct reasons a domain name might resolve successfully while a web page still fails to load.

Remember: protocols divide communication into manageable responsibilities, from local delivery to application meaning.