Behind the web: cookies, DNS, video and text generation

The everyday internet runs on many invisible rules. Here we look at four of them: cookies, DNS, video delivery and how text is generated. The site’s four works are all simplified educational models. The real systems are more complex, and the numbers and rules on screen are made-up values chosen to explain.

Cookies: notes left with the browser

By default a website does not remember one request from the next. So a site can ask the browser to hold a small note and show it again on the next visit. That note is a cookie. The server sends it as a name=value pair (Set-Cookie) and the browser sends it back later (Cookie).

Cookies are said to have been invented in 1994, with the problem of remembering an online shopping cart often given as a reason. Lou Montulli is named as the inventor. The name is said to come from the old Unix term “magic cookie”. The current specification is RFC 6265 (April 2011). A revised draft is in its final stages at the IETF but is not an RFC yet (as checked in October 2026).

Attributes decide when a cookie is sent.

• Lifetime (Expires, Max-Age): with neither, it is a session cookie and disappears when the browser closes. If both are present, Max-Age wins.
• Domain: if omitted, the cookie goes only to that exact host. If set, it also goes to subdomains.
• Path: sent only for that path and the pages below it.
• Secure: sent only over a secure connection (HTTPS).
• HttpOnly: hidden from scripts on the page (it is still sent with requests to the server).
• SameSite: decides whether it is sent with requests coming from another site. Strict means same-site only, Lax adds the case of following a link to the site, and None sends it everywhere (None requires Secure). Treating a missing setting as Lax is the current approach.

A third-party cookie is one set by a different site from the one you are viewing. It is used for ads and embedded parts, and can also recognise the same browser across sites. Browsers treat it differently. By date: one began blocking by default in March 2020, one began keeping a separate store for each site in June 2022, and one announced in April 2025 that it was dropping its plan to phase them out. This area changes quickly, so check each browser’s own documentation for the latest.

DNS: from names to addresses

DNS is the system that turns a name like “example.com” into the numeric address (IP address) used to communicate. Its core specification is RFC 1034 (November 1987, with its companion RFC 1035), and Paul Mockapetris is credited as the author. It is often compared to a phone book.

Names form a tree and become more specific from right to left. www.example.com goes down from the root, to “.com”, to “example.com”. A resolver (the helper that looks things up) typically asks the root first and gets directions to “.com”, asks there and gets directions to whoever manages “example.com”, then gets the final address from that server. It is not “always three steps”, though. What has been learned is kept (cached), so later lookups often skip the root.

How long an answer is kept is set by its TTL, in seconds. RFC 1034 describes TTL as how long a record may be cached before it should be discarded. Within the TTL the cached answer is used; after it, the resolver asks again. Records come in types: A maps a name to an IPv4 address, CNAME is an alias (read this name as another), and NS points to the name servers for a zone.

The root name servers have 13 identifying names, A to M, run by 12 independent organisations. That does not mean 13 machines: the same names are served from many places worldwide, and as of 17 October 2026 there were more than 2,000 operating instances.

The examples here use names like example.com and addresses like 192.0.2.x. These are reserved for use in documents and are not meant to be used for real (RFC 2606, RFC 5737).

Video: cut it up and read ahead

To stream video, you do not have to send one huge file from start to finish. One approach cuts it into short “segments” of a few seconds and hands out a “playlist”, like a table of contents. HLS is one such method: it was introduced in 2009 and is described in RFC 8216 (2017). Note that RFC 8216 is not a Standards Track document; it is published as Informational. A different method, MPEG-DASH, had its first international standard in 2012. The playlist lists several picture qualities so the player can switch with the connection. In RFC 8216, a typical segment length is 10 seconds.

The player loads ahead of the playing position and stores it. That store is the buffer. When it runs empty, playback stops. If the connection stays slower than the bitrate (data per second) of the chosen quality, the buffer drains. For example, with a connection of 3 and a quality of 6, only half of what each second needs arrives, and the rest is taken from the stored amount. It is simple division. So players use adaptive bitrate: they look at the connection and the buffer to choose the quality of the next segment. There is research on methods that weigh the buffer level heavily (a 2014 paper). The selection rule on this site’s screen is a simplified one for explanation, and is not what any real player does.

LLMs: calculating the next word

A large language model splits text into small units called tokens, works out the probability of each possible next token from the tokens so far, picks one and adds it, and repeats this to build text. Tokens include pieces smaller than words. Ways of writing rare words as combinations of pieces were studied in a 2015 paper, among others. This site splits text with a small rule of its own, which is different from real tokenisers.

The 2017 paper “Attention Is All You Need” proposed a new structure, the transformer, built only on a mechanism called attention. Many of today’s language models are built on this structure.

Choosing the token involves something like a lottery. When picking from a table of probabilities, a number called temperature adjusts the bias. Lowering it concentrates the choice on the likeliest options; raising it flattens the odds, so unusual options appear more often. The calculation divides each score by the temperature and then turns the scores into probabilities. For scores 2.0, 1.0 and 0.1, a temperature of 1 gives about 0.66, 0.24 and 0.10, and a temperature of 2 flattens them to about 0.50, 0.30 and 0.19.

The key point is that the model is built to choose a plausible next word, and on its own it has no built-in way to check whether what it wrote is true. That is why plausible-sounding mistakes can appear; research calls this “hallucination”. The examples here use a small made-up probability table. They do not show what any real model knows.

Spot the differences

• Cookies: the same cookie is sent in different situations depending on its attributes.
• DNS: the second lookup is fast because the answer is cached. When the TTL runs out, it asks again.
• Video: it stops when the connection cannot keep up with the quality and the buffer empties.
• LLMs: changing the temperature changes the text produced from the same input.

Try the four works in turn and you may notice the same ideas running through all of them: storing, remembering, choosing.