Network: Part 7. Application Layer

The era of meaning

In December 1990, at the European Organization for Nuclear Research (CERN) near Geneva, a NeXT computer started working with a hand-glued label: "This machine is a server. DO NOT POWER IT DOWN!" Its owner, Tim Berners-Lee, hosted on it the world's first website — one page explaining what the World Wide Web is. For the first months, the Web existed inside the walls of the institute: Berners-Lee published the announcement in the alt.hypertext newsgroup only on August 6, 1991, and by the end of 1993 there were about six hundred sites in the world. Thirty-five years later, the application layer — the very thing for which all the others were actually built — looks like this. As of October 2026, 401.6 million domain names are registered in the world (Verisign, second quarter of 2026); about 390 billion emails are sent and received daily (Radicati Group); approximately 6 billion people are connected to the network — 74% of the planet's population (ITU, 2025); more than 95% of page loads in the Chrome browser go over encrypted HTTPS; the median web page weighs 2.4 megabytes and requires about a hundred requests (HTTP Archive, 2025); video accounts for about two thirds of all world traffic; and HTTP/3 — a protocol standardized only in 2022 — is already supported by 41% of websites (W3Techs, October 2026).

The paradox of the application layer is that it is the only level of the network model that the user sees with their own eyes. Everything below — signals in the wire, Ethernet frames, IP packets, TCP segments — exists solely so that the protocols of this level can exchange messages. The physical layer speaks about bits, the transport layer — about reliable delivery of bytes, and the application layer — about pages, letters, videos, and function calls. It is precisely here that "delivery" turns into "meaning": the network, which knew only how to forward bytes between addresses, becomes mail, a library, a cinema, a telephone, and a trading floor. At the same time, the application layer is the widest part of the Internet's hourglass: the narrow waist of IP has hardly changed in forty-five years, the transport layer was refined rather than rebuilt, and on top have grown hundreds of thousands of protocols, a significant part of which are standardized in thousands of RFCs.

This architecture gives rise to a series of critical questions:

1. The naming question. People and programs work with names like google.com; the network works with numbers like 142.250.74.14. How does a distributed database without a single center, replicating itself through caching, withstand trillions of requests per day without becoming a single point of failure — and why should the answer to this question be sought in 1983, when the entire address book of the Internet had to be replaced by a tree?
2. The state question. HTTP deliberately remembers nothing about the client between requests. From this simplicity grew both the scalability of the Web and an entire superstructure — cookies, sessions, tokens — which from a mechanism for an abandoned shopping cart turned into the foundation of authentication and into the main tool for tracking users.
3. The evolution question. From a protocol with one method and no headers (1991) to HTTP/3 over QUIC (2022), the Web four times rebuilt its own foundation while remaining compatible with pages from thirty years ago. Why did HTTP/1.1 dominate for twenty years, why did HTTP/2's multiplexing run into TCP, and why did the new transport have to be hidden inside the old UDP?
4. The scale question. One server is physically incapable of serving millions of viewers simultaneously. Caching, CDNs, peer-to-peer networks — over thirty years the Internet turned from a "client asks server" scheme into a distributed content delivery system, where most bytes are given not by the author, but by a copy of a copy lying two steps from the user.
5. The time question. Video requires megabytes per second, and a telephone conversation — a delay of less than 150 milliseconds; for the first, buffering is acceptable; for the second — death. How do one and the same applications coexist with channels of the most varied quality — and why does the client choose the bitrate without asking the network?
6. The trust question. Application protocols were designed in an era of universal trust: SMTP does not verify the sender, DNS does not sign responses, HTTP encrypts nothing. For forty years the industry has been patching these holes on the fly — SPF, DKIM, and DMARC for mail, DNSSEC and DoH for names, TLS for everything else — and still has not patched them completely.
7. The privacy question. The application layer has become the main theater of the fight for privacy: third-party cookies track the user across sites, DNS requests reveal the entire browsing history to the provider, and encrypted HTTPS hides the content but not the metadata. The battle of browsers, regulators, and the advertising business is rewriting the protocols right now.

Next we will go through the entire application layer: from the first applications of ARPANET and the client-server and P2P architectures — through DNS as a system and as a protocol, HTTP with all its versions, cookies, caching, and proxies — to page loading, streaming video, CDNs, electronic mail with its store-and-forward architecture, modern APIs (WebSocket, REST, GraphQL, gRPC), veterans like FTP and Gopher, advertising and tracking, and security. In the finale we will trace the path of a single request — from the browser's address bar to the pixels on the screen and the confirmation letter in the mailbox. The material is based on IETF and W3C standards, historical documents, and statistics of 2025–2026.

The birth of the application layer

"LO": the applications appeared before the network was built for them

The first message in the history of the Internet was an application-layer message. On the evening of October 29, 1969, UCLA student Charlie Kline, sitting at a terminal, attempted to transmit the word LOGIN to the computer of the Stanford Research Institute: the network managed to deliver the letters L and O, after which the remote system crashed. The historic "Lo" is remarkable not for the curiosity, but for its essence: already on the first day, the network was needed not for abstract "data transmission," but for a concrete application — remote login to someone else's computer. Telnet-like access, then file transfer, then mail — these are the three pillars on which ARPANET stood even before it acquired the familiar protocol stack.

The chronology here is more important than it seems. The specification of the file transfer protocol FTP appeared in RFC 114 on April 16, 1971 — more than three years before Cerf and Kahn's article about TCP, and twelve years before TCP/IP became the standard of the network. The first applications worked on top of NCP (Network Control Program) and knew neither IP addresses nor segments. The layers of the network model were not built from the bottom up, as in the textbooks: first the community learned what the network was needed for — and only then built delivery for these tasks. The application layer is the oldest in the Internet, and it is the one that defines the look of all the others.

Electronic mail: the first killer application

At the end of 1971, Ray Tomlinson, an engineer at BBN, the company building the ARPANET processors, thought to cross two existing programs: the local SNDMSG, which left notes in a mailbox on the same computer, and CPYNET, which transferred files over the network. The result was the first network mail — a message capable of flying from machine to machine. Tomlinson chose the @ symbol out of considerations of rarity: it did not occur in usernames and separated the recipient's name from the host name — ray@bbn-tenexa. The author did not remember the content of the first letters; according to him, it was nonsense like "QWERTYUIOP."

But everyone remembered the effect. By 1973, according to the estimates of contemporaries, electronic mail accounted for about three quarters of all ARPANET traffic: the network conceived for sharing computational resources turned out to be, first of all, a means of communication. Mail became the first killer app — the service for the sake of which people and organizations connected to the network — and set the pattern for half a century ahead: applications pull the infrastructure, not the other way around. Already in May 1978, the first spam flew across ARPANET — the DEC advertising mailing, of which more ahead, in the mail chapter.

Client-server: a model from the mainframe era

The architecture of network applications was predetermined by the computers of the 1960s–1970s. A mainframe with batch processing and "dumb" terminals printing characters and showing the result — this is precisely the prototype of the client-server model: asymmetric, where one party (the server) constantly works, stores data, and serves requests, while the other (the client) generates those requests. The division of labor invented for sharing expensive processor time among the employees of one institute was transferred to the division of labor between machines in a network — and it turned out to be so successful that almost the whole Internet still stands on it: HTTP, DNS, SMTP, IMAP.

Standards: the RFC factory

The application layer is standardized by the same RFC factory as the rest — but it produces an order of magnitude more output: the majority of the almost ten thousand IETF documents describe precisely applications. The oldest active specification of the layer is SMTP, the mail transfer protocol, released by Jon Postel in August 1982 (RFC 821 and RFC 822; the modern edition is RFC 5321, 2008): it is forty-five years old, and most of the world's letters still travel by it. The lifespan of an application protocol is measured in decades — the decisions sewn into the specification outlive their authors and the epoch. The price of longevity is conservatism: the design errors of SMTP and DNS are corrected not by replacing the protocols, but by superstructures on top of them.

The tasks and architectures of the application layer

Where delivery ends and meaning begins

The boundary of the layer is easiest to see on the encapsulation chain — the same one that was dissected for the transport and the network, with one more layer on top:

application message → TCP segment or UDP datagram → IP packet → Ethernet frame → bits in the medium

Each level adds its own header to the data and solves its own task. The data link level is responsible for transmitting a frame between neighbors, the network level — for delivering a packet between hosts through a multitude of networks, the transport level — for delivering a stream of bytes between processes. The application level creates the message itself: its format, its meaning, and the rules of the conversation. HTTP does not think about routes and losses — IP and TCP are busy with that; HTTP thinks about which resource is being requested, in which representation to return it, and what the received response means. The lower levels are delivery; the application level is the meaning of the communication. Hence the practical consequence familiar to everyone who has opened the browser developer tools: delivery problems are cured by configuring the network; problems of meaning — only by fixing the applications and protocols.

The four tasks of the layer

From this position follow four tasks that any application protocol solves.

• Data format. How the message looks on the wire: HTTP is human-readable text with headers, DNS is a dense binary format with compression pointers, mail is text with MIME extensions, gRPC is binary protobuf messages. The format determines efficiency, debuggability, and compatibility — the choice between them is an eternal engineering bargain.
• Interaction logic. Who starts the conversation, who answers, how many steps are in the dialogue. The "request — response" model (HTTP) is only one of many: multi-step dialogues (SMTP, IMAP), permanent two-way channels (WebSocket), asynchronous transmission with accumulation (mail), equal exchange without dedicated servers (BitTorrent).
• Naming. People work with meaningful names — google.com, user@example.com — while the network operates with numbers. Indirection — resolving a name into an address through a separate layer — is one of the most powerful tools of computer science, and in the Internet it is implemented by DNS: without it there would be neither portable links, nor migrations between hostings, nor load balancing.
• Semantics. What the message means and what is allowed to be done with it: "GET /index.html" — "give me the page," the code 404 — "not found." Semantics includes the contract on repeatability: safe operations (reading) do not change the state of the server; idempotent ones (deletion, PUT) give the same result when repeated — caching, retries, and the entire reliability of the web on top of an unreliable network rest on these properties.

The client-server architecture

