URLs, DNS and bit streaming
From web address to web page
- You type a web address and a page appears almost instantly.
- Behind that are two ideas: the URL that names the resource, and DNS that finds it.
- Then we look at how media streams to you.
The URL
- A URL locates a resource on the web. Its parts:
https://www.example.com/about/contact.html
└─protocol─┘└──domain name──┘└────path────┘
- protocol —
http,https, … - domain name — a readable server address
- path — which resource on that server
In https://www.example.com/about/contact.html, what is https?
https is the protocol; www.example.com is the domain name; /about/contact.html is the path.
The Domain Name System (DNS)
- DNS is a distributed set of servers that turns domain names into IP addresses.
- When you type a URL, the browser asks a resolver for the IP; it queries DNS servers (root → top-level → authoritative) until it finds it.
- The browser then connects to that IP and requests the path.
- DNS saves us memorising IP addresses, and lets a site change server without changing its name.
The Domain Name System (DNS) mainly:
DNS resolves human-readable domain names to the numeric IP addresses the network actually uses.
One benefit of DNS is that:
Because the name maps to whatever IP DNS returns, the server can change while the domain name stays the same — and humans need not memorise IPs.
Bit streaming
- Streaming sends media as a continuous stream the receiver plays as it arrives, instead of downloading the whole file first.
- Real-time (live) — captured and sent as it happens (live sport, calls); you can't rewind, and low latency is vital.
- On-demand — pre-recorded on a server (video sites); you can pause and rewind, and the server can buffer ahead.
- A buffer stores a little data before playback so brief network dips don't interrupt it; lossy compression keeps the stream within the bandwidth.
Streaming media plays as it arrives, without first downloading the whole file.
That is the defining feature of streaming — the receiver plays the stream as it comes in (with a small buffer), rather than waiting for a full download.
Compared with real-time (live) streaming, on-demand streaming:
On-demand content is pre-recorded, so you can pause/rewind and the server can buffer well ahead. Live streaming can't be rewound and needs low latency.
Why does a streaming player use a buffer?
The buffer holds a few seconds ahead of what is playing, so short slow-downs in the network don't cause the playback to stall.
You've got it
- a URL = protocol + domain name + path
- DNS turns a domain name into an IP address (resolver → root → TLD → authoritative)
- streaming plays media as it arrives; real-time (no rewind) vs on-demand (pause/rewind)
- a buffer smooths playback; streaming uses lossy compression to fit the bandwidth