The Application Layer

A network application consists of programs running on end systems: phones, laptops and servers. Their processes exchange messages across the network. Routers and switches forward the packets; they do not need a new application program installed whenever someone creates a new service.

Two ways to assign the work

An application architecture describes how the application divides work among hosts. It is separate from the network's layered architecture. The developer chooses where programs run while relying on the existing network to connect them.

In a client-server design, clients contact an always-on server at a known address. A browser requests a document from a web server, which returns the document. Other browsers do not need to be online for that exchange to work. A popular service can spread its server role over thousands of machines in data centers; one public name can represent that group. Equipment, power, cooling and internet connections all cost money.

A peer-to-peer, or P2P, design lets user devices exchange data directly. A peer can request a file chunk and also upload chunks it already holds. Peers may disconnect or change addresses, so the application must find available peers and keep operating as membership changes.

Follow one exchange

Suppose a research group distributes a large data set. In a client-server design, every researcher downloads a copy from the group's server. Ten new researchers mean ten more copies for that server to upload. In a P2P design, researchers who already hold some chunks send those chunks to newcomers. Each joining researcher can add capacity as well as demand. This is self-scaling: the application's resources grow with participation.

Self-scaling still depends on useful contributions. A peer with a slow upload link adds less capacity than one with a fast link. Many residential links are asymmetric: downloading is faster than uploading. A peer that disconnects contributes nothing while offline. P2P software must also protect participants against untrusted peers and encourage users to upload instead of only taking data.

Central coordination and direct transfer

A hybrid design combines server coordination with P2P data transfer. A BitTorrent tracker tells a peer about other peers; it does not have to send the file itself. Similarly, a calling service can locate participants through a server, let their devices exchange media directly, and use a relay when a direct path is unavailable. Classify the path carrying the data separately from the path that sets it up.

The words client and server also describe roles in an individual exchange. If peer Mira initiates a request to peer Leo, Mira is the client and Leo is the server for that exchange. They can reverse roles a moment later. P2P removes dependence on dedicated content servers; it does not remove the initiating and responding roles.

A running application program is a process. Processes on different hosts exchange messages through sockets, the software interfaces between the application and transport layers. Application code decides what the message means; the transport service carries its bytes or datagrams.

Find the receiving process

An IP address identifies a host, but the host can run many services. A port number identifies a transport endpoint on it. To contact an HTTPS service at 203.0.113.10, a client normally targets port 443. Its own operating system usually assigns a temporary, or ephemeral, source port.

Ports are 16-bit values, from 0 through 65,535. System ports occupy 0–1023, registered ports 1024–49,151, and dynamic ports 49,152–65,535. Common service ports include HTTP 80, HTTPS 443, SMTP transfer 25 and DNS 53. A port is part of addressing, not a statement that the traffic is encrypted or trustworthy.

Agree on the messages

An application-layer protocol defines message types, syntax, semantics and exchange rules. Types distinguish a request from a response. Syntax describes fields and separators. Semantics tells each participant what those fields mean. Exchange rules determine when a process sends a message and how the receiver responds. Public specifications, often RFCs, let programs written by different developers communicate.

A protocol is one component of an application. The web also needs browsers, servers and documents. Defining HTTP alone does not build a browser or decide how its interface looks.

Match the service to the need

Consider four needs: correct delivery, enough throughput, acceptable delay, and security. An email attachment requires every byte. A voice call can tolerate some lost media but suffers if old audio arrives too late. A stored video needs sustained throughput near its encoded bit rate, while an elastic download can use whatever rate is available.

TCP includes flow control to protect the receiver and congestion control to reduce overload in the network. It supplies no minimum bandwidth or delivery deadline. UDP itself adds neither reliability nor congestion control. Choosing it does not remove congestion from the path.

For example, a game sending positions 30 times each second produces a fresh update about every 33 ms. It may use UDP so a lost update can be replaced by a newer one without waiting for that update to be retransmitted. The game's chat still needs reliable delivery, whether through TCP or reliability added by its own protocol.

Add security to the stack

Neither bare TCP nor bare UDP encrypts application data. HTTP/1.1 and HTTP/2 commonly use TLS over TCP for HTTPS. TLS adds confidentiality, integrity and server authentication. HTTP/3 uses QUIC over UDP; QUIC supplies reliability, congestion control and built-in TLS 1.3. Stored video delivered with HTTP therefore uses TCP or QUIC, while interactive calls often carry media over UDP.