The main model inherits from the mainframes: the client initiates the connection and asks the questions; the server listens on a known port, answers, and stores the state. The server is a constantly running process with a publicly addressable machine (or a cluster behind a balancer); the client is any device, from a phone to a sensor. The asymmetry is simple to manage, but runs into the performance of the server. Hence three paths of scaling: vertical (powerful hardware), horizontal (clusters and balancers), and geographic (copies of the content closer to users — CDNs).

The peer-to-peer architecture: an equality that did not win

The alternative to client-server is the peer-to-peer network (P2P), where every node is simultaneously a client and a server, and there is no center at all. The main trump card is scalability: the power of the system grows together with the number of participants, since every new consumer also brings resources. The history of P2P is three generations. Napster (Shawn Fanning, June 1999) was a hybrid: files traveled directly between users, but a central server stored the index; in two years the service gathered tens of millions of users and perished in the courts of the record companies (July 2001). Gnutella (March 2000) removed the center altogether — and drowned in its own inefficiency: queries poured out in an avalanche, every node retransmitted other people's searches. BitTorrent (Bram Cohen, 2001) solved both problems: pieces of files, exchange on the "you to me, I to you" principle (tit-for-tat), priority for rare pieces (rarest first), coordination by a tracker, later replaced by a distributed hash table. Skype (2003) built global telephony on supernodes.

But equality revealed systemic downsides: most users behind NAT do not accept incoming connections, nodes come and go (churn), the predictability of service is zero, monetization is impossible, and copyright holders and providers wage war on the distributions. The result: the share of P2P in world traffic fell from roughly sixty percent in the mid-2000s to single-digit percent today. The hybrid model won: management — through servers, data — from anywhere, including neighboring nodes; game updates, distribution delivery, and blockchain networks are built this way. Pure P2P remained a niche — but it proved that scalable content delivery does not have to be centralized, and prepared the ground for CDNs.

The protocol as an API

And the main generalization of the layer: an application protocol is a network API, a contract not between machines, but between programs. URI (RFC 3986, 2005) sets the universal syntax of names — scheme://host/path?query — and the port number indicates which application on the host the message is addressed to. Everything else is the agreement of two parties: the format of the messages, the admissible actions, the possible responses. In this lie both the source of the speed of innovation (anyone can invent a protocol and publish an RFC without asking anybody's permission) and the problems (nobody will check a new protocol for security). The application layer is the widest part of the hourglass: below is the narrow waist of IP, above are hundreds of thousands of applications, and the boundary between "protocol" and "application" is conditional: REST, WebSocket, and gRPC are simultaneously agreements about messages and ways of organizing software systems.

DNS: names instead of numbers

The crisis of one file and Mockapetris's answer

DNS is easy to take for the "telephone book of the Internet" — a table of "name → address." This simplification misses the essence: DNS is a distributed, hierarchical, caching, general-purpose naming system, and before 1983 there was no system at all. There was a file. The host table HOSTS.TXT was kept by the Network Information Center Service (SRI-NIC) under the direction of Elizabeth Feinler: the administrator of every new ARPANET node sent the center a letter with the name and address of their machine; NIC employees manually corrected the file and mailed it to all hosts twice a week. The scheme worked while there were dozens of hosts. In the early 1980s the number of machines began doubling approximately every ninety days; the distribution ate a noticeable share of the channels; names began to conflict (several organizations independently chose identical ones — like "fubar"); manual administration stopped keeping up with the growth. It became clear: a single point of name keeping does not scale.

There were two requirements: globally unique names and decentralized administration. The solution was designed by Paul Mockapetris of ISI: in November 1983 came out RFC 882 and RFC 883, and Mockapetris himself wrote the first implementation — JEEVES. In 1984–1985, four students of the University of California at Berkeley (Douglas Terry, Mark Painter, David Riggle, and Zhou Sunnian) created BIND — the first widely distributed implementation, which today is maintained by the ISC consortium. In 1987 the specification was revised into the current RFC 1034 and RFC 1035. There were four key ideas: a single tree of names, delegation of responsibility for subtrees, caching with a time to live, and a common data format — DNS stores not only addresses, but arbitrary typed records.

The tree and delegation

The name space is organized as an inverted tree. The root is an empty label; from it depart the top-level domains (TLD): national (.ru, .de, .uk), general-purpose (.com, .org, .net), and "new" ones that appeared after ICANN's 2012 program (.app, .dev, .museum — about a thousand and a half TLDs in total). Below are second-level domains (google.com), third-level ones (mail.google.com), and so on; the full name is read from right to left, from the general to the particular, and the dot at the end (google.com.) is that very root, which browsers hide out of politeness.

The tree is managed just as hierarchically. The root zone is maintained by IANA (a function of ICANN); on October 1, 2016, its management passed from the US government to the global multistakeholder community. The root servers are thirteen logical names from a.root-servers.net to m.root-servers.net, behind which stand twelve organizations (Verisign, ISC, RIPE NCC, ICANN, WIDE, and others). Thirteen is a limitation of the protocol of the 1980s (a UDP response fit the addresses of exactly thirteen servers), not of physical machines: thanks to anycast, the same names are served by more than two thousand instances around the world (root-servers.org, 2026). The records of every domain store its authoritative servers; delegation — an NS record at the parent — transfers responsibility for the subtree to the owner of the domain. This is how the tree scales: nobody stores all the records; everyone stores their own and references to other people's. According to Verisign data for June 30, 2026, 179.1 million names are registered in the .com and .net zones (166.6 million in .com), and across all TLDs in total — 401.6 million.

The path of a request: recursive and iterative

When the browser asks for the address of example.com, the path looks like this. First the local caches are checked: the browser's, the operating system's (in Windows — the DNS Client service, in Linux — systemd-resolved), the /etc/hosts file. If there is no answer, the request goes to the recursive resolver — the DNS server of the provider or a public one (Google Public DNS 8.8.8.8, launched in December 2009; Cloudflare 1.1.1.1 — since April 2018). The client sets the RD flag (Recursion Desired) — "do all the work for me"; the resolver answers with the RA flag if it supports recursion.

Then the resolver walks the tree iteratively — each server returns not an answer, but a "hint" (referral). To the root — "where is the .com zone?" — it answers with the list of NS of the .com zone and their addresses (glue records). To the .com servers — "where is example.com?" — the answer: the NS of the domain. To the authoritative servers of example.com — "what is the address?" — the answer: an A record with a TTL. The resolver returns the answer to the client and caches it for the TTL; the hints are cached too. It is precisely caching that keeps the system alive: only fractions of a percent of requests reach the root servers — otherwise the thirteen names would not last a day. The scale: Google Public DNS alone answers more than a trillion requests per day.

Two types of requests are worth distinguishing firmly: the recursive one ("find and give me the whole answer") goes from the client to its resolver; the iterative one ("tell me whom to ask next") — from the resolver to the root, TLD, and authoritative servers. The client almost never walks the tree itself; the resolver almost never demands recursion from others.

Record types: DNS is not only addresses

DNS is a typed database. The main types: A (an IPv4 address) and AAAA (an IPv6 address) — a name into a number; CNAME — an "alias" (www.example.com → example.com), forcing the resolver to repeat the request for another name; NS — the authoritative servers of the zone; SOA — the parameters of the zone (serial number, timings, negative TTL); MX — the mail servers of the domain with priorities (RFC 974, 1986) — without MX, electronic mail does not work; TXT — arbitrary text, which practice has turned into a service channel: SPF policies, DKIM keys, domain ownership confirmations, DMARC parameters live there; PTR — the reverse mapping "address → name"; SRV (RFC 2782) — the address and port of a service (SIP, XMPP). The newest generation is the SVCB and HTTPS records (RFC 9460): from them the browser learns, before connecting, whether the server supports HTTP/3 — DNS is being embedded ever deeper into the configuration of applications.

TTL and caching: speed at the price of staleness

Every record is given out with a time to live (TTL): resolvers and clients have the right to keep it in the cache no longer than this term. TTL is the main lever for managing the system: a large one (hours and days) reduces the load on the authoritative servers; a small one (seconds and minutes) allows quickly changing addresses — at the price of growing traffic. Hence the practical consequences: a change of IP during a move "propagates" not instantly, but over the course of the TTL — plus caches that are not obliged to respect the TTL (historically many resolvers kept records longer than prescribed); before a migration the TTL is reduced to minutes in advance; and the diagnosis "it works for me, not for the user" in half the cases means a divergence of caches. There also exists negative caching (RFC 2308): answers "no such name" (NXDOMAIN) are remembered too — otherwise typos would load the authoritative servers repeatedly.

DNS beyond naming: the global control plane

Since DNS stands before every connection, it long ago became the control plane of the Internet. One domain returns several addresses, and the order of the answer can be varied — the simplest load balancing (round robin). The authoritative server sees the address of the resolver — and often the client's subnet — so it answers different users differently: with the nearest CDN node (geo-routing), the least loaded data center, a backup address in case of an accident (failover with health checks). Systems of the GSLB class (global server load balancing) turn DNS into a dispatcher of planetary scale — this is exactly how Cloudflare, Akamai, and Amazon direct requests to the right points. The reverse side is the coarseness of the tool: DNS does not see the user's real load, and caching makes switches slow, so DNS dispatching is supplemented by anycast (one address from many points — the routing itself makes the choice) and by balancing inside data centers. There is also reverse resolution: the in-addr.arpa zones for IPv4 and ip6.arpa for IPv6, where the addresses are written backwards (14.74.250.142.in-addr.arpa). PTR records are used by logging, mail filters (the absence of a reverse name is a bad sign for a sender), and security tools.

The Internet is technically capable of working without DNS — curl with an explicit address will connect normally. But the name is the only point of entry: no name — no site, no mail (MX!), no API. DNS is critical infrastructure in the literal sense: its failure makes resources "nonexistent," even when the servers are alive. This role — in the absence of built-in authentication in the original protocol — has made DNS a permanent target.

DNS as a protocol: on the wire

UDP, TCP, and port 53

