Lesson 1 of 12

Introduction

16 min read

TCP/IP Networking — Introduction

What You Are About to Learn

This section of the course covers the foundational layer beneath almost everything in cybersecurity: how computers talk to each other. Before you can understand how an attacker intercepts communications, how a firewall blocks traffic, or how a vulnerability scanner finds open services, you need to understand the rules that govern network communication. That set of rules is called the TCP/IP suite.

This introduction gives you the lay of the land — what TCP/IP is, where it came from, why it matters for security, and what the rest of this section covers. By the end of this file you will have a clear picture of why networking knowledge is not optional for anyone serious about cybersecurity.

What TCP/IP Actually Is

The name "TCP/IP" is shorthand that has stuck even though it only names two of the dozens of protocols that make up the suite. TCP stands for Transmission Control Protocol. IP stands for Internet Protocol. Together, these two protocols handle the most critical jobs in network communication: getting data from one place to another (IP) and ensuring that data arrives completely and in the right order (TCP). But they do not work alone.

The TCP/IP suite is a family of protocols — a collection of agreed rules that, taken together, govern how data moves across networks. Other members of this family include:

UDP — User Datagram Protocol, an alternative to TCP for situations where speed matters more than guaranteed delivery
ICMP — Internet Control Message Protocol, used for diagnostics and error reporting (the protocol behind the ping command)
DNS — Domain Name System, which translates human-readable names like example.com into numeric IP addresses
DHCP — Dynamic Host Configuration Protocol, which automatically assigns IP addresses to devices joining a network
ARP — Address Resolution Protocol, which maps IP addresses to physical hardware addresses on a local network
HTTP and HTTPS — Hypertext Transfer Protocol (and its secure variant), the protocols your browser uses to load web pages
FTP — File Transfer Protocol, used for transferring files between systems
SMTP — Simple Mail Transfer Protocol, used for sending email
SSH — Secure Shell, used for encrypted remote access to systems

Every one of these protocols is part of the TCP/IP world. When you hear someone say "the internet runs on TCP/IP," they mean the internet runs on this entire coordinated family of protocols — with TCP and IP at the center.

A useful analogy: if networking were a postal system, IP would be the addressing system that tells the post office where a package is going, and TCP would be the certified mail service that confirms each piece arrived and requests a re-send if it did not. The other protocols are different specialized services offered by the same postal system: DNS is the phone book that finds addresses, SMTP is the mail delivery system for letters, and ICMP is the system that sends you a notice when a package cannot be delivered.

What a Protocol Is

The word "protocol" appears everywhere in networking, so it is worth defining precisely before going further.

A protocol is a set of agreed rules that two parties follow in order to communicate successfully. Both sides must agree on the same rules, or communication fails. This is true for human communication too — if you speak English and the person you are calling speaks only Japanese, no information gets through, no matter how good the phone connection is.

In networking, a protocol defines things like:

How a conversation starts (who speaks first and what they say)
What format data must be in (where the destination address goes, how long a field can be, what units are used)
How errors are signaled and handled
How a conversation ends

When two programs on two different computers want to exchange data, they both run the same protocol. One sends a message formatted exactly as the protocol requires; the other receives it and knows exactly how to interpret every byte because it follows the same rules.

Protocols are defined formally in documents called RFCs — Requests for Comments. This is a name with a modest history: when the original researchers were building what became the internet, they circulated their ideas as "requests for comments" to invite peer review. The name stuck. Today, RFCs published by the IETF — the Internet Engineering Task Force, the standards body responsible for internet protocols — are the authoritative definitions of protocols like TCP, IP, UDP, DNS, and hundreds of others. When there is a disagreement about how a protocol should behave, the RFC is the reference.

The Protocol Stack: Why Protocols Are Layered

Networks use dozens of protocols simultaneously. Rather than building one enormous protocol that does everything, engineers organized protocols into layers, where each layer handles a specific job and relies on the layer below it to handle the layers it does not care about.