A web page is usually several objects, each with its own URL. The base HTML names images, scripts and other files. In https://www.example.org/docs/intro.html, the scheme is https, the host is www.example.org, and the path is /docs/intro.html.

Read a request and response

HTTP follows request-response exchanges. An HTTP/1.1 request starts with a method, path and version:

GET /docs/intro.html HTTP/1.1
Host: www.example.org
Connection: close

The request line and header lines use CRLF endings. A blank line ends the headers, and an optional body follows. Host is required in HTTP/1.1 because several sites can share one server address. Connection: close requests closure after the response.

GET retrieves an object. HEAD requests its response headers without the body. POST sends data in a request body; a GET can also carry form values in its URL query string. PUT stores an object at a specified URL, and DELETE removes one.

The response begins with a status line such as HTTP/1.1 200 OK, followed by headers, a blank line and the body. Content-Type identifies the representation; Content-Length gives its byte length. Status classes are 1xx information, 2xx success, 3xx redirection, 4xx client error and 5xx server error. A 301 points to a new URL in Location; 304 permits reuse of a cached copy. A 404 means the server replied that the requested object was not found, not that the server was unreachable. Other useful codes include 400, 500 and 505.

HTTP is stateless: each request can be understood without earlier requests. A website can still keep login or cart state above HTTP. An ordinary repeated GET can return the object again, while a conditional request can validate a saved copy.

Count the round trips

For one object over a new TCP connection, allow one RTT for connection setup and one for the request and start of the response. Then add object transmission time. With RTT 30 ms, size 500 kB and rate 50 Mbps:

The total is 60 ms plus 80 ms, or 140 ms. This model ignores DNS, TLS and processing time. A full TLS 1.3 handshake over the new TCP connection adds another RTT.

Reuse or reopen the connection

A non-persistent connection carries one object. A persistent connection can carry later requests without another TCP setup. Persistence is the HTTP/1.1 default, though idle connections eventually close.

For one HTML object and eight small images, RTT 20 ms, and negligible transmission times:

The image requests depend on receiving the HTML. Even with parallel fetching, they cannot start before their URLs are known. Count those dependency stages before counting handshakes. HTTP/1.1 browsers commonly use several connections per host; pipelining is a timing model, not a requirement for persistence.

HTTP requests stand on their own, yet a store can remember a cart. A browser can also reuse an image instead of downloading it again. Cookies support recognition across requests; caches support reuse of responses.

Follow a cookie

On a first visit, shop.example.com creates a database entry for a visitor and returns Set-Cookie: id=1678. The browser stores that value. Later matching requests include Cookie: id=1678, allowing the server to look up the cart. The cookie is data, not executable code, and the cart itself can remain in the server's database.

Cookie attributes control its use. Expires or Max-Age sets a lifetime; a cookie without either is a session cookie. Domain and Path restrict matching requests. Secure restricts sending to HTTPS, HttpOnly prevents access through page scripts, and SameSite controls sending in cross-site contexts. Session restoration can retain session cookies when a browser restores a previous session.

First-party cookies belong to the visited site. An embedded third-party service can use cookies across different sites to recognize a browser. Safari blocks third-party cookies by default; Firefox partitions them by site; Chrome provides user controls and blocks them in Incognito mode. European Union rules require consent for cookies that are not strictly necessary to provide a requested service.

Follow a cached request

A web cache stores HTTP responses. A browser has its own cache. A caching proxy sits between clients and origin servers: it serves a cache hit directly, or fetches, stores and forwards a response on a miss. It acts as a server toward the browser and as a client toward the origin. A proxy can exist without caching.

A nearby hit reduces delay, origin load and access-link traffic. For 90 requests per second averaging 1 Mbit each, the offered traffic is 90 Mbps. On a 100 Mbps access link, the traffic intensity is 0.9, where queues can become large. A 40% hit rate leaves 60% crossing the link: 54 Mbps and intensity 0.54. With hits taking 10 ms and misses 200 ms, the mean response time is:

This traffic calculation assumes the same mean object size for the hit and miss groups. A hit rate measured by request count alone need not equal the fraction of bytes saved when object sizes differ.

Check freshness before reuse

A conditional GET sends If-Modified-Since with a saved modification date, or If-None-Match with a saved ETag. An unchanged object gives 304 Not Modified without an object body. The cache reuses its copy. A changed object gives 200 OK with the replacement. Validation saves body transmission, but still makes a round trip to the origin.

A shared proxy normally cannot inspect the contents of an HTTPS connection passing through it. Browser caches and CDN servers serving on a site's behalf can cache at the endpoints where those responses are available in readable form.

HTTP versions keep the meanings of methods, statuses, fields and URLs. A 404 still means the requested resource was not found. What changes is how requests and responses travel: HTTP/1.1 uses text messages, while HTTP/2 and HTTP/3 use binary framing.

Let small responses make progress

On an HTTP/1.1 connection, ordered responses can make a small object wait behind a large one. This is application-level head-of-line blocking. Opening several TCP connections reduces that waiting but costs extra setup and gives the page several competing congestion-controlled connections.

HTTP/2 divides messages into frames and assigns each request-response exchange a stream. The sender interleaves frames from different streams on one TCP connection. Header compression, called HPACK, reduces repeated field data. Priorities can guide which responses receive attention first.

For a simplified comparison, one large response has 1,000 frames and eight small ones have two frames each. Send one frame per time slot. Sending the large response first makes small responses finish at slots 1,002 through 1,016, with a mean of 1,009. Sending one frame from each unfinished stream in turn lets the small responses finish in slots 11 through 18, with a mean of 14.5. The large response finishes at slot 1,016. Interleaving changes completion times without increasing the link's transmission rate.

HTTP/2 also specified server push, which sends content before a request. Major browsers have disabled it. A 103 Early Hints response instead points out resources so the browser can start requesting them.

Find the remaining blocking point

TCP delivers one ordered byte stream. If bytes are missing, later bytes wait for recovery even when they contain another HTTP/2 stream's frames. HTTP/2 removes response-order blocking but retains this transport-level blocking.

HTTP/3 maps HTTP onto QUIC, a transport running over UDP, and compresses headers with QPACK. QUIC supplies reliable streams, flow and congestion control, and TLS 1.3 security. Each stream has its own delivery order. Missing data on one stream does not, by itself, prevent delivery of already received data on another. Shared congestion control and application dependencies can still affect several streams.

QUIC uses connection IDs so a connection can survive an IP address change, such as moving from Wi-Fi to cellular service. Its implementation can be updated with an application library, avoiding the slow deployment path of changes to TCP in operating systems and middleboxes.

Compare a fresh connection

With RTT 50 ms and no DNS or processing cost, TCP plus TLS 1.3 takes two RTTs before the first HTTP/2 request leaves. A first response begins after about 150 ms. QUIC combines transport and security setup into one RTT, so an HTTP/3 response can begin after about 100 ms. Resumed QUIC connections can use 0-RTT data, but replay risk limits what requests can safely be sent early.

Browsers can discover HTTP/3 through Alt-Svc or DNS HTTPS records. If UDP is blocked, they can fall back to HTTP over TCP. HTTP/3 remains reliable because QUIC provides reliability above UDP.

A name such as www.example.org is convenient for a person. A connection needs an IP address. The Domain Name System, or DNS, is both the distributed database of naming records and the application protocol used to query it. It normally uses port 53 and operates separately from HTTP.

Divide the naming work

Read www.example.org. from right to left: root, org, example, then www. The final dot represents the root and is usually omitted in everyday writing. A centralized server for every name would create a failure point, a traffic bottleneck and long paths for distant clients.

Root servers refer resolvers to top-level domain servers. TLD servers refer them to the authoritative servers for domains beneath the TLD. Authoritative servers publish the actual records for a domain. The root's 13 named server identities are replicated across many physical instances; 13 is not the number of machines supporting the world's DNS.

The host normally sends its question to a local resolver, provided by its organization, ISP or a public service. That resolver works on the host's behalf. It is not another level between the root and the TLD in the naming hierarchy.

Trace an empty-cache lookup

A campus laptop needs the IPv4 address of www.example.org:

1. The laptop asks its local resolver for the final answer.
2. The resolver asks a root server and receives a referral to .org servers.
3. It asks a .org server and receives a referral to the authoritative servers for example.org.
4. It asks an authoritative server and receives 203.0.113.25.
5. It returns the address to the laptop.

There are four query-reply pairs, or eight messages. The host's request is recursive: obtain the answer for me. The resolver's queries are iterative: each contacted server answers from its knowledge or refers the resolver onward. The root is not fetching the web server's address on the laptop's behalf.

Reuse answers until their TTL ends

A resource record carries a time-to-live, or TTL, measured in seconds. Resolvers keep reusable records in caches until their permitted lifetime ends. They can cache referrals as well as final addresses. A remembered TLD or domain delegation lets a later lookup skip earlier steps. Operating systems and browsers may also have caches.

With a 2 ms RTT between host and resolver and a 30 ms RTT for each of three sequential hierarchy queries, the empty-cache lookup takes about 92 ms. A cached address at the resolver takes about 2 ms. The waiting times add because each referral supplies information needed for the next query.

Caching also delays changes. If a resolver cached an address with a one-hour TTL just before an update, it can keep returning the old address for the remaining lifetime. Lowering a TTL in advance of a planned change limits this overlap; changing the authoritative record alone does not replace every cached copy.

DNS does more than name-to-address lookup. It supports aliases, finds mail servers, and distributes load by returning several addresses for a service. Those roles explain why email delivery and CDN selection also depend on DNS.

DNS stores resource records with a name, value, type and TTL. A type tells the resolver how to interpret the value. An address record, an alias and a mail-server record answer different questions about the same domain.

Read the record type

For example, www.example.org. 3600 IN A 203.0.113.25 gives the owner name, TTL, internet class, type and address. An NS value is a name, not an address. A referral can include a separate A record supplying the name server's address, often called glue when needed to resolve the delegation.

A CNAME such as media.example.org pointing to edge.cdn.example.net leads the resolver to look up the target's address. An MX record instead directs mail delivery. With preferences 10 and 20, try the mail server with preference 10 first; a larger number does not mean higher priority.

Read the message around the records

Queries and replies share a format. The 12-byte header contains an identification number, flags and counts of entries in four sections. The reply copies the query's ID so the requester can match the exchange.

The question section names what was requested. The answer section holds matching records. The authority section can hold NS referrals, while additional supplies helpful records such as name-server addresses. In printed dig output, qr marks a reply, rd means recursion was requested and ra means recursion is available. NOERROR reports no DNS error; NXDOMAIN reports that the queried name does not exist. A no-error response can still lack a record of the requested type.

To publish a new domain, an owner registers it and supplies its authoritative server information. The parent delegation directs queries to those servers, which publish the domain's own host and mail records. Registering the name does not turn the registrar into the server holding every record.

Delivery and protection

Most small DNS exchanges use UDP port 53. A truncated UDP reply has its TC flag set; the resolver can retry over TCP port 53. TCP also supports zone transfers. DNS is therefore not restricted to UDP.

Classic DNS traffic exposes queried names to observers on its path. DNS over TLS or DNS over HTTPS encrypts the client-to-resolver exchange, commonly on ports 853 and 443 respectively. Encryption of that exchange and authenticity of a record are separate properties.

In cache poisoning, a resolver accepts a forged answer and later sends users to the wrong address. Unpredictable IDs and source ports make forged replies harder to match. DNSSEC adds signatures that support verification of record authenticity; it does not hide the query. Flooding can also make DNS servers unreachable. Replication and cached referrals reduce dependence on the root for every request, but failures at a widely used authoritative provider can still disrupt many sites.

Email separates composing a message from delivering it. A user agent is the app or web page used to read and write mail. A mail server stores incoming mail in mailboxes and holds outgoing messages in a queue. SMTP transfers messages between systems.

Trace delivery after submission

Alice submits a message for Bob to her own server. That server looks up the MX records for Bob's domain, resolves the chosen server's address and opens a TCP connection to port 25. It pushes the message to Bob's server, which stores it in his mailbox. Alice's server is the SMTP client during that transfer, even though it serves Alice's user agent in another exchange.

If the destination is temporarily unavailable, the outgoing queue retains the message for retries. Alice's device can go offline while her server keeps working. After repeated failure, a non-delivery report can return to the envelope sender.