DNS travels on port 53 — historically over UDP, in modern times increasingly over TCP and encrypted superstructures. The choice of UDP is obvious: a typical request is a few dozen bytes, a response — hundreds; a datagram requires no handshake and saves an RTT. TCP comes in in three cases. First: the response does not fit into a datagram — the server sets the TC flag (truncated) in the header, and the client repeats the request over TCP. The historical limit of a UDP response is 512 bytes from RFC 1035; the EDNS0 extension (RFC 2671, 1999; current edition RFC 6891, 2013) allowed declaring a larger buffer — usually 1232 or 4096 bytes. Second: zone transfers (AXFR/IXFR) from the primary server to the secondaries. Third: DNSSEC — signatures bloat the messages several times over. A separate date is February 1, 2019, "DNS Flag Day": the largest operators (Google, Cloudflare, Cisco, Akamai, ISC) simultaneously stopped working around the bugs of old implementations that did not understand EDNS — an extremely rare case of forced modernization of a decentralized protocol.

The five sections of a message

The DNS request and response are arranged identically — five sections in a row. HEADER: the request identifier (16 bits) for matching responses; flags — QR (request or response), RD/RA (recursion desired/available), AA (the answer is authoritative), TC (truncated); the result code RCODE (NOERROR, NXDOMAIN — "the name does not exist," SERVFAIL); counters of the four remaining sections. QUESTION: what we are asking — the name (QNAME), the record type (QTYPE: A, AAAA, MX...) and the class (QCLASS, almost always IN — Internet). ANSWER: the records found, each with a name, type, class, TTL, and data. AUTHORITY: the NS records of the zone — the hint "whom to ask next." ADDITIONAL: additional data saving requests — for example, the addresses of those very NS servers (glue records).

Names are encoded by a sequence of labels ("www," "example," "com," the root) with a length before each, and are compressed by two-byte pointers to the first occurrences. The compression of 1983 allowed fitting responses with dozens of records into one datagram — and it also became a source of vulnerabilities (cyclic pointers in malicious responses).

Optimizations built into the design

Three mechanisms make the system fast: caching at all levels, thanks to which only a negligible share of requests reaches the root servers; the ADDITIONAL section with glue records — the addresses of the NS servers arrive together with the hint, without spending an extra request; negative caching of NXDOMAIN. The last one has a dark side: attackers generate millions of random subdomains to load the authoritative servers — attacks of the "water torture" class.

Vulnerabilities: spoofing, cache poisoning, and the Kaminsky attack

The original DNS authenticates nothing: a response is recognized as genuine if the request identifier, the address, and the port of the sender matched — and all three values in the implementations of the 1980s were predictable. Hence two techniques. Spoofing — slipping the victim a fake response faster than the real one; cache poisoning — the same response fed to the resolver: one successful forgery redirects all its clients to the attacker for the whole TTL, and through forged delegations — even longer (bailiwick attacks). In July 2008, Dan Kaminsky showed: the weakness is deeper — by brute-forcing the identifiers, the cache is poisoned even without guessing which name is being requested. On July 8, 2008, an unprecedented coordinated patch of the largest vendors came out; the measures were consolidated by RFC 5452 (2009): random source ports, strong identifiers, and also Paul Vixie's "0x20" trick — random alternation of the case of letters in the name as an additional bit of entropy.

DNSSEC: signatures instead of trust

The radical solution is cryptography. DNSSEC (RFC 4033–4035, March 2005) signs the zones: RRSIG signatures, DNSKEY keys, NSEC/NSEC3 hashes of nonexistent names; the trust is a chain from the root key downward through the DS records of delegation. A resolver that has verified the signature knows: the response really is from the owner of the zone and was not altered on the way. The root zone was signed on July 15, 2010; .com — on April 1, 2011; today the overwhelming majority of TLDs are signed. But the "last mile" lags: signed domains in .com number a few percent (Verisign, 2023); validating resolvers — on the order of a third of world traffic. The reasons are typical: signatures bloat the responses, key management is operationally complex, and there is no visible benefit for the user — as long as HTTPS works, a forged DNS response will run into an invalid certificate. And the main thing: DNSSEC protects the integrity and origin of the data, but not confidentiality.

DNS as a target of attacks

On February 6, 2007, a coordinated DDoS attack poured requests onto all thirteen root servers at once and lasted about twelve hours; the internet as a whole did not notice — caching and anycast saved it. In March 2013, the dispute of the anti-spammers Spamhaus with the hosting Cyberbunker spilled into an amplification attack (DNS amplification) with a power of about 300 Gbit/s — the largest in history at that time: tiny requests with the reflected address of the victim came back from open resolvers with responses tens of times larger. On October 21, 2016, the Mirai botnet of infected IoT devices struck the DNS provider Dyn in three waves: on the east coast of the USA, Twitter, GitHub, Reddit, Spotify, and PayPal went down for hours. The lesson of Dyn: it was not a site that fell — the provider of names fell, and thousands of independent services disappeared along with it. Hence the practices: several DNS providers per zone, short TTLs for critical records, anycast, filtering of forged traffic (BCP 38).

Privacy and encrypted DNS

Ordinary DNS is the last major unencrypted protocol of the mass Internet: the provider and any observer along the way sees every requested name — effectively the list of all visited sites. The answer is encryption. DoT (DNS over TLS, RFC 7858, 2016) — DNS in a TLS tunnel on port 853; DoH (DNS over HTTPS, RFC 8484, 2018) — DNS requests as HTTPS calls on port 443, indistinguishable for filters from web traffic; Oblivious DoH (RFC 9230, 2022) — a scheme where the proxy does not see the request, and the resolver does not see the client. Mozilla enabled DoH by default for American users of Firefox in February 2020; Chrome since the end of 2019 automatically upgrades to DoH the resolvers that support it. The deployment is controversial: corporate networks lose filtering, providers — telemetry, states — the lever of censorship; the dispute of "this breaks parental control" versus "the provider sells my browsing history" is political, not technical. Most requests from devices to the first resolver still travel as open UDP — but the trend is obvious: DNS is moving toward encryption by default.

HTTP: the protocol that became the Internet

"Vague, but exciting"

In March 1989, Tim Berners-Lee, an employee of CERN, submitted to the management the proposal "Information Management: A Proposal": a system of hypertext documents linked by references and accessible through the network. The task was prosaic: documentation was being lost in the institute; knowledge left together with those who resigned. On the title page survives the resolution of his boss Mike Sendall: "Vague, but exciting." In a year and a half, Berners-Lee wrote the WorldWideWeb browser-editor, the first server on his NeXT, and the HTTP protocol itself; the site info.cern.ch started working on December 20, 1990.

The first HTTP, retroactively named version 0.9, consisted of one command: the line "GET /path," in response — an HTML document, after which the connection was closed. No headers, no status codes, no other methods. The rest was determined by the market and the community: in 1993, Marc Andreessen and Eric Bina of NCSA released Mosaic — a browser that showed pictures inside the text; by the end of 1993 there were about six hundred sites in the world, by 1995 — tens of thousands. On April 30, 1993, CERN transferred the technologies of the Web to the public domain — a decision without which there would be no talk of any Internet in its current form (it also buried the competitor — Gopher). Andreessen went into business: in 1994, together with Jim Clark, he founded Netscape; the IPO of August 9, 1995 — the shares doubled on the first day of trading — gave the start to the dot-com era. Microsoft answered with Internet Explorer, distributed free together with Windows — the browser war ended with the antitrust case against Microsoft (1998–2001) and the opening of the Netscape code (January 1998; from it grew Mozilla and Firefox).

Standardization kept up with practice: HTTP/1.0 was described in RFC 1945 (June 1996; Berners-Lee, Fielding, and Frystyk) — the document recorded what browsers and servers already could do: headers, status codes, the POST and HEAD methods, content types from MIME. It was then that HTTP became a universal transport for any data, not only hypertext.

The anatomy of a request and a response

HTTP is a textual protocol for exchanging resources on the "client — server" model. The text here is literal: a request can be typed by hand, and the simplest debugging to this day looks like a telnet to port 80 and four lines:

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

The start line sets the method (GET), the path to the resource (/index.html), and the protocol version. Then come the headers — "name: value" pairs: who is asking (User-Agent), which host is meant (Host — mandatory since HTTP/1.1, and it made virtual hosting possible: dozens of sites on one IP address), which format is preferred (Accept). An empty line separates the headers from the body: in a GET there usually is none; in POST and PUT the data lies there. The response is mirrored: the status line "HTTP/1.1 200 OK," headers (Content-Type, Content-Length, Cache-Control), an empty line, the body. In HTTP/1.1 the chunked mode was added: the body is transmitted in portions without a length known in advance — the basis of streaming over HTTP. The main architectural luck of the format is extensibility through headers: for thirty years the protocol grows its capabilities without changing the grammar, and old intermediaries transparently pass through headers they do not know.

Methods and status codes: semantics as a contract

Methods set the meaning of the action. The set is described in RFC 9110 (June 2022): GET — obtain a resource; HEAD — the same without the body; POST — send data/create; PUT — replace the resource entirely; DELETE — delete; OPTIONS, CONNECT (a tunnel for TLS), and TRACE (practically forbidden) — service ones; PATCH (partial update) was added separately — RFC 5789 (2010). Behind the methods stand two properties on which the reliability of the web rests: safety (GET does not change the state of the server — it can be cached, repeated, prefetched) and idempotence (repeating a PUT or DELETE gives the same result — the client has the right to retransmit the request on a break; POST is not idempotent, and pressing "refresh" on a payment page is a bug of the user, not of the browser).

Status codes are the language of responses, a five-class system. 1xx — service ones (101 Switching Protocols — changing the protocol; WebSocket will need it); 2xx — success (200 OK, 201 Created, 204 No Content, 206 Partial Content — partial content, on which file download resumption and range-based video rest); 3xx — redirections (301 permanently, 302 temporarily, 304 Not Modified — "the cache is fresh," 307/308 — the same without changing the method); 4xx — client error (400 Bad Request, 401 Unauthorized — "identify yourself," 403 Forbidden — "I know who you are and I will not let you in," 404 Not Found, 429 Too Many Requests); 5xx — server error (500 Internal, 502 Bad Gateway and 504 Gateway Timeout — the typical responses of a proxy to the death of the backend, 503 Service Unavailable). The protocol is not averse to self-irony: the code 418 I'm a teapot was born in the April Fools' RFC 2324 (1998) about a coffee maker control protocol and became the industry's favorite joke; the code 451 Unavailable For Legal Reasons (RFC 7725, 2016) is named in honor of "Fahrenheit 451."

