Networking Concepts Explained: CDNs, VPNs, QoS, and TTL

Computer Networking for Beginners series — Part 4. This post continues Part 1: A Complete Guide to How Networks Work, Part 2: What Is the OSI Model?, and Part 3: Networking Devices Explained. Each post in the series takes one topic and covers it in depth. This one covers four concepts you’ll run into constantly: CDNs, VPNs, QoS, and TTL.

In Part 3, you met the devices that make networks work. This post looks at four ideas that build on top of them — ways networks are made faster, more secure, more reliable, and self-correcting:

• Content delivery networks (CDNs) make websites load faster by keeping copies of content close to the people who request it.
• Virtual private networks (VPNs) create secure, encrypted connections across the public internet.
• Quality of Service (QoS) makes sure the most important traffic, like video calls, gets through first when the network is busy.
• Time to Live (TTL) puts a limit on how long something lasts — a packet’s journey across the internet, or a saved DNS answer.

You’ll find all four in everyday life: every time you stream a video, join a work meeting from home, or visit a website that just changed servers.

Content Delivery Networks (CDNs)

The Problem: Distance

Data travels fast, but not instantly. If a website’s server is in Virginia and a visitor is in Tokyo, every request has to cross an ocean and back, passing through many routers on the way. Each round trip adds delay — latency — and a modern web page can need dozens of requests for its HTML, CSS, JavaScript, images, and fonts. On top of that, if thousands of visitors all hit that one server at once, it can slow down or fail.

The Solution: Copies Close to Users

A content delivery network (CDN) is a large group of servers spread across many cities around the world. These locations are called points of presence (PoPs), and the servers in them are called edge servers. Each one caches — stores a copy of — your website’s content. Your own web server is called the origin.

When a visitor requests your site, they’re automatically sent to the nearest edge server:

• Cache hit: the edge server already has a copy of the file, so it sends it immediately. The request never travels to the origin at all.
• Cache miss: the edge server doesn’t have the file yet (or its copy has expired), so it fetches it from the origin, sends it to the visitor, and keeps a copy for the next person.

After the first visitor in a region, everyone else nearby gets the content from just a few miles away instead of from across the world.

Why Use a CDN?

• Faster loading, because content travels a much shorter distance.
• Less load on your origin server, because most requests are answered by edge servers.
• Better reliability: if one edge location has a problem, visitors are sent to another, and cached content can sometimes still be served even if the origin is briefly down.
• Protection against attacks: CDNs are built to absorb huge amounts of traffic, which helps protect websites from DDoS (distributed denial-of-service) attacks.
• Lower bandwidth costs for the origin.

What Gets Cached?

CDNs work best for static content — files that are the same for every visitor: images, videos, CSS, JavaScript, fonts, and downloads. Static websites can be served almost entirely from a CDN. Personalized pages, like a shopping cart or an account dashboard, usually come from the origin each time.

How long an edge server keeps a copy is controlled by the website, usually with an HTTP header called Cache-Control, which sets how many seconds a file can be cached. That number is another kind of TTL, which you’ll learn about later in this post. When you update a file before its time is up, you can purge (clear) it from the CDN’s cache, or give the new version a new file name so it’s fetched fresh.

Well-known CDN providers include Cloudflare, Akamai, Fastly, and Amazon CloudFront. Video streaming services and large websites rely on them heavily — much of the traffic on the internet today is delivered by CDNs.

Virtual Private Networks (VPNs)

The Problem: The Internet Isn’t Private

The public internet is untrusted: your data passes through networks owned by many different companies, and on public Wi-Fi, other people on the same network may be able to see unencrypted traffic. Yet employees need to reach their company’s private network from home, and branch offices need to connect to headquarters.

The Solution: An Encrypted Tunnel

A virtual private network (VPN) creates a secure, encrypted connection — often called a tunnel — across the internet. Data is encrypted before it leaves one end and decrypted at the other, so anyone in between sees only scrambled data. To the devices at each end, it’s as if they were connected to the same private network.

The tunnel works through encapsulation, the same idea you saw in Part 2: your original packet — including its private addresses — is encrypted and wrapped inside a new packet with public internet addresses. When it reaches the other end of the tunnel, the outer packet is removed, the inner packet is decrypted, and it continues on its way as if it had never left the private network.

Types of VPNs

• Remote access VPN: connects one device to a private network. An employee working from home runs a VPN client on their laptop and can reach the company’s internal servers as if they were in the office.
• Site-to-site VPN: connects two entire networks, like a branch office and headquarters. The tunnel is set up between the two offices’ routers or firewalls, so every device in the branch can reach the main office automatically — no software is needed on each computer.

VPN Concentrators

A company with hundreds or thousands of remote workers needs something that can handle all of those encrypted tunnels at once. A VPN concentrator is a device (or a feature of a firewall) built for exactly that: it terminates many VPN connections, handling the encryption and decryption for every one of them, and authenticates each user. Today, this job is often done by a next-generation firewall (see Part 3) or by a cloud service.