Read the conversation

SMTP uses text commands and numeric replies. Here is a shortened delivery exchange; C: and S: identify the two speakers and are not transmitted as part of each command.

S: 220 mail.example.net ready
C: EHLO mail.example.org
S: 250 mail.example.net
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<bob@example.net>
S: 250 OK
C: DATA
S: 354 Send message
C: From: Alice <alice@example.org>
C: To: Bob <bob@example.net>
C: Date: Tue, 03 Mar 2026 10:02:44 +0100
C: Subject: Lab report
C:
C: The report is ready.
C: .
S: 250 Message accepted
C: QUIT
S: 221 Closing

EHLO introduces the sending host. MAIL FROM sets the envelope sender; each RCPT TO names an envelope recipient. DATA begins the message, and a line containing only a period ends it. One connection can carry more than one message. Reply classes distinguish success (2xx), a request for further input (3xx), temporary failure (4xx) and permanent failure (5xx). A 4xx response calls for later retry; a 5xx failure needs different handling, often a bounce.

Keep delivery addresses separate from displayed fields

The envelope controls routing. The From: and To: fields inside the message are displayed to the reader. They can differ from the envelope. A Bcc recipient can appear in RCPT TO without appearing in the visible message headers. Replying to a message and reporting a delivery failure need not use the same address.

A user normally submits through authenticated SMTP on port 587 with STARTTLS, or port 465 with TLS from the start. Server-to-server transfer normally uses port 25 and can negotiate STARTTLS. Submission and transfer have different roles even when both use SMTP. HTTP generally pulls requested objects; SMTP pushes a prepared message.

Check the sender's domain

A visible From: field is easy to forge. SPF checks whether the sending host is authorized for the envelope domain. DKIM verifies a message signature using a public key published in DNS. DMARC connects a successful SPF or DKIM result to the visible From domain through domain alignment and publishes a policy for failures. Passing SPF for an unrelated envelope domain alone does not validate the visible sender.

Mail transfer, message content and mailbox access are separate parts of email. SMTP moves a message to a mail server. The message has its own header-and-body format, and a recipient later accesses the stored mailbox through another protocol.

Read the message itself

A message begins with fields such as From:, To:, Date:, Subject: and Message-ID:. A blank line separates these headers from the body. They remain part of the stored message; SMTP's MAIL FROM and RCPT TO commands do not become message headers.

The basic format uses text lines. MIME, Multipurpose Internet Mail Extensions, describes richer content with extra fields. Content-Type: text/plain; charset=UTF-8 describes plain text and its character encoding. image/jpeg identifies an image. multipart/mixed describes multiple parts, separated by a boundary string, such as a text note followed by an attachment. Each part can have its own content type and transfer encoding.

Content-Transfer-Encoding describes how a part is represented for transfer. Base64 turns each group of three bytes into four ASCII characters. For a 3 MB attachment, 3,000,000 bytes become 4,000,000 characters before line breaks and message headers. The encoding adds about one third to the size. A server's total message-size limit therefore cannot be compared with the raw attachment size alone. Quoted-printable is another encoding suited to mostly readable text.

Choose a mail access protocol

The recipient's server can receive mail while the recipient's devices are offline. When the recipient returns, a mail access protocol lets a client retrieve stored messages.

IMAP can fetch a message's headers or selected parts without downloading every attachment. It commonly uses port 143 with STARTTLS or port 993 with TLS from the start. POP3 commonly uses port 110 or TLS on 995. Its deletion marks take effect when the session completes normally. Download-and-keep leaves copies on the server, but POP3 does not provide IMAP's server folders and shared flags.

Suppose Bob checks mail on a laptop before leaving home, then on a phone. If the laptop uses POP3 download-and-delete, the phone may find an empty server mailbox. With IMAP, marking a message read on the laptop changes server state that the phone can also see. The difference is mailbox synchronization, not SMTP delivery.

Follow a webmail message beyond the browser

A browser submits or reads mail using HTTPS. The webmail provider still uses SMTP to move mail to another domain's server. A complete path can therefore be HTTPS from sender to provider, SMTP between providers, then IMAP or HTTPS at the receiving end. Calling a service webmail describes its user interface and browser connection, not every protocol used along the message's route.