Stateless and cookies: the story of one compromise

HTTP fundamentally does not store state (stateless): the server remembers neither previous requests nor who made them. The decision is conscious: any server of the cluster can serve any request (scalability); the fall of a server does not lose the "session" (fault tolerance); intermediaries freely cache the responses. The price is the impossibility of "recognizing" the user: neither login between pages, nor a shopping cart.

The way out was found at Netscape in the summer of 1994: Lou Montulli was solving the task for the first commercial application of the browser — a virtual shopping cart. The idea was borrowed from Unix — "magic cookies": small data that a program issues and receives back unchanged. Thus the cookies mechanism was born: the server sends a Set-Cookie header with an identifier; the browser stores it and automatically attaches the Cookie header to subsequent requests to the same domain. The state remained on the server, and the protocol formally remained stateless.

Standardization went painfully: from RFC 2109 (1997), which recorded the diverging versions of Netscape and Microsoft, through the nearly dead RFC 2965 (2000) — to RFC 6265 (2011), which described the real practice. Cookies can be session ones (they die with the browser) and persistent ones (Expires/Max-Age), with a scope (Domain/Path) and security attributes added as the attacks came: Secure — only over HTTPS; HttpOnly — do not give to scripts (protection against session theft through XSS); SameSite — do not attach to cross-site requests (protection against CSRF; since February 2020 Chrome by default treats cookies as "Lax"). In essence a session cookie is a bearer token: presented it — means the owner. Hence the attacks on sessions (interception over unencrypted HTTP, theft through XSS, session fixation) and the practice: sensitive cookies — only Secure+HttpOnly+SameSite, short lifetimes, rotation of identifiers.

Content negotiation: one URL — many representations

The resource and its representation are separated in HTTP: at one address the server can give HTML to a browser and JSON to a program. The mechanism is content negotiation: the client declares its preferences with the headers Accept (data types with quality weights), Accept-Language (language — en, ru, de), Accept-Encoding (compression — gzip, br); the server chooses the representation and warns the caches with the Vary header: "the response is different for different Accept-Language; do not give a German the English copy." The same mechanics through Client Hints is gradually replacing the User-Agent string — the chaos of browsers' self-presentations: the string of modern Chrome still contains "Mozilla/5.0 ... like Gecko ... Safari."

The evolution of HTTP: thirty years of fighting latency

HTTP/1.0: the price of every connection

Before HTTP/1.1, each connection served one request: open a TCP connection (the handshake — a whole RTT), transmit the request, receive the response, close. For a page with fifty pictures this is a catastrophe: fifty handshakes and slow starts — TCP accelerates the window gradually, and a short connection does not have time to reach speed. Browsers coped by opening two parallel connections per host.

HTTP/1.1: persistent connections and the pipeline that did not take off

HTTP/1.1 (RFC 2068, January 1997; revision RFC 2616, June 1999) made connections persistent by default (keep-alive): one TCP connection serves a sequence of request-responses; chunked transfer, byte ranges (Range/206), and strict caching (Cache-Control) were added. The specification lived twenty-five years: in 2014 it was cut into RFC 7230–7235 (Fielding and Reschke), and in 2022 reissued as RFC 9110–9112 — without changing the meaning.

The main failure of HTTP/1.1 was pipelining: the specification allowed sending several requests in a row without waiting for the responses, but the responses returned strictly in order. One slow generation at the head of the queue delayed all the rest — head-of-line blocking; proxies massively broke the pipeline, and browsers turned it off. Practice went another way: six parallel connections per host, "domain sharding" (img1...img4.example.com), enlarging files — icon sprites, gluing CSS and JavaScript. All the frontend optimization of the 2000s is a monument to the fight against the limitations of HTTP/1.1.

HTTP/2: from SPDY into the standard

Google solved the problem differently: in November 2009 the company presented SPDY — an experimental protocol on top of TLS, where one connection carried many parallel prioritized streams, headers were compressed, and the server could itself suggest resources (push); measurements showed a loading speedup of up to one and a half times. In 2012 the IETF took SPDY as the basis of the standard, and in May 2015 came out RFC 7540 — HTTP/2 (reissued as RFC 9113 in 2022).

The key differences: binary framing instead of text — a message is cut into frames belonging to streams; the semantics of HTTP/1.1 did not change; multiplexing — hundreds of request-responses over one TCP connection in parallel, which removes both the limit of six connections and domain sharding; HPACK (RFC 7541) — header compression with a static dictionary and a dynamic connection table; stream priorities. But two problems remained. The first is TCP head-of-line blocking: all HTTP/2 streams share one reliable byte stream, and the loss of a segment stops them all — on networks with losses HTTP/2 in places lost to HTTP/1.1. The second is server push: the server did not know what was already in the client's cache; Chrome removed the support in 2022. Today HTTP/2 is the working standard of large sites and CDNs: by the W3Techs methodology, 35% of sites use it (October 2026).

HTTP/3 and QUIC: the transport moves into the protocol

The answer to TCP blocking lay on the surface: replace the transport. QUIC (RFC 9000, May 2021; details in the article about the transport layer) works on top of UDP: each stream is reliable by itself, the TLS 1.3 handshake is built into the transport one (one RTT for everything, zero for a repeated connection), and the connection identifier allows migrating between networks (Wi-Fi → LTE) without a break. In June 2022 came out RFC 9114 — HTTP/3: the same HTTP semantics, QPACK header compression (RFC 9204), but over QUIC instead of TCP.

Discovery works through the Alt-Svc header ("the resource is also available over h3") and the HTTPS/SVCB DNS records; the browser tries QUIC, and on failure (UDP is blocked in 3–7% of networks) falls back to TCP. The pace of adoption is unprecedented: in the three years after the RFC, 41.1% of websites declare support for HTTP/3 (W3Techs, October 2026), and the actual share of h3 requests in the Cloudflare network has passed a fifth (Cloudflare Radar, Q3 2026): the mobile Internet with losses and network switches is the environment where the gain of QUIC is maximal.

What latency is made of

The thirty-year race of versions is a war for round trips, and they run into physics. Light in fiber optics travels at a speed of about 200 thousand km/s — approximately 5 ms per thousand kilometers one way; the round trip New York — London is 70–80 ms, Sydney — London — close to 300 ms, and no protocol will cancel this. The budget of handshakes before the first byte at a cold start: DNS — from zero RTT (the record is in the cache) to two or three (a full walk of the tree); TCP — 1 RTT; TLS 1.2 — 2 RTT (TLS 1.3 — 1 RTT; QUIC — 0–1 RTT together with the transport); then the request-response itself — at least 1 more RTT. In total, three to five round trips "wasted" — this is why the combined handshake of QUIC and DNS caches give a gain of hundreds of milliseconds on transcontinental connections. Additional mechanisms save trips pointwise: TCP Fast Open (RFC 7413), 0-RTT in TLS 1.3, the status 103 Early Hints (RFC 8297, 2017) — an intermediate response with hints "start downloading these CSS and fonts" while the main server generates the page.

Page loading: from URL to pixels

A pipeline of seven steps

Let us connect the levels into one scenario — typing an address in the browser. Step 1: name resolution — the caches of the browser and the OS, then the recursive resolver, if necessary a full walk of the tree. Step 2: connection establishment — the TCP handshake (or QUIC, if h3 is known). Step 3: the TLS handshake — certificate verification, key exchange. Step 4: the HTTP request — with cookies and cache headers. Step 5: the response — HTML. Step 6: parsing and subrequests — the browser spawns dozens of new requests for CSS, JavaScript, fonts, pictures — possibly to other domains, with their own DNS and connections. Step 7: rendering. Up to the first byte at a cold start pass two to four RTTs plus the generation time on the server; a full load of a modern page takes seconds even on a fast channel.

The innards of the browser: DOM, CSSOM, and the critical path

Having received the HTML, the parser builds the DOM — the tree of document objects; from the CSS the CSSOM is built — the tree of styles; their merger gives the render tree, the basis for computing geometry (layout), drawing (paint), and assembling layers (composite). Two resources behave specially. CSS blocks rendering: the browser will show nothing until it builds the CSSOM, hence the technique of "inline critical CSS." JavaScript blocks parsing: a script tag without attributes stops the parsing of the HTML until the script is loaded and executed; it is treated with the attributes defer (execute after parsing, in order) and async (execute immediately, independently). While the parser is blocked, the preload scanner works — a look-ahead through the text, catching the URLs of resources for an early start of the download.

The page as a graph of resources

A modern page is not a document, but a graph of dependencies, and the statistics of the HTTP Archive (Web Almanac 2025) record this: the median page weighs about 2.4 MB on desktop and 2.1 MB on mobile; the median home page — 2.86 MB; over the decade the weight has grown roughly threefold. The composition of the median desktop home page: images about 1.06 MB, JavaScript about 0.7 MB, fonts 0.139 MB, CSS 0.082 MB, and the HTML itself — 22 kilobytes. Requests number around a hundred. The dependencies form a cascade: HTML → CSS → fonts, HTML → JS → API call → data → new resources; each link adds an RTT to the loading "waterfall." Hence the commandment of performance: reduce the depth of the graph (fewer sequential dependencies) and the width (fewer requests, a larger cache) — and remember that the response of the backend delays everything that depends on it.

Metrics and optimization

User perception of speed is formalized in Core Web Vitals (Google, May 2020): LCP — the rendering time of the largest element (the goal is less than 2.5 s), CLS — layout shift (less than 0.1), INP — responsiveness to interactions, which replaced FID in March 2024 (less than 200 ms); since 2021 the metrics count in search results. The optimization toolkit is a consequence of the pipeline's structure: a CDN brings the bytes closer to the user; caching removes requests altogether; compression (gzip, brotli — RFC 7932) cuts texts by 70–80%; the image formats WebP and AVIF cut the size by 30–50% against JPEG; lazy loading postpones resources outside the first screen; minification and bundling reduce the number of files — with an eye on HTTP/2, where the cache of one huge bundle is invalidated entirely; resource hints (dns-prefetch, preconnect, preload) allow the browser to start work in advance. The universal conclusion for the backend: every request is latency, and the fastest request is the one that did not have to be made.