Think of it as a division of labor. The protocol responsible for delivering a web page does not need to know whether the physical connection is a fiber optic cable or a wireless radio signal. The protocol responsible for routing packets across the internet does not need to know whether the data inside the packet is a video, an email, or a database query. Each layer focuses on its own job and trusts the other layers to handle theirs.

This layered structure is called a protocol stack. When data is sent, it passes down through the layers, and each layer adds its own information (called a header) to the data before passing it to the layer below. When data is received, the process reverses: each layer reads and removes its own header, then passes the remaining data up to the layer above. This process of adding headers going down is called encapsulation. The reverse — stripping headers going up — is called decapsulation.

There are two major models used to describe this layering:

The OSI model — Open Systems Interconnection — is a seven-layer reference model created by the ISO (International Organization for Standardization) in 1984. It is used primarily as a teaching and troubleshooting tool, not as a literal implementation. Almost everyone in networking uses OSI terminology to describe where in the communication stack something happens.

The TCP/IP model is the four-layer model that reflects how TCP/IP networking is actually implemented. Its layers are: Network Access (also called Link), Internet, Transport, and Application. The TCP/IP model maps roughly onto the OSI model but combines several OSI layers at the top and bottom.

Both models are covered in detail in this section. For now, the key idea is this: protocols are layered because separation of concerns makes systems easier to build, understand, maintain, and secure.

A Brief History: From ARPANET to the Modern Internet

The internet did not appear suddenly. It grew from a research project funded by the United States Department of Defense (DoD) in the 1960s.

In 1969, the DoD's Advanced Research Projects Agency, or ARPA (later renamed DARPA — Defense Advanced Research Projects Agency), funded the creation of ARPANET — the Advanced Research Projects Agency Network. ARPANET connected computers at four university research sites: UCLA (University of California, Los Angeles), Stanford Research Institute, UC Santa Barbara, and the University of Utah. The first message sent over ARPANET was "lo" — the beginning of the word "login," before the system crashed. The network recovered, and the experiment continued.

ARPANET was designed around a concept called packet switching. Instead of dedicating an entire circuit between two parties for the duration of a conversation (as telephone networks did), packet switching breaks data into small chunks called packets, routes each packet independently across whatever path is available, and reassembles them at the destination. This design made the network inherently resilient — if one path was destroyed, packets could be routed around it. The DoD funded this research partly because it wanted communications infrastructure that could survive partial destruction.

Throughout the 1970s, other networks emerged alongside ARPANET, and the question became how to interconnect them. Researchers Vint Cerf and Bob Kahn published a landmark paper in 1974 — "A Protocol for Packet Network Intercommunication" — that proposed a design for connecting separate networks together. This proposal became the foundation of what we now call TCP/IP.

The key milestones in TCP/IP's formalization:

1974: Cerf and Kahn publish the paper proposing the interconnection protocol
1981: IPv4 — IP version 4 — is formally defined in RFC 791, published by the IETF. This document remains the authoritative specification for the version of IP most networks still use today.
1981: TCP is formally defined in RFC 793, published the same year.
January 1, 1983: ARPANET officially switches to TCP/IP. This date is sometimes called "flag day" — the day all connected systems were required to use the new protocol suite. This date is often cited as the birthday of the modern internet.
1990: ARPANET is decommissioned. The networks that replaced and extended it, running TCP/IP, became the internet.

The internet you use today is the direct descendant of ARPANET. The protocols you use every time you load a web page, send an email, or stream a video trace their lineage directly to the work done in those university computer labs and DoD-funded research centers in the 1970s and 1980s.

This history matters for cybersecurity because TCP/IP was designed for reliability and interoperability among trusted researchers — not for security against adversarial users. Many of the fundamental vulnerabilities in internet protocols exist because security was not a primary design goal when these protocols were created. Understanding this context helps explain why attacks like IP spoofing, ARP poisoning, and TCP session hijacking are possible in the first place.