Distributing a file means every recipient must obtain a complete copy. The bottleneck is not always the server: a slow downloader or insufficient total upload capacity can set the minimum time. The standard model assumes access links are the bottlenecks and the core has enough capacity.

Compare the lower bounds

Let the file contain $F$ bits, with $N$ recipients. The server uploads at $u_s$; peer $i$ uploads at $u_i$ and downloads at $d_i$. The lowest peer download rate is $d_{min}$. Use matching units, such as Mbit and Mbps, so division produces seconds.

With client-server distribution, the server must send $NF$ bits and the slowest peer must receive $F$ bits:

For P2P, the server must introduce every bit at least once. Peers still have to download the file, and the whole system must upload enough data for all copies:

Take the maximum, because all requirements must be met during the distribution. Adding the terms would incorrectly assume those upload and download activities occur one after another. These are lower bounds; protocol overhead, unavailable peers and other bottlenecks can make real transfers slower.

Work one comparison

For a 2 Gbit file, use 2,000 Mbit. Let server upload be 100 Mbps, the slowest download 20 Mbps, and each of 100 peers upload at 5 Mbps.

The client-server server term is 200,000 Mbit divided by 100 Mbps, or 2,000 s. The slowest download term is 100 s. Its bound is therefore 2,000 s.

For P2P, introducing the file takes at least 20 s. The slowest download still takes 100 s. Total upload capacity is 100 plus 500, or 600 Mbps; distributing 200,000 Mbit takes at least about 333 s. The P2P bound is about 333 s. With 1,000 peers, the client-server bound rises to 20,000 s, while the P2P bound is about 392 s. For equal peer upload rates, the total-capacity term approaches file size divided by one peer's upload rate as the peer count becomes large.

Trade chunks in BitTorrent

A torrent is a group sharing one file. Peers exchange chunks, discover neighbors through a tracker or distributed hash table, and can upload before finishing the download. A seeder has the complete file and continues sharing it.

Rarest first chooses a needed chunk held by the fewest neighbors, helping preserve chunks that could otherwise disappear when a peer leaves. It decides what to request. Tit-for-tat encourages useful exchange by favoring neighbors supplying data quickly; it decides whom to upload to.

In the original design, four interested neighbors are unchoked at a time, including one optimistic unchoke. The regular choice is reconsidered about every 10 s and the optimistic peer about every 30 s. That exploratory slot gives newcomers a way to get initial chunks and helps discover better partners. The tracker coordinates discovery; it is not the data source for every chunk.

A video consists of frames displayed over time. Compression removes repeated information within a frame (spatial redundancy) and across frames (temporal redundancy). The encoded result has a bit rate: the amount of video data needed for each second of playback.

Connect rate, size and playback time

A two-hour video at 5 Mbps contains 36,000 Mbit, or 4.5 GB. Multiply rate by duration to obtain bits, then divide by eight for bytes. An average path throughput below the selected video rate eventually drains any finite buffer during continued playback.

A player can start before downloading the whole video. It stores upcoming data in a buffer, measured here in seconds of playable video. Playback consumes that buffer while downloads replenish it. A larger starting buffer gives protection against throughput dips but increases startup delay.

Request one segment at a time

DASH, Dynamic Adaptive Streaming over HTTP, stores several encoded versions at different rates and cuts each into segments. A manifest lists available versions and segment URLs. The client requests a segment with HTTP GET and chooses a version again at the next segment boundary. HLS uses a similar approach with playlists.

The player makes the adaptation decision using measured throughput and buffer level. A high recent throughput estimate favors a higher rate; a low buffer calls for caution. Choosing the highest rate seen once can cause a stall if the next download slows down. Players also try to avoid distracting, frequent quality switches.

Calculate a segment download

Consider 4 s segments encoded at 1, 2.5, 5 and 8 Mbps. At a measured throughput of 6 Mbps, the 5 Mbps segment contains 20 Mbit. It downloads in about 3.33 s, adding 4 s of playable content while playback uses about 3.33 s. With playback continuing, the buffer grows by about 0.67 s.

An 8 Mbps segment contains 32 Mbit and takes about 5.33 s, so the buffer shrinks by about 1.33 s. The path's 6 Mbps is a transfer rate; it does not turn an 8 Mbps encoding into a 6 Mbps encoding.

