Application architectures and the web
Applications are why networks exist. Their protocols define how programs on different hosts talk, and the web's HTTP is the most important of all.
Client-server and peer-to-peer
In the client-server architecture, an always-on server with a fixed address serves many clients, as with web, email, and streaming services; large services use data centres with many servers. In peer-to-peer (P2P) architectures, hosts communicate directly, each acting as both client and server, as in BitTorrent file sharing; P2P scales naturally because each new peer also adds capacity.
Sockets and transport choice
Application processes send and receive messages through sockets, the interface between an application and the transport layer. An application chooses a transport service: TCP for reliable, ordered byte streams, as needed for web pages, email, and file transfer; or UDP for lightweight, unreliable datagrams, used where speed or simplicity matters, such as DNS queries and real-time media.
Addressing processes
A process is identified by its host's IP address plus a port number. Well-known ports identify standard services: 80 for HTTP, 443 for HTTPS, 25 for SMTP, 53 for DNS, 22 for SSH. Clients usually use temporary (ephemeral) ports chosen by their operating system.
HTTP basics
The Hypertext Transfer Protocol (HTTP) is a request-response protocol. A client sends a request line such as GET /index.html HTTP/1.1, followed by headers like Host: example.com and Accept-Language: en, and sometimes a body. The server replies with a status line such as HTTP/1.1 200 OK, headers such as Content-Type: text/html, and the body. HTTP is stateless: each request stands alone.
Methods and status codes
Common methods are GET (retrieve), POST (submit data), PUT (replace), PATCH (modify), DELETE, and HEAD (headers only). Status codes are grouped: 1xx informational, 2xx success (200 OK, 204 No Content), 3xx redirection (301 Moved Permanently, 304 Not Modified), 4xx client errors (400, 401, 403, 404), and 5xx server errors (500, 503 Service Unavailable).
Cookies, caching, and state
Because HTTP is stateless, servers track sessions with cookies: a Set-Cookie response header asks the browser to store a value, which it then sends back in later requests. Caching avoids repeated downloads: Cache-Control headers set lifetimes, and conditional requests using ETag or Last-Modified let servers reply 304 Not Modified instead of resending unchanged content.
HTTP versions
HTTP/1.0 typically opened a new TCP connection per object; HTTP/1.1 (1997) added persistent connections. HTTP/2 (2015) multiplexes many requests as streams over one connection with compressed binary headers. HTTP/3 (standardised in 2022) runs over QUIC, a UDP-based transport with built-in encryption, avoiding head-of-line blocking when one lost packet would stall all streams in TCP.
Worked example
Loading a page with an HTML file and 10 images over non-persistent HTTP/1.0 with RTT 50 ms needs, per object, one RTT for the TCP handshake and one for the request and response: 11 x 2 x 50 = 1,100 ms, ignoring transmission time. With one persistent HTTP/1.1 connection and requests sent one after another, it takes 50 ms for the handshake plus 11 x 50 ms = 600 ms. HTTP/2 can request all 10 images at once after the HTML: about 50 + 50 + 50 = 150 ms.
Key takeaways
Client-server applications rely on always-on servers; peer-to-peer applications let peers serve each other and scale with users. Applications use sockets and choose TCP for reliability or UDP for speed and simplicity. Processes are addressed by IP address and port; HTTP uses 80, HTTPS 443, DNS 53. HTTP is a stateless request-response protocol with methods such as GET and POST and status codes from 1xx to 5xx. Cookies maintain sessions; Cache-Control, ETags, and 304 responses enable caching. HTTP/1.1 added persistent connections, HTTP/2 multiplexing, and HTTP/3 runs over QUIC.
Flashcard
Always-on server serving clients
Check your understanding
Why does a browser receiving 304 Not Modified save time?