Why This Matters for Cybersecurity

Every attack that happens over a network — which is the vast majority of attacks in the modern threat landscape — travels through the TCP/IP protocol suite. This makes protocol knowledge foundational to cybersecurity in both directions: understanding attacks and building defenses.

Here is a concrete picture of why:

When a network scanner like Nmap discovers what services are running on a target system, it works by sending TCP and UDP packets to specific port numbers and analyzing the responses. To understand how a network scanner works — and how to detect one — you need to understand TCP, UDP, and ports.

When an attacker performs a man-in-the-middle attack — positioning themselves between two communicating parties to intercept or alter their communications — they typically exploit weaknesses in ARP (Address Resolution Protocol) to redirect traffic to their own machine. To understand how this attack works and how to prevent it, you need to understand ARP.

When a Distributed Denial of Service (DDoS) attack floods a server with more requests than it can handle, the attacker often exploits characteristics of the TCP handshake — specifically, a technique called a SYN flood that consumes server resources by initiating but never completing connections. To understand how to defend against this, you need to understand how TCP connections are established.

When a firewall decides whether to allow or block a packet, it makes that decision based on IP addresses, port numbers, protocols, and sometimes the content of the packets themselves. To configure or evaluate a firewall effectively, you need to understand all of those concepts.

When security analysts read logs, they see IP addresses, port numbers, protocol identifiers, and flags. To interpret what those logs mean — to determine whether traffic is normal or suspicious — they must understand what normal looks like at the protocol level.

This is not theoretical. The Cybersecurity and Infrastructure Security Agency (CISA) — the U.S. federal agency responsible for infrastructure security — consistently notes that attackers exploit fundamental network protocol behaviors, not just software vulnerabilities. Many of the techniques used in advanced persistent threats (APTs) — sophisticated, long-term attacks typically conducted by nation-state actors — involve manipulating or abusing standard network protocols because protocols are everywhere, often trusted by default, and rarely monitored with the granularity needed to detect subtle abuse.

You do not need to be a network engineer to work in cybersecurity. But you need to understand what is happening on the wire. This section gives you that foundation.

Legal and Ethical Context

Understanding network protocols gives you the ability to use tools and techniques that are powerful and, in the wrong context, harmful. Network scanners, packet analyzers, and protocol manipulation tools are all built on the knowledge covered in this section.

The principle that applies throughout this course applies here: knowledge itself is neutral. The same understanding of how TCP connections work that lets an attacker conduct a SYN flood lets a defender recognize one and configure a firewall to block it. The same understanding of DNS that lets an attacker perform DNS poisoning lets a defender implement DNSSEC — DNS Security Extensions — to prevent it.

What is not neutral is what you do with that knowledge. Scanning networks you do not own or have explicit permission to scan is illegal in most jurisdictions under laws like the Computer Fraud and Abuse Act (CFAA) in the United States, the Computer Misuse Act in the United Kingdom, and equivalent legislation in most other countries. Intercepting network traffic you are not authorized to intercept carries similar legal penalties.

Throughout this section, examples and exercises are designed for use on your own systems, in controlled lab environments, or within the scope of explicit authorized testing. The goal is to understand how things work, not to cause harm.

What This Section Covers

The TCP/IP networking section of this course moves through the subject in a logical order, each topic building on the ones before it:

The OSI model introduces the seven-layer framework used to describe network communication. Before diving into specific protocols, having this framework in place makes it much easier to understand where each protocol fits and what job it does.

The TCP/IP model covers the four-layer model that reflects how TCP/IP is actually implemented, and maps it against the OSI model so you can see the relationship between the two frameworks.

IP addressing covers how devices are identified on a network. IP addresses are the fundamental addressing system of the internet, and understanding them is prerequisite to understanding almost everything else.