If throughput falls to 3 Mbps, the same 5 Mbps segment takes about 6.67 s. The buffer loses about 2.67 s per segment. Switching to the 2.5 Mbps version produces a 10 Mbit segment that takes about 3.33 s, allowing the buffer to grow again. For uninterrupted playback during a download, the starting buffer must also last until new playable data is available.

Stored streams and interactive calls

Stored-video streaming uses ordinary HTTP objects, which browser caches and CDN servers can serve. It therefore runs over TCP or QUIC according to the HTTP version. Interactive calls often use UDP-based media transport because waiting for older media can be worse than losing it.

A live event can also use segmented HTTP streaming, but the player waits for each segment to be produced and keeps a buffer behind the live action. Shorter segments can reduce that delay while increasing the number of requests. Seeking to an unbuffered location also requires refilling the player, which can briefly lower quality.

A content distribution network, or CDN, serves copies of content from many locations. It avoids sending every viewer to one distant data center and reduces repeated long-distance transfers. Distributing service capacity also reduces dependence on one site.

Put content near its users

A private CDN belongs to one provider; a third-party CDN serves many customers. Both can deliver images, scripts, software and web pages as well as video. The original content source is the origin. CDN clusters hold copies so the origin does not handle every request.

There are two useful placement strategies:

Placement and content filling are separate choices. With pull, a cluster missing an object fetches it from the origin or another cluster, stores it and serves it. With push, the provider sends objects in advance, often during quiet periods. A pull CDN's first request for an uncached object can still depend on the origin.

Trace a DNS handoff

A user requests https://video.stream.example.com/v/6Y7B23V:

1. The user's resolver asks about video.stream.example.com.
2. The provider's authoritative server returns a CNAME into the CDN's namespace, such as a1105.cdn.example.net.
3. The resolver follows that name to the CDN's authoritative DNS service.
4. The CDN selects a cluster and returns an address such as 198.51.100.17.
5. The client connects to that server with HTTPS and requests the content.

The CNAME changes where name resolution continues. DNS returns naming information; the video bytes arrive through HTTP afterward. If the content is segmented, many ordinary segment requests follow the same basic path to a selected server.

Choose a useful location

The closest cluster on a map may have a poor network path or be overloaded. A DNS-based decision may see the resolver's location, which can be far from the user. Better selection can use measured delay and loss, current load, and sometimes information about the client's network.

IP anycast provides another route to nearby service: several locations advertise the same IP address, and internet routing chooses a path to one of them. The resulting location depends on routing, not simply physical distance. A server close to the viewer can still deliver poor video if the viewer's own access link is the bottleneck.

Netflix's Open Connect places appliances inside ISP networks and connects at exchange locations. Content is filled ahead of demand, reducing busy-hour upstream traffic. Its application services and encoded video delivery need not run on the same infrastructure. Other private CDN designs can fill caches on demand. In each case, adaptive streaming controls what rate the player requests, while the CDN helps determine the path and server from which those requests are served.

Python sockets send bytes. Encode a string before sending and decode the received bytes afterward; the default text encoding is UTF-8. AF_INET selects IPv4 and SOCK_DGRAM selects UDP. Start with a local service so both processes can use loopback address 127.0.0.1.

Run the receiver first

This server handles short text datagrams and replies in uppercase:

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as server:
    server.bind(("127.0.0.1", 12000))
    while True:
        data, client_addr = server.recvfrom(2048)
        reply = data.decode().upper().encode()
        server.sendto(reply, client_addr)

bind gives the socket its receiving address and port. Binding to 127.0.0.1 accepts only local traffic. The empty address string "" instead binds to all IPv4 interfaces, making the service reachable from other hosts when the network permits it. Stop the running server before starting another copy on the same endpoint.

recvfrom blocks until a datagram arrives. It returns the data and sender's address, including the sender's port. The server uses that returned pair as the destination of sendto, so it can reply to clients whose ephemeral ports it did not know in advance.

Send a request and bound the wait

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as client:
    client.settimeout(2.0)
    client.sendto(b"hello network", ("127.0.0.1", 12000))
    try:
        data, server_addr = client.recvfrom(2048)
        print(data.decode())
    except TimeoutError:
        print("No reply within 2 seconds")