Full Tunnel and Split Tunnel

• In a full tunnel, all of the device’s traffic goes through the VPN — even regular web browsing. It’s the most secure option, because the company’s security tools can inspect everything, but it adds load to the VPN and can slow things down.
• In a split tunnel, only traffic headed for the private network goes through the VPN, and everything else goes straight to the internet. It’s faster and lighter on the VPN, but the device’s other traffic isn’t protected by the company’s security tools.

VPN Protocols

VPNs use protocols designed for secure tunneling:

• IPsec — a widely used standard for site-to-site and remote access VPNs.
• SSL/TLS VPNs — use the same encryption as HTTPS, so they work through almost any firewall. Some even run in a web browser without installing a client.
• WireGuard — a newer, simpler, and very fast protocol.
• OpenVPN — a popular open-source option.

Business VPNs and Consumer VPNs

The VPN services advertised to consumers are a different use of the same technology. Instead of connecting you to a private network, they send your traffic through the provider’s servers, which hides your activity from your local network (useful on public Wi-Fi) and shows websites the provider’s IP address instead of yours. They don’t make you anonymous, and you’re trusting the VPN provider with your traffic instead.

For your own devices, a mesh VPN like Tailscale gives you secure access to your home network from anywhere, without configuring a VPN server — see How to Set Up Tailscale.

Quality of Service (QoS)

The Problem: Not All Traffic Is Equal

Every network connection has a limited amount of bandwidth. When more traffic is waiting than the connection can carry, packets have to wait in line, and some may be dropped. For most traffic, that’s fine: a file download that takes a few extra seconds isn’t a problem, and TCP resends anything that’s lost.

Real-time traffic is different. A video call or a voice call needs a steady stream of packets arriving on time. Delays (latency), uneven delays (jitter), and lost packets make voices choppy and video freeze — and a late packet is useless, because that moment of the conversation has already passed.

The Solution: Prioritize What Matters

Quality of Service (QoS) is a set of settings that tells network devices which traffic is most important, so it gets through first when the network is busy. QoS doesn’t add bandwidth; it decides who goes first when there isn’t enough to go around.

QoS works in a few steps:

1. Classify the traffic: identify what kind of traffic each packet is — a voice call, a video meeting, a web page, or a backup.
2. Mark it: label each packet with its priority. On IP networks, this is done with a field in the IP header called DSCP (Differentiated Services Code Point), so every router and switch along the way can see the priority.
3. Queue it: devices keep separate lines (queues) for different priorities and always send the high-priority packets first.

A typical set of priorities might look like this:

Traffic Shaping and Policing

Two related tools control how much bandwidth traffic can use:

• Traffic shaping smooths traffic out to a set rate. When a type of traffic goes over its limit, the extra packets are held in a buffer and sent a little later, instead of being dropped. For example, a company might shape backup traffic so it never uses more than a fixed share of the connection during working hours.
• Traffic policing enforces a hard limit by dropping (or re-marking) traffic that goes over it. Internet providers often police traffic to the speed you pay for.

At home, many routers have a QoS or SQM (Smart Queue Management) setting that prioritizes video calls and gaming, or reduces lag while someone else in the house is downloading a large file.

Time to Live (TTL)

Time to Live (TTL) is a limit that keeps something from lasting forever. The name is the same everywhere, but what it counts depends on the protocol. The two you’ll see most are in IP routing, where it counts hops, and in DNS, where it counts seconds.

TTL in IP: Counting Hops

Every IP packet carries a TTL value in its header. The device that sends the packet sets a starting value — commonly 64 on Linux and macOS and 128 on Windows. Then:

1. Every router that forwards the packet subtracts 1 from the TTL.
2. If the TTL reaches 0, the router discards the packet instead of forwarding it.
3. The router sends an ICMP “Time Exceeded” message back to the sender, so it knows the packet didn’t make it.

Why have a limit at all? Because of routing loops. If routers are misconfigured — router A sends a packet to router B, and router B sends it right back to router A — a packet without a limit could circle forever, wasting bandwidth and adding to every other loop until the network collapsed. With TTL, a lost packet always dies after a set number of hops. (In IPv6, the same field is called Hop Limit, which describes it more accurately.)

You’ve already seen IP TTL in action. In Part 1, the ping output showed ttl=54 in every reply from example.com:

64 bytes from 104.20.23.154: icmp_seq=0 ttl=54 time=23.882 ms

That’s the TTL that was left when the reply arrived. If the server started at 64, the reply passed through 10 routers on the way back. Ping your own router, which is just one step away, and you’ll see the full value:

ping -c 1 192.168.1.1

64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=4.119 ms

You can even set the TTL yourself to watch a packet expire. On macOS, ping -m 3 sends a packet with a TTL of 3 (on Linux, use ping -t 3; on Windows, ping -i 3):

ping -c 1 -m 3 example.com