Caching and proxies: the delivery infrastructure

The hierarchy of caches

If delivering a byte across the ocean costs tens of milliseconds, the best way to speed it up is not to deliver the byte at all. Caching is the central mechanism of the web, standardized in RFC 9111 (June 2022). Caches divide into private (the browser — for one user) and shared (intermediate). The hierarchy: browser → proxy → CDN → origin server. Each level absorbs its share of requests: for a well-configured static site, a CDN gives more than 90% of requests from the cache — this is exactly the mechanism that allows one server to serve the planet.

Cache-Control, ETag, and 304 Not Modified

Caching has two modes. The first is the freshness cache (strong caching): a response with "Cache-Control: max-age=3600" can be given out for a whole hour without asking the server at all. The second is validation: the cache stores a copy with a label (ETag — the fingerprint of the version, Last-Modified — the date of modification) and, before issuing it, makes a conditional request (If-None-Match / If-Modified-Since); if the resource has not changed, the server answers 304 Not Modified — with an empty body. The bytes are saved, but the RTT is spent — that is why fresh responses do not require validation. The Cache-Control directives finely manage the policy: public versus private (only for the browser — for personal data), no-store (never cache), no-cache (cache, but validate every time), s-maxage (a separate TTL for shared caches), stale-while-revalidate (RFC 5861) — give the stale one immediately, updating the copy in the background. The Expires header with an absolute date is a legacy of HTTP/1.0; it was abandoned because of clock desynchronization; the typical pattern: HTML — a short max-age or no-cache; static files with a hash in the name — max-age=31536000, immutable.

Invalidation: a hard problem

Phil Carlton is credited with the aphorism: "There are two hard problems in computer science: cache invalidation and naming things" (jokers add a third — off-by-one errors). A cache giving out stale content is a source of endless accidents: "users see the old version," "we rolled back the deploy, but it hangs." The remedies are the same as in DNS: TTL, URL versioning (new content — a new file name with a hash), forced purging (purge requests to the CDN). The conflict of "speed versus freshness" is unsolvable in principle — it is only tuned to the class of content.

Forward and reverse proxies

A proxy is an intermediary that performs requests on behalf of another party. A forward proxy stands on the client side: all the traffic of the organization goes through it, which gives access control (blocking sites in offices and in censorship networks), caching, partial anonymity; the classic implementation is Squid (1996). A reverse proxy stands on the server side and is indistinguishable from the server itself for the client: it balances requests across backends, terminates TLS (the encryption is unpacked at the proxy; plain HTTP goes inside), caches static content, filters attacks (WAF — web application firewall). The most famous is nginx by Igor Sysoev: started in 2002 as an answer to the C10K problem (ten thousand simultaneous connections), released in October 2004; nearby are HAProxy (2000), Envoy (Lyft, 2016, the basis of service meshes), API gateways. The typical path of a request today: client → CDN → reverse proxy → a pool of backends.

Streaming video: how the Internet learned to show movies

From RealAudio to Obama's inauguration

Transmitting an HTML page is simple; transmitting video is hard: it is megabytes per second, sensitive to delivery time. There are two classes of applications — buffered broadcasting (YouTube, Netflix: a stock can be accumulated) and real-time interactive (calls: latency is critical, a stock is impossible). First came specialized stacks: RealNetworks' RealAudio (April 1995) with its own servers and ports, then the IETF standards RTP and RTSP (RFC 1889 and RFC 2326, 1996–1998), and the era of Flash broadcasting over RTMP. The problem of "special" protocols is one: firewalls and NAT cut them, the cache infrastructure does not understand them, the servers are expensive. The turning point happened in 2007–2009: YouTube (founded in February 2005) proved the mass character of online video; Netflix launched streaming in January 2007; and the inauguration of Barack Obama on January 20, 2009 — more than a million simultaneous viewers, the record of the time — went through Akamai over ordinary HTTP. The industry understood: streaming = ordinary HTTP traffic, and it gets caches, CDNs, passage through firewalls, and scaling for free.

Chunks, manifests, and adaptive bitrate

The modern scheme: the video is cut into short segment files (2–10 seconds), and their list lies in a playlist manifest. Apple presented HLS (HTTP Live Streaming) in June 2009 (standardized in RFC 8216, 2017): a .m3u8 file with a list of .ts segments, later — fragmented MP4. The competitor is MPEG-DASH (ISO/IEC 23009-1, 2012): an XML manifest .mpd, codec independence; YouTube uses it. In 2018, the efforts of Apple and Microsoft gave birth to CMAF — a common container of fragmented MP4, so that one set of files serves both HLS and DASH. The client downloads the manifest, then the segments — with ordinary GET requests — stacking them into a buffer of 5–30 seconds of playback; when the buffer empties, the viewer sees the "spinner."

The key idea on top of this is the adaptive bitrate (ABR). The server stores the video in several qualities (a "ladder" from 240p to 4K); the manifest lists the variants; and the client itself, measuring the download speed of the segments and the buffer level, chooses the quality for the next chunks — dynamically, during viewing, without the participation of the network. This is a triumph of the end-to-end philosophy: the application adapts to the channel, not the channel to the application. The choice algorithms evolved from naive "by the last speed" (quality oscillations) to buffer-oriented ones (BOLA, 2016) and hybrid ones (MPC), and in 2017 MIT showed Pensieve — reinforcement learning. The target metric is QoE: startup time, the frequency and duration of "freezes" (rebuffering), the quality and smoothness of switches; Netflix's research entered the canon: for the viewer, a freeze is worse than low resolution — hence aggressive buffering and a cautious upgrade of quality. The codecs changed three times: H.264 → VP9 → AV1 (the AOMedia alliance, 2018); each gave a 30–50% saving of bitrate.

Real time: WebRTC and the gradations of latency

Buffering and conversation are incompatible: for a dialogue, a one-way delay of up to 150 ms is acceptable (the ITU-T G.114 recommendation); 400 ms is already hard. Here RTP over UDP reigns: lost packets are not retransmitted (an overdue frame is useless), losses are concealed by interpolation, jitter is smoothed by a small buffer (the mechanics were dissected by the article about the transport layer). Around this core grew WebRTC: Google bought the Swedish Global IP Solutions in 2011, opened the stack, and in January 2021 the W3C adopted the 1.0 specification — browser-to-browser calls without plugins, with media over SRTP, NAT traversal through ICE/STUN/TURN, and group SFU servers. Thus the ladder of latencies formed: VoD (tens of seconds of buffer) → live streaming (6–45 s) → low-latency live (LL-HLS/LL-DASH; Twitch — about 2 s) → interactive WebRTC (fractions of a second) → cloud gaming (less than 100 ms). The lower the step, the smaller the margin of safety: the triangle "latency — quality — stability" cannot be resolved entirely, and each application chooses its corner. New standards (MoQ — Media over QUIC, WebTransport) try to push the boundaries by moving media delivery onto QUIC.

The economics of video traffic

The scales determine the architecture. Video is about two thirds of all internet traffic (Sandvine, 2023 data); the average user downloads on the order of 5.6 GB per day (AppLogic Networks, 2025); several tech giants — Alphabet, Meta, as well as Netflix, Disney, and TikTok — produce more than half of world web traffic. Netflix with its 300+ million subscribers solves the task its own way: the Open Connect program (2012) places servers directly in the providers' networks for free, and about 95% of the company's traffic is given out "from inside" the ISP. It is precisely the traffic of such giants that kindled the disputes about net neutrality: the conflict of Comcast and Level 3 (2010) and Netflix's paid peering with Comcast (2014) posed the question "who pays for the last kilometer."

CDN and P2P: content delivery at planetary scale

Akamai: from a mathematical problem into an industry

The content delivery industry was born out of an academic problem. In 1995, MIT professor Tom Leighton and his graduate student Danny Lewin took up the question: how to spread the contents of a site across thousands of servers so that the user automatically lands on the nearest and least loaded one? The answer was consistent hashing (the article by Karger and co-authors, 1997) and smart DNS routing. In August 1998, Leighton and Lewin founded Akamai; in 1999 the company held its IPO at the peak of the dot-com boom — and survived the crash of the boom by selling "shovels for the gold rush." Danny Lewin perished on September 11, 2001, in American Airlines flight 11; he was 31. The network itself in those days withstood an unprecedented traffic spike precisely thanks to the distributed model — the caching edges turned out to be sturdier than the central servers of the news outlets, which were falling one after another.

Further, the industry grew like an avalanche: Limelight (2001), Amazon CloudFront (2008), Fastly (2011), and Cloudflare — the project launched on September 27, 2010, by Matthew Prince, Michelle Zatlyn, and Lee Holloway, which grew out of the anti-spam service Project Honey Pot and turned into a security and edge computing platform for a noticeable share of the Web. Netflix in 2012 went its special way with Open Connect. By 2026, Akamai declares more than 4,400 points of presence in 130+ countries with a capacity of over a petabit per second; Cloudflare — presence in 330+ cities; the predominant share of consumer web traffic passes through CDNs.

How it works: DNS, anycast, cache