The b prefix creates a bytes literal; "hello network".encode() produces the same bytes. The operating system assigns the client's local port when needed. The expected response is HELLO NETWORK. Neither program calls listen or accept, because UDP has no transport connection setup.

A missing response does not tell the client exactly what failed. The request or reply may be lost, or no server may be listening. The timeout lets the application regain control. Some systems can report a closed destination port as an error; Windows may raise ConnectionResetError during receive.

Respect datagram boundaries

Each receive handles one datagram. Two datagrams are not combined into one message. If the receive buffer is too small, the excess of that datagram is discarded on typical Unix systems; Windows can report an error instead. Another receive does not recover the missing tail. Choose a buffer large enough for the application's expected messages.

The IPv4 UDP payload limit is 65,507 bytes with a minimum-size IPv4 header. That is a protocol maximum, not a useful target for routine datagram size. A program that needs loss detection can number messages, record send times with time.perf_counter(), and count timeouts. Two timeouts from ten requests give a measured loss rate of 20%. Retrying a request can cause duplicate processing, so a timeout-and-retry design may also need a way to recognize repeated message numbers.

TCP gives the program an ordered byte stream. It does not preserve the boundaries of sendall calls. A complete short test can arrive in one recv, but a correct program must also handle a request split across several receives.

Frame one text request

Choose a newline delimiter. The client sends one UTF-8 line, and the server returns one uppercase line. This server reads until it finds that delimiter before decoding:

from socket import socket, AF_INET, SOCK_STREAM

with socket(AF_INET, SOCK_STREAM) as server:
    server.bind(("127.0.0.1", 12000))
    server.listen(5)
    while True:
        conn, client_addr = server.accept()
        with conn:
            data = b""
            while b"\n" not in data:
                chunk = conn.recv(1024)
                if not chunk:
                    break
                data += chunk
            if b"\n" in data:
                line = data.split(b"\n", 1)[0]
                conn.sendall(line.decode().upper().encode() + b"\n")

listen creates a listening, or welcoming, socket. accept returns a new connection socket and the client's address. Use conn for this client's bytes; the original socket remains available to accept more connections. Here, clients are served one at a time. The backlog of five concerns pending connections, not five active worker threads.

Complete the client side

from socket import create_connection

with create_connection(("127.0.0.1", 12000), timeout=2) as client:
    client.sendall(b"hello network\n")
    data = b""
    while b"\n" not in data:
        chunk = client.recv(1024)
        if not chunk:
            raise EOFError("Reply ended before its newline")
        data += chunk
    print(data.split(b"\n", 1)[0].decode())

The expected result is HELLO NETWORK. sendall keeps sending until all supplied bytes are handed off or an error occurs. A single send may send only part and reports how many bytes it accepted. Neither call supplies application message boundaries to the receiver.

This service accepts one line per connection. A persistent multi-message service would retain bytes after the first newline for its next message. Length prefixes and closing the sending direction are other framing choices. Receiving b"" means the peer has ended its sending side; it is not an empty chunk to keep retrying.

Connect the code to real protocols

An HTTP/1.1 request is also a sequence of bytes:

from socket import create_connection

request = ("GET / HTTP/1.1\r\n"
           "Host: example.com\r\n"
           "Connection: close\r\n\r\n")
with create_connection(("example.com", 80), timeout=5) as sock:
    sock.sendall(request.encode("ascii"))
    chunks = []
    while True:
        chunk = sock.recv(4096)
        if not chunk:
            break
        chunks.append(chunk)
print(b"".join(chunks).decode(errors="replace")[:200])

This displays the start of the raw response, including its status and headers. A server can return an error or redirect; the code does not assume a particular response body. HTTPS on port 443 needs TLS wrapping with certificate and host-name verification, not just a changed port number. For example, ssl.create_default_context().wrap_socket(sock, server_hostname="example.com") wraps a connected socket after import ssl. A refused connection commonly means no listener; silently dropped traffic can time out. For quick server restarts on Unix, setting SO_REUSEADDR before bind can permit reuse when an old connection is closing; it does not let two active listeners own the same endpoint. Concurrent servers use threads or event loops, and distinguish connections by both endpoint address-port pairs.