Subnetting covers how IP address spaces are divided into smaller networks. This is essential for understanding how organizations structure their networks and how attackers identify targets within address ranges.

ARP — Address Resolution Protocol — covers how devices on the same local network find each other's hardware addresses. ARP is also the basis of several important attack techniques.

TCP and UDP cover the two main transport protocols in detail — how they work, how they differ, and what their security implications are.

ICMP — Internet Control Message Protocol — covers the protocol used for network diagnostics and error messages, including the ping and traceroute tools that security professionals use constantly.

DNS — Domain Name System — covers how names are resolved to addresses, how DNS queries and responses work, and why DNS is a frequent target for attackers.

DHCP — Dynamic Host Configuration Protocol — covers how devices automatically receive IP configuration when they join a network, and the security risks this creates.

Routing covers how packets find their way from source to destination across multiple networks, including how routing can be attacked or manipulated.

Common ports covers the standard port numbers associated with well-known services, which is knowledge you use every time you read a firewall log, run a port scan, or configure a network rule.

Each topic is covered at the depth needed to understand both the normal operation of the protocol and its security implications. By the end of this section, you will have the networking foundation that cybersecurity professionals rely on every day.

The Bottom Line

TCP/IP is not a single protocol — it is a family of dozens of protocols that together govern how data moves across networks, from the physical signals on a cable to the web pages displayed in a browser. The two most central protocols are TCP (Transmission Control Protocol), which ensures reliable delivery, and IP (Internet Protocol), which handles addressing and routing. This suite traces its origins to ARPANET, a 1969 U.S. Department of Defense research network, and was formally defined in RFCs published in 1981. It became the standard for the internet on January 1, 1983.

For cybersecurity, this knowledge is not optional. Every attack travels over a network, every defense operates at the network level, and every security tool — from firewalls to intrusion detection systems to vulnerability scanners — depends on understanding the protocols being analyzed. The rest of this section builds that understanding layer by layer.

Check Your Understanding

TCP/IP is described as a "suite" rather than a single protocol. What does that mean, and can you name at least three protocols that are part of the suite besides TCP and IP?
ARPANET was funded by the U.S. Department of Defense and designed with resilience in mind. How did the design principle of packet switching contribute to that resilience, and what aspect of ARPANET's original design context helps explain why many TCP/IP protocols have inherent security weaknesses?

Something to Think About

TCP/IP was designed in an era when the network connected a small number of trusted researchers at universities and government labs. The internet now connects billions of devices operated by parties with wildly different intentions. If you were designing a network protocol suite from scratch today, knowing what you know about the modern threat landscape, what properties would you prioritize that the original designers did not?
The same protocol knowledge is used by both attackers and defenders. A penetration tester (a security professional who tests systems by attempting to break into them, with permission) and a malicious attacker use many of the same tools and techniques. What do you think distinguishes ethical security research from malicious activity — and does the line ever get complicated?

References

Official Specification. RFC 791 — "Internet Protocol". Internet Engineering Task Force, September 1981. — The document that defines IPv4, including packet structure, addressing, and fragmentation.
Official Specification. RFC 793 — "Transmission Control Protocol". Internet Engineering Task Force, September 1981. — The document that defines TCP, including the three-way handshake, flow control, and reliable delivery.
Standards Body. IETF — "How the IETF Works". Internet Engineering Task Force. — The organization that defines and maintains TCP/IP protocol standards through the RFC (Request for Comments) process.
Historical Reference. Cerf, Vint, and Kahn, Bob. "A Protocol for Packet Network Intercommunication." IEEE Transactions on Communications, Vol. 22, No. 5, May 1974. — The original paper proposing what became TCP/IP, co-authored by the two engineers who designed the suite.
Real-World Context. CISA — "Understanding and Protecting Against Network-Based Attacks". Cybersecurity and Infrastructure Security Agency. — Federal guidance applying networking protocol knowledge in a defensive security context.