Click any topic to jump directly to it
Understanding what data actually is before it travels anywhere.
Data is simply information — any information. Your name is data. A photo is data. A song is data. The temperature outside is data. The price of a stock is data.
Humans represent information in many ways — words, drawings, numbers, sounds. But computers can't understand any of those directly. Computers are electronic machines. They only understand one thing: is there an electrical signal or not?
That's it. That's the entire foundation of computing and networking. Everything — every photo, video, email, webpage — is ultimately stored and transmitted as a long sequence of 1s and 0s.
This system of representing everything as 1s and 0s is called binary.
Humans use the decimal system — 10 digits (0–9). We chose 10 probably because we have 10 fingers. Computers use binary — 2 digits (0 and 1) — because transistors (the tiny switches inside every chip) have exactly two states: on or off.
A single 0 or 1 is called a bit — short for binary digit. It is the absolute smallest possible unit of data. One bit alone can only represent two things: yes/no, on/off, true/false.
8 bits grouped together = 1 Byte. With 8 bits you get 2⁸ = 256 possible combinations — enough to represent every letter (upper and lowercase), every digit, and common symbols.
This mapping of characters to binary numbers is called ASCII (American Standard Code for Information Interchange):
So the word "Hi" stored in a computer is: 01001000 01101001 — two bytes, sixteen 1s and 0s.
| Unit | Size | Real-world example |
|---|---|---|
1 bit | Single 0 or 1 | One switch position |
1 Byte | 8 bits | One character of text |
1 KB | 1,024 bytes | A short text email |
1 MB | 1,024 KB | A photo from your phone |
1 GB | 1,024 MB | A HD movie |
1 TB | 1,024 GB | A large hard drive |
1 PB | 1,024 TB | What large companies store |
1 EB | 1,024 PB | What the entire internet generates per day |
When data travels across a network it's still 1s and 0s — just represented differently depending on the physical medium:
| Medium | How 1 is sent | How 0 is sent | Used for |
|---|---|---|---|
| Copper cable (Ethernet) | High voltage pulse | Low voltage | Local networks, short distances |
| Fiber optic | Light pulse | No light | Long distances, submarine cables |
| WiFi | Radio wave pattern A | Radio wave pattern B | Wireless local networks |
The data itself doesn't change — only the physical representation does. At the receiving end it's always converted back to 1s and 0s.
Imagine a wall of 8 light switches in a row. Each switch can be independently UP (on = 1) or DOWN (off = 0). The pattern of ups and downs represents one byte — one character of data.
A modern CPU has billions of these switches (transistors), flipping billions of times per second. That is all computing is — incredibly fast switch flipping.
Networking regularly uses three number systems. You don't need to be a mathematician — you need to understand what each is, why it exists, and how to read it. Converting between them is a bonus, not a core skill.
| System | Base | Digits Used | Used For |
|---|---|---|---|
| Decimal | 10 | 0–9 | Human everyday use |
| Binary | 2 | 0, 1 | How computers work internally |
| Hexadecimal | 16 | 0–9, A–F | MAC addresses, IPv6, memory addresses |
Decimal is base 10. Uses 10 digits: 0–9. When you run out of single digits, you add another column to the left. Each column represents a power of 10:
This is so natural we don't even think about it. But this exact same logic applies to every other number system — only the base changes.
Binary is base 2. Only two digits: 0 and 1. Each column is a power of 2 instead of a power of 10:
Imagine a car odometer where each wheel only has 0 and 1 instead of 0–9. It counts the same way as a normal odometer — it just runs out of digits much faster and needs more columns to represent the same numbers. That's all binary is.
Hexadecimal (hex) is base 16. It uses 16 digits: 0–9 and then A–F for values 10–15. Letters were chosen simply because we ran out of single-digit numbers after 9.
The key insight: one hex digit = exactly 4 binary bits. This makes hex a compact shorthand for binary — much easier to read and write without losing any information.
| Decimal | Binary | Hex | Note |
|---|---|---|---|
| 0 | 00000000 | 00 | Minimum value of one byte |
| 10 | 00001010 | 0A | A is 10 in hex |
| 15 | 00001111 | 0F | F is 15 in hex |
| 16 | 00010000 | 10 | Hex "carries over" at 16 |
| 65 | 01000001 | 41 | Letter "A" in ASCII |
| 255 | 11111111 | FF | Maximum value of one byte |
00:1A:2B:3C:4D:5E2606:4700::0x41 written in technical docs. The 0x prefix simply means "this number is in hex."FF in hex = 255 in decimal = 11111111 in binary — the maximum value of one byte. This is exactly why IPv4 address octets max out at 255. Each octet is one byte, and one byte can't go higher than 255.
A computer processes data — but processing takes time. Data needs somewhere to live while the computer works on it, and somewhere to persist when the power goes off. These are two very different requirements solved by two very different types of storage.
RAM is your computer's working space. Everything actively being used right now lives in RAM — your open browser, your document, the video you're watching. The CPU needs to access data billions of times per second, and RAM delivers it in nanoseconds.
RAM requires constant power to hold its charge. Cut the power → all data instantly gone. This is why unsaved work disappears in a crash, and why restarting fixes many software problems — RAM is wiped completely clean.
HDDs are permanent storage. A completely mechanical device with actual moving physical parts — spinning magnetic platters and a read/write head that physically moves across them.
To read data the head must physically seek to the right track, then wait for the platter to spin the right sector underneath — this mechanical movement takes milliseconds, making HDDs vastly slower than RAM.
SSDs also provide permanent storage but with no moving parts at all. They use flash memory — transistors that trap electrical charges permanently, even without power.
| Property | HDD | SSD |
|---|---|---|
| Technology | Magnetic spinning platters | Flash memory chips |
| Moving parts | Yes (motor, platters, arm) | None |
| Access speed | 5–10 ms | 0.05–0.1 ms |
| Capacity | Up to 20TB | Up to 8TB (typical) |
| Price per GB | ~$0.02/GB (very cheap) | ~$0.08/GB |
| Durability | Fragile — drops damage it | Drop-resistant |
| Noise | Audible spinning | Silent |
| Non-volatile? | ✅ Yes | ✅ Yes |
| Best for | Bulk cold storage | OS, apps, active files |
Storage isn't just RAM vs disk. There is a full hierarchy from fastest and smallest to slowest and largest — each level a tradeoff between speed and cost.
This is why apps take a moment to open — that's the time copying from storage into RAM. Once loaded, everything runs fast because the CPU is reading from RAM, not the disk.
A smart chef keeps active ingredients on the counter (RAM). They'd never walk to the warehouse for every single pinch of salt — just as a CPU never reads every byte directly from a hard drive.
CPU stands for Central Processing Unit. It is the component that actually executes instructions — it does all the thinking. Everything else — RAM, storage, keyboard, screen — exists either to feed data to the CPU or receive results from it.
This is the fundamental loop every CPU runs, billions of times per second. Everything a computer does — from loading a webpage to running a video game — is just this cycle repeating at incredible speed.
A core is one complete fetch-decode-execute unit. One core = one thing at a time. Multiple cores = multiple things simultaneously.
| Device | Typical Cores | Used For |
|---|---|---|
| Budget laptop | 4 cores | Everyday tasks |
| High-end laptop | 8–12 cores | Development, video editing |
| Desktop workstation | 16–32 cores | Heavy computation |
| Server | 32–128 cores | Running many applications simultaneously |
The CPU has an internal clock — a crystal that oscillates at a fixed frequency, setting the rhythm for every operation. Every tick of the clock = one cycle. Operations complete in one or more cycles.
Higher clock speed = each core does things faster. More cores = more things done simultaneously. A 4-core 3GHz CPU is often better than a 2-core 5GHz CPU for server workloads — because servers run many tasks at once, not one task very fast.
We learned about the memory hierarchy in Topic 1.3. The CPU has its own tiny, ultra-fast memory built directly onto the chip called cache. It stores copies of data the CPU uses most frequently so it doesn't have to go all the way to RAM every time.
Everything on the internet is built on one simple relationship — one device asks for something, another device provides it. The one that asks is the client. The one that provides is the server.
A client is any device or application that initiates a request to get something — a webpage, a file, data, a video stream.
The word "client" doesn't refer to a type of hardware. It refers to a role. Your laptop is a client when you browse the web. Your phone is a client when you open Instagram. Even a server can act as a client when it requests data from another server.
A server is any device or application that listens for incoming requests and responds to them. The word comes from "to serve" — it serves data to whoever asks.
Again — "server" is a role, not a type of hardware. A server is usually a powerful computer in a data center running 24/7, but technically any computer can act as a server.
The most important distinction: clients always initiate, servers always wait.
A server never randomly reaches out to a client. It sits there listening until a client knocks. When a client sends a request, the server wakes up, processes it, responds, and goes back to waiting. This is called a request–response model.
Servers listen on specific port numbers — numbered doors on a machine. A web server listens on port 80 (HTTP) and port 443 (HTTPS). A mail server listens on port 25. When a client connects, it specifies both the IP address and the port. Think of the IP as the building address and the port as the specific door inside the building.
Client and server are roles, not fixed identities. A single machine can play both roles simultaneously:
This is how almost every web application works — your browser talks to an app server, which in turn talks to a database server. The app server is simultaneously a server (to you) and a client (to the database).
| Property | Client | Server |
|---|---|---|
| Role | Requests data or services | Provides data or services |
| Who initiates | Always starts the conversation | Never initiates — always waits |
| Fixed address needed? | No — IP can change | Yes — needs a known, stable IP or domain |
| Runs 24/7? | No — used as needed | Yes — must always be available |
| Serves many at once? | No — one user | Yes — thousands simultaneously |
| Hardware | Laptop, phone, tablet | Powerful computer in a data center |
| Examples | Chrome browser, mobile app | google.com host, API backend, DNS server |
When you visit google.com, millions of other people are doing the same thing at that exact moment. How does one server handle all of them?
The answer is that it's never really just "one server." Large-scale services use:
Think of a restaurant:
The kitchen never walks out to a random customer's house and starts cooking. It waits. Customers come to it. That's the client–server model.
When a user visits a Cloudflare-protected website, Cloudflare plays both roles simultaneously:
This pattern is called a reverse proxy — the foundation of every Cloudflare App/API Security product.
An Operating System (OS) is software that acts as the middleman between hardware and applications. Every computer — laptop, phone, server — needs an OS. Without it, hardware is just silicon and metal with no idea what to do.
Think of the OS as the manager of a building. The hardware is the building itself (floors, electricity, elevators). Applications are the tenants. The OS manages everything in between — allocating resources, handling requests, making sure tenants don't interfere with each other.
The OS has six core jobs it performs constantly behind the scenes:
Inside every OS is a component called the kernel — the innermost, most privileged piece of software. The kernel runs directly on the hardware and has total control.
Applications never talk directly to hardware. They make requests to the OS via an interface called system calls (syscalls). The OS then carries out the action on their behalf. This is a critical security boundary — it prevents badly written or malicious apps from corrupting the system.
In networking and Cloudflare conversations, you'll encounter three OS families constantly:
| OS Family | Examples | Where You'll See It |
|---|---|---|
| Linux | Ubuntu, Debian, CentOS, Amazon Linux | Almost every server on the internet. Cloudflare runs Linux. AWS, GCP, Azure run Linux. Your customers' servers run Linux. |
| Windows | Windows Server 2019/2022 | Enterprise environments — especially companies running Microsoft Active Directory, IIS web servers, .NET applications. |
| macOS | macOS Ventura, Sonoma | Developer laptops. Rarely on servers. |
Linux is free and open source — no licensing costs. It's extremely stable (servers run for years without rebooting). It's highly configurable and efficient. It runs on everything from a tiny Raspberry Pi to a 128-core server. Every major cloud provider, every CDN, every web host runs Linux. When you SSH into a customer's server or a Cloudflare system — it's Linux.
The OS plays a direct role in every network connection. When your browser wants to load a webpage, here's what actually happens at the OS level:
This is why networking concepts like ports, sockets, and IP addresses are OS-level concepts — not just application concepts. The OS manages all of this on behalf of every application running on the machine.
Tenants never wire their own electricity or dig network cables. They request it through the manager. Applications never talk to hardware directly — they request it through the OS.
When you run a program — a browser, a web server, a database — the OS doesn't just "run" it as a static thing. It creates a process — a live, running instance of that program, with its own slice of CPU time, its own chunk of RAM, and its own identity on the system.
The key distinction: a program is a file sitting on disk (like chrome.exe). A process is that program actively running in memory, doing work.
You can run the same program multiple times — each instance becomes a separate process. Open three browser windows? That might be three separate processes, each with its own memory.
Every process gets a unique number from the OS called a PID (Process ID). The OS uses this to track and manage processes — to kill one, prioritise one, or monitor its resource use.
On this server: the web server (nginx) has PID 891, the database (MySQL) has PID 1024. The OS tracks them separately, gives each their own RAM allocation, and can kill either independently.
A process can spawn multiple threads — lightweight sub-units of execution that share the same memory but can run concurrently on different CPU cores.
This is how a web server handles thousands of simultaneous visitors — one process, many threads, each handling one request at a time.
Now here's the bridge between processes and networking.
A server machine has one IP address. But it might be running dozens of processes simultaneously — a web server, a database, an SSH server, a mail server. When a network packet arrives at that IP address, how does the OS know which process it's meant for?
The answer is ports.
A port is a numbered endpoint — a logical channel — that a process listens on. When a packet arrives, the OS reads the port number and routes it to the correct process.
Ports range from 0 to 65,535. They're divided into three ranges:
| Range | Name | Description |
|---|---|---|
0 – 1023 | Well-Known Ports | Reserved for standard services. Assigned by IANA. Require root/admin to use. |
1024 – 49151 | Registered Ports | Used by applications. Less strict, registered with IANA by convention. |
49152 – 65535 | Ephemeral Ports | Temporary ports assigned by the OS to clients making outbound connections. |
| Port | Protocol | What it does |
|---|---|---|
20 / 21 | FTP | File Transfer Protocol — transferring files |
22 | SSH | Secure Shell — encrypted remote login to servers |
25 | SMTP | Simple Mail Transfer Protocol — sending email |
53 | DNS | Domain Name System — name to IP lookups |
80 | HTTP | HyperText Transfer Protocol — unencrypted web traffic |
443 | HTTPS | HTTP Secure — encrypted web traffic (TLS) |
3306 | MySQL | MySQL database connections |
5432 | PostgreSQL | PostgreSQL database connections |
6379 | Redis | Redis in-memory data store |
8080 | HTTP alt | Common alternative HTTP port for dev/testing |
A port alone doesn't identify a unique connection. What uniquely identifies a connection is the combination of IP address + port on both ends — called a socket.
The four values together — client IP, client port, server IP, server port — uniquely identify every network connection on the internet. The OS tracks millions of these simultaneously.
You know servers listen on well-known ports (80, 443, etc.). But what port does the client use?
When your browser opens a connection to a website, the OS automatically assigns a temporary random port (between 49152–65535) to that connection. This is an ephemeral port — it exists only for the duration of that connection and is released when it closes.
Think of an IP address as a building address and a port as a specific door in that building. Sending to 142.250.80.46:443 means: go to that building, use door 443 (HTTPS). Door 22 leads to SSH. Door 3306 leads to the database. Same building, completely different destinations.
When a server process wants to accept connections, it goes through these steps with the OS:
Process asks OS to create a socket — a communication endpoint.
Process tells OS: "I want to own port 443." OS registers this — no other process can use 443 while this one has it.
Process tells OS it's ready to accept connections. OS starts queuing incoming connection attempts.
For each incoming connection, OS hands it to the process. Process spins up a thread to handle it while continuing to listen for new ones.
Cloudflare only proxies traffic on specific ports. When a customer's domain is proxied (orange cloud), only these ports are accepted at Cloudflare's edge:
| HTTP ports | HTTPS ports |
|---|---|
80, 8080, 8880, 2052, 2082, 2086, 2095 | 443, 2053, 2083, 2087, 2096, 8443 |
Traffic on any other port is not proxied — it goes directly to the origin, bypassing Cloudflare entirely. This is a common gotcha when customers have services running on non-standard ports.
Everything in Module 1 is foundation. Before moving to Module 2 — Physical Networking — make sure these concepts are solid. You will see every single one of them again throughout this curriculum.
FF hex = 255 decimal = 11111111 binary = max value of one byte00:1A:2B:3C:4D:5E) and IPv6 addressesHow bits physically travel between devices — the cables, signals, and hardware that make all networking possible.
In Module 1 we learned that all data is ultimately 1s and 0s. But how do those 1s and 0s actually move from one device to another? They need a physical medium to travel through. The oldest and most common medium is copper wire — carrying bits as electrical signals.
Copper wire conducts electricity. By varying the voltage (the strength of the electrical signal) on a wire, we can encode binary data:
The sender raises voltage for a 1 and drops it for a 0, in rapid pulses. The receiver reads these voltage changes and reconstructs the binary data. This is the essence of electrical communication.
The most common copper networking cable is an Ethernet cable — the cable with the plastic clip you plug into a laptop or router. It looks simple from outside but has a precise internal structure:
Inside every Ethernet cable are 8 copper wires arranged in 4 twisted pairs. The twisting is not decorative — it serves a critical purpose.
When electrical current flows through a wire, it creates a small magnetic field around it. This magnetic field can interfere with neighbouring wires — causing errors in the signal. This interference is called crosstalk.
Twisting the two wires of each pair together causes their magnetic fields to cancel each other out. The interference from one wire is neutralised by its twisted partner. The result: a much cleaner signal with far fewer errors.
This is why you can't just use any wire as a network cable. The precise twist ratio per pair is engineered to specific electromagnetic tolerances. This is also why bending or crushing an Ethernet cable can degrade performance — it disrupts the twist geometry.
Electrical signals weaken as they travel along copper wire. This is called signal attenuation. The longer the cable, the weaker the signal arrives at the other end. Beyond a certain distance, the signal is too weak to reliably read — errors occur.
This is why Ethernet has a maximum distance of ~100 metres per cable segment. Beyond that, the signal needs to be regenerated by a switch or repeater. In large buildings, you'll find network closets every 100 metres or so for exactly this reason.
Not all Ethernet cables are equal. They come in categories (Cat) that define their maximum speed and bandwidth capacity:
| Category | Max Speed | Max Frequency | Common Use |
|---|---|---|---|
| Cat5e | 1 Gbps | 100 MHz | Older office networks — still common |
| Cat6 | 1 Gbps (10Gbps up to 55m) | 250 MHz | Modern office and home networks |
| Cat6a | 10 Gbps | 500 MHz | Data centers, high-performance networks |
| Cat7 | 10 Gbps | 600 MHz | Data centers, shielded environments |
| Cat8 | 25–40 Gbps | 2000 MHz | Data center server connections |
The higher the category, the tighter the twist, the better the shielding, and the higher the frequency the cable can handle — all translating to higher speeds.
The plastic clip at the end of every Ethernet cable is called an RJ45 connector. It has 8 pins — one for each of the 8 wires inside. When you plug it in, each pin makes contact with a corresponding port on the device, completing the electrical circuit.
The NIC (Network Interface Card) is the hardware component that does the conversion between binary data and electrical signals. We'll cover NICs in depth in Topic 2.4.
You open your laptop, plug in an Ethernet cable, and type cloudflare.com in your browser. Here's exactly what happens at the copper wire level:
Laptop 192.168.1.5 → Cloudflare Server 104.21.5.10 over a Cat6 Ethernet cable
Browser creates an HTTP request: GET / HTTP/1.1 Host: cloudflare.com
This text is converted to binary: 01000111 01000101 01010100 ...
OS wraps the data in TCP, IP, then Ethernet headers.
Final structure: [Ethernet header][IP header][TCP header][HTTP data]
Laptop's NIC takes the binary packet and converts each bit:
1 → high voltage pulse (~2.5V) | 0 → low voltage (~0V)
Firing at 1 billion pulses per second on a 1 Gbps link.
Voltage pulses travel through 4 twisted copper pairs at ~200,000 km/s — reaching the router 3 metres away in nanoseconds.
Router's NIC reads the voltage changes, converts them back to bits, and reconstructs the packet. Router reads the destination IP 104.21.5.10 and forwards it toward the internet.
Cable → NIC → router → cable → NIC → router ... all the way until the packet reaches Cloudflare's server.
The copper cable's job is tiny but critical — it faithfully carries voltage pulses from one NIC to the next. It has no idea what those pulses mean (HTTP request, video stream, email — all looks identical to the wire). The intelligence lives in the devices at each end, not the cable itself.
Think of Ethernet signalling like Morse code on a telegraph wire. Morse code uses short and long signals (dots and dashes) to represent letters. Ethernet uses high and low voltage to represent 1s and 0s. Same concept — different encoding. Both are just patterns on a wire that the receiver translates back into information.
Copper cable works well up to 100 metres. But what about connecting buildings across a city, countries across continents, or continents across oceans? Electrical signals can't travel thousands of kilometres — they degrade too quickly and can't practically cross oceans.
The solution: use light instead of electricity. Light travels at roughly 200,000 km/second through glass — fast enough to cross an ocean in under 100ms. This is fiber optic technology.
A fiber optic cable carries bits as pulses of light:
At the sending end, a laser or LED converts electrical signals from the NIC into pulses of light. At the receiving end, a photodetector converts those light pulses back into electrical signals. The glass strand in between just carries the light.
The most important concept in fiber optics is total internal reflection. Without it, light would just leak out the sides of the glass strand and disappear.
The fiber has two layers — a glass core where light travels, and a glass cladding surrounding it with a slightly lower refractive index. When light hits the boundary between core and cladding at a shallow enough angle, it reflects completely back into the core. It never escapes — it just keeps bouncing its way along the cable, even around gentle bends, until it reaches the other end.
There are two types of fiber, and they're used in different contexts:
| Property | Single-Mode (SMF) | Multi-Mode (MMF) |
|---|---|---|
| Core size | ~8–10 μm (tiny) | ~50–62 μm (larger) |
| Light source | Laser | LED |
| Distance | Up to 100+ km | Up to ~2 km |
| Speed | 100 Gbps+ | Up to 100 Gbps (short range) |
| Cost | More expensive | Cheaper |
| Used for | Long distance — submarine cables, ISP backbone, between cities | Short distance — inside data centers, between buildings |
The internet's backbone is built on submarine fiber optic cables laid on the ocean floor. This is not metaphor — these are real physical cables running under the Atlantic, Pacific, and Indian Oceans carrying the vast majority of international internet traffic.
Key things to note about submarine cables:
| Property | Copper (Ethernet) | Fiber Optic |
|---|---|---|
| Signal type | Electrical voltage | Light pulses |
| Max distance | ~100 metres | 100+ km (single-mode) |
| Speed | Up to 10 Gbps | 100 Gbps to Tbps |
| Interference | Affected by EMI, crosstalk | Immune to electromagnetic interference |
| Weight | Heavier | Much lighter |
| Cost | Cheap | More expensive |
| Typical use | Last metre — device to wall socket | Everything beyond — building to building, city to city, continent to continent |
Imagine a long tunnel lined entirely with mirrors. You shine a flashlight in one end. The light bounces off the mirrored walls thousands of times but keeps going until it reaches the other end — perfectly intact. That's exactly what total internal reflection does inside a fiber optic strand. The glass core walls act as perfect mirrors for the light.
Copper and fiber both require a physical cable between devices. WiFi eliminates the cable by transmitting bits through the air as radio waves — the same physical phenomenon used by FM radio, TV broadcasts, and mobile phones, just at different frequencies.
A radio wave is an electromagnetic wave that oscillates (vibrates) at a specific frequency. WiFi encodes 1s and 0s by varying properties of these waves — such as their amplitude, frequency, or phase. The receiving device's antenna picks up these variations and decodes them back into bits.
WiFi operates on specific radio frequency bands. Each has different characteristics — understanding these explains why WiFi behaves differently in different situations.
| Band | Frequency | Range | Speed | Wall penetration | Best for |
|---|---|---|---|---|---|
| 2.4 GHz | 2.4 GHz | ~45m indoors | Up to ~600 Mbps | ✅ Good — longer wavelength | Large areas, many walls, IoT devices |
| 5 GHz | 5 GHz | ~25m indoors | Up to ~3.5 Gbps | ⚠️ Moderate | Fast speeds, fewer walls, modern devices |
| 6 GHz | 6 GHz | ~15m indoors | Up to ~9.6 Gbps | ❌ Poor — shorter wavelength | High-density, short range, WiFi 6E |
Higher frequency waves carry more data (more oscillations per second = more bits encoded) but are absorbed more easily by walls, furniture, and even water molecules in the air. Lower frequency waves pass through obstacles more easily but carry less data. It's always a tradeoff — speed vs range vs penetration.
WiFi versions are defined by the IEEE 802.11 standard. Each new generation improves speed, capacity, and efficiency:
| Standard | Marketing Name | Year | Max Speed | Frequencies |
|---|---|---|---|---|
| 802.11n | WiFi 4 | 2009 | 600 Mbps | 2.4 + 5 GHz |
| 802.11ac | WiFi 5 | 2013 | 3.5 Gbps | 5 GHz |
| 802.11ax | WiFi 6 | 2019 | 9.6 Gbps | 2.4 + 5 GHz |
| 802.11ax | WiFi 6E | 2021 | 9.6 Gbps | 2.4 + 5 + 6 GHz |
| 802.11be | WiFi 7 | 2024 | 46 Gbps | 2.4 + 5 + 6 GHz |
WiFi works on exactly the same physical principle as FM radio. A radio station transmits audio by encoding it into radio waves at a specific frequency (e.g. 98.5 MHz). Your car radio's antenna picks up those waves and decodes the audio. WiFi does the same thing — just at higher frequencies (2.4–6 GHz), shorter range, and encoding binary data instead of audio. The physics is identical.
Once you have more than two devices that need to communicate, you need a central piece of hardware to connect them all together. Historically there were two options: a hub or a switch. Understanding the difference explains why switches completely replaced hubs — and why it matters for how networks work today.
A hub is the simplest possible network device. When a packet arrives on any port, the hub does one thing: copy it out to every single other port simultaneously. No intelligence, no selectivity — everyone gets everything.
This causes three serious problems:
A switch solves all three problems with one key capability: it learns which device is on which port and sends packets only to the correct destination port.
A switch doesn't come pre-programmed with device locations. It learns them dynamically by observing traffic:
Switch reads the source MAC address from the packet and records: "MAC AA:AA:AA:AA:AA:AA is on Port 1." This is added to the MAC address table.
If the destination MAC is already in the table, send only to that port. If not yet known — flood to all ports temporarily until it learns the location.
After a few seconds of normal traffic, the switch has learned where every device is. From then on, all traffic is perfectly directed — no more flooding.
| Property | Hub | Switch |
|---|---|---|
| Intelligence | None — dumb repeater | Smart — learns MAC addresses |
| Packet delivery | Broadcasts to all ports | Sends only to correct port |
| Privacy | ❌ None — all devices see all traffic | ✅ Traffic isolated per port |
| Collisions | ❌ Common — shared medium | ✅ None — each port is isolated |
| Bandwidth | Shared across all devices | Dedicated per port |
| Speed | Slow under load | Full speed per port |
| Still used? | ❌ Obsolete since ~2000 | ✅ Universal — in every network |
A hub is like someone using a megaphone in a room — everyone hears everything, whether it was meant for them or not. A switch is like giving everyone a dedicated walkie-talkie channel — you talk directly to one person and nobody else hears it.
In Topic 2.4 we covered what a switch does — directs traffic only to the correct port using a MAC address table. Now let's go deeper into exactly how that works, what happens in edge cases, and the concepts you'll encounter in real network conversations.
The MAC address table (also called the CAM table — Content Addressable Memory) is the switch's lookup database. Every entry has three pieces of information:
The Age column is important — entries don't stay forever. If a device stops sending traffic, its entry ages out and is removed. This prevents stale entries from clogging the table when devices disconnect or move to different ports.
Three scenarios cause a switch to flood — send a packet out every port except the one it arrived on:
FF:FF:FF:FF:FF:FF — the broadcast address. Switch always floods this to every port by design. Used by ARP and DHCP.A VLAN (Virtual Local Area Network) lets you logically divide one physical switch into multiple isolated networks. Devices on different VLANs cannot communicate directly — even if they're plugged into the same physical switch.
VLANs are widely used in enterprise networks to:
| Type | Configuration | VLANs | Used For |
|---|---|---|---|
| Unmanaged | None — plug and play | ❌ | Home networks, small offices |
| Managed | Web UI or CLI (Cisco IOS etc.) | ✅ | Enterprise networks, data centers |
Cloudflare's 330+ PoP data centers are full of managed switches connecting servers, routers, and network equipment. When you learn about Magic Transit or Cloudflare's network interconnects, the underlying infrastructure is switches and routers working exactly as described here. Also — when customers ask about on-premise network design to integrate with Cloudflare, VLANs and switch configuration often come up.
A switch connects devices within the same network using MAC addresses. A router connects different networks together using IP addresses. This is the most important distinction in networking.
A router receives a packet, reads the destination IP address, consults its routing table, and forwards the packet toward its destination — one hop at a time. The packet may pass through 15–20 routers before reaching its destination.
Every router has a routing table — a list of known network destinations and which direction (next hop) to send traffic for each. This is the router's decision-making engine.
| Destination Network | Subnet Mask | Next Hop | Interface |
|---|---|---|---|
192.168.1.0 |
255.255.255.0 |
Directly connected | eth0 (LAN) |
10.0.0.0 |
255.255.255.0 |
Directly connected | eth1 (WAN) |
172.16.5.0 |
255.255.255.0 |
10.0.0.5 |
eth1 |
0.0.0.0 |
0.0.0.0 |
10.0.0.1 |
eth1 ← default route |
When a packet arrives, the router compares the destination IP against every route in the table and picks the most specific match (longest prefix match). The last entry — 0.0.0.0/0 — is the default route: "if nothing else matches, send it here." This is typically the ISP gateway — the on-ramp to the internet.
| Type | How Routes are Added | Pros | Cons |
|---|---|---|---|
| Static | Manually configured by admin | Predictable, simple, secure | Doesn't adapt to failures, doesn't scale |
| Dynamic | Learned automatically via routing protocols (BGP, OSPF) | Adapts to failures, scales to millions of routes | More complex, slight overhead |
The internet runs on dynamic routing — specifically BGP (Border Gateway Protocol), which we'll cover in Module 4. Your home router uses a simple static default route pointing to your ISP.
Your home router does something critical beyond just routing: NAT (Network Address Translation). Your ISP gives you one public IP address. But you have many devices. NAT lets all of them share that one IP.
Every IP packet has a field called TTL (Time to Live) — a counter that starts at 64 or 128 and decrements by 1 at each router hop. When TTL reaches 0, the router discards the packet and sends an error back to the sender.
This prevents packets from looping forever if there's a routing mistake. It's also what makes traceroute work — it sends packets with TTL=1, then TTL=2, etc., and maps each hop by watching where the "TTL expired" errors come from.
A router is like a GPS system at every intersection on the internet. Your packet is a car. At each router (intersection), the GPS (routing table) says "turn left toward this next router" — moving the packet one hop closer to its destination. The packet doesn't know the full path upfront — it just follows instructions one hop at a time until it arrives.
Every network interface card (NIC) — whether in a laptop, phone, server, or router — is permanently assigned a unique identifier at the factory called a MAC address (Media Access Control address).
It looks like this: 00:1A:2B:3C:4D:5E
Six pairs of hexadecimal digits separated by colons. 48 bits total. Globally unique — no two network interfaces in the world share the same MAC address.
The first half (OUI — Organizationally Unique Identifier) identifies the manufacturer. The second half uniquely identifies the specific device. This is how 00:1A:2B always means Intel, F4:5C:89 always means Apple, etc.
| Property | MAC Address | IP Address |
|---|---|---|
| What it identifies | The physical hardware (NIC) | The device's location on a network |
| Assigned by | Manufacturer — burned in at factory | Network/ISP/DHCP — can change |
| Changes? | Permanent (can be spoofed in software) | Changes when you move networks |
| Scope | Local network only | Works across the internet |
| Used by | Switches (Layer 2) | Routers (Layer 3) |
| Format | 00:1A:2B:3C:4D:5E | 192.168.1.5 |
| Analogy | Your permanent national ID number | Your current home address |
MAC addresses are a Layer 2 concept — they only have meaning on a local network segment. When your packet leaves your local network through a router, the router strips the Ethernet frame (which contains the MAC address) and creates a new one for the next hop. The MAC address changes at every router hop — the IP address does not.
When your laptop sends a request to cloudflare.com:
192.168.1.5 → 104.21.5.10) never change throughout the entire journeyMAC addresses appear in security contexts you'll encounter as a Cloudflare SE:
We now know switches use MAC addresses and routers use IP addresses. But here's the gap: when your laptop wants to send a packet to your router at IP 192.168.1.1 — how does it know the router's MAC address to put in the Ethernet frame?
It doesn't — until it asks. That asking process is ARP.
Once your laptop learns a MAC address via ARP, it stores it locally in an ARP cache (ARP table) so it doesn't have to ask again for every packet:
Every time your laptop connects to a new network — at home, at a coffee shop, at a customer's office — the first thing it does before sending any real traffic is ARP for the default gateway (router) to learn its MAC address. This happens automatically and invisibly in milliseconds.
ARP has no authentication — any device can respond to an ARP request claiming to be any IP address. ARP spoofing (or ARP poisoning) is an attack where a malicious device responds to ARP requests with its own MAC, tricking devices into sending traffic to the attacker instead of the real destination. This is a man-in-the-middle attack at Layer 2 — one reason why Zero Trust (never trust the local network) matters.
ARP only works within a local network segment. You cannot ARP for a device on the other side of the internet — that's what DNS and routing are for. ARP is purely a Layer 2 / local network mechanism.
Module 2 covered how bits physically travel across networks. These concepts underpin every product conversation involving network architecture, traffic flow, and security.
FF:FF:FF:FF:FF:FF always floods — used by ARP and DHCP0.0.0.0/0 = "send everything else to the ISP" — the internet on-rampThe rules and addressing systems that govern how networks are organised, addressed, and managed.
Not all networks are the same size or scope. The type of network determines who owns it, how fast it is, what hardware it uses, and how it connects to other networks. In Module 2 we already used "LAN" and "internet" — now let's define all of them properly.
A network confined to a single physical location — a home, an office floor, a building. You own it and control it entirely.
A network spanning a city or campus — larger than a LAN but smaller than a WAN. Often owned by a city government, university, or ISP.
A network spanning multiple cities, countries, or continents. No single organization owns the whole thing — it's built by leasing infrastructure from ISPs and telecom providers.
Cloudflare operates a private WAN connecting 330+ PoPs across the globe. When traffic enters Cloudflare in Mumbai, it travels over Cloudflare's own WAN backbone to reach an origin server in London — bypassing the public internet entirely. This is faster and more reliable than the traffic taking a public internet path.
The internet is not one network — it's a network of networks. Millions of LANs, MANs, and WANs owned by different organizations, all interconnected using agreed-upon protocols (primarily TCP/IP and BGP).
No single entity owns the internet. Your ISP owns the last mile to your home. Backbone providers own transcontinental fiber. IXPs (covered in Module 4) are the physical meeting points where these networks exchange traffic.
| Type | Scale | Speed | Latency | Ownership | Hardware |
|---|---|---|---|---|---|
| LAN | Room / building | 1–100 Gbps | ~0.1ms | You own it all | Switches, WiFi APs |
| MAN | City / campus | 1–10 Gbps | ~1–5ms | Partially leased | Fiber, routers |
| WAN | Country / global | 100Mbps–10Gbps | 10–150ms | Leased from ISP/telco | Routers, BGP, MPLS |
| Internet | Global | Varies | Varies | Nobody — decentralised | All of the above |
An IP address is the logical address assigned to a device on a network. Unlike a MAC address (burned into hardware), an IP address is assigned by the network and can change. It tells routers where to deliver packets — globally.
An IPv4 address is a 32-bit number, written as four decimal numbers (called octets) separated by dots. Each octet is 8 bits, so ranges from 0 to 255.
Every IP address has two parts — the network part (which network is this?) and the host part (which device on that network?). A subnet mask tells you where the split is. We'll go deep on this in Topic 3.7.
Originally IPv4 addresses were divided into classes. You don't configure these today — modern networking uses CIDR — but you'll hear the terms, so know them:
| Class | Range | Default Network Bits | Hosts per Network | Designed For |
|---|---|---|---|---|
| A | 1.0.0.0 – 126.255.255.255 | 8 bits | 16.7 million | Huge organisations (governments, large ISPs) |
| B | 128.0.0.0 – 191.255.255.255 | 16 bits | 65,534 | Medium-large organisations |
| C | 192.0.0.0 – 223.255.255.255 | 24 bits | 254 | Small networks (offices, home) |
| D | 224.0.0.0 – 239.255.255.255 | — | — | Multicast (not assigned to hosts) |
| E | 240.0.0.0 – 255.255.255.255 | — | — | Reserved / experimental |
With only ~4.3 billion possible addresses and billions of devices, IPv4 addresses ran out. The last blocks were allocated around 2011. Solutions:
IPv4 gave us ~4.3 billion addresses. The internet has billions of devices — phones, laptops, servers, IoT sensors, smart TVs. We ran out. IPv6 was designed to solve this permanently.
An IPv6 address is 128 bits — written as 8 groups of 4 hexadecimal digits separated by colons:
Full IPv6 addresses are long. Two rules shorten them:
0042 → 420000 → 00000:0000:0000 → ::::. Only once per address.| Full Address | Shortened |
|---|---|
2606:4700:4700:0000:0000:0000:0000:1111 | 2606:4700:4700::1111 |
0000:0000:0000:0000:0000:0000:0000:0001 | ::1 (loopback) |
fe80:0000:0000:0000:0a00:27ff:fe4e:66a1 | fe80::a00:27ff:fe4e:66a1 |
| Property | IPv4 | IPv6 |
|---|---|---|
| Length | 32 bits | 128 bits |
| Format | Dotted decimal: 192.168.1.5 | Hex groups: 2606:4700::1 |
| Addresses | ~4.3 billion | 340 undecillion |
| NAT needed? | Yes — addresses are scarce | No — every device gets a real global IP |
| Header size | Variable (20–60 bytes) | Fixed (40 bytes) — faster routing |
| Security | Optional (IPSec) | Built-in IPSec support |
| Adoption today | Still dominant | ~40–50% of traffic (growing fast) |
Cloudflare fully supports IPv6 and actually provides free IPv6 connectivity to customers who only have IPv4 origins — called IPv6 compatibility mode. When a user visits a site over IPv6, Cloudflare translates it to IPv4 when talking to the origin. This is one example of Cloudflare operating at the network layer on behalf of customers.
A public IP is globally unique and routable on the internet. When your browser connects to 104.21.5.10 (Cloudflare), that's a public IP. Any device on the internet can theoretically reach it.
Public IPs are assigned and managed by IANA (Internet Assigned Numbers Authority) → regional registries (ARIN, RIPE, APNIC) → ISPs → you.
Private IPs are reserved ranges that are not routable on the internet. Routers on the public internet drop packets destined for private IPs. They are used only within local networks.
| Range | CIDR | Addresses Available | Typical Use |
|---|---|---|---|
10.0.0.0 – 10.255.255.255 | 10.0.0.0/8 | 16.7 million | Large enterprises, cloud VPCs |
172.16.0.0 – 172.31.255.255 | 172.16.0.0/12 | 1 million | Medium networks |
192.168.0.0 – 192.168.255.255 | 192.168.0.0/16 | 65,536 | Home and small office networks |
Your home router assigns private IPs from the 192.168.0.0/16 range because it's the smallest private block — just right for home networks. The router's LAN interface gets 192.168.1.1 (or similar), and your devices get 192.168.1.2 through 192.168.1.254 via DHCP.
| Address | Name | What it does |
|---|---|---|
127.0.0.1 | Loopback | "This device itself." Traffic sent here never leaves the machine. Used to test local services. ping 127.0.0.1 tests your own network stack. |
localhost | Loopback hostname | DNS name for 127.0.0.1. When developers run a web server locally and visit http://localhost:3000 — they're connecting to themselves. |
0.0.0.0 | Any / Unspecified | Means "all interfaces" when a server binds to it. In routing tables, means "default route" (anywhere). |
255.255.255.255 | Limited Broadcast | Send to every device on the local network. Used by DHCP — a device with no IP sends to this to find a DHCP server. |
169.254.0.0/16 | APIPA / Link-Local | Auto-assigned when DHCP fails. If you see a 169.254.x.x address on your machine — it couldn't reach a DHCP server. Usually means WiFi/network problem. |
224.0.0.0/4 | Multicast | Send to a group of devices simultaneously. Used by routing protocols and streaming. Not routed normally on internet. |
::1 | IPv6 Loopback | IPv6 equivalent of 127.0.0.1. |
If a customer says their server has address 169.254.x.x and can't reach the internet, you immediately know: their DHCP server is unreachable. The server self-assigned an APIPA address. Check DHCP server, network connectivity, and VLAN config. This is a common troubleshooting signal.
Imagine a company with 1,000 employees in 5 departments. If they put everyone on one flat network:
Subnetting solves this by dividing one large network into smaller sub-networks. Each department gets its own subnet — isolated, manageable, and secure.
A subnet mask is a 32-bit number that tells you which part of an IP address is the network and which part is the host. It always has a block of 1s followed by a block of 0s:
Wherever the mask has 255 (all 1s in binary) = network part. Wherever 0 (all 0s in binary) = host part. So 255.255.255.0 means: first 3 octets are network, last octet is host.
Writing out full subnet masks is verbose. CIDR (Classless Inter-Domain Routing) notation replaces them with a slash and a number — the number of 1-bits in the mask:
| Subnet Mask | CIDR | Network Bits | Host Bits | Usable Hosts |
|---|---|---|---|---|
255.0.0.0 | /8 | 8 | 24 | 16,777,214 |
255.255.0.0 | /16 | 16 | 16 | 65,534 |
255.255.255.0 | /24 | 24 | 8 | 254 |
255.255.255.128 | /25 | 25 | 7 | 126 |
255.255.255.252 | /30 | 30 | 2 | 2 |
255.255.255.255 | /32 | 32 | 0 | 1 (host route) |
With 8 host bits you get 2⁸ = 256 addresses. But two are reserved — the network address (all host bits = 0, e.g. 192.168.1.0) and the broadcast address (all host bits = 1, e.g. 192.168.1.255). So usable hosts = 256 - 2 = 254.
A company has the network 10.0.0.0/8 and wants to create separate subnets for 4 departments:
| Department | Subnet | Range | Max Hosts |
|---|---|---|---|
| Engineering | 10.1.0.0/24 | 10.1.0.1 – 10.1.0.254 | 254 |
| HR | 10.2.0.0/24 | 10.2.0.1 – 10.2.0.254 | 254 |
| Finance | 10.3.0.0/24 | 10.3.0.1 – 10.3.0.254 | 254 |
| Management | 10.4.0.0/24 | 10.4.0.1 – 10.4.0.254 | 254 |
Each department is now on its own subnet. Without VLANs and routing rules between them, they cannot directly communicate — exactly like the HR/Finance VLAN example from Module 2.
CIDR isn't just for internal networks — it's how IP blocks are allocated on the internet:
104.16.0.0/12 — a block of ~1 million IPs203.0.113.0/24 — 254 public IPs/32 is a single host route — used in BGP to advertise one specific IP/0 means "everything" — the default route (the entire internet)When you write a Cloudflare WAF rule to block a range of IPs — say block all traffic from 203.0.113.0/24 — you're using CIDR notation. Understanding this means you'll immediately know that rule blocks 254 specific IPs, not just one. This comes up constantly when building IP allowlists/blocklists in WAF, Magic Firewall, and Access policies.
Your ISP gives you one public IP address. But you have 10 devices at home — laptop, phone, tablet, smart TV, gaming console. All need internet access simultaneously. NAT makes this possible by letting all devices share that one public IP.
Packet: Source IP = 192.168.1.5, Source Port = 52341, Dest IP = 104.21.5.10, Dest Port = 443
Router rewrites: Source IP = 76.102.45.8 (your public IP), Source Port = 40001 (mapped port). Records this in its NAT table.
Response goes to 76.102.45.8:40001 — your public IP and the mapped port.
Router looks up port 40001 → maps back to 192.168.1.5:52341. Delivers to your laptop.
| Type | How it works | Used for |
|---|---|---|
| PAT / NAT Overload | Many private IPs → one public IP, differentiated by port. What your home router does. | Home networks, small offices |
| Static NAT | One private IP maps permanently to one public IP. 1:1 mapping. | Servers that need a fixed public IP |
| Dynamic NAT | Pool of public IPs shared across private IPs. No port translation. | Enterprises with multiple public IPs |
When Cloudflare sees traffic from a customer's website visitor, the source IP is the visitor's public IP after NAT — not their private home IP. This is what Cloudflare uses for:
This also means all devices behind a home NAT look like the same IP to Cloudflare — which is why rate limiting by IP can sometimes inadvertently affect multiple users sharing one public IP (e.g. a corporate office).
Every device on a network needs four pieces of configuration to communicate:
192.168.1.5255.255.255.0192.168.1.11.1.1.1Without DHCP, every device would need manual configuration. DHCP automates this entirely — you plug in a device and it gets all four automatically within seconds.
The acronym DORA: Discover → Offer → Request → Acknowledge. After ACK, the device is fully configured and can communicate on the network.
IPs assigned by DHCP are not permanent — they're leases with an expiry time (typically 24 hours for home networks, 8 hours for corporate). Before expiry, the device renews the lease. If not renewed (device left the network), the IP goes back into the pool and can be reassigned to another device.
| Concept | What it means |
|---|---|
| Lease time | How long the IP is valid. Short = faster IP recycling. Long = stable IPs but slower pool turnover. |
| IP pool | The range of IPs the DHCP server can assign. e.g. 192.168.1.100 – 192.168.1.200 |
| DHCP reservation | Assign a fixed IP to a specific MAC address. The device always gets the same IP — but still via DHCP, not manual config. |
| Rogue DHCP server | An unauthorised device responding to DHCP requests with bad config (wrong gateway → traffic goes to attacker). A real attack vector. |
At home: your WiFi router is the DHCP server. In enterprises: a dedicated Windows Server or Linux server runs DHCP. In cloud: AWS/GCP/Azure automatically assign private IPs to VMs via their own DHCP infrastructure. In Cloudflare's WARP/Zero Trust: Cloudflare's DHCP assigns IPs to connected devices in the virtual network.
When your laptop wants to send a packet somewhere, it first checks: is the destination on my local network or somewhere else?
192.168.1.x) → send directly, no router needed104.21.5.10) → send to the default gatewayThe default gateway is your router's LAN IP address — typically 192.168.1.1. It's the "exit door" off your local network. Every device gets it automatically via DHCP.
Your device applies the subnet mask to both its own IP and the destination IP. If the network parts match — same network, send directly. If not — different network, send to default gateway. Example: you're on 192.168.1.5/24. Destination 192.168.1.20: same network (192.168.1.x). Destination 104.21.5.10: different network → goes to gateway.
We touched on routing tables in Topic 2.6. Now let's go deeper. Every router — from your home router to a Cloudflare backbone router — makes every forwarding decision based on its routing table.
When multiple routes match a destination, the router picks the most specific one — the one with the most network bits (longest prefix):
| Property | Static Routing | Dynamic Routing (BGP/OSPF) |
|---|---|---|
| Setup | Admin manually adds each route | Routers learn routes automatically from neighbours |
| Adapts to failures? | No — if a link dies, traffic stops | Yes — reroutes automatically within seconds |
| Scale | Only works for small, simple networks | Powers the entire internet (BGP handles millions of routes) |
| Used by | Home routers, small office edge cases | ISPs, Cloudflare, enterprise networks, cloud providers |
As a Cloudflare SE, you'll regularly need to diagnose connectivity issues — is the problem at the DNS layer? Is it routing? Is it the origin server? Is it within Cloudflare? These three commands will be your first tools every time.
ping sends ICMP Echo Request packets to a destination and waits for a reply. It tests basic connectivity and measures round-trip latency.
| What to read | What it tells you |
|---|---|
time=12.4ms | Round-trip latency — how long packets take to reach and return |
ttl=55 | TTL remaining — started at 64 or 128, decremented per hop. 64-55=9 hops to reach destination |
0% packet loss | No packets dropped — path is clean |
| No reply / 100% loss | Host unreachable, firewall blocking ICMP, or host is down |
traceroute (Mac/Linux) or tracert (Windows) reveals every router hop between you and the destination. Invaluable for diagnosing where in the path things break.
When a hop shows high latency or * * *, that's where to investigate. If all hops before Cloudflare are fast but Cloudflare's hop is slow — the issue may be at Cloudflare's edge or the origin.
These tools query DNS servers directly. Essential for diagnosing whether a domain resolves correctly and which IP it resolves to.
| Command | Best for | Platform |
|---|---|---|
ping <IP or domain> | Basic connectivity test, latency check | All platforms |
traceroute / tracert | Path discovery, locating where failure occurs | Mac/Linux / Windows |
nslookup <domain> | Quick DNS lookup, available everywhere | All platforms |
dig <domain> | Detailed DNS output — preferred by engineers | Mac/Linux (install on Windows) |
curl -I <url> | Test HTTP response headers from command line | Mac/Linux |
When a customer says "my site isn't working," work from bottom to top of the stack:
Run nslookup domain.com — does it return an IP? Is it Cloudflare's IP or the origin directly?
Run ping <IP> — is the IP responding? Any packet loss?
Run traceroute <domain> — at which hop does it fail or go slow?
Run curl -I https://domain.com — what HTTP status code comes back? 200 = OK, 5xx = origin error, 4xx = client/Cloudflare issue.
As a Cloudflare SE, these are tools you'll use constantly when troubleshooting customer issues:
| Tool | What it does |
|---|---|
1.1.1.1/help | Tests if Cloudflare's DNS resolver is working from your location |
cloudflare.com/cdn-cgi/trace | Shows which Cloudflare PoP you're hitting, your IP, HTTP version |
dig @1.1.1.1 domain.com | DNS lookup via Cloudflare's resolver — tests if DNS resolves correctly |
curl -I https://domain.com | HTTP response headers — look for cf-ray to confirm CF is proxying |
speed.cloudflare.com | Measures latency and throughput to the nearest Cloudflare PoP |
The cf-ray header in any HTTP response uniquely identifies the request and PoP — e.g. cf-ray: 7a1b2c3d4e5f-DFW where DFW = Dallas Fort Worth. First thing to check when debugging a customer issue.
2606:4700:4700::1111:: replaces consecutive zero groups. ::1 = loopback (like 127.0.0.1)10.x.x.x, 172.16.x.x, 192.168.x.x — not routable on internet127.0.0.1 = loopback (yourself). localhost = same thing169.254.x.x = DHCP failed — device auto-assigned. Signal of a network problem255.255.255.255 = limited broadcast (entire local network)255.255.255.0 = first 3 octets are network/24 = 24 network bits = 255.255.255.0 = 254 usable hosts/32 = single host. /0 = default route (entire internet)203.0.113.0/24 = 254 IPs blocked169.254.x.x = DHCP failed, device self-assigned — indicates network problem0.0.0.0/0 = default route — "send everything else to the ISP"ping — basic reachability + latency testtraceroute / tracert — reveals every hop, locates where failures occurnslookup / dig — DNS resolution checkcurl -I — HTTP response code checkThe physical and logical infrastructure that connects the world — ISPs, submarine cables, data centers, BGP, Anycast, and CDNs.
An ISP (Internet Service Provider) is the company that gives you access to the internet — AT&T, Comcast, Verizon, BT, Jio. They own the physical infrastructure (cables, routers, data centers) that connects you to the global internet and charge you for access.
ISPs aren't all equal. They're organised in a hierarchy based on how they connect to the rest of the internet:
| Tier | Who they are | How they connect | Examples |
|---|---|---|---|
| Tier 1 | Own the global backbone — transcontinental fiber, submarine cables | Free peering with other Tier 1s (no money changes hands) | AT&T, NTT, Lumen, Telia, Cogent |
| Tier 2 | Regional/national networks | Peer for free where possible, pay Tier 1 for global reach | BT, Deutsche Telekom, Comcast backbone |
| Tier 3 | Local "last mile" providers | Pay Tier 2 for transit to the internet | Local cable companies, small ISPs |
The last mile is the final connection between your ISP's network and your home or office. It's called "last mile" because it's literally the last segment of delivery — often the most expensive and slowest part of the entire internet path.
| Technology | Medium | Speed | Latency | Common in |
|---|---|---|---|---|
| Fiber to the Home (FTTH) | Fiber optic all the way to premises | 1–10 Gbps | Very low (~1ms) | New deployments, urban areas |
| Cable (DOCSIS) | Coaxial cable | 100Mbps–1Gbps | ~5–15ms | US (Comcast/Xfinity) |
| DSL | Existing phone copper | 5–100Mbps | ~10–30ms | Older areas, rural |
| Fixed Wireless | Radio waves from tower | 10–300Mbps | ~5–20ms | Rural, 5G home internet |
| Satellite (Starlink) | LEO satellite signals | 50–200Mbps | ~20–40ms | Remote areas, maritime |
Cloudflare peers directly with Tier 1 and Tier 2 ISPs at 300+ IXPs globally. When a customer's user is on Comcast (Tier 3), their traffic reaches Comcast's backbone (Tier 2), which peers with Cloudflare at an IXP — often just one hop away. This is why Cloudflare can deliver content so fast — it's not travelling through multiple transit providers, it's going directly peer-to-peer.
The internet backbone is the collection of high-speed, high-capacity data routes that carry the majority of the internet's traffic across long distances — between cities, countries, and continents. It's owned by Tier 1 ISPs and large network operators.
The backbone consists of:
Most people imagine the internet as wireless. The reality: ~99% of international internet traffic travels through submarine cables. Satellites (even Starlink) handle only a tiny fraction of global internet traffic.
Historically: Tier 1 ISPs and telecom companies (AT&T, NTT, Orange). Today: tech giants are building their own:
The most common cause: ship anchors dragging across the ocean floor. It happens several times per year. The consequence depends on redundancy:
Cable repair ships are a real profession — specialist vessels with underwater robots that physically splice broken cables on the ocean floor.
An IXP (Internet Exchange Point) is a physical location — usually a data center — where multiple networks (ISPs, CDNs, cloud providers, content companies) connect directly to each other and exchange traffic.
Without IXPs, traffic between two ISPs would have to travel through a third-party transit provider (expensive, slower). At an IXP, they plug directly into the same switch and exchange traffic for free — or at much lower cost.
| IXP | Location | Participants | Peak Traffic |
|---|---|---|---|
| DE-CIX Frankfurt | Frankfurt, Germany | 1,000+ | ~15 Tbps |
| AMS-IX | Amsterdam, Netherlands | 900+ | ~10 Tbps |
| LINX | London, UK | 900+ | ~7 Tbps |
| Equinix IX | Global (50+ locations) | Thousands | Varies |
Cloudflare is present at 300+ IXPs globally — more than almost any other network. This is a key competitive advantage. When your ISP peers with Cloudflare at a local IXP, your traffic to any Cloudflare-protected site stays within that local exchange rather than traversing the global internet. Lower latency, higher reliability, lower cost.
A data center is a purpose-built facility housing computing infrastructure — servers, networking equipment, storage — operated 24/7. Every website, app, and cloud service runs out of a data center somewhere.
| Tier | Redundancy | Uptime | Downtime/year | Used for |
|---|---|---|---|---|
| Tier 1 | None — single path | 99.671% | ~28 hours | Small companies, dev environments |
| Tier 2 | Partial | 99.741% | ~22 hours | Mid-size businesses |
| Tier 3 | N+1 redundancy, concurrent maintenance | 99.982% | ~1.6 hours | Enterprise, most cloud providers |
| Tier 4 | Full fault-tolerant, 2N redundancy | 99.995% | ~26 minutes | Financial systems, critical infrastructure |
Cloudflare primarily uses colocation — they own their own servers but place them in third-party data centers globally. This lets them put hardware in 330+ cities without building their own buildings everywhere. Each Cloudflare PoP is a colo cage in an existing data center, connected directly to local ISPs and IXPs.
The internet is not one big network — it's tens of thousands of individual networks operated by different organisations. Each of these independently managed networks is called an Autonomous System (AS).
Every AS is assigned a unique ASN (Autonomous System Number) by IANA. Examples:
| Organisation | ASN |
|---|---|
| Cloudflare | AS13335 |
| AS15169 | |
| AT&T | AS7018 |
| Amazon (AWS) | AS16509 |
| Comcast | AS7922 |
An AS announces to the world: "I own these IP address ranges." For example, Cloudflare announces it owns 104.16.0.0/12. This is how the rest of the internet knows where to send traffic destined for Cloudflare IPs.
BGP (Border Gateway Protocol) is the routing protocol that connects all autonomous systems together. It is the protocol that makes the internet work as a cohesive whole. Without BGP, individual networks would have no way to know how to reach each other.
BGP's job: exchange routing information between ASes — "I know how to reach these networks, you should send traffic for them to me."
Two ASes establish a BGP session — a TCP connection between their border routers. They agree to share routing information with each other.
Each AS announces its own IP prefixes: "I own 104.16.0.0/12." It also re-announces routes it learned from others, building a path through the network.
When multiple paths exist to the same prefix, BGP selects the best one using a set of attributes (AS path length, local preference, etc.). Shortest AS path usually wins.
The selected routes propagate across the internet. Within minutes of a new network connecting via BGP, the entire internet knows how to reach it.
BGP has no built-in authentication — any AS can announce ownership of any IP prefix. BGP hijacking is when a malicious (or misconfigured) AS announces prefixes it doesn't own, redirecting traffic intended for another network.
Famous examples: in 2010, China Telecom briefly announced ~40,000 IP prefixes it didn't own — briefly rerouting 15% of global internet traffic through China. In 2019, a misconfigured ISP in Nigeria accidentally rerouted Google traffic through China Telecom.
Modern mitigation: RPKI (Resource Public Key Infrastructure) — cryptographically verifies that an AS is authorised to announce a given IP prefix. Cloudflare was one of the first to deploy RPKI broadly.
Cloudflare's Magic Transit product works by having customers advertise their IP ranges to Cloudflare via BGP. Cloudflare then announces these prefixes globally, attracting the customer's traffic through Cloudflare's network first (for DDoS scrubbing) before forwarding clean traffic to the customer's origin. The whole product depends on BGP.
You now know about routers, BGP, ISPs, and IXPs. Let's trace exactly what happens when you send a packet from your laptop in Texas to a Cloudflare server.
Packet leaves your laptop, reaches your home router (default gateway) via WiFi or Ethernet. Router checks its routing table — destination 104.21.5.10 is not local, so it sends to the ISP.
Packet travels over your last mile connection (cable/fiber) to your ISP's nearest POP. Your ISP's router checks its BGP routing table — Cloudflare's prefix 104.16.0.0/12 is via a peering session at a local IXP.
ISP forwards packet to the IXP switch. Cloudflare is also connected to that IXP. Packet crosses from ISP's AS to Cloudflare's AS (AS13335) — one physical hop inside the exchange.
Cloudflare's nearest PoP (Dallas, Texas in this case) receives the packet. WAF, DDoS protection, caching all run here. If the content is cached — response goes back immediately. If not — Cloudflare forwards to origin over its private backbone.
Each router hop decrements the TTL by 1. A packet from your laptop starts at TTL=64. After 5 hops through routers, TTL=59 when it reaches Cloudflare. Running traceroute cloudflare.com from Texas would show exactly these hops.
Every concept from Modules 2, 3, and 4 connects into this single picture:
Latency is the time it takes for a packet to travel from source to destination. Measured in milliseconds (ms). Also called round-trip time (RTT) when measuring the full there-and-back journey.
| Type | What it is | Example |
|---|---|---|
| Propagation delay | Time for signal to physically travel the distance. Physics — can't be beaten. | NY → London = ~70ms minimum (speed of light through fiber) |
| Processing delay | Time routers take to read headers and make forwarding decisions | ~microseconds per router hop |
| Queuing delay | Time packets spend waiting in a router's queue during congestion | Adds ms–100ms during network congestion |
| Transmission delay | Time to push all bits of a packet onto the wire | 1,500 byte packet on 1 Gbps link = 0.012ms |
| Route | Approximate Latency |
|---|---|
| Your laptop → home router | ~1ms |
| Your laptop → local Cloudflare PoP | ~5–15ms |
| New York → London | ~70ms |
| New York → Tokyo | ~150ms |
| London → Sydney | ~250ms |
| LEO satellite (Starlink) | ~20–40ms |
| Geostationary satellite (old) | ~600ms |
Bandwidth is the maximum capacity of a network link — how much data can flow through it simultaneously. Measured in bits per second (Mbps, Gbps, Tbps).
Think of data travelling like cars on a highway:
Throughput is the actual data transferred per second — always less than or equal to bandwidth. Bandwidth is the pipe size; throughput is what actually flows through it.
| Concept | What it means | Analogy |
|---|---|---|
| Bandwidth | Maximum capacity of the link | Highway with 10 lanes |
| Throughput | Actual data transferred (always ≤ bandwidth) | Actual cars on the highway right now |
| Latency | Time for one packet to travel | Speed each car travels |
Cloudflare's 330+ PoPs mean your traffic hits a Cloudflare server physically close to you — minimising propagation delay. Cloudflare also uses its own private backbone (not the public internet) to carry traffic between PoPs, avoiding congested public internet paths. The combination reduces latency for users compared to going directly to a distant origin server.
Anycast is a network addressing method where the same IP address is advertised from multiple locations simultaneously. When a packet is sent to an anycast IP, the internet's routing (BGP) automatically delivers it to the nearest location advertising that IP.
Compare the four addressing types:
| Type | How it works | Example |
|---|---|---|
| Unicast | One source, one destination — standard IP routing | Your laptop → one specific server |
| Broadcast | One source → all devices on local network | ARP request to 255.255.255.255 |
| Multicast | One source → a group of subscribed receivers | Video streaming to multiple subscribers |
| Anycast | One IP → many locations, traffic goes to nearest one | Cloudflare's 1.1.1.1 — hits nearest PoP |
Cloudflare runs servers in 330+ cities. All of them advertise the same IP prefix (e.g. 104.16.0.0/12) via BGP. When your packet is destined for 104.21.5.10:
Cloudflare's public DNS resolver 1.1.1.1 is anycast. That single IP is advertised from all 330+ Cloudflare PoPs simultaneously. When your laptop queries 1.1.1.1, BGP routes the packet to the nearest Cloudflare PoP — could be 5ms away. This is how it became the world's fastest DNS resolver.
Every Cloudflare product relies on Anycast. When a customer puts their domain on Cloudflare, all traffic to that domain is handled by Cloudflare IPs — which are Anycast. Users worldwide automatically hit their nearest PoP. This is the foundation of Cloudflare's performance and resilience story.
Imagine a company based in New York with a single origin server there. A user in Singapore visits their website:
Singapore user requests example.com/logo.png. Nearest Cloudflare PoP (Singapore) has no cached copy. It fetches from the New York origin (~250ms).
Cloudflare stores the logo in its Singapore PoP cache. Cache duration depends on Cache-Control headers from the origin (we'll cover this in Module 7).
Next Singapore user requesting the same logo gets it from the local cache in ~5ms. Origin server never involved. This is called a cache hit.
Cloud computing means accessing computing resources — servers, storage, databases, networking — on-demand over the internet rather than owning physical hardware. You pay for what you use, like a utility bill.
| Model | What you get | What you manage | Examples |
|---|---|---|---|
| IaaS Infrastructure as a Service | Raw VMs, storage, networking | OS, runtime, apps — everything above the virtualisation layer | AWS EC2, Azure VMs, Google Compute Engine |
| PaaS Platform as a Service | Managed platform to deploy code | Only your application code and data | Heroku, Google App Engine, Cloudflare Workers |
| SaaS Software as a Service | Ready-to-use software | Nothing — just configure and use | Gmail, Salesforce, Cloudflare Dashboard |
Cloudflare customers run workloads everywhere — AWS, Azure, GCP, on-premise, hybrid. Cloudflare sits in front of all of it. A customer might have their origin in AWS (public cloud) and their internal tools on-premise (private). Cloudflare protects both. Understanding these models helps you understand where the customer's origin server actually lives when designing a solution.
Before VPNs: a company with offices in New York and London needed a dedicated private leased line between them (MPLS or similar) — expensive, inflexible. Employees working from home couldn't access internal systems at all.
VPNs solved this by creating an encrypted tunnel over the public internet, making it behave like a private network — without the dedicated hardware.
Your laptop runs VPN software. It establishes an encrypted tunnel to a VPN server (usually at your company's HQ or a VPN provider's server).
Your device's traffic is wrapped (encapsulated) in an encrypted packet and sent through the tunnel. Your device acts as if it's physically on the corporate network.
The VPN server unwraps your packet, decrypts it, and sends it to the actual destination on your behalf. Replies come back the same way.
Traditional VPNs work but have serious problems at scale:
| Problem | What it means |
|---|---|
| Network-level access | Once connected, user is on the full internal network. Compromised VPN credentials = attacker has access to everything. |
| Hairpinning | All traffic routes through the VPN server — even traffic to the internet. Slows everything down and overloads HQ bandwidth. |
| Doesn't scale | VPN concentrators are hardware devices. Scaling for 10,000 remote workers is expensive and complex. |
| No per-app control | Traditional VPN grants access to the network, not specific applications. Can't say "this user can access the HR portal but not the finance system." |
Cloudflare Access (ZTNA) replaces the VPN model entirely. Instead of connecting users to a network, Access grants users access to specific applications based on identity. No VPN client, no network-level access, no hairpinning. This is the "VPN replacement" story you'll use in every Cloudflare One conversation — and it only makes sense if you understand what VPNs do and why they're painful.
The agreed-upon rules that govern all network communication — and the layered model that organises them.
A protocol is a set of agreed-upon rules that define how two devices communicate. Without protocols, every manufacturer would invent their own communication method and devices from different vendors would never be able to talk to each other.
Think of it like human language — English works because both speakers agree on the same grammar and vocabulary. Protocols are the "language" computers agree to use.
Protocols define:
Networking is complex. A single web request involves dozens of different technologies — WiFi, IP routing, TCP connections, TLS encryption, HTTP. Without a framework, it would be chaos.
The OSI Model (Open Systems Interconnection) was created by the ISO in 1984 as a conceptual framework that divides all networking functions into 7 distinct layers, each with a specific job. Each layer only talks to the layer directly above or below it.
The OSI model doesn't describe actual protocols in use — it's a reference model for understanding and categorising network behaviour. Its value: when something breaks, you can immediately narrow down which layer has the problem.
| Layer | Why it matters for Cloudflare |
|---|---|
| L7 — Application | WAF, Bot Management, Rate Limiting, CDN — all operate here. Inspect and act on HTTP requests. |
| L6 — Presentation | TLS termination — Cloudflare decrypts HTTPS at the edge here before inspecting the HTTP beneath it. |
| L4 — Transport | TCP/UDP — Cloudflare's Spectrum product proxies at L4. Magic Firewall filters here. |
| L3 — Network | Magic Transit operates at L3 — filters IP packets before they reach the application layer. |
When customers talk about DDoS, the layer matters enormously:
A "100 Gbps DDoS attack" is L3/L4. A "10 million requests per second HTTP flood" is L7. Completely different defence mechanisms.
The OSI model is a conceptual framework. The TCP/IP model is the practical one — it's what the internet actually runs on. It was developed by DARPA in the 1970s and has 4 layers instead of 7, collapsing some of the OSI layers that are rarely distinct in practice.
In the OSI model, Session (L5), Presentation (L6), and Application (L7) are theoretically separate. In practice, most protocols handle all three — HTTP handles session management and TLS handles presentation (encryption). So TCP/IP just calls it all "Application."
In Cloudflare conversations, people use both models interchangeably. The most common reference is OSI — specifically L3, L4, and L7. You'll rarely hear "L1" or "L6" in a product conversation.
| TCP/IP Layer | OSI Layers | Data unit name | What it contains |
|---|---|---|---|
| Application | L5/L6/L7 | Data / Message | HTTP request, DNS query, email — actual content |
| Transport | L4 | Segment (TCP) / Datagram (UDP) | Application data + TCP/UDP header (ports, sequence numbers) |
| Internet | L3 | Packet | Segment + IP header (source IP, destination IP, TTL) |
| Network Access | L1/L2 | Frame | Packet + Ethernet header (source MAC, destination MAC) |
As data moves from the Application layer down to the Physical layer, each layer wraps the data with its own header — adding addressing and control information needed at that layer. This process is called encapsulation. At the receiving end, each layer strips off its header — this is decapsulation.
Cloudflare sits in the path of every request and operates at multiple layers simultaneously:
This is why Cloudflare can inspect a WAF rule on User-Agent header (L7) while simultaneously enforcing an IP block (L3) and a rate limit by port (L4) — all on the same packet, in the same PoP, in microseconds.
TCP is the reliable delivery protocol at Layer 4. When your browser loads a webpage, it uses TCP to make sure every byte of the HTML, CSS, and images arrives correctly — in order, without gaps, without corruption.
TCP provides three guarantees: ordered delivery (packets arrive in sequence), reliable delivery (lost packets are retransmitted), and error checking (corrupted data is detected and discarded).
Before any data is exchanged, TCP establishes a connection with a 3-step process:
Only after the handshake completes does the browser send the HTTP request. This is why the first connection to a website takes slightly longer — the handshake adds one round-trip of latency before any data flows.
A SYN flood is a DDoS attack that exploits the TCP handshake. The attacker sends millions of SYN packets but never completes the handshake (never sends the final ACK). The server allocates memory for each half-open connection, waiting for the ACK that never comes — eventually exhausting resources and crashing. Cloudflare's L4 DDoS protection detects and drops SYN floods before they reach the origin.
| Concept | What it does |
|---|---|
| Sequence numbers | Each byte gets a sequence number so the receiver can reassemble packets in order even if they arrive out of sequence |
| Acknowledgements (ACK) | Receiver tells sender which bytes were received. If no ACK comes, sender retransmits. |
| Flow control | Receiver tells sender how much data it can handle at once (window size). Prevents overwhelming a slow receiver. |
| Congestion control | TCP slows down when it detects packet loss — a sign of network congestion. Gradually speeds up when the path is clear. |
| Connection teardown | FIN → ACK → FIN → ACK. 4 steps: client sends FIN, server ACKs, server sends FIN, client ACKs. Both sides confirm they are done sending before closing. |
Applications don't talk to TCP directly — they use the OS abstraction called a socket. A socket is the combination of an IP address and a port that uniquely identifies one end of a connection. A full TCP connection is identified by 4 values:
The OS tracks thousands of simultaneous socket connections — each identified by this unique 4-tuple. This is how your browser can have 10 tabs open to different sites while keeping all their data streams separate.
UDP is TCP's counterpart at Layer 4 — but with the opposite philosophy. Where TCP prioritises reliability, UDP prioritises speed. It sends packets and doesn't care if they arrive.
| Property | TCP | UDP |
|---|---|---|
| Reliability | ✅ Guaranteed delivery, retransmission | ❌ Fire and forget |
| Order | ✅ Always in sequence | ❌ May arrive out of order |
| Speed | Slower (overhead of acknowledgements) | Faster (no handshake, no ACKs) |
| Connection | Connection-oriented (3-way handshake) | Connectionless (just send) |
| Use cases | HTTP/HTTPS, email, file downloads, SSH | DNS, video streaming, VoIP, gaming, QUIC |
If you're watching a live video stream and a packet is lost — there's no point retransmitting it. By the time it arrives, that frame is already 500ms in the past. Better to just show a slightly glitchy frame and keep playing. TCP's retransmission would cause freezing. UDP's "accept the loss" approach is better for real-time media.
HTTP/3 (the latest version of HTTP) is built on QUIC — a protocol that runs over UDP instead of TCP. QUIC gets the reliability features of TCP (retransmission, ordering) but implements them at the application layer, avoiding TCP's head-of-line blocking problem. Cloudflare was one of the first CDNs to support HTTP/3 and QUIC globally. This comes up in Module 7 when we cover HTTP versions.
UDP has no handshake — so an attacker can send packets with a spoofed source IP (fake sender address). This enables amplification attacks:
Common amplification targets: DNS (up to 50x amplification), NTP (up to 556x), Memcached (up to 51,000x). Cloudflare blocks these at L3/L4 before they reach customers.
ICMP is not a data transfer protocol — it's a diagnostic and error-reporting protocol. It operates at Layer 3 alongside IP and is used by routers and hosts to communicate network conditions.
| ICMP Use | What it does | Tool that uses it |
|---|---|---|
| Echo Request/Reply | Test if a host is reachable and measure RTT | ping |
| TTL Exceeded | Router tells sender "TTL hit 0, packet discarded" | traceroute |
| Destination Unreachable | Router can't forward packet — no route to host, port closed | Appears as error messages |
| Redirect | Router tells sender to use a different gateway | Routing optimisation |
Many firewalls block ICMP — which is why you sometimes see * * * in traceroute output even when the path is working fine.
ping uses Echo Request/Reply. traceroute uses TTL Exceeded messages.* * * in traceroute = that router blocks ICMP, not necessarily that the path is brokenThe phonebook of the internet — how domain names get translated into IP addresses, and why it's the first thing that happens on every single web request.
Computers communicate using IP addresses — 104.21.5.10. Humans remember names — cloudflare.com. DNS is the system that bridges this gap: it translates human-readable domain names into machine-readable IP addresses.
Without DNS, you'd need to memorise IP addresses for every website you visit. With DNS, you type a name and the internet figures out the address for you — automatically, in milliseconds.
DNS is the very first step of every internet connection. Before your browser can connect to any website, it must resolve the domain name to an IP address. If DNS fails — nothing works. Not email, not websites, not apps. DNS is often described as the "phone directory of the internet" — without it, you know the name but can't find the number.
This is also why DNS is such a high-value attack target — taking down DNS takes down everything that depends on it.
Cloudflare has two distinct DNS products that often get confused:
These are different products solving different problems. A customer onboarding to Cloudflare uses Authoritative DNS. An employee using 1.1.1.1 on their laptop is using the resolver.
Domain names are read right to left — the most significant part is on the right. Each section separated by a dot is called a label.
A FQDN is the complete domain name including the root dot (which is normally invisible). For example: blog.cloudflare.com. — note the trailing dot. The root (.) is the very top of the DNS hierarchy.
| TLD Type | Examples | Managed by |
|---|---|---|
| Generic (gTLD) | .com .org .net .io .dev | ICANN-accredited registrars |
| Country (ccTLD) | .uk .de .in .jp .au | Country's designated authority |
| New gTLD | .cloud .app .security .bank | Various operators (ICANN-approved) |
| Infrastructure | .arpa | IANA — used for reverse DNS |
When a customer onboards to Cloudflare, they add a zone — typically their registered domain (e.g. example.com). Cloudflare then manages DNS records for that zone, including all subdomains. A customer can proxy www.example.com through Cloudflare (orange cloud) while leaving mail.example.com unproxied (grey cloud) — because email should not route through Cloudflare's HTTP proxy.
DNS is not a single server or database — it's a distributed, hierarchical system spread across thousands of servers globally. No single server knows everything. Instead, each level knows about the next level down.
| Server Type | What it knows | Who runs it |
|---|---|---|
| Root Nameservers | Where to find each TLD's nameserver. Nothing else. | 13 organisations (ICANN coordinates). Anycast — 1000+ physical servers globally. |
| TLD Nameservers | Which authoritative nameserver is responsible for each domain under that TLD. | Registry operators — Verisign (.com), PIR (.org), Nominet (.uk), etc. |
| Authoritative Nameservers | The actual DNS records for a specific domain — A, MX, CNAME, TXT, etc. | Domain owners — or their DNS provider (e.g. Cloudflare, Route53, GoDaddy) |
A recursive resolver (also called a recursive nameserver or DNS resolver) is the server your device talks to when it needs to resolve a domain. It does the legwork of querying the hierarchy on your behalf — asking root, then TLD, then authoritative — and returns the final answer to you.
DNS resolution is a multi-step process. Most of the time it's instant because of caching — but understanding the full uncached flow is essential.
The full recursive lookup above only happens when nothing is cached. In practice, most DNS queries are answered from cache at one of these levels:
Your browser caches DNS results. Chrome, Firefox, Safari all maintain their own DNS cache. Check with chrome://net-internals/#dns.
Your operating system maintains a DNS cache. On Mac: sudo dscacheutil -flushcache. On Windows: ipconfig /flushdns.
Your resolver (1.1.1.1) caches results and serves them to all users who query the same domain. A popular domain may never trigger a full recursive lookup at this stage.
Only happens if all caches are cold — root → TLD → authoritative. Even this takes only ~100ms globally.
TTL (Time to Live) is a value in seconds attached to every DNS record that tells resolvers how long they can cache the answer before they need to ask again. It's set by whoever manages the authoritative DNS for that domain.
| TTL Value | Pros | Cons | Use case |
|---|---|---|---|
| Short (60–300s) | Changes propagate quickly | More DNS queries, slightly higher latency | During migrations, incident response |
| Medium (300–3600s) | Good balance | Moderate propagation time | Most production sites |
| Long (86400s = 1 day) | Fewer queries, fast for users, lower load | Changes take a full day to propagate globally | Stable infrastructure that rarely changes |
When you change a DNS record, the old answer is still cached at resolvers around the world for up to the TTL duration. This is why "DNS propagation" takes time — each resolver must wait for its cached copy to expire before fetching the new answer. With a 24-hour TTL, some users might see the old IP for up to 24 hours after you make a change.
When onboarding a customer to Cloudflare, the standard advice is to lower TTL to 300 seconds (5 minutes) before changing nameservers. This ensures that if anything goes wrong, you can quickly roll back and the change will take effect within 5 minutes rather than waiting hours. After everything is stable, TTL can be raised back to normal. This is a real workflow you'll guide customers through.
| Record | Full Name | What it does | Example |
|---|---|---|---|
| A | Address | Maps domain → IPv4 address. Most common record. | cloudflare.com → 104.21.5.10 |
| AAAA | IPv6 Address | Maps domain → IPv6 address. | cloudflare.com → 2606:4700::1 |
| CNAME | Canonical Name | Maps domain → another domain name (alias). The resolver then resolves the target domain. | www.example.com → example.com |
| MX | Mail Exchange | Specifies which server handles email for the domain. Has a priority number — lower = higher priority. | example.com MX 10 mail.example.com |
| TXT | Text | Stores arbitrary text. Used for domain verification, SPF (email anti-spoofing), DMARC, DKIM. | v=spf1 include:cloudflare.com ~all |
| NS | Nameserver | Specifies which DNS servers are authoritative for the domain. Set when delegating to a DNS provider. | ns1.cloudflare.com, ns2.cloudflare.com |
| SOA | Start of Authority | Administrative info about the zone — which nameserver is primary, contact email, serial number. | Auto-generated, rarely set manually |
| PTR | Pointer | Reverse DNS — maps IP → domain name. Used by mail servers to verify sender identity. | 10.5.21.104.in-addr.arpa → cloudflare.com |
| SRV | Service | Specifies host and port for a service (VoIP, XMPP, etc.). | _sip._tcp.example.com SRV 10 60 5060 sip.example.com |
| CAA | Certification Authority Authorization | Specifies which CAs can issue SSL certs for the domain. Security control. | example.com CAA 0 issue "letsencrypt.org" |
example.com → 104.21.5.10example.com).
www.example.com → example.com → 104.21.5.10Standard DNS doesn't allow a CNAME on the root/apex domain (example.com) — only on subdomains. This is a problem for services like CDNs that require a CNAME. Cloudflare solves this with CNAME Flattening — internally resolving the CNAME chain and returning an A record at the root. This is unique to Cloudflare's DNS implementation and a real differentiator in customer conversations.
When a customer signs up for Cloudflare, the first thing they do is point their domain's NS records to Cloudflare. This transfers authoritative control of their DNS to Cloudflare.
Cloudflare scans existing DNS records and imports them automatically.
At GoDaddy/Namecheap/Route53, customer changes nameservers to ns1.cloudflare.com and ns2.cloudflare.com.
The world's resolvers gradually learn that Cloudflare is now authoritative. After TTL expiry on old NS records, all queries go to Cloudflare.
All A/CNAME records are now managed in Cloudflare dashboard. Customer can proxy records through Cloudflare or leave them direct.
In the Cloudflare dashboard, every DNS record has a cloud icon that controls whether traffic is proxied through Cloudflare or goes directly to the origin:
When a record is orange cloud (proxied), Cloudflare's authoritative DNS does not return the origin's real IP — it returns Cloudflare's Anycast IP instead. The origin IP is never exposed to the public internet. This is a key security benefit — attackers can't bypass Cloudflare by finding and directly hitting the origin IP.
One of the most frequent support issues: a customer proxies their root domain (example.com) through Cloudflare and their email breaks. The reason: email uses SMTP on port 25, which Cloudflare's proxy doesn't handle. MX records and email-related DNS records must always be grey cloud. This is a gotcha you'll encounter on almost every onboarding conversation.
Standard DNS has no authentication — a resolver has no way to verify that the answer it receives is genuine. An attacker who can intercept or tamper with DNS responses could redirect users to malicious servers — even though the domain name looks correct. This attack is called DNS spoofing or cache poisoning.
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. Resolvers can verify these signatures to confirm the answer came from the legitimate authoritative server and hasn't been tampered with.
The domain owner signs all DNS records with a private key. Each record gets an RRSIG (Resource Record Signature) attached.
The corresponding public key is published as a DNSKEY record in the zone. A hash of it (DS record) is published at the parent TLD — creating a chain of trust from root → TLD → authoritative.
A DNSSEC-validating resolver retrieves the record + RRSIG, fetches the DNSKEY, and cryptographically verifies the signature. If it doesn't match — the response is rejected as tampered.
DNSSEC proves that a DNS answer is authentic — but it does not:
Cloudflare supports DNSSEC for all authoritative DNS zones with one-click enablement in the dashboard. Cloudflare also validates DNSSEC on its 1.1.1.1 resolver — meaning queries resolved via 1.1.1.1 are protected against cache poisoning. About 30% of domains currently have DNSSEC enabled globally.
Standard DNS queries travel in plaintext over UDP port 53. This means:
DNSSEC (Topic 6.8) prevents tampering but doesn't hide the query. DoH and DoT solve the privacy problem by encrypting the DNS query itself.
DNS queries wrapped in a TLS connection on port 853. Encrypts queries but uses a dedicated port — ISPs and firewalls can easily detect and block port 853, making it easy to enforce their own DNS.
DNS queries sent as HTTPS requests over port 443 — the same port as all other HTTPS web traffic. Completely indistinguishable from regular browser traffic. Much harder to block without breaking the entire HTTPS web.
| Property | Standard DNS | DoT | DoH |
|---|---|---|---|
| Port | 53 (UDP) | 853 (TCP) | 443 (TCP) |
| Encrypted? | ❌ No | ✅ Yes (TLS) | ✅ Yes (HTTPS) |
| Privacy | ❌ ISP sees all queries | ✅ Encrypted | ✅ Encrypted + hidden in HTTPS |
| Blockable? | Easy — filter port 53 | Easy — filter port 853 | Very hard — would break all HTTPS |
| Supported by | Everything | Mobile OS, some browsers | Chrome, Firefox, Edge, iOS, Android |
Cloudflare's 1.1.1.1 resolver supports both DoT (1.1.1.1:853) and DoH (https://cloudflare-dns.com/dns-query). This is also relevant to Cloudflare Gateway (the SWG product in Cloudflare One) — it intercepts DNS at the OS or browser level to enforce filtering policies, and uses DoH/DoT to do so securely.
DNS is infrastructure — it underpins everything. Attacking DNS can redirect users, deny service, or intercept traffic at massive scale without ever touching the target's servers directly.
An attacker injects a false DNS record into a resolver's cache. Any user that resolver serves then gets the fake answer — redirecting them to a malicious server. Classic man-in-the-middle at the DNS layer.
Prevention: DNSSEC, randomised source ports and transaction IDs, filtering at the resolver level.
The most common UDP amplification attack. Attacker sends small DNS queries to open resolvers with the victim's IP spoofed as the source. Resolvers send large responses to the victim. Amplification factor up to 50x — a 1 Gbps attack becomes 50 Gbps.
Prevention: ISP-level BCP38 filtering (blocks spoofed source IPs), Cloudflare's network-level DDoS protection absorbs at the edge.
Attacker compromises either the registrar account (changing NS records), the authoritative nameserver, or the resolver — redirecting all DNS queries for a domain to attacker-controlled servers. More targeted than cache poisoning — affects the entire domain, not just cached entries.
Prevention: Registrar lock (prevents unauthorised NS changes), multi-factor auth on registrar accounts, DNSSEC.
Attacker encodes data inside DNS queries and responses to exfiltrate data or establish a covert command-and-control channel through firewalls that allow DNS traffic. DNS is often allowed through firewalls even when other protocols are blocked.
Prevention: Cloudflare Gateway inspects DNS query patterns and blocks anomalous tunneling behaviour.
Flood of DNS queries targeting an authoritative nameserver — overwhelming it so it can't respond to legitimate queries. Effectively takes the domain offline for everyone.
Prevention: Cloudflare's authoritative DNS is Anycast — attack traffic is distributed across 330+ PoPs globally. No single server receives the full volume.
| Attack | What it does | Cloudflare defence |
|---|---|---|
| Cache Poisoning | Injects false DNS records into resolver cache | DNSSEC validation on 1.1.1.1 |
| Amplification DDoS | Uses DNS to amplify traffic at victim | L3/L4 DDoS protection, BCP38 advocacy |
| DNS Hijacking | Redirects entire domain at registrar/NS level | DNSSEC, registrar lock, 2FA guidance |
| DNS Tunneling | Exfiltrates data via DNS queries | Gateway DNS filtering detects anomalous patterns |
| Auth NS DDoS | Overwhelms authoritative nameserver | Anycast distributes attack across all PoPs |
blog.cloudflare.com = subdomain.SLD.TLDThe language browsers and servers use to communicate — the foundation of every web application, API, and Cloudflare security product.
HTTP (HyperText Transfer Protocol) is the protocol that browsers and servers use to exchange web content. It defines how a client requests a resource and how a server responds. Every webpage, API call, and file download you've ever made on the web used HTTP.
HTTP sits at Layer 7 (Application) of the OSI model — the very top. It doesn't care about how packets are routed or whether TCP or UDP delivers them — it just defines the format of requests and responses.
One of the most important properties of HTTP: every request is independent. The server has no memory of previous requests from the same client. Each request must contain all the information the server needs to respond.
This means if you load a webpage that has 50 images — that's 51 separate HTTP requests (1 for the HTML + 50 for images). The server treats each one independently, with no knowledge of the others.
This simplicity is why HTTP scaled to power the entire internet — but it also creates challenges for things like login sessions (solved by cookies, covered in 7.7).
80443HTTPS is HTTP + TLS. The HTTP request/response format is identical — TLS just encrypts it in transit. We'll go deep on TLS in Module 8.
When a user visits an HTTPS site protected by Cloudflare, the TLS connection terminates at Cloudflare's PoP — not at the origin server. Cloudflare decrypts the request, inspects it (WAF, Bot Management, etc.), then re-encrypts it to forward to the origin. The user's browser shows a padlock, but the TLS certificate they see belongs to Cloudflare, not the origin. This is called TLS termination at the edge — and it's what enables every L7 security product.
Every web resource is identified by a URL (Uniform Resource Locator). URLs have a precise structure — each part serves a specific purpose:
| URL Part | Example | Purpose |
|---|---|---|
| Scheme | https:// | Which protocol to use |
| Subdomain | blog. | Optional prefix — specific section of the site |
| Domain | cloudflare.com | The registered domain — resolved via DNS |
| Port | :443 | Usually omitted — browser assumes 80 for HTTP, 443 for HTTPS |
| Path | /path/to/page | Which resource on the server to fetch |
| Query string | ?q=dns&page=2 | Additional parameters. Multiple pairs with & |
| Fragment | #section | Browser-side anchor. Never sent to the server. |
Cloudflare WAF rules can match on any part of a URL — path, query string, or even specific query parameters. For example: "block any request where the query string contains SELECT" (SQL injection detection). Understanding URL anatomy means you'll immediately understand what a WAF rule is targeting when you see it in the dashboard.
An HTTP method (also called an HTTP verb) tells the server what action to perform on the requested resource. When your browser loads a page, it sends a GET request. When you submit a form, it sends a POST. When an API updates an existing record, it uses PUT (full replace) or PATCH (partial update).
Methods are fundamental to how web applications work — and they're used extensively in WAF rules, API security, and rate limiting.
| Method | Action | Has Request Body? | Typical Use |
|---|---|---|---|
| GET | Retrieve a resource | No | Loading a webpage, fetching API data |
| POST | Submit data to create something | Yes | Submitting a form, creating a new record via API |
| PUT | Replace a resource entirely | Yes | Update a user profile — replaces all fields |
| PATCH | Partially update a resource | Yes | Update just one field (e.g. change email only) |
| DELETE | Delete a resource | Sometimes | Delete a record via API |
| HEAD | Same as GET but returns only headers | No | Check if a resource exists / get metadata without downloading body |
| OPTIONS | Ask server what methods are supported | No | CORS preflight checks (browser sends this before cross-origin requests) |
Methods have two important properties that affect how they're treated by caches, proxies, and security tools:
When you use a web app like a task manager:
Same URL, different methods = completely different operations
HTTP methods are a first-class field in Cloudflare WAF rules. Common use cases:
When your browser wants a resource, it sends an HTTP request. Every HTTP request has the same structure: a request line, headers, an empty line, and an optional body.
The first line of every request has three parts: Method + Path + HTTP Version
The server's reply follows the same structure: a status line, headers, and a body containing the actual content.
The first line of every response has: HTTP Version + Status Code + Reason Phrase
| Property | Request | Response |
|---|---|---|
| First line | Method + Path + Version | Version + Status Code + Reason |
| Sent by | Client (browser) | Server |
| Body | Optional (POST/PUT have bodies, GET does not) | Usually present (HTML, JSON, image, etc.) |
| Headers | Describe the request (what browser accepts, auth tokens, etc.) | Describe the response (content type, cache rules, CF metadata) |
Every HTTP response proxied through Cloudflare contains a cf-ray header — a unique identifier for that specific request. For example: cf-ray: 7a1b2c3d-DFW. The suffix (DFW) tells you which Cloudflare PoP handled the request (Dallas Fort Worth in this case). When a customer reports an issue, the first thing to ask for is the cf-ray value — Cloudflare support can use it to pull the exact logs for that request.
Every HTTP response includes a 3-digit status code that tells the client what happened with their request. Status codes are grouped into 5 classes based on the first digit:
| Code | Name | Meaning | Common cause |
|---|---|---|---|
| 200 | OK | Request succeeded. Response contains the requested content. | Normal successful response |
| 201 | Created | Resource successfully created. | Successful POST to an API |
| 204 | No Content | Success but no body to return. | Successful DELETE |
| 301 | Moved Permanently | Resource has permanently moved to a new URL. Browser should update bookmarks. | HTTP → HTTPS redirect, domain change |
| 302 | Found (Temporary Redirect) | Resource temporarily at a different URL. | Login redirects, A/B testing |
| 304 | Not Modified | Cached version is still fresh — use it. | Browser has cached content that hasn't changed |
| 400 | Bad Request | Server can't understand the request — malformed syntax. | Invalid JSON body, missing required field |
| 401 | Unauthorized | Authentication required. Not authenticated. | Missing or invalid token/session |
| 403 | Forbidden | Authenticated but not permitted to access this resource. | Cloudflare WAF block, IP block, Access denied |
| 404 | Not Found | Resource doesn't exist at this URL. | Wrong URL, deleted page |
| 429 | Too Many Requests | Rate limit exceeded. | Cloudflare Rate Limiting triggered |
| 500 | Internal Server Error | Generic server-side error. | Bug in application code, unhandled exception |
| 502 | Bad Gateway | Proxy received an invalid response from the upstream server. | Origin server crashed, returned garbage |
| 503 | Service Unavailable | Server temporarily unable to handle requests. | Origin overloaded, maintenance mode |
| 504 | Gateway Timeout | Proxy timed out waiting for upstream server. | Origin too slow to respond within timeout window |
| 520–527 | Cloudflare-specific errors | Cloudflare's own error codes for specific failure modes. | Origin unreachable, SSL mismatch, Cloudflare-side issues |
Cloudflare has its own set of error codes in the 5xx range that you'll encounter constantly in support conversations:
| Code | Meaning | Where the problem is |
|---|---|---|
| 520 | Unknown error from origin | Origin returned an unexpected response |
| 521 | Origin web server is down | Origin refused the connection |
| 522 | Connection timed out | Origin didn't respond within 15 seconds |
| 523 | Origin is unreachable | Cloudflare can't route to origin IP |
| 524 | A timeout occurred | Origin connected but didn't respond in time |
| 525 | SSL handshake failed | TLS negotiation failed between Cloudflare and origin |
| 526 | Invalid SSL certificate | Origin's certificate is invalid or self-signed without Cloudflare configured for it |
401 Unauthorized = "I don't know who you are — please log in." The word "unauthorized" is technically misleading — it really means unauthenticated.
403 Forbidden = "I know who you are, but you're not allowed here." This is what Cloudflare returns when a WAF rule blocks a request, when an IP is blocked, or when Cloudflare Access denies access. When a customer says "users are getting 403s," it almost always means something in Cloudflare is blocking them — not an origin issue.
When a customer reports 5xx errors, the first question is: is this Cloudflare or the origin?
cf-ray header to confirm Cloudflare is in the path. If there's no cf-ray, Cloudflare isn't involved.Headers are key-value metadata attached to every HTTP request and response. They tell the server and client important context about the communication — what format the content is in, how to cache it, who is making the request, what authentication is being used, and much more.
Headers are invisible to end users but are the primary thing Cloudflare's WAF, Bot Management, and other products inspect to make security decisions.
| Header | Example Value | What it tells the server |
|---|---|---|
| Host | cloudflare.com | Which domain is being requested (required in HTTP/1.1). Critical — allows one server to host multiple domains. |
| User-Agent | Mozilla/5.0 (Mac; Intel...) | What browser/app is making the request. Bots often have distinctive or fake User-Agent strings. |
| Accept | text/html, application/json | What content types the client can handle. |
| Accept-Encoding | gzip, deflate, br | What compression formats the client supports. Brotli (br) is the most efficient. |
| Authorization | Bearer eyJhbGciO... | Authentication credentials — API tokens, JWT tokens, Basic auth. |
| Cookie | session=abc123; theme=dark | Sends stored cookies back to the server. How sessions are maintained. |
| Referer | https://google.com/search?q=... | Which page the user came from. Used for analytics and hotlink protection. |
| X-Forwarded-For | 203.0.113.5, 10.0.0.1 | Original client IP when request passes through a proxy. Cloudflare adds this when forwarding to origin. |
| CF-Connecting-IP | 203.0.113.5 | Cloudflare-specific header — the real visitor IP. More reliable than X-Forwarded-For. |
| Content-Type | application/json | Format of the request body (for POST/PUT requests). |
| Header | Example Value | What it tells the client |
|---|---|---|
| Content-Type | text/html; charset=UTF-8 | Format of the response body — HTML, JSON, image, etc. |
| Content-Length | 24820 | Size of the response body in bytes. |
| Cache-Control | max-age=3600, public | How the response should be cached. Critical for CDN behaviour. Covered deeply in 7.9. |
| Set-Cookie | session=abc123; HttpOnly; Secure | Tells browser to store a cookie. HttpOnly = JS can't access it. Secure = HTTPS only. |
| Location | https://www.example.com/ | Where to redirect (used with 301/302 responses). |
| ETag | "abc123def456" | Unique identifier for this version of the resource. Used for cache validation. |
| Strict-Transport-Security | max-age=31536000 | HSTS — forces HTTPS for this domain for 1 year. Covered in 7.11. |
| cf-ray | 7a1b2c3d-DFW | Cloudflare request ID + PoP. First thing to check when debugging. |
| cf-cache-status | HIT / MISS / BYPASS | Whether Cloudflare served from cache or fetched from origin. |
| server | cloudflare | Identifies Cloudflare as the server. Origin server header is hidden from the public. |
Beyond standard headers, applications and platforms define their own. Convention: custom headers are prefixed with X- (though this is no longer required by spec):
| Custom Header | Example Value | Purpose |
|---|---|---|
X-Request-ID | 7a8b9c-abc123 | Unique ID for tracking this specific request through systems |
X-RateLimit-Remaining | 47 | How many requests the client has left in the current rate limit window |
X-Content-Type-Options | nosniff | Security header — prevents MIME-type sniffing by the browser |
CF-Connecting-IP | 203.0.113.5 | Cloudflare-added header — real visitor IP before NAT/proxy |
Cloudflare WAF rules can match on any header in a request. The most commonly used in rules:
HTTP was designed in 1991 for a simple web of text documents. Modern websites load 50–200 resources (HTML, CSS, JS, images, fonts, API calls). Each version of HTTP was created to solve the performance bottlenecks of the previous one.
HTTP/1.1 (1997) was a major improvement over HTTP/1.0 — it introduced persistent connections (keep the TCP connection open for multiple requests instead of reopening it every time). But it had one critical flaw:
Head-of-Line Blocking: Within a single connection, requests must complete in order. If request #1 is slow, requests #2, #3, #4 all wait — even if the server is ready to serve them. The solution was to open multiple TCP connections (browsers open 6 per domain), but this is wasteful and still limited.
HTTP/2 (2015) solved head-of-line blocking at the HTTP layer by introducing multiplexing — multiple requests and responses flow simultaneously over a single TCP connection as independent streams. No waiting in line.
HTTP/2 also introduced header compression (HPACK) — repeated headers (like User-Agent or Host) are sent once and referenced by index on subsequent requests, dramatically reducing overhead.
HTTP/2 multiplexed at the HTTP layer but still used TCP underneath. TCP itself has head-of-line blocking — if one TCP packet is lost, all streams wait for it to be retransmitted, even those that don't need that data.
QUIC is a new transport protocol built on UDP that reimplements TCP's reliability (retransmission, ordering) in userspace, with independent stream handling — a lost packet only blocks the stream it belongs to, not others. HTTP/3 runs on top of QUIC.
| Property | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport | TCP | TCP | QUIC (UDP) |
| Multiplexing | ❌ | ✅ | ✅ |
| Head-of-line blocking | HTTP + TCP | TCP only | ❌ None |
| TLS | Optional | Effectively required | Built-in (mandatory) |
| Header compression | ❌ | ✅ HPACK | ✅ QPACK |
| Connection setup | TCP 3-way + TLS | TCP 3-way + TLS | 1-RTT (or 0-RTT for returning) |
| Connection migration | ❌ | ❌ | ✅ (WiFi → 4G seamlessly) |
Cloudflare was one of the first CDNs to support HTTP/3 and QUIC — enabled by default for all proxied zones. The 0-RTT feature means returning visitors skip the handshake entirely, reducing connection overhead. Cloudflare also supported QUIC before it was an IETF standard, influencing the protocol's development. When you're selling Cloudflare performance, HTTP/3 support is a real differentiator vs. older CDNs or origin-only architectures.
HTTP is stateless — the server doesn't remember anything between requests. But real web applications need state: you log in once and stay logged in, your shopping cart persists across pages, your language preference is remembered.
Cookies are small pieces of data that a server asks the browser to store and send back with every subsequent request. They're how the web maintains state on top of a stateless protocol.
Server response includes: Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict
Browser saves the cookie locally, associated with the domain.
Every subsequent request to that domain includes: Cookie: session=abc123
Server reads the session ID, looks it up in its database, and knows who this user is.
| Attribute | What it does | Why it matters |
|---|---|---|
| HttpOnly | JavaScript cannot access this cookie | Prevents XSS attacks from stealing session cookies via document.cookie |
| Secure | Cookie only sent over HTTPS | Prevents session hijacking on HTTP connections |
| SameSite=Strict | Cookie only sent for same-site requests | Prevents CSRF attacks — cookie won't be sent if request originates from another site |
| SameSite=Lax | Sent for same-site + top-level navigation | Balances security and usability. Default in modern browsers. |
| SameSite=None | Sent for all requests including cross-site | Required for third-party cookies (tracking, embeds). Must also have Secure. |
| Expires / Max-Age | When the cookie expires | Session cookies (no expiry) = deleted when browser closes. Persistent = survives browser restart. |
| Domain | Which domains receive the cookie | e.g. Domain=.cloudflare.com — sent to all subdomains |
| Path | Which URL paths receive the cookie | e.g. Path=/api — only sent with /api requests |
Cookies are critical in Cloudflare for two reasons:
A session is the server's way of tracking a user across multiple HTTP requests. Since HTTP is stateless, the server needs a mechanism to say "this request belongs to the same user as the last one."
The classic approach: the server assigns a random session ID, stores it with the user's data, and sends it to the browser as a cookie. The browser sends it back with every request, and the server looks it up.
Modern APIs and Single Page Apps often use JWT (JSON Web Token) instead of session cookies. A JWT is a self-contained token that encodes the user's identity and claims — the server doesn't need to look it up in a database because the token itself contains the information, signed with a secret key.
JWT is sent in the Authorization header: Authorization: Bearer <token>. The server verifies the signature — if it checks out, the token is genuine.
| Property | Session Cookie | JWT |
|---|---|---|
| Where state lives | Server (session store/database) | Client (inside the token itself) |
| Server lookup needed? | Yes — look up session ID every request | No — verify signature, read payload directly |
| Revocation | Easy — delete session from server | Hard — can't invalidate a valid token before expiry |
| Scales well? | Harder (need shared session store) | Yes — any server can verify without DB lookup |
| Used for | Traditional web apps | APIs, microservices, SPAs |
Cloudflare Access (ZTNA product) issues a JWT to authenticated users. Every request to an Access-protected application carries this token. Cloudflare validates it at the edge — if the token is valid, the request is forwarded to the origin; if not, the user is redirected to authenticate. The origin doesn't need to implement its own authentication — Access handles it entirely. This JWT mechanism is a core part of the Zero Trust story.
Caching stores a copy of a response so it can be served again without going back to the origin. Every layer of the web can cache — the browser, a CDN, a reverse proxy. The goal: serve content faster with less load on the origin.
Caching is controlled by HTTP headers — specifically Cache-Control. Understanding these headers is fundamental to Cloudflare CDN configuration.
The server sets Cache-Control in the response to tell downstream caches (browsers, CDNs) what to do with the response.
| Directive | Example | Meaning |
|---|---|---|
| max-age | max-age=3600 | Cache for 3600 seconds (1 hour). Relative to time of response. |
| s-maxage | s-maxage=86400 | Cache for 86400 seconds — but only applies to shared caches (CDNs). Overrides max-age for CDNs. |
| public | Cache-Control: public | Any cache (browser, CDN) may store this. Safe for shared caching. |
| private | Cache-Control: private | Only the browser can cache. CDN must not store (personalised content). |
| no-store | Cache-Control: no-store | Never cache under any circumstances. For sensitive data. |
| no-cache | Cache-Control: no-cache | Misleading name — can cache, but must revalidate with origin before serving. Always ask if still fresh. |
| must-revalidate | Cache-Control: must-revalidate | Once stale, must check with origin — cannot serve stale content even if origin is unreachable. |
| stale-while-revalidate | stale-while-revalidate=60 | Serve stale for up to 60s while fetching fresh in background. Great for performance. |
When a cached response expires, the cache doesn't have to discard it immediately. It can revalidate — ask the origin "has this changed?" If not, the origin responds with 304 Not Modified (no body), saving bandwidth.
ETag: "abc123"If-None-Match: "abc123"304 Not Modified200 OK with new content
Last-Modified: Wed, 6 Aug 2026 10:00:00 GMTIf-Modified-Since: Wed, 6 Aug...304200 with new content
Every response from Cloudflare includes a cf-cache-status header telling you exactly what the cache did:
| Value | Meaning |
|---|---|
| HIT | Served from Cloudflare cache — origin not contacted |
| MISS | Not in cache — fetched from origin, now cached for future requests |
| EXPIRED | Was cached but TTL expired — fetched fresh from origin |
| BYPASS | Cache bypassed — usually because request had cookies or Cache-Control: no-store |
| DYNAMIC | Content is dynamic (e.g. API response) — Cloudflare determined it shouldn't be cached |
| REVALIDATED | Cache revalidated with origin — returned 304 Not Modified, served from cache |
Cloudflare caches based on file extension by default. Static assets are cached; dynamic content is not:
Cloudflare's default caching is conservative. Customers use Cache Rules (previously Page Rules) to override behaviour for specific paths:
/api/* endpoints that must always be freshThis is one of the most common configuration tasks you'll do with customers during onboarding.
Browsers enforce a security rule called the Same-Origin Policy: a webpage can only make requests to the same origin it was loaded from. An origin is defined as the combination of scheme + domain + port.
Modern web apps frequently need to call APIs on different origins — a frontend at app.example.com calling an API at api.example.com, or a single-page app calling a third-party payment API. The Same-Origin Policy would block all of these by default.
CORS is the mechanism that lets servers explicitly permit cross-origin requests. It's enforced by the browser — not the server.
For certain requests, the browser sends a preflight request first — an OPTIONS request asking "am I allowed to do this?" Preflight is triggered by:
PUT, DELETE, PATCHPOST with Content-Type: application/json (API calls) — but not regular form POST (application/x-www-form-urlencoded)AuthorizationSimple requests that do not trigger preflight: GET, HEAD, and form-based POST with standard content types.
| Header | Example | Meaning |
|---|---|---|
| Access-Control-Allow-Origin | https://app.example.com or * | Which origins are allowed. * = any origin (open API). Cannot be * if credentials are included. |
| Access-Control-Allow-Methods | GET, POST, PUT, DELETE | Which HTTP methods are permitted cross-origin. |
| Access-Control-Allow-Headers | Authorization, Content-Type | Which request headers are allowed in the actual request. |
| Access-Control-Max-Age | 86400 | How long the browser can cache this preflight response (seconds). Reduces preflight overhead. |
| Access-Control-Allow-Credentials | true | Whether cookies/auth headers can be sent cross-origin. Requires specific origin (not *). |
A common customer issue: Cloudflare WAF blocks the OPTIONS preflight request (e.g. a WAF rule matching on certain headers fires on preflight). The frontend then shows a CORS error — which looks like a browser/origin issue but is actually Cloudflare blocking the OPTIONS request. The fix: create a WAF rule to skip checks for OPTIONS requests from trusted origins, or use Cloudflare's Transform Rules to add CORS headers. This comes up frequently in API security conversations.
Security headers are HTTP response headers that instruct the browser to enforce specific security behaviours — restricting what content can load, preventing clickjacking, enforcing HTTPS, and more. They're a critical defence-in-depth layer for any web application.
Cloudflare can inject these automatically on behalf of customers without touching their origin — via Transform Rules and the Managed Headers feature.
| Header | Example Value | What it does |
|---|---|---|
| Strict-Transport-Security (HSTS) | max-age=31536000; includeSubDomains; preload | Forces HTTPS for this domain for the specified duration. Browser will refuse to connect over HTTP. Prevents protocol downgrade attacks. |
| Content-Security-Policy (CSP) | default-src 'self'; script-src 'self' cdn.example.com | Defines which sources are allowed for scripts, styles, images, etc. Prevents XSS by blocking inline scripts and untrusted sources. |
| X-Frame-Options | DENY or SAMEORIGIN | Prevents the page from being embedded in an iframe. Defends against clickjacking attacks where a malicious page overlays a transparent iframe. |
| X-Content-Type-Options | nosniff | Prevents the browser from MIME-sniffing (guessing content type). Forces browser to use declared Content-Type. Stops some XSS vectors. |
| Referrer-Policy | strict-origin-when-cross-origin | Controls how much Referer header information is sent with requests. Protects sensitive URL parameters from leaking to third parties. |
| Permissions-Policy | camera=(), microphone=(), geolocation=() | Controls which browser features the page can use (camera, mic, GPS). Limits attack surface if page is compromised. |
HSTS (HTTP Strict Transport Security) tells the browser: "For the next year, never connect to this domain over HTTP — always use HTTPS, even if the user types http://"
Cloudflare can inject security headers at the edge without the customer changing their origin code — using the Managed Headers feature in Transform Rules. Enables HSTS, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy with one click. This is a common onboarding win — customers get immediate security improvement with zero origin changes.
Standard HTTP is request-response: client asks, server answers, connection closes (or is reused for the next request). This doesn't work for real-time applications where the server needs to push data to the client at any time — live chat, trading dashboards, collaborative editing, gaming.
WebSockets solve this by upgrading an HTTP connection into a persistent, full-duplex channel where both sides can send messages at any time.
WebSocket doesn't have its own connection mechanism — it piggybacks on HTTP to start. The browser sends a normal HTTP request with an Upgrade: websocket header. The server responds with HTTP 101 Switching Protocols — meaning "Agreed. We're switching from HTTP to WebSocket now." After this, HTTP is done. The same TCP connection becomes a persistent WebSocket channel.
Think of it like two people mid-conversation agreeing to switch languages: "Let's speak French from now on" → "Agreed." — and from that point everything is in French. The 101 response is that agreement moment.
WebSocket starts as an HTTP request with an Upgrade header — asking the server to switch protocols:
Cloudflare proxies WebSocket connections transparently on orange-cloud domains. The upgrade handshake passes through Cloudflare's edge and the persistent connection is maintained. Cloudflare's Durable Objects (developer platform) are specifically designed for stateful WebSocket applications — e.g. real-time collaborative tools running at Cloudflare's edge.
An API (Application Programming Interface) is a defined way for two pieces of software to communicate with each other. It's a contract — one side says "here's what requests I accept and what I'll return", the other side follows that contract to get data or trigger actions.
Think of it like a restaurant menu. The menu defines what you can order (the API). You don't need to know how the kitchen works — you just place your order (make a request) and get your food (response). The kitchen and you never directly interact; the menu (API) is the interface between you.
REST (Representational State Transfer) is an architectural style for building APIs over HTTP. It's not a protocol — it's a set of conventions that makes APIs predictable and easy to use.
Instead of putting the action in the URL, you put the resource name. The HTTP method tells the server what to do with it.
| ❌ Non-REST (action in URL) | ✅ REST (resource in URL) |
|---|---|
/getUser?id=42 | GET /users/42 → readDELETE /users/42 → deletePATCH /users/42 → update |
/deleteUser?id=42 | |
/updateUserEmail?id=42 |
Same URL /users/42 — the HTTP method tells the server what to do with it. This makes APIs consistent and predictable.
CRUD = Create, Read, Update, Delete — the four basic operations on any data. REST maps these to HTTP methods:
| What you want to do | HTTP Method | Example |
|---|---|---|
| Create something new | POST | POST /users |
| Read / retrieve | GET | GET /users/42 |
| Update fully (replace all fields) | PUT | PUT /users/42 |
| Update partially (one field only) | PATCH | PATCH /users/42 |
| Delete | DELETE | DELETE /users/42 |
Every request must contain everything the server needs to process it. The server keeps no memory of previous requests. This means authentication is sent with every single request — typically as a token in the Authorization header:
| Method | Endpoint | Action |
|---|---|---|
GET | /users | List all users |
POST | /users | Create a new user |
GET | /users/42 | Get user with ID 42 |
PUT | /users/42 | Replace user 42 entirely |
PATCH | /users/42 | Update specific fields of user 42 |
DELETE | /users/42 | Delete user 42 |
| Nested Resources | ||
GET | /users/42/posts | List all posts by user 42 |
POST | /users/42/posts | Create a post for user 42 |
Cloudflare's API Shield product is designed specifically for REST APIs. It discovers all API endpoints automatically, lets you define OpenAPI schemas (what valid requests look like), and blocks malformed requests before they reach the origin. Rate limiting per endpoint, sequence abuse detection, and mTLS client certificates are all part of API Shield. Understanding REST is the foundation for understanding what API Shield is protecting.
A "website" is rarely just one server anymore. Modern web applications are made of multiple components — each with a specific job.
A reverse proxy sits in front of one or more servers and forwards client requests to them. Clients talk to the reverse proxy — they don't know (or need to know) about the backend servers.
| Property | Forward Proxy | Reverse Proxy |
|---|---|---|
| Serves | Clients — sits in front of users | Servers — sits in front of backend |
| Client knows about it? | Yes — explicitly configured | No — transparent to the client |
| Used for | Privacy, content filtering, corporate outbound proxy | Load balancing, SSL termination, caching, WAF |
| Example | Corporate proxy, VPN | Cloudflare, nginx, AWS ALB |
Cloudflare is a reverse proxy. When you orange-cloud a domain, Cloudflare sits transparently between users and your origin. Users connect to Cloudflare's IP. Cloudflare connects to your origin. Users never see the origin IP — they only see Cloudflare.
A load balancer distributes incoming requests across multiple backend servers to prevent any single server from being overwhelmed.
| Algorithm | How it works | Best for |
|---|---|---|
| Round Robin | Server 1, Server 2, Server 3, Server 1... in rotation | Identical servers, uniform requests |
| Least Connections | Send to server with fewest active connections | Long-lived connections (WebSockets) |
| IP Hash | Same client IP always goes to same server | Session stickiness without cookies |
| Geo-based | Route to nearest/best server for the user's location | Global deployments, latency optimisation |
| Health-check based | Only send to servers passing health checks | Automatic failover when a server goes down |
Cloudflare has its own Load Balancer product that operates at the DNS + HTTP level — distributing traffic across origins globally, with health checks, automatic failover, geo-steering, and session affinity. Unlike a traditional load balancer sitting in one data center, Cloudflare's operates across 330+ PoPs — routing users to the best origin from the nearest edge. This becomes a major product conversation in Phase 2.
cf-ray header = Cloudflare request ID + PoP. First thing to check when debugging any issue.cf-ray header in response = Cloudflare is NOT in the pathCF-Connecting-IP (not X-Forwarded-For) for the real visitor IP in WAF rulesAuthorization: Bearer <token>cf-cache-status: HIT = served from cache. MISS = fetched from origin. BYPASS = cache skipped.How data is kept private and authentic in transit — the cryptographic foundation behind every HTTPS connection and Cloudflare security product.
When you send data across the internet, it passes through dozens of routers, ISPs, and network devices — all of which can theoretically read the data. Without encryption, everything is sent as plaintext — readable by anyone who intercepts it.
Encryption solves three distinct security problems:
TLS (the protocol behind HTTPS) provides all three. Understanding each one matters — because when TLS is misconfigured, it might provide confidentiality but not authentication, or vice versa.
In symmetric encryption, the same key encrypts and decrypts the data. Both sender and receiver must have this key. Like a physical padlock where both parties have a copy of the key.
The key exchange problem: If you encrypt data with a key, how do you share that key with the other party? You can't send it unencrypted — it could be intercepted. You can't encrypt it either — that requires a key they already need. This is the fundamental problem asymmetric encryption solves.
Asymmetric encryption uses two mathematically linked keys: a public key (shared freely with everyone) and a private key (kept secret, never shared). What one key encrypts, only the other key can decrypt.
In practice, TLS uses both: asymmetric encryption to securely exchange a symmetric key, then symmetric encryption for all actual data. This gives you the security of asymmetric with the speed of symmetric.
A hash function takes any input and produces a fixed-size output called a hash (or digest). Three critical properties make it useful for security:
| Algorithm | Output Size | Status | Used for |
|---|---|---|---|
| MD5 | 128 bits | ⚠️ Broken — collisions found | File checksums only (not security) |
| SHA-1 | 160 bits | ⚠️ Deprecated — weaknesses found | Legacy systems (avoid) |
| SHA-256 | 256 bits | ✅ Secure | TLS certificates, password storage, HMAC |
| SHA-384 / SHA-512 | 384/512 bits | ✅ Secure | High-security applications |
| bcrypt / Argon2 | Varies | ✅ Secure | Password storage specifically — designed to be slow |
A digital signature combines hashing and asymmetric encryption to prove: (1) this message came from who it claims, and (2) it hasn't been tampered with.
A SHA-256 hash of the message is computed: hash("Hello") → 8f14e45f...
Only the sender has their private key — encrypting the hash proves it came from them. This encrypted hash is the digital signature.
Recipient decrypts the signature with the sender's public key to get the original hash. Then hashes the received message independently. If the two hashes match — message is authentic and unmodified.
Digital signatures are used everywhere in TLS — the certificate authority signs certificates with their private key. Your browser verifies the signature using the CA's public key (built into the browser). This is the foundation of trust on the web.
Asymmetric encryption requires a public key. But when your browser connects to cloudflare.com and receives a public key — how does it know that key genuinely belongs to Cloudflare, and isn't a public key from an attacker pretending to be Cloudflare?
This is the trust problem, and it's solved by a system of trusted third parties called Certificate Authorities (CAs).
A digital certificate is a document that binds a domain name to a public key — signed by a trusted third party (CA) to prove the binding is legitimate. Think of it as a digital passport issued by a trusted authority.
A Certificate Authority is an organisation trusted to verify domain ownership and issue certificates. Before issuing, the CA proves the applicant controls the domain (via DNS records, file upload, or email). The CA then signs the certificate with its private key.
Your browser and OS come pre-installed with a list of ~150 trusted root CAs (including DigiCert, Let's Encrypt, Comodo, GlobalSign). If a certificate is signed by any of them — it's trusted.
CAs don't sign site certificates directly with their root key (too risky — root key compromise = all trust destroyed). Instead they use a hierarchy:
PKI is the full system — the policies, procedures, hardware, software, and CAs — that manages digital certificates and public keys. TLS on the web is the largest PKI in existence.
| Component | What it does |
|---|---|
| Root CA | Ultimate trust anchor. Private key kept offline in a vault. Rarely used directly. |
| Intermediate CA | Issues end-entity certificates on behalf of root. If compromised, only intermediate is revoked — root stays safe. |
| Leaf/End-Entity Certificate | The actual cert for a domain. Has a validity period (usually 1 year or 90 days for Let's Encrypt). |
| CRL / OCSP | Certificate Revocation List / Online Certificate Status Protocol — checks if a cert has been revoked before expiry. |
When a domain is proxied through Cloudflare, Cloudflare automatically issues a TLS certificate for it — for free — via its own CA partnerships and Let's Encrypt. Users see a valid padlock. The certificate is managed entirely by Cloudflare — renewed automatically before expiry. This is called Universal SSL and it was a major moment for internet security when launched in 2014 — overnight, millions of sites got HTTPS for free.
TLS (Transport Layer Security) is the protocol that encrypts all data sent between a browser and a server. It's what turns HTTP into HTTPS. TLS operates at Layer 6 (Presentation) of the OSI model, sitting between TCP (Layer 4) and HTTP (Layer 7).
TLS provides all three security properties from Topic 8.1 simultaneously: confidentiality (encrypted data), integrity (HMAC detects tampering), and authentication (certificate proves server identity).
Before any encrypted data flows, the client and server must negotiate TLS. This negotiation is called the handshake. In TLS 1.2, it takes 2 round trips (2-RTT) before data can flow:
TLS 1.3 (2018) reduced the handshake to 1 round trip (1-RTT) — cutting connection setup time nearly in half. It also removed weak algorithms that had accumulated in TLS 1.2 over the years.
| Property | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake round trips | 2-RTT | 1-RTT (0-RTT for resumption) |
| Cipher suites | Many, including weak ones (RC4, 3DES) | 5 modern ciphers only (AES-GCM, ChaCha20) |
| Forward Secrecy | Optional | Mandatory — always |
| RSA key exchange | Supported | Removed — only ECDHE |
| 0-RTT resumption | No | Yes — returning clients skip handshake |
Forward Secrecy means that even if a server's private key is compromised in the future, past encrypted sessions cannot be decrypted. TLS 1.2 without forward secrecy: an attacker who records encrypted traffic today and later gets the private key can decrypt everything retroactively. TLS 1.3 always uses forward secrecy — past sessions are always safe.
HTTPS is simply HTTP running inside a TLS connection. The HTTP request and response are identical in format — TLS is a transparent layer that encrypts the entire conversation. The URL changes from http:// to https:// and the port changes from 80 to 443.
In the Cloudflare dashboard, customers can set the minimum TLS version their site accepts — typically TLS 1.2 minimum. Cloudflare recommends TLS 1.3 for all new deployments. Customers in regulated industries (finance, healthcare) often need to explicitly disable TLS 1.0 and 1.1 for compliance (PCI-DSS requires TLS 1.2+). This is a real configuration conversation during onboarding.
In standard TLS, only the server presents a certificate — the client verifies the server's identity. The server doesn't verify who the client is (anyone can connect).
mTLS (Mutual TLS) requires both sides to present certificates — the server verifies the client's identity too. This creates a two-way authentication: you know who you're talking to, and they know who you are.
| Use Case | Why mTLS |
|---|---|
| API security (B2B) | Only authorised partner services can call the API. No API key to steal — certificate is cryptographic. |
| Microservices | Service A can only talk to Service B if it has a valid certificate. Prevents lateral movement in a breach. |
| IoT devices | Each device has a unique certificate. Revoke one device without affecting others. |
| Zero Trust networks | Every device on the network proves its identity before accessing anything. |
Cloudflare's API Shield product supports mTLS client authentication. Customers upload their CA certificate to Cloudflare, then issue client certificates to each authorised API consumer. Cloudflare verifies the client cert at the edge — any request without a valid certificate is rejected with a 403 before reaching the origin. This is a zero-trust approach to API security that replaces weaker API key authentication.
TLS termination means decrypting an incoming TLS connection at a specific point in the network path. The device that "terminates" TLS decrypts the traffic, processes it as plaintext, then optionally re-encrypts it before forwarding it further.
Cloudflare offers Origin CA certificates — certificates issued by Cloudflare's own CA, trusted only between Cloudflare's edge and the customer's origin server (not trusted by browsers). This lets customers use Full (Strict) mode without buying a certificate from a public CA. Valid for up to 15 years. Free. This is the recommended setup for all Cloudflare customers — it ensures the CF-to-origin leg is always encrypted and validated, without certificate cost or renewal overhead.
Understanding the attacks that Cloudflare's products defend against — the threat landscape every SE needs to know.
A firewall is a security system that monitors and controls network traffic based on a set of rules. It sits between a trusted network (your internal systems) and an untrusted network (the internet), deciding what traffic to allow and what to block.
The name comes from the physical concept — a firewall in a building stops fire from spreading between sections. A network firewall stops malicious traffic from spreading into your systems.
| Property | Network Firewall | WAF (Web Application Firewall) |
|---|---|---|
| OSI Layer | L3/L4 | L7 |
| Inspects | IP addresses, ports, protocols | HTTP headers, URLs, request body, cookies |
| Blocks | Unauthorised connections, port scans | SQLi, XSS, CSRF, bots, DDoS at HTTP layer |
| Knows about HTTP? | No — sees only TCP packets | Yes — reads full HTTP requests and responses |
| Example | FortiGate, Cisco ASA, AWS Security Group | Cloudflare WAF, AWS WAF, Imperva |
Firewalls work through an ordered list of rules — called a ruleset or policy. Each packet is checked against rules from top to bottom. The first matching rule wins.
Cloudflare operates firewalls at multiple layers simultaneously on every request:
The key advantage: Cloudflare's firewall runs at the edge (330+ PoPs) — traffic is filtered before it ever reaches the customer's origin server.
A DDoS (Distributed Denial of Service) attack overwhelms a target with traffic until it can no longer respond to legitimate users. The "Distributed" part means the attack comes from thousands or millions of sources simultaneously — making it impossible to block a single IP.
The goal is not to steal data — it's to make the target unavailable. Every second of downtime costs money, reputation, and trust.
DDoS attacks are typically carried out by botnets — networks of thousands of compromised devices (computers, IoT cameras, routers, phones) infected with malware. The attacker commands the botnet remotely. The infected device owners have no idea they're participating.
DDoS attacks operate at different layers, requiring completely different defences. Getting this wrong in a customer conversation is a significant mistake.
| Property | L3/L4 DDoS (Volumetric) | L7 DDoS (Application) |
|---|---|---|
| Target | Network bandwidth or TCP stack | Web application logic |
| Measured in | Gbps or Tbps (packet volume) | Requests per second (rps) |
| Attack looks like | Massive flood of UDP/TCP/ICMP packets | Legitimate HTTP requests — harder to detect |
| Example attacks | UDP flood, SYN flood, ICMP flood, DNS amplification | HTTP flood, Slowloris, credential stuffing |
| Cloudflare defence | Magic Transit, network-level DDoS protection | WAF + HTTP DDoS managed ruleset |
| Scale examples | Largest ever: 5.6 Tbps (blocked by Cloudflare, 2024) | Largest ever: 71M rps (blocked by Cloudflare, 2023) |
Traditional DDoS mitigation uses scrubbing centres — when an attack is detected, traffic is rerouted to a centralised facility where it's cleaned, then sent onward. This adds latency and has limited capacity.
Cloudflare's approach: every PoP is a scrubbing centre. Because of Anycast, attack traffic is spread across all 330+ PoPs globally — no single location receives the full volume. A 5 Tbps attack gets distributed across hundreds of locations, each handling a fraction. Cloudflare's total network capacity is over 280 Tbps — more than enough to absorb even the largest recorded attacks.
Cloudflare offers unmetered DDoS protection — customers are never charged based on the volume of attack traffic. This is a significant differentiator vs. competitors who charge per Gbps of attack traffic absorbed. A customer under a 5 Tbps attack pays the same as a customer with no attacks. This is possible because Cloudflare's network capacity far exceeds any realistic attack volume.
The Open Worldwide Application Security Project (OWASP) is a non-profit foundation that publishes open standards and research on web application security. Their most widely referenced resource is the OWASP Top 10 — a list of the 10 most critical web application security risks, updated every few years based on real-world data from thousands of applications.
The entire WAF industry — including Cloudflare's WAF — is largely organised around defending against the OWASP Top 10. When you talk to security-conscious customers, they will reference OWASP directly.
| # | Risk | What it is | Cloudflare defence |
|---|---|---|---|
| A01 | Broken Access Control | Users accessing resources they shouldn't — reading other users' data, admin pages without auth | Cloudflare Access (ZTNA), WAF rules |
| A02 | Cryptographic Failures | Sensitive data exposed due to weak/missing encryption — passwords in plaintext, HTTP instead of HTTPS | HTTPS enforcement, HSTS, TLS version control |
| A03 | Injection | Attacker inserts malicious code into queries — SQL injection, command injection, LDAP injection | WAF Managed Ruleset (OWASP core rule set) |
| A04 | Insecure Design | Architectural flaws — security not built into the design phase | Not directly — requires secure development practices |
| A05 | Security Misconfiguration | Default credentials, exposed error messages, unnecessary features enabled, open cloud storage | WAF rules, security headers via Managed Headers |
| A06 | Vulnerable Components | Using libraries or frameworks with known vulnerabilities — Log4Shell was this category | WAF virtual patching — blocks exploit attempts while origin is patched |
| A07 | Authentication Failures | Broken login — credential stuffing, brute force, weak passwords, session fixation | Bot Management, Rate Limiting, Cloudflare Access |
| A08 | Software & Data Integrity Failures | Untrusted code/data in pipeline — malicious npm packages, insecure deserialization | Page Shield (client-side JS protection) |
| A09 | Logging & Monitoring Failures | Not detecting breaches — no logs, alerts, or incident response | Cloudflare Security Analytics, SIEM integration |
| A10 | Server-Side Request Forgery (SSRF) | App fetches remote URL controlled by attacker — access internal systems via server | WAF rules targeting SSRF patterns |
Cloudflare's WAF includes the OWASP Core Rule Set (CRS) as a managed ruleset — a set of rules maintained by OWASP that covers the most common attack patterns across all Top 10 categories. Customers can enable it with one click. Cloudflare's security team also maintains their own additional rulesets on top of OWASP CRS, updated in real-time as new vulnerabilities are discovered.
SQL Injection is an attack where an attacker inserts malicious SQL code into an input field, which then gets executed by the database. It's one of the oldest and most devastating attacks — responsible for countless data breaches.
Consider a login form. The backend takes the username and password and builds a SQL query:
| Type | What it does | Example payload |
|---|---|---|
| Classic / In-band | Results returned directly in response | ' OR '1'='1 |
| UNION-based | Appends another SELECT to extract data from other tables | ' UNION SELECT username,password FROM users-- |
| Blind SQLi | No direct output — infers data from true/false responses or timing | ' AND 1=1-- vs ' AND 1=2-- |
| Time-based Blind | Uses database sleep functions to infer data via response delay | '; IF (1=1) WAITFOR DELAY '0:0:5'-- |
The proper fix is parameterised queries / prepared statements — separating SQL code from user data so input can never be interpreted as SQL. The WAF provides an additional layer by detecting and blocking SQLi patterns in requests before they reach the origin.
XSS attacks inject malicious JavaScript into a webpage that is then executed in other users' browsers. Unlike SQLi which targets the database, XSS targets the users themselves.
A user submits a comment on a website. The comment is stored and displayed to other visitors. If the site doesn't sanitise input:
| Type | How it works | Persistence |
|---|---|---|
| Stored (Persistent) | Malicious script saved in database, served to every visitor. Most dangerous. | Permanent until removed |
| Reflected | Script in URL parameter reflected back in response. Victim clicks a malicious link. | Only affects users who click the link |
| DOM-based | JavaScript on the page itself reads attacker-controlled data and writes it to DOM unsafely. | Client-side only — never sent to server |
SQLi and XSS are the two most common attack types the WAF is configured to block. Cloudflare's OWASP Managed Ruleset includes hundreds of signatures for both — detecting patterns like SELECT FROM, UNION SELECT, <script>, onerror=, javascript: etc. in URLs, headers, and request bodies. When you write a custom WAF rule to block a specific SQLi variant, you're extending this protection.
CSRF (Cross-Site Request Forgery) tricks a user's browser into making an unwanted request to a site where the user is already logged in. The attacker doesn't steal the session — they abuse it.
The attack relies on one key fact: browsers automatically attach cookies to every request to a domain — even if the request originates from a different site.
| Method | How it works |
|---|---|
| CSRF Token | Server generates a unique secret token per session and embeds it in every form. Attacker's forged request doesn't have the token → request rejected. Most effective defence. |
| SameSite Cookie attribute | SameSite=Strict or SameSite=Lax prevents cookies being sent with cross-site requests. Covered in Module 7.7. |
| Checking Origin/Referer headers | Server checks where the request came from. If it's not from the expected domain — reject it. |
| Requiring re-authentication | For sensitive actions (money transfer, email change) — ask for password again. Even a valid CSRF token can't bypass this. |
Modern browsers now default to SameSite=Lax for cookies — meaning cookies are not sent on cross-site POST requests. This breaks the core CSRF mechanism for most scenarios. However, older browsers and misconfigured SameSite=None cookies still leave CSRF possible. WAF rules can also detect common CSRF patterns — missing CSRF tokens or mismatched origin headers.
A bot is any automated program that makes HTTP requests — acting like a browser but without a human behind it. Bots are not inherently bad. A huge portion of internet traffic is bots. The challenge is distinguishing good bots from bad bots.
Attackers obtain lists of leaked username/password combinations from data breaches (billions exist on the dark web). They then use bots to automatically try these credentials on other sites — betting that users reuse passwords.
Cloudflare's Bot Management assigns every request a bot score from 1–99:
Detection signals used:
| Signal | What it detects |
|---|---|
| JavaScript fingerprinting | Real browsers execute JS in specific ways — bots often don't or behave differently |
| TLS fingerprinting (JA3) | The TLS handshake reveals the client's software — bot frameworks have distinctive signatures |
| Behavioural analysis | Mouse movements, scroll patterns, timing between requests — bots are too consistent, too fast |
| Request header analysis | Bots often have missing, unusual, or fake User-Agent strings |
| IP reputation | Cloudflare's global network sees 20% of internet traffic — known bad IPs are flagged immediately |
| Machine learning | Models trained on trillions of requests identify bot patterns that rule-based systems miss |
| Product | Available on | What it does |
|---|---|---|
| Bot Fight Mode | Free plan | Blocks obvious bots — simple fingerprinting, challenges known bad bot IPs |
| Super Bot Fight Mode | Pro/Business plans | Adds ML detection, verified bot allowlist (Googlebot etc.), JS challenges |
| Bot Management | Enterprise plan | Full bot score (1–99), custom rules by score, analytics, API access, model tuning |
APIs are the backbone of modern applications — mobile apps, SPAs, microservices, and third-party integrations all communicate via APIs. But APIs are often less protected than web frontends:
| Attack | What it is | Example |
|---|---|---|
| Broken Object Level Authorisation (BOLA) | API returns data for any object ID — attacker changes the ID to access other users' data. #1 on OWASP API Top 10. | GET /api/users/42 works. Attacker tries GET /api/users/43 → gets another user's data. |
| Broken Authentication | Weak or missing authentication on API endpoints — API tokens never expire, endpoints accessible without any token | API key sent in URL query string → logged in server logs → leaked |
| Excessive Data Exposure | API returns more data than needed — frontend filters it, but full data is exposed in the API response | API returns full user object including SSN and DOB — frontend only shows name and email |
| Rate Limiting Absent | No limits on how many requests a client can make — enables scraping, brute force, credential stuffing | Attacker calls /api/search 10M times to dump entire product catalogue |
| Mass Assignment | API blindly applies all fields from request body to database object — attacker adds privileged fields | POST body: {"name":"alice","role":"admin"} → user gets admin role if API doesn't filter fields |
| Injection via API | SQLi, NoSQLi, command injection through API parameters — same attack as web but via JSON body | {"username": "admin' OR '1'='1"} in JSON body |
| Sequence Abuse | API calls designed to be made in a specific order — attacker skips steps (e.g. skip payment, go straight to order confirmation) | E-commerce: browse → add to cart → pay → confirm. Attacker calls /confirm directly. |
Cloudflare's API Shield product addresses the full API attack surface:
A Man-in-the-Middle (MitM) attack is when an attacker secretly intercepts and potentially modifies communication between two parties — each believing they're communicating directly with the other.
| Attack | How it works | Defence |
|---|---|---|
| HTTP interception | User visits an HTTP (not HTTPS) site. Attacker on same network reads all traffic in plaintext. | HTTPS everywhere, HSTS to force HTTPS |
| SSL stripping | Attacker downgrades an HTTPS connection to HTTP — user's browser talks HTTP to attacker, attacker talks HTTPS to server. User thinks they're on a secure connection. | HSTS with preload — browser refuses HTTP entirely |
| Rogue WiFi / Evil Twin | Attacker sets up a fake WiFi hotspot ("Free Airport WiFi"). User connects — all traffic routes through attacker. | TLS + HSTS — even on rogue WiFi, encrypted traffic can't be read without the cert's private key |
| ARP Spoofing | On a local network, attacker claims their MAC is the router — devices send all traffic through attacker. Covered in Module 2. | Dynamic ARP inspection, network-level controls |
| BGP Hijacking | Attacker announces false BGP routes — traffic for a destination gets routed through attacker's network. Covered in Module 4. | RPKI, route filtering, BGP route monitoring |
When TLS is implemented correctly, MitM attacks face a fundamental barrier: the attacker cannot forge a valid TLS certificate for the target domain (they don't have the CA-signed private key). The browser will show a certificate error.
The attacker is left with two options — both of which fail when users and systems are configured correctly:
Cloudflare protects against MitM at multiple levels:
A zero-day vulnerability is a security flaw in software that is unknown to the vendor — meaning they have had zero days to fix it. Because no patch exists yet, any system running that software is exposed with no defence from the vendor.
Zero-days are the most dangerous category of vulnerability because:
| Vulnerability | Year | What it was | Impact |
|---|---|---|---|
| Log4Shell (CVE-2021-44228) | 2021 | Critical flaw in Apache Log4j logging library — attackers could run any code on the server by logging a malicious string | Hundreds of millions of systems affected. Cloudflare deployed WAF rules within hours of disclosure. |
| EternalBlue | 2017 | NSA-developed exploit for a Windows SMB flaw, leaked by Shadow Brokers | Used in WannaCry and NotPetya ransomware — billions in damage |
| Heartbleed (CVE-2014-0160) | 2014 | Buffer over-read in OpenSSL — attackers could read server memory including private keys | Affected ~17% of all HTTPS servers. Private keys, passwords, session tokens exposed. |
When a vulnerability is publicly disclosed, it gets assigned a CVE identifier — a standardised reference number like CVE-2021-44228. This allows vendors, security tools, and teams worldwide to refer to the same vulnerability unambiguously.
CVSS (Common Vulnerability Scoring System) rates severity from 0–10. A score of 9.0+ is considered Critical.
When a critical zero-day is disclosed (like Log4Shell), organisations need weeks or months to patch all affected systems. The WAF can be updated in hours to detect and block exploit attempts — buying time while the underlying software gets patched.
Cloudflare's security team deployed WAF rules blocking Log4Shell exploit attempts within hours of public disclosure — before most organisations even knew they were vulnerable. This is virtual patching at scale, and it's one of the strongest arguments for a WAF in any customer conversation.
Regex (Regular Expressions) is a pattern-matching syntax. You define a pattern, and it checks whether a string matches it. In Cloudflare WAF, regex is used in custom rules to match attack patterns in URLs, headers, and request bodies.
| Symbol | Meaning | WAF Example |
|---|---|---|
^ | Starts with | ^/admin — URL must start with /admin |
$ | Ends with | \.php$ — URL must end with .php |
| | OR | SELECT|UNION|DROP — any of these words |
(?i) | Case-insensitive | (?i)SELECT matches select, SELECT, SeLeCt — essential since attackers mix case to evade detection |
| What to block | Regex pattern | What it matches |
|---|---|---|
| SQL injection | (?i)(SELECT|UNION|INSERT|DROP) | SQL keywords in any case |
| XSS script tags | (?i)<script | Opening script tags in any form |
| Known attack scanners | (?i)(sqlmap|nikto|nmap) | Common attack tool names in User-Agent |
| Admin paths | ^/admin | Any URL starting with /admin |
| Path traversal | \.\./ | Directory traversal like ../../etc/passwd |
In the WAF rule builder, set the operator to "matches regex" and write your pattern. Common fields to match against: http.request.uri.path (URL path), http.user_agent, http.request.body.raw.
Example: Block if User-Agent matches (?i)(sqlmap|nikto) — done. You don't need to be a regex expert to write effective WAF rules.
SameSite=Strict/Lax cookies (now browser default)^ starts with, $ ends with, | OR, (?i) case-insensitivehttp.request.uri.path, http.user_agent, http.request.body.raw using regexEvery concept from every module comes together in one complete picture — what happens when you type a URL, where Cloudflare fits, and how to think about the full stack as an SE.
You've now learned every layer of the stack. Here's how they all connect in a single web request. When you type https://cloudflare.com and press Enter:
Browser checks cache → OS cache → Resolver (1.1.1.1) → Root → .com TLD → Cloudflare's authoritative NS.
Result: cloudflare.com resolves to 104.21.5.10 (Cloudflare's Anycast IP)
Browser initiates a TCP connection to 104.21.5.10:443.
SYN → SYN-ACK → ACK. One round trip. Connection established.
Browser and Cloudflare's nearest PoP negotiate TLS 1.3. One more round trip (1-RTT).
Certificate verified. Session key exchanged. Connection is now encrypted.
Browser sends: GET / HTTP/3 with headers (Host, User-Agent, Accept, etc.)
Travels over the encrypted TLS channel to Cloudflare's PoP.
At the PoP, Cloudflare runs in milliseconds:
DDoS check → WAF rules → Bot score → Cache lookup → Rate limiting
If cache HIT: response served from PoP immediately. No origin contact.
If not cached, Cloudflare forwards the request to the origin server over its private backbone (not the public internet). New TLS connection opened between Cloudflare and origin.
Origin returns HTTP response. Cloudflare caches it per Cache-Control headers.
Adds cf-ray, cf-cache-status, and other Cloudflare response headers.
Browser receives HTTP response with status 200. Renders HTML. Makes additional requests for CSS, JS, images — each following the same path (but hitting the cache for most static assets).
Every step of the web request lifecycle maps to specific OSI layers. This is the framework that lets you precisely diagnose issues and explain products:
| OSI Layer | What happened in our request | Cloudflare product operating here |
|---|---|---|
| L7 — Application | HTTP request/response. Headers, URL, cookies, request body. DNS resolution. | WAF, Bot Management, CDN cache, Rate Limiting, API Shield, Workers |
| L6 — Presentation | TLS encryption/decryption. Cloudflare terminates TLS at the edge, re-encrypts to origin. | TLS termination, Universal SSL, mTLS |
| L5 — Session | TCP session management. Keep-alive connections, multiplexing in HTTP/2. | Connection management, QUIC sessions (HTTP/3) |
| L4 — Transport | TCP/UDP. Port numbers (443 for HTTPS). TCP handshake. Flow control. | Spectrum (L4 proxy), Magic Firewall (L4 filtering) |
| L3 — Network | IP packets. Routing. BGP path selection to nearest Cloudflare PoP via Anycast. | Magic Transit (L3 DDoS), network-level DDoS protection |
| L2 — Data Link | Ethernet frames. MAC addresses. Switch forwards frames at IXP to Cloudflare. | Network infrastructure (handled by data center switches) |
| L1 — Physical | Bits on fiber optic cables. Radio waves for WiFi last mile. Submarine cables across oceans. | Network infrastructure (Cloudflare's PoP hardware) |
Cloudflare sits between users and the origin server — acting as a reverse proxy. Users connect to Cloudflare, Cloudflare connects to the origin. Neither side knows about each other directly.
| Cloudflare CAN | Cloudflare CANNOT |
|---|---|
| Block malicious requests before they reach origin | Fix bugs in the origin application code |
| Cache content globally to reduce latency | Speed up an uncacheable dynamic origin that's inherently slow |
| Terminate TLS and inspect HTTP content | Inspect traffic if the customer uses Full (Strict) end-to-end encryption without Cloudflare's knowledge |
| Absorb DDoS attacks at 280+ Tbps capacity | Protect origins that aren't proxied (grey cloud) or accessed directly via IP |
| Add security headers, transform requests/responses | Prevent a data breach if the origin database itself is compromised |
This is one of the most important and most commonly misunderstood decisions in Cloudflare. Every DNS record has a proxy toggle that fundamentally changes how traffic flows.
When diagnosing a customer issue, the first thing to confirm is whether Cloudflare is actually proxying the request:
Run curl -I https://domain.com. If you see cf-ray: ... in the response headers — Cloudflare is proxying. If no cf-ray header — Cloudflare is NOT in the path.
Run nslookup domain.com. If the IP belongs to Cloudflare (check cloudflare.com/ips) — proxied. If it's the customer's own IP — grey cloud.
Visit https://domain.com/cdn-cgi/trace. If Cloudflare is proxying, this returns a trace page showing the PoP, visitor IP, and HTTP version. If not proxied, it returns 404.
In Cloudflare's terminology, the origin server is the customer's actual web server — the one that contains the real application and data. Cloudflare sits in front of it. When Cloudflare can't serve from cache (cache miss), it fetches from the origin.
| Origin Type | Where it lives | What Cloudflare connects to |
|---|---|---|
| Traditional origin | Customer's own servers or VPS (DigitalOcean, Linode) | Origin's public IP address on port 80/443 |
| Cloud origin | AWS EC2, Azure VM, Google Cloud Compute | Instance's IP or load balancer DNS name |
| Cloud storage | AWS S3, Google Cloud Storage | Bucket's public URL |
| PaaS origin | Heroku, Render, Railway | App's platform-provided domain |
| Serverless origin | AWS Lambda + API Gateway, Vercel | Function endpoint URL |
| On-premise origin | Customer's own data center | Public IP or Cloudflare Tunnel (no open port needed) |
Traditionally, Cloudflare connects to an origin via its public IP on port 443. But what if the origin is behind a corporate firewall with no public IP? Cloudflare Tunnel (formerly Argo Tunnel) solves this — a lightweight agent runs on the origin and creates an outbound connection to Cloudflare. No inbound ports needed.
We covered this in Module 8, but it's worth summarising here as it's one of the most common customer configurations:
| Mode | User → CF | CF → Origin | Use when |
|---|---|---|---|
| Off | HTTP only | HTTP | Never — completely insecure |
| Flexible | HTTPS ✅ | HTTP ❌ | Avoid — origin traffic unencrypted. Only if origin has NO SSL at all. |
| Full | HTTPS ✅ | HTTPS ✅ (any cert) | Origin has HTTPS but self-signed cert |
| Full (Strict) | HTTPS ✅ | HTTPS ✅ (valid cert) | ✅ Always use this in production. Origin cert must be valid (use Cloudflare Origin CA) |
Always use Full (Strict) in production. It's the only mode that ensures end-to-end encryption with verified certificates. Common support issue: customers set "Flexible" because their origin doesn't have a cert — but then traffic between Cloudflare and origin is unencrypted. Solution: issue a free Cloudflare Origin CA certificate and switch to Full (Strict).
cf-ray header — unique request ID + PoP codecf-ray header in response. No cf-ray = not proxied.You've completed the full networking, HTTP, DNS, TLS, and security foundation. Every concept from these 10 modules directly enables the Cloudflare product conversations in Phase 2.