PING example.com (104.20.23.154): 56 data bytes
36 bytes from 203.0.113.45: Time to live exceeded

The packet made it through two routers, and the third one reduced its TTL to 0, threw it away, and sent back the “Time to live exceeded” message.

How traceroute Uses TTL

This is exactly how traceroute (tracert on Windows) maps the path to a destination, as you saw in Part 1. It sends packets with a TTL of 1, then 2, then 3, and so on. Each packet expires one router farther along the path, and each “Time Exceeded” reply reveals the address of the router where it expired. Put the replies in order, and you have a list of every hop between you and the destination.

TTL in DNS: Counting Seconds

In DNS, TTL means something different: how many seconds a DNS answer can be cached before it should be looked up again.

Every DNS record has a TTL set by whoever manages the domain. When a DNS resolver looks up a name, it saves the answer for that many seconds. Any request during that time gets the saved answer instantly, without repeating the full lookup. When the TTL runs out, the saved answer is thrown away, and the next request triggers a fresh lookup. (For a refresher on how DNS lookups work, see Part 1.)

You can see the TTL with the dig command, which is included with macOS and Linux:

dig example.com A +noall +answer

example.com.		188	IN	A	172.66.147.243
example.com.		188	IN	A	104.20.23.154

The second column is the TTL: the resolver will keep this answer for another 188 seconds. Run the same command a few seconds later, and the number has gone down:

example.com.		182	IN	A	172.66.147.243
example.com.		182	IN	A	104.20.23.154

Six seconds later, there are 182 seconds left. You’re seeing the cached answer count down. When it reaches zero, the resolver will look the name up again. (On Windows, Resolve-DnsName example.com in PowerShell shows the TTL too.)

Choosing a DNS TTL

DNS TTLs are a trade-off:

• A long TTL (like 86,400 seconds, one day) means fewer lookups and faster responses, because answers stay cached. But if you change the record, some visitors may keep getting the old answer until their cached copy expires.
• A short TTL (like 300 seconds, five minutes) means changes spread quickly, at the cost of more DNS lookups.

This matters most when you move a website to a new server. A common practice:

1. A day or two before the move, lower the TTL on the domain’s records — for example, to 300 seconds — so cached answers expire quickly.
2. Change the record to point to the new server. Within minutes, visitors start reaching the new server.
3. Once everything works, raise the TTL again.

This is also why people say a DNS change is “propagating”: nothing is being pushed out — resolvers around the world are simply waiting for their cached copies to expire.

TTL Elsewhere

You’ll see the same idea under different names: the Cache-Control header that tells browsers and CDNs how long to keep a file, DHCP leases that expire unless a device renews its IP address, and session timeouts on websites. Each one is a limit that makes sure data eventually gets refreshed instead of lasting forever.

Putting It All Together

Imagine you’re working from home and join a video meeting hosted on your company’s video platform:

1. Your laptop connects to the company network through a VPN with split tunneling: traffic to internal company servers goes through the encrypted tunnel, while the video meeting goes straight to the internet.
2. Your laptop looks up the video service’s domain. The DNS answer comes from your resolver’s cache, because its DNS TTL hasn’t expired yet.
3. The meeting’s web app and its images load quickly from a nearby CDN edge server.
4. Your home router’s QoS gives the call’s audio and video priority over a large download running on another computer.
5. Every packet carries an IP TTL, so if a misconfigured router anywhere on the path sent them in a loop, they’d be discarded instead of circling forever.

Quick Summary

What’s Next in This Series

These four concepts show how networks are tuned for speed, security, and reliability. Upcoming posts in the Computer Networking for Beginners series will continue to build on these foundations, with topics like IP addressing and subnetting, DNS in more depth, and setting up and securing your own network. Until then, try the commands from this post: check the TTL in your own ping results, watch a DNS TTL count down with dig, and look for a QoS setting on your home router.

Conclusion

CDNs bring content closer to users by caching it on edge servers around the world. VPNs carry private traffic safely across the public internet through encrypted tunnels, whether for one remote worker or an entire branch office. QoS makes sure real-time traffic like voice and video gets through first when bandwidth runs short. And TTL keeps things from lasting forever: in IP, it limits how many hops a packet can take, preventing routing loops; in DNS, it limits how many seconds an answer can be cached.

Each of these concepts solves a real problem — distance, privacy, congestion, and stale or runaway data — and together they’re a big part of why the internet feels fast and reliable most of the time.

Next in the Computer Networking for Beginners series: Cloud Networking Explained: VPCs, Gateways, Virtualization, and Security, how everything in this series works when the network is virtual.

Computer Networking for Beginners series: Part 1: A Complete Guide to How Networks Work · Part 2: What Is the OSI Model? · Part 3: Networking Devices Explained · Part 4: CDNs, VPNs, QoS, and TTL · Part 5: Cloud Networking Explained · Part 6: Internet Protocol Explained · Part 7: Well-Known Port Numbers · Part 8: Protocols for Troubleshooting, Tunneling, and Security