The mechanics of a CDN are composed of three elements. Content: copies of the objects lie on edge servers; on a cache miss, the edge requests the object from the origin server — often through an intermediate origin shield, so that hundreds of edges do not duplicate misses — caches it, and gives it to the next user. Routing: the site's domain is delegated by a CNAME record into the DNS of the CDN provider, and that one, seeing the address of the resolver (and the client's subnet through EDNS Client Subnet, RFC 7871), returns the address of the nearest healthy edge; large networks additionally announce one anycast address from many points. Management: TTL, forced purging, caching rules. The effect is fourfold: less latency (the server is two steps away), less load on the origin (by tens of times), higher delivery reliability (short paths and the CDN's own backbones between points — Cloudflare Argo, Akamai SureRoute), higher fault tolerance. In essence, a CDN is a gigantic distributed cache that has become the habitat of web content.

P2P as an alternative — and why it yielded

The ideologically opposite approach is to distribute content by the forces of the viewers themselves. BitTorrent (Bram Cohen, July 2001) brought it to perfection: the file is cut into pieces; peers exchange the missing parts on the principle of reciprocity (tit-for-tat: you seed — you receive); rare pieces are prioritized (rarest first — the stability of the swarm); and since 2005 the coordination is done by a distributed hash table (DHT), which made magnet links fully decentralized. The throughput of the system grows with every new viewer — a dream for delivering updates: this is how Linux distributions, Blizzard game patches, and Internet Archive collections are distributed; Facebook in the 2010s used BitTorrent to roll out configurations in its data centers.

But commercial streaming was not taken by P2P: most users behind NAT do not accept incoming connections, peers unpredictably leave (churn), there are no quality guarantees, providers cut P2P traffic, and copyright holders wage a legal war on file sharing. When the prices for bandwidth fell and the CDNs grew, the economics tilted in favor of centralized edges. Hybrids remained: mesh calls of WebRTC between several participants, blockchain networks. The lesson of Napster — BitTorrent — Open Connect is simple: decentralization solves the problem of capacity, but loses manageability and predictability — and the market pays for the second.

Edge computing and the reverse side of centralization

Static delivery became a commodity, and CDNs turned into computing platforms: Cloudflare Workers (September 2017; V8 isolates instead of containers), AWS Lambda@Edge (2017), and Fastly Compute@Edge allow executing application code in hundreds of points of the planet — the request is processed right where the cache lies. The "backend" becomes a global function; the price is the complexity of state (it has to be moved out into distributed stores like KV) and lock-in to the platform.

The reverse side of efficiency is the concentration of risk. One configuration error at a large provider takes down a noticeable part of the Internet: on June 8, 2021, the hour-long Fastly accident (a client configuration change touched a hidden bug) laid down Reddit, Amazon, and the websites of the governments of the UK and the USA; on July 22, 2021, a failure of Akamai's EdgeDNS for 45 minutes disconnected banks (Lloyds, Virgin Money) and airlines (American, United, Southwest, Delta); on July 2, 2019, a regular expression in a new configuration of Cloudflare's WAF ate the CPUs across the whole network; in January 2026, a route leak (type 3/4 by the classification of RFC 7908) for 25 minutes disrupted the availability of Cloudflare services in part of the regions. There are no "single points of failure" in the architecture of the Internet, but there are such points in its economics — and multi-CDN, multi-DNS, and other people's postmortems have become part of engineering hygiene.

Electronic mail: the store-and-forward architecture

A protocol older than the Internet in its current form

The Web is not the oldest mass application; mail is older. Its path from the local program SNDMSG to a planetary system took a decade: in August 1982, Jon Postel released RFC 821 (the SMTP transfer protocol) and RFC 822 (the message format) — separating mail from FTP, whose MAIL and MLFL commands it had used before that. The current edition is RFC 5321 (2008); Eric Allman's "sendmail," written at Berkeley in the early eighties, has lived to our days. SMTP had a serious competitor: the ITU's X.400 standard — the "adult" corporate mail of OSI, which Europe was deploying with government orders. The simple textual SMTP, which worked on top of anything, won: by the mid-nineties X.400 left the stage — the first and not the last case when a "correct" standard lost to a "good enough" one.

The path of a letter: a chain of independent hops

Mail is a store-and-forward system: "save and pass on." The participants: MUA (the mail client), MSA (the submission server), MTA (transfer agents — the servers forwarding the letter between themselves), MDA (the delivery agent into the mailbox). The letter travels in hops: client → its submission server (port 587, with authentication) → the recipient's MTA (port 25) → the mailbox → the recipient's client picks it up later. Each hop is a full-fledged save: the server accepts the message entirely, puts it in a queue, and tries to pass it on; a temporary error (a 4xx code) means "repeat later" — the attempts last for days; a permanent one (5xx) — a return to the sender (bounce). In this lies the fundamental difference from HTTP: a web request is synchronous and end-to-end, while a letter is asynchronous and multi-step; the unavailability of the recipient does not cancel the sending, it only postpones it. That is exactly why mail survived all the failures of the Internet: the queue architecture absorbs failures — by the very nature of a network built on best effort with retries.

Where exactly to carry the letter, the MTA learns from DNS: the MX record of the recipient's domain (RFC 974, 1986) lists the mail servers with priorities. Without DNS, mail is impossible in principle; a broken MX record is the classic reason for "letters do not reach us," invisible from the web interface.

The SMTP dialogue and its ports

SMTP is a textual protocol, literally a "chat between servers": the sender introduces itself (EHLO — the extended greeting of ESMTP; in response the server lists the supported extensions), announces the envelope (MAIL FROM — the return address, RCPT TO — the recipient), transmits the contents with the DATA command up to the line with a lone dot, and ends the session (QUIT). There are three ports: 25 — server-to-server transfer (between other people's MTAs there is historically no authentication — the sender's name was trusted, and this trust became the main hole of mail); 587 — submission from the client to its own server (RFC 6409: authentication is mandatory, otherwise the server becomes an open relay for spam); 465 — the obsolete "implicit TLS," returned by practice (RFC 8314). Encryption between servers is added by STARTTLS (RFC 3207) — opportunistic, vulnerable to encryption-stripping attacks by an intermediary; so on top of it were invented MTA-STS (RFC 8461) and DANE (RFC 7672), tying the policy to DNS. More than 90% of Gmail's incoming traffic today goes over TLS (Google data) — but the server's certificate is verified, while the authenticity of the sender is not.

POP3 and IMAP: two philosophies of receiving

The letter delivered into the mailbox is picked up by the client itself — the pull model, which gave birth to two protocols with opposite philosophies. POP3 (RFC 1939, 1996) — "mail lives on my computer": the client authorizes (USER/PASS), asks for the list (LIST), downloads the letters (RETR), and by default deletes them from the server (DELE). The model is honest for one device and hopeless for several: no folders, no flags, no synchronization. IMAP (Mark Crispin, Stanford, 1986; RFC 3501, 2003; the current version IMAP4rev2 — RFC 9051, 2021) — "mail lives on the server": folders, flags, search on the server, partial download of large letters, the IDLE extension (RFC 2177) — a long-lived connection through which the server itself reports new letters. IMAP won: multi-device usage is the norm of life. On top of it, modernity has built the push notifications of mobile platforms (APNs at Apple, FCM at Google) and web mail over HTTPS: Hotmail (July 4, 1996 — the first mass web mail, sold to Microsoft for approximately 400 million dollars) and Gmail (April 1, 2004 — a gigabyte of mailbox and invitations; the world seriously discussed whether it was an April Fools' joke). The heir of IMAP is JMAP (RFC 8620, 2019, the brainchild of Fastmail): JSON over HTTP; it takes root slowly — mail is more conservative than the web.

The letter format and MIME

The letter itself is text with headers according to RFC 822 (now RFC 5322): From, To, Subject, Date, Message-ID, and the chain of Received — every server along the way stamps its line, forming a built-in protocol of movements by which forensic experts restore the route of the letter. The body was originally strictly 7-bit ASCII: no attachments, no Cyrillic, no pictures. The MIME extension (Nathaniel Borenstein and Ned Freed; the first RFCs — 1992; the current 2045–2049 — November 1996) solved everything at once with the Content-Type and Transfer-Encoding headers: multipart structures glue together in one letter the text, the HTML version, and the attachments; binary data is encoded in base64. Borenstein sent the first MIME letter in 1992 to his colleagues at Bellcore — with a photograph of his vocal ensemble's performance. Thus the protocol that "could do only text" learned everything that mail can do today — including HTML letters, which clients render with legendary crookedness (Outlook to this day lays them out with the Microsoft Word engine). Full internationalization (addresses and headers in UTF-8, RFC 6530–6532, 2012) did not take off — mail remains 7-bit at heart.

Spam: the economics of a fifty-year war

The first network spam was the Thuerk mailing of 1978. The first scandalous one was on April 12, 1994: the lawyer spouses Canter and Siegel sent an advertisement of the "green card lottery" to six thousand Usenet groups, called it marketing, and collected, by their own account, a hundred thousand dollars. The very term comes from a Monty Python sketch, where the word spam repeats until it drowns out the conversation: an exact metaphor. The economic nature of spam is ineradicable: the cost of sending tends to zero, which means a conversion of fractions of a per mille is profitable — a rational plague. By 2008–2010, spam made up 85–90% of world mail traffic; it was driven by botnets (Rustock, Srizbi, Mega-D) from "bulletproof" hostings. The operation against McColo is telling: on November 11–12, 2008, the upstream providers disconnected the California hoster — and world spam fell by roughly half within a day.

The fight against spam and sender authentication: SPF, DKIM, DMARC

The protection was built in layers: DNSBL — reputational blacklists distributed through DNS itself (the first was Paul Vixie's MAPS, 1997); Bayesian content filters (Paul Graham's essay "A Plan for Spam," 2002); greylisting (2003) — a temporary refusal with the expectation of a repeat: a normal MTA will repeat, a spam bot will not. But the main hole was the absence of sender authentication: SMTP believes the MAIL FROM field on its word, and forging a "letter from your bank" is trivial. It was closed with three superstructures. SPF (the idea of 2003, Meng Weng Wong; RFC 7208, 2014): the owner of the domain publishes in a TXT record the list of IPs allowed to send its mail — the receiver checks the address of the connection. DKIM (RFC 4871, 2007; the merger of Yahoo DomainKeys and Cisco Identified Internet Mail): the domain cryptographically signs the letter; the signature is verified by a public key from DNS and survives forwardings. DMARC (RFC 7489, 2015; started by PayPal with Google, Microsoft, and Yahoo): the policy — what to do if the checks fail (accept/quarantine/reject), plus reports to the domain owner. The final chord was February 1, 2024: Google and Yahoo made mandatory for mass senders SPF or DKIM, DMARC alignment, one-click unsubscribe, and a complaint rate below 0.3% — forty-two years after RFC 821, sender authentication became de facto mandatory. The war is not over: spam holds at the level of about 45% of traffic (2025), and instead of it phishing and business frauds (BEC) have blossomed — attacks on people, not on the protocol.

Why mail does not die

Mail is buried every decade — and every time it outlives those who bury it. The reasons are structural: federation (no owner, no single service — anyone can raise their own server), asynchrony (it does not require the presence of both parties), open standards, and a forty-five-year network effect. Plus a role that nobody planned: the mail address has become the universal identifier of a person on the Internet — registration, password recovery, and two-factor authentication of the rest of the web rest on it. The numbers of 2026: about 390 billion letters per day and more than 4.5 billion users (Radicati Group) — the oldest application protocol of the Internet remains one of the most heavily loaded.

The APIs of today: WebSocket, REST, GraphQL, gRPC

The server cannot speak first

Classic HTTP is a protocol of strict turn-taking: the client speaks, the server answers, the initiative is always with the client. For pages and files this is enough, but chats, notifications, stock quotes, multiplayer, and collaborative editing require the reverse — server push. While there was no standard, the web wriggled: periodic polling burned traffic in vain; long polling (generalized under the name Comet in 2005–2006) kept the request open until data appeared — a half-measure, where every "push" cost a new connection.

WebSocket: full duplex on port 80

The standard appeared in December 2011 — RFC 6455, which grew out of the experiments of Michael Carter (Kaazing, 2008) and a specification brought to completion by Ian Hickson. It is arranged elegantly: the connection begins as an ordinary HTTP request with the header "Upgrade: websocket"; the server answers with the status 101 Switching Protocols — and the TCP connection stops being HTTP: the parties exchange binary frames (textual or binary, with the service ping/pong/close) in both directions simultaneously. WebSocket stays on ports 80/443 and passes through proxies and firewalls — the same disguise as HTTP that QUIC will later apply. Client frames are obligatorily masked with a random key — a protection against attacks on caching proxies, because of which early implementations of the protocol had to be recalled in 2010. The price of duplex is state: long-lived connections require balancing with "sticky" sessions, a pub/sub layer between servers, and careful handling of breaks. Where only a "server → client" stream is needed, SSE (Server-Sent Events) is simpler; the new generation is WebTransport over HTTP/3.

REST: an architectural style, not a protocol

In 2000, Roy Fielding — one of the authors of HTTP/1.1 — defended his dissertation "Architectural Styles and the Design of Network-based Software Architectures," in which he described and named REST (Representational State Transfer). It is not a protocol, but a set of constraints on the architecture: client-server separation, absence of state on the server, cacheability of responses, a uniform interface — resources are identified by URIs and manipulated through representations (JSON, XML) via standard methods — and layering of the system. In practice, "REST API" means HTTP + JSON + "nouns" in the URL (/users/42/orders) + verb-methods + meaningful status codes. JSON made its own revolution: the format described by Douglas Crockford in 2001 and standardized in RFC 8259 (2017) displaced XML from web APIs — compactness and "nativeness" to browsers beat schemas and namespaces. REST won the era of public APIs without inventing a new protocol: the semantics of HTTP — cache, methods, codes — became the construction set.

GraphQL: the client orders the shape of the response

REST revealed systemic overheads: overfetching — the response carries more fields than the client needs, and underfetching — related data require a series of requests ("after the profile — a request for friends, after friends — for their posts"). The answer was invented at Facebook, where in 2012 the mobile application was being rewritten: GraphQL (opened together with the specification in September 2015) turns the relationship around — the client itself describes the needed shape of the data with a request tree, and the server assembles a response of exactly that shape, from a single endpoint, according to a strict typed schema with self-introspection. The landmark adoption was the GitHub API v4 (May 2017). The price: the HTTP cache almost stops working (all requests are POST to one URL), resolvers spawn the N+1 problem against the database, and a maliciously deep request becomes a vector of DoS. GraphQL did not replace REST — it occupied the niche of complex client applications with a strong frontend.

gRPC: a function call between data centers

The history of RPC — the remote procedure call — began with the article by Birrell and Nelson of Xerox PARC (1984): "a call must look local." Sun RPC (RFC 1050, 1988) gave birth to NFS; CORBA (1991) — the era of heavyweight object middleware; SOAP and XML-RPC (the turn of the 2000s) — corporate integration over XML, of which everyone grew tired, which cleared the road for REST. But inside data centers RPC never disappeared: Google from the early 2000s used the internal system Stubby with binary protobuf serialization (opened in 2008) — by the mid-2010s, trillions of calls per week passed through it. In March 2015, Google announced gRPC — an open rethinking of Stubby: service contracts are described in .proto files; code generators make client and server classes for a dozen languages; the transport is HTTP/2; four modes of operation: a unary call and three kinds of streaming — server, client, and bidirectional (a structured analog of WebSocket, but with a schema and types). gRPC became the standard of microservice communication and the foundation of service meshes (Istio, Envoy); browsers have access to it through gRPC-Web and proxies. The choice between REST and gRPC is dictated by the boundary of the system: outward — the readable and cacheable HTTP+JSON; inward, between your own services — the fast and typed gRPC.

Three models of interaction

All the variety of application protocols reduces to three models. "Request — response" (HTTP, REST, GraphQL): synchronous, the client leads, the responses are cached; most of the web is built this way. "Stream" (WebSocket, SSE, gRPC streams, WebRTC): a long-lived channel, the server speaks on its own; chats, quotes, and collaborative work are built this way. "Store and forward" (mail, message queues): asynchronous, the participants are not obliged to be online simultaneously, the failure of an intermediate node does not lose the data. Real systems combine the models — REST for data, WebSocket for live updates, queues for background tasks — and the choice of model is a first-order architectural decision.

Veterans and the fallen: FTP, telnet, Gopher

FTP: a protocol older than TCP

The file transfer protocol is older than the stack in which it works: RFC 114 came out on April 16, 1971 (Abhay Bhushan, MIT) — in the era of NCP, twelve years before the appearance of TCP/IP; the current specification RFC 959 is dated 1985. The architectural peculiarity of FTP is two connections: the control one (port 21, commands and responses) and a separate one for data (port 20 in active mode — the server itself connects to the client! — or a negotiated range in passive mode). Active mode broke against NAT long before this became a problem for the web. In the 1980s–1990s, anonymous FTP was the main mechanism of software distribution — archive servers kept mirrors of all software, and the first search engine Archie (1990, McGill University) indexed the listings of FTP catalogs. The security of FTP is zero — the login, password, and data go in open text; the FTPS superstructure (RFC 4217, 2005) saved the situation only partly, and the administrative niche was taken by SFTP — a protocol over SSH which, despite the similar abbreviation, has almost nothing to do with FTP. The agony ended in 2021, when Chrome (version 88) and Firefox (version 90) removed FTP support from the browsers; the protocol lives on in legacy integrations and hosting.

Telnet and SSH: the price of an open password

Telnet (first implementations — 1969; the standard RFC 854 — 1983) gave a remote terminal in open text: commands and passwords flew across the whole Internet in a form readable by any intermediary. In the spring of 1995, a sniffer attack on the network of the Helsinki University of Technology collected the passwords of hundreds of users — and Tatu Ylönen in a week wrote SSH: an encrypted terminal, port 22, publication in July of the same year. SSH-2 (RFC 4251–4254, 2006) and the free implementation OpenSSH (1999) displaced telnet, rlogin, and rsh from administration everywhere. Today SSH is a universal Swiss army knife: terminal, tunnels, port forwarding, transport for git and SFTP.

Gopher: the road not taken

In April 1991, the team of the University of Minnesota (Mark McCahill and colleagues) released Gopher — a system of menu-oriented documents: simple to deploy, hierarchical, with search through Veronica. The years of Gopher and the Web coincided, and universities at first more readily installed precisely Gopher. The denouement came in February 1993: Minnesota announced license fees for server implementations — and on April 30, 1993, CERN declared the WWW technologies free for everyone. The Web won not only by architecture (hyperlinks versus menus), but also by the decision not to take money. Gopher has lived to the present day in a tiny subculture of enthusiasts — a textbook example of how, in networks with a network effect, pricing a protocol is equivalent to suicide.

Other long-livers

Next to the Web quietly work the protocols of old: NTP (David Mills, RFC 958, 1985) — clock synchronization as an application service; whois (RFC 812, 1982); IRC (Jarkko Oikarinen, 1988); NNTP — the transport of Usenet. The application layer is simultaneously a museum and a laboratory: a protocol of 1971 coexists in one stack with a protocol of last year.

Advertising, tracking, and privacy

The cookie economy

The free web is paid for by advertising, and advertising — by tracking. The mechanics are simple: a resource of a third-party domain is embedded into the page — a script of an ad network or an analytics pixel — and this domain sets (or reads) its own cookie; the same domain on other sites recognizes the same user — this is how the behavioral profile is assembled, and the showing of each advertisement goes to a real-time auction. DoubleClick, founded in 1995, built on this a business sold to Google in 2008 for 3.1 billion dollars. The scale: at least one tracker is present on 75% of desktop and 74% of mobile pages (HTTP Archive, 2025).

The battle over tracking

The first battles thundered in the 1990s: press exposés, FTC hearings, the failed self-regulation through the P3P protocol (W3C, 2002). Then came the law: the ePrivacy Directive (2002/2009) gave birth to the European consent banners; GDPR (applicable since May 25, 2018) made the processing of personal data legally risky. Then — the browsers: Safari with Intelligent Tracking Prevention (2017) and Firefox with Enhanced Tracking Protection (2019) blocked third-party cookies by default; Chrome promised the same in 2020 (Privacy Sandbox), postponed it for four years, in July 2024 renounced the blocking, and in 2025 limited itself to "user choice" — the conflict of interest of the largest browser owned by the largest seller of advertising, in pure form. Apple in April 2021 (iOS 14.5) demanded explicit permission for tracking in mobile applications — a blow that cost, by estimates, up to 10 billion dollars of revenue to Facebook alone in a year. Tracking mutated: instead of cookies — fingerprinting (fonts, canvas, device characteristics), which cannot be switched off without breaking the web; the answers are partitioned cookies (CHIPS), the Topics API, the Storage Access API. Privacy became a property of the protocols, not only of the settings.

Privacy as a property of the protocol

HTTPS removed from the chain the observer-intermediary, but not the observer-recipient: the server still knows everything about the user. The metadata also flows: SNI in the TLS handshake names the domain even in an encrypted connection (the treatment is Encrypted Client Hello); DNS requests reveal the history (the treatment is DoH/DoT); the IP address links the sessions. The application layer became the front of privacy precisely because it is here that the bytes acquire meaning — and it is precisely here that there is something to protect.

Security of the application layer

HTTPS: from a privilege to the default

For the first two decades the web was open text: SSL was born at Netscape (1994–1995); TLS 1.0 was standardized in 1999 (RFC 2246); TLS 1.2 — in 2008 (RFC 5246); TLS 1.3 — in August 2018 (RFC 8446, after four years of work and 28 drafts: a handshake in one RTT, thrown-out insecure ciphers). But until the mid-2010s, HTTPS remained a showcase for banks and payment pages: certificates cost money, issuance — manual labor. The turning point was made by two events: the disclosures of Edward Snowden (2013) turned the open web into a political problem, and Let's Encrypt (an ISRG project; the first certificate — December 3, 2015) — into a solved engineering one: free certificates, automation through the ACME protocol, a lifespan of 90 days instead of a year. By the end of 2025, Let's Encrypt was issuing up to 10 million certificates a day, protecting hundreds of millions of sites; the share of HTTPS loads in Chrome reached 95–99% back by 2020; the browser since 2016 marks open HTTP as "Not secure," and from October 2026 (Chrome 154) turns on the "Always use secure connection" mode by default. Today HTTPS is the norm, and the exception requires explanations.

Attacks on applications and on the protocols themselves

The classics of application attacks entered the OWASP lists: injections (SQL — data as code), XSS (an injected script steals cookies — hence HttpOnly), CSRF (the attacker forces the browser to send a request with automatically attached cookies — hence SameSite and tokens). A separate layer is attacks on HTTP itself: request smuggling (desynchronization of the interpretation of Content-Length and Transfer-Encoding along a chain of proxies — described in 2005, returned in a wave after the research of James Kettle in 2019), web cache poisoning (an unaccounted header gets into the CDN cache and serves the victims other people's content), attacks on the Host header. Layer-seven DDoS strikes not at the channel, but at the logic: flooding with expensive endpoints and Slowloris (2009) — holding thousands of connections with incomplete requests. A separate era is supply chain attacks: typosquatting of npm and PyPI packages, dependency confusion, and the crown of the genre — SolarWinds (2020), where the target was not a server, but the software update mechanism. The general conclusion of forty years: the application layer expanded the attack surface faster than the means of protection.

Trust in the name: the seam between DNS and TLS

Trust in the web is assembled from two halves: DNS says where the name is located, and the certificate of a certificate authority (CA) confirms that the one answering owns this name. The seam between them is the favorite place of attacks. A DNS forgery runs into TLS: the attacker will not present a valid certificate for someone else's domain — but only on condition that certificates are not issued to just anyone. When it turned out that Symantec had massively issued them without due verification, the browsers in 2017–2018 stripped the entire company of trust — the precedent of the execution of a certificate authority. The mechanisms for repairing trust: Certificate Transparency (RFC 6962) — public logs of all issued certificates; CAA records in DNS — the domain owner indicates which CAs are allowed to issue it certificates; DANE/TLSA — tying the certificate to the domain through DNSSEC, without any CA at all. Not one mechanism has become ubiquitous — the security of names remains a patchwork quilt.

The path of one order: putting it all together

Let us trace an end-to-end scenario — a purchase in an online store by a user who is overseas from the origin server — and we will see all the mechanisms of the layer in one bundle.

In the address bar appears shop.example.com/checkout. The browser checks the DNS cache: the record is alive, the TTL has not expired — name resolution cost not a single request. A cold start would go longer: the recursive resolver would walk the anycast roots, the .com zone, and the authoritative servers of the store, where a CNAME record would lead the search into the DNS of the CDN provider, and that one would return the address of the nearest edge. The DNS record of type HTTPS hinted, even before connecting: the edge speaks HTTP/3 — the browser opened a QUIC connection with the built-in TLS 1.3 handshake, and since the visit is repeated, the data left in the very first packet (0-RTT).

The request POST /checkout carries the session cookies (Secure, HttpOnly, SameSite=Lax), the conditional headers If-None-Match, and Accept-Encoding: br. A personalized response cannot be cached — Cache-Control: private, no-store — and the edge proxies the request through the intermediate shield to the origin: the reverse proxy nginx balances it onto a backend; that one calls the internal services over gRPC (protobuf over HTTP/2), while the public contract is described by REST resources. While the backend was generating the page, the status 103 Early Hints had already sent the browser the hint to start downloading the styles — the waterfall of resources started before the main response.

A 200 OK arrives with HTML. The browser builds the DOM and CSSOM: the critical CSS is inlined, the main JavaScript is marked defer, the preload scanner has sent the requests for the static content in advance. Dozens of files — fonts, scripts, images in AVIF — have hashes in their names and the headers max-age=31536000, immutable: they are given out by the caches of the nearest edge, hardly disturbing the origin. Lazy loading postpones everything below the first screen; the rendering fits into the norms of Core Web Vitals even on an average mobile. A third-party analytics domain receives a beacon — and sets a partitioned cookie, no longer able to link the user across sites directly.

The order confirmation leaves as a letter. The backend hands it to its submission server over SMTP to port 587 with authentication; that one signs the message with the domain's DKIM signature and connects to the recipient's mail provider — the address found by the MX record; the transport is raised through STARTTLS according to the MTA-STS policy. The receiving server checks SPF, DKIM, and DMARC — the letter lands in the mailbox, and the mobile platform sends a push notification. Were the recipient unavailable, the letter would calmly lie in the queue for a day: store-and-forward is in no hurry anywhere.

One purchase engaged naming and caching, multiplexing and adaptation, three models of interaction, four mechanisms of trust — and not one of the protocols knew about the existence of the others. In this lies the very structure of the application layer: dozens of independent agreements add up into one user action.

Conclusions

The application layer is the place where the Internet becomes itself for people: the lower levels forward bytes, and only here do the bytes turn into pages, letters, videos, and function calls. Everything we have dissected fits into several through-lines.

The first line — meaning on top of delivery. The layer solves four tasks: the format of messages, the logic of interaction, naming, and semantics. The protocol here is a network API, a contract between programs, not between machines; the hourglass of the Internet expands upward precisely because adding a new application requires nobody's permission — the agreement of two parties is enough. Hence both the record speed of the layer's evolution and its main misfortune: together with the freedom to create came the freedom to create insecurely.

The second line — naming as the foundation. DNS grew out of the crisis of one HOSTS.TXT file into a distributed hierarchical database of 401.6 million domains, working on caching, delegation, and TTL. From a translator of names it turned into the control plane of the Internet — through it, load is balanced, users are geolocated, failover is switched on, and traffic is directed into CDNs. It also remained unprotected by birth: spoofing and cache poisoning were treated with randomization and DNSSEC, privacy — with DoT/DoH, and the role of critical infrastructure was confirmed by the attacks on the roots (2007), Spamhaus (2013), and Dyn (2016). Without DNS the Internet is technically alive — but for people and programs it is unsolvable.

The third line — the cache as a way to scale. The hierarchy "browser → proxy → CDN → origin" with its Cache-Control, ETag, and 304 turned planetary distances into local answers: the median page weighs megabytes, but most of them are given out from two steps from the user. CDNs grew out of an MIT mathematical problem into an infrastructure carrying most consumer traffic and executing code at the edge. The price is organizational centralization: one Fastly (2021) or Akamai (2021) configuration took down a noticeable part of the Web, and multi-CDN became part of engineering hygiene. Cache invalidation remained a hard problem — but URL versioning and TTL discipline make it solvable.

The fourth line — evolution through compatibility. HTTP/0.9 knew one method; HTTP/3 speaks QUIC over UDP — while the semantics (methods, headers, codes) have not changed in thirty-five years, and pages of the nineties are opened by today's browsers. SMTP of 1982 still carries the world's mail, growing superstructures: MIME taught it attachments, STARTTLS — encryption, SPF/DKIM/DMARC — sender verification. FTP outlived its own stack: born before TCP, it died in browsers only in 2021. Where compatibility has ossified, a new protocol disguises itself as an old one — QUIC hides in UDP on port 443; WebSocket begins its life as an HTTP request. The evolution of the application layer is work with the legacy, not against it.

The fifth line — three models of interaction. "Request — response" (HTTP, REST, GraphQL), "stream" (WebSocket, gRPC streams, WebRTC), and "store and forward" (mail, queues) exhaust the architectural space of network applications; real systems combine them, and the choice of model is the first architectural decision of any service. The model dictates everything: the infrastructure, the handling of failures, the way of scaling.

The sixth line — trust and privacy are built after the fact. The protocols of the era of universal trust had to be urgently patched with cryptography: TLS made HTTPS the norm (95–99% of loads in Chrome, hundreds of millions of Let's Encrypt certificates); Certificate Transparency and CAA repair the system of certificate authorities; encrypted DNS closes the last mass hole of privacy. At the same time, the application layer became the front of the fight for privacy: third-party cookies, trackers on three quarters of pages, fingerprinting — and the answers SameSite, browser blockings, GDPR. The war is not over, and it is fought with headers and attributes — the same weapon with which the layer itself was built.

For the practitioner, the conclusions are down-to-earth. First, the diagnostics of the layer is simple and accessible: dig and nslookup show the work of names, curl -v — the whole HTTP conversation, the developer tools — the waterfall and the caches; most "mysterious" problems are TTL, cache, or cookies misunderstood. Second, the architecture of an application is the choice of the model of interaction and of the latency budget: the physics of RTT is inexorable, and every extra request, every depth of the resource graph, every synchronous call in the chain costs the user milliseconds and seconds. Third, the cache and state are parts of correctness, not of optimization: Cache-Control, Vary, SameSite, and the invalidation policy must be designed together with the business logic. Fourth, reliability is in diversity: several DNS providers, multi-CDN, queues instead of synchronous calls wherever asynchrony is admissible.

The stack has been climbed to the top. From the "LO" of October 29, 1969 — two letters of a broken-off login — to 390 billion letters per day, hundreds of millions of sites, and video making two thirds of world traffic: the application layer turned the engineering of delivery into human infrastructure. The first website, info.cern.ch, still answers at its native address — a living monument to the main property of the layer: compatibility, which turned out to be more important than perfection. Above the protocols there remain only meanings — and the whole history of the application layer is the story of how bytes learned to express them.