If you’ve ever tried to learn networking and got lost switching between the OSI model and the TCP/IP model, you’re not alone. I’ve been there — flipping between diagrams that don’t quite match, wondering why one chart has seven layers and another has four. This cheat sheet is my attempt to lay out the TCP/IP model in a way that’s actually usable, whether you’re studying for a CompTIA Network+ or CCNA exam, prepping for a sysadmin interview, or just trying to figure out why a packet isn’t reaching its destination at 2 AM.
I’ll walk through every layer, the protocols that live there, how they map to the OSI model, and the practical commands you’ll actually use to troubleshoot each one. Bookmark this page — it’s built to be a reference you come back to.
What Is the TCP/IP Model?
The TCP/IP model (also called the Internet Protocol Suite) is the practical, real-world framework that describes how data travels across networks — including the internet itself. It was developed by the U.S. Department of Defense in the 1970s, well before the OSI model existed, and it’s the model that actually runs the internet today.
Unlike the OSI model’s seven layers, the TCP/IP model condenses everything into four layers (sometimes described as five, depending on the textbook). It’s less theoretical and more focused on what actually happens when your laptop talks to a web server on the other side of the planet.
Here’s the quick snapshot before I go deeper:
| Layer | Name | Primary Job | Example Protocols |
|---|---|---|---|
| 4 | Application | User-facing services and data formatting | HTTP, HTTPS, FTP, DNS, SMTP, SSH |
| 3 | Transport | End-to-end delivery, reliability, ports | TCP, UDP |
| 2 | Internet | Logical addressing and routing | IP, ICMP, ARP |
| 1 | Network Access (Link) | Physical transmission and framing | Ethernet, Wi-Fi, PPP, ARP |
TCP/IP Model vs OSI Model: Layer Mapping
This is the comparison everyone searches for, so let’s get it out of the way early.
| OSI Layer | OSI Name | TCP/IP Layer | TCP/IP Name |
|---|---|---|---|
| 7 | Application | 4 | Application |
| 6 | Presentation | 4 | Application |
| 5 | Session | 4 | Application |
| 4 | Transport | 3 | Transport |
| 3 | Network | 2 | Internet |
| 2 | Data Link | 1 | Network Access |
| 1 | Physical | 1 | Network Access |
The main difference: TCP/IP merges OSI’s Application, Presentation, and Session layers into a single Application layer, and it merges the Physical and Data Link layers into one Network Access (or Link) layer. If an interviewer asks you to explain the difference in one sentence, that’s it — TCP/IP is a condensed, practical model; OSI is a detailed, theoretical reference model.
Layer 1: Network Access (Link) Layer
This is the bottom layer, and it’s responsible for the physical and logical connection between a device and the network medium — cables, network interface cards, switches, and wireless radios all live here conceptually.
What It Does
- Converts data into bits for transmission over physical media (copper, fiber, radio waves)
- Handles MAC (Media Access Control) addressing
- Manages framing — packaging data into frames with headers and trailers
- Detects transmission errors at the physical level
Key Protocols and Technologies
| Protocol/Tech | Purpose | Notes |
|---|---|---|
| Ethernet (802.3) | Wired LAN standard | Most common wired networking standard |
| Wi-Fi (802.11) | Wireless LAN standard | a/b/g/n/ac/ax variants exist |
| ARP | Maps IP addresses to MAC addresses | Technically bridges Layer 1/2 and Layer 2 (Internet) functions |
| PPP | Point-to-point serial connections | Common in older WAN links, VPNs |
| MAC Address | 48-bit hardware address | Format: 00:1A:2B:3C:4D:5E |
Common Commands
# View MAC address and network interfaces (Linux)
ip link show
# View MAC address (Windows)
ipconfig /all
# View ARP table (cross-platform)
arp -a
# Check interface statistics (Linux)
ethtool eth0
Example output of arp -a:
? (192.168.1.1) at 00:1a:2b:3c:4d:5e [ether] on eth0
? (192.168.1.15) at f4:5c:89:12:34:56 [ether] on eth0
This tells you which MAC address corresponds to which IP address on your local network — useful when you’re chasing down duplicate IP conflicts or unauthorized devices.
Layer 2: Internet Layer
This is where IP addressing and routing decisions happen. If the Network Access layer is about “how do I get onto the wire,” the Internet layer is about “where does this data actually need to go.”
What It Does
- Assigns and interprets logical (IP) addresses
- Routes packets between networks
- Fragments and reassembles packets when needed
- Handles error reporting and diagnostics via ICMP
Key Protocols
| Protocol | Purpose | Port/Type |
|---|---|---|
| IPv4 | 32-bit logical addressing | N/A |
| IPv6 | 128-bit logical addressing | N/A |
| ICMP | Error reporting, diagnostics (ping, traceroute) | N/A |
| ARP | Resolves IP to MAC | N/A |
| IGMP | Manages multicast group membership | N/A |
| IPsec | Encrypts and authenticates IP packets | N/A |
IPv4 Address Classes (Reference Table)
| Class | Range | Default Subnet Mask | Use Case |
|---|---|---|---|
| A | 1.0.0.0 – 126.255.255.255 | 255.0.0.0 (/8) | Large networks |
| B | 128.0.0.0 – 191.255.255.255 | 255.255.0.0 (/16) | Medium networks |
| C | 192.0.0.0 – 223.255.255.255 | 255.255.255.0 (/24) | Small networks |
| D | 224.0.0.0 – 239.255.255.255 | N/A | Multicast |
| E | 240.0.0.0 – 255.255.255.255 | N/A | Experimental/Reserved |
Private IP Ranges (You’ll See These Constantly)
| Range | CIDR | Typical Use |
|---|---|---|
| 10.0.0.0 – 10.255.255.255 | /8 | Large enterprise networks |
| 172.16.0.0 – 172.31.255.255 | /12 | Medium-sized networks |
| 192.168.0.0 – 192.168.255.255 | /16 | Home and small office networks |
Common Commands
# Check your IP configuration (Linux)
ip addr show
# Check your IP configuration (Windows)
ipconfig
# Check your IP configuration (macOS)
ifconfig
# Test reachability
ping 8.8.8.8
# Trace the route packets take
traceroute google.com # Linux/macOS
tracert google.com # Windows
# Show the routing table
ip route show # Linux
route print # Windows
netstat -rn # macOS/Linux
Example output of ping:
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=14.2 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=13.8 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
If you see 100% packet loss here, the problem is likely somewhere at this layer or below — routing, firewall rules, or physical connectivity.
Layer 3: Transport Layer
This layer is where I’d say the real personality of TCP/IP shows up. It decides whether your data needs to arrive perfectly intact (TCP) or whether speed matters more than reliability (UDP).
What It Does
- Establishes end-to-end communication between hosts
- Segments data and manages flow control
- Handles error correction and retransmission (TCP only)
- Uses port numbers to direct traffic to the correct application
TCP vs UDP: The Classic Comparison
| Feature | TCP | UDP |
|---|---|---|
| Connection type | Connection-oriented | Connectionless |
| Reliability | Guaranteed delivery, retransmits lost packets | No guarantee |
| Ordering | Preserves order | No ordering guarantee |
| Speed | Slower (overhead from handshakes/acks) | Faster (minimal overhead) |
| Header size | 20–60 bytes | 8 bytes |
| Use cases | Web browsing, email, file transfer | Streaming, gaming, DNS, VoIP |
| Flow control | Yes | No |
| Error checking | Yes, with retransmission | Checksum only, no recovery |
The TCP Three-Way Handshake
This is a near-guaranteed interview question, so know it cold:
- SYN — Client sends a synchronize packet to the server to initiate connection
- SYN-ACK — Server responds with synchronize-acknowledge
- ACK — Client sends acknowledge, and the connection is established
And when closing a connection, TCP uses a four-way handshake (FIN, ACK, FIN, ACK) since both sides need to independently signal they’re done sending data.
Common Well-Known Ports
| Port | Protocol | Service |
|---|---|---|
| 20/21 | TCP | FTP (data/control) |
| 22 | TCP | SSH |
| 23 | TCP | Telnet |
| 25 | TCP | SMTP |
| 53 | TCP/UDP | DNS |
| 67/68 | UDP | DHCP |
| 80 | TCP | HTTP |
| 110 | TCP | POP3 |
| 143 | TCP | IMAP |
| 443 | TCP | HTTPS |
| 3389 | TCP | RDP |
| 3306 | TCP | MySQL |
| 5432 | TCP | PostgreSQL |
Common Commands
# View active connections and listening ports
netstat -tuln # Linux
netstat -an # Windows/macOS
# Modern alternative to netstat on Linux
ss -tuln
# Check if a specific port is open on a remote host
nc -zv example.com 443
# Test a TCP connection with telnet
telnet example.com 80
Example output of ss -tuln:
Netid State Local Address:Port Peer Address:Port
tcp LISTEN 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0.0.0.0:443 0.0.0.0:*
udp UNCONN 0.0.0.0:68 0.0.0.0:*
This tells you exactly which services are listening and on what ports — a first step in both troubleshooting and basic security auditing.
Layer 4: Application Layer
This is the layer users actually interact with, even if they don’t realize it. Every time you open a browser, send an email, or SSH into a server, you’re working at this layer.
What It Does
- Provides network services directly to applications
- Handles data formatting, encryption, and session management (functions that OSI splits into separate layers)
- Defines how applications communicate over the network
Key Protocols
| Protocol | Purpose | Default Port |
|---|---|---|
| HTTP | Web page transfer | 80 |
| HTTPS | Encrypted web transfer | 443 |
| FTP | File transfer | 20/21 |
| SFTP | Secure file transfer (over SSH) | 22 |
| SSH | Secure remote login | 22 |
| Telnet | Unencrypted remote login (legacy) | 23 |
| SMTP | Sending email | 25 |
| POP3 | Retrieving email (download and delete) | 110 |
| IMAP | Retrieving email (sync across devices) | 143 |
| DNS | Domain name resolution | 53 |
| DHCP | Automatic IP assignment | 67/68 |
| SNMP | Network device monitoring | 161/162 |
| NTP | Time synchronization | 123 |
Common Commands
# DNS lookups
nslookup example.com
dig example.com
host example.com
# Detailed DNS record query
dig example.com MX
# HTTP request from the command line
curl -I https://example.com
# Check DHCP lease info (Linux)
cat /var/lib/dhcp/dhclient.leases
# Renew DHCP lease
dhclient -r && dhclient # Linux
ipconfig /release && ipconfig /renew # Windows
Example output of dig example.com:
;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34
;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
How Data Moves Through the Layers: Encapsulation
Understanding encapsulation is what makes the whole model click. As data moves down the stack on the sending device, each layer wraps the data from the layer above it with its own header (and sometimes a trailer).
| Layer | Data Unit (PDU) | What Gets Added |
|---|---|---|
| Application | Data | Application-specific formatting |
| Transport | Segment (TCP) / Datagram (UDP) | Source/destination port numbers |
| Internet | Packet | Source/destination IP addresses |
| Network Access | Frame | Source/destination MAC addresses |
On the receiving end, this process reverses — it’s called de-encapsulation. Each layer strips off its corresponding header as the data climbs back up the stack to the receiving application. A simple way to remember the encapsulation order: Data → Segment → Packet → Frame → Bits.
Best Practices for Working With TCP/IP Networks
- Use private IP ranges for internal networks and NAT for internet access — don’t expose internal devices directly to public IPs unless absolutely necessary.
- Segment your network with VLANs and subnets to contain broadcast domains and limit the blast radius of a compromised device.
- Prefer TCP for anything requiring reliability (file transfers, financial transactions) and UDP for latency-sensitive applications (VoIP, live video, gaming).
- Close unused ports. Every open port is a potential attack surface — audit regularly with
nmaporss. - Use DHCP reservations for critical infrastructure (printers, servers) instead of full static assignment, so you keep centralized visibility without losing predictability.
- Monitor ARP tables periodically on sensitive networks to catch ARP spoofing attempts.
- Keep TTL and MTU settings in mind when diagnosing weird intermittent connectivity issues — mismatched MTU is a classic, hard-to-spot problem in VPN and tunnel setups.
- Document your IP addressing scheme. I know it sounds basic, but undocumented static IPs are one of the most common causes of conflicts in growing networks.
Troubleshooting Guide by Layer
| Symptom | Likely Layer | What to Check |
|---|---|---|
| No physical link light | Network Access | Cable, NIC, switch port |
| Device has no IP address | Internet | DHCP service, cable, VLAN config |
| Can ping IP but not hostname | Application | DNS server settings |
| Can ping locally but not externally | Internet | Default gateway, routing table |
| Website loads slowly, times out | Transport | Port availability, firewall rules, TCP retransmissions |
| “Connection refused” error | Transport | Check if service is actually listening (ss/netstat) |
| “Destination unreachable” | Internet | Routing, firewall ACLs |
| Intermittent packet loss | Network Access/Internet | Cabling, duplex mismatch, congestion |
| SSL/TLS handshake failure | Application | Certificate validity, protocol version support |
A Practical Troubleshooting Workflow
- Check physical connectivity — link lights, cable seating, Wi-Fi signal strength
- Verify IP configuration —
ipconfig/ip addr, confirm it’s not a stuck DHCP lease - Test local connectivity — ping the default gateway
- Test external connectivity — ping a known external IP like
8.8.8.8 - Test DNS resolution — ping a domain name; if the IP ping works but domain doesn’t, it’s DNS
- Check the specific service/port — use
telnetorncto confirm the port is open and listening - Review firewall rules — both host-based and network firewalls can silently drop traffic
Real-World Use Cases
Setting up a small office network: You’d typically assign a private range like 192.168.1.0/24, configure a router to handle DHCP and NAT, and reserve static IPs for the printer and any local server. Understanding the Internet and Transport layers here helps you troubleshoot why a laptop suddenly can’t reach the shared drive.
Debugging a “website is down” ticket: This is where the layered troubleshooting workflow really pays off. I’ve seen cases that looked like an application bug turn out to be a misconfigured firewall silently dropping port 443 traffic — a Transport layer issue masquerading as an Application layer one.
Configuring a VPN: VPNs typically operate by encapsulating traffic in an additional layer of headers (think IPsec or a TLS tunnel), which is a great real-world example of encapsulation in action — and also a common source of MTU-related headaches.
Choosing between TCP and UDP for an application you’re building: If you’re building a chat app, TCP makes sense since message delivery matters more than speed. If you’re building a live video call feature, UDP (often via protocols like WebRTC) makes more sense since a dropped frame is better than a delayed one.
Frequently Asked Questions
Q: Is the TCP/IP model the same as the internet? Not exactly — it’s the conceptual framework that describes how the internet’s protocols work together, but “the internet” is the physical and logical infrastructure that implements it.
Q: Why does TCP/IP have 4 layers while OSI has 7? TCP/IP was designed as a practical implementation model, built before OSI existed. OSI came later as a more granular, vendor-neutral teaching and design reference. TCP/IP simply combines functions that OSI splits apart.
Q: Which layer does a firewall operate at? It depends on the firewall type. Traditional packet-filtering firewalls operate at the Internet and Transport layers (filtering by IP and port). Next-generation firewalls and proxies can inspect traffic up at the Application layer.
Q: Which layer does a switch operate at? What about a router? A standard switch operates at the Network Access layer (using MAC addresses). A router operates at the Internet layer (using IP addresses) to move traffic between different networks.
Q: What’s the difference between a socket and a port? A port is just a number identifying a specific process on a device. A socket is the combination of an IP address and a port number, which together uniquely identify one end of a network connection.
Q: Does the TCP/IP model include a Session or Presentation layer? No — TCP/IP folds session management (like maintaining a login state) and data presentation (like encryption or encoding) into the single Application layer.
Common Interview Questions
- Explain the layers of the TCP/IP model and their functions.
- Walk me through the TCP three-way handshake.
- What’s the difference between TCP and UDP, and when would you choose one over the other?
- How does encapsulation work as data moves through the TCP/IP stack?
- What happens when you type a URL into a browser and hit enter? (This tests knowledge across every layer.)
- What’s the difference between a public and private IP address?
- How does ARP work, and why is it necessary?
- What is NAT, and why do most home networks use it?
- Explain the difference between IPv4 and IPv6.
- What’s the difference between the TCP/IP model and the OSI model?
- What is the purpose of a subnet mask?
- How would you troubleshoot a device that can’t reach the internet?
Common Mistakes to Avoid
- Confusing the OSI and TCP/IP models when answering exam or interview questions — know which one is being asked about, since layer numbering doesn’t match up 1:1.
- Assuming ping failures always mean “the network is down.” ICMP can be blocked by a firewall even when the actual service is reachable — always verify with a port-specific test too.
- Forgetting that UDP has no built-in reliability. If you’re building on UDP, your application layer needs to handle retransmission logic itself if reliability matters.
- Overlooking MTU mismatches as a cause of “some sites work, some don’t” symptoms, especially over VPNs.
- Treating private IP addresses as inherently secure. NAT is not a security feature by itself — it just hides addressing, it doesn’t authenticate or encrypt anything.
- Not distinguishing between “connection refused” and “connection timed out” — the former usually means the port is closed but reachable; the latter usually means a firewall is silently dropping the traffic, or the host is unreachable entirely.
- Assuming DNS issues are always server-side. Often it’s a local resolver cache or a misconfigured
/etc/resolv.conf/ DNS client setting.
Printable Quick-Reference Summary
TCP/IP MODEL — QUICK REFERENCE
LAYER 4: APPLICATION
Protocols: HTTP(S), FTP, SSH, DNS, SMTP, IMAP, DHCP
Job: User-facing services, data formatting
LAYER 3: TRANSPORT
Protocols: TCP (reliable), UDP (fast, no guarantee)
Job: End-to-end delivery, ports, flow control
Handshake: SYN -> SYN-ACK -> ACK
LAYER 2: INTERNET
Protocols: IP, ICMP, ARP, IGMP
Job: Logical addressing, routing
LAYER 1: NETWORK ACCESS
Protocols: Ethernet, Wi-Fi, PPP
Job: Physical transmission, MAC addressing, framing
ENCAPSULATION ORDER (sending):
Data -> Segment -> Packet -> Frame -> Bits
KEY COMMANDS:
ping, traceroute/tracert, nslookup/dig, netstat/ss,
ipconfig/ip addr, arp -a, curl -I, telnet/nc
KEY PORTS:
20/21 FTP | 22 SSH | 23 Telnet | 25 SMTP | 53 DNS
67/68 DHCP | 80 HTTP | 110 POP3 | 143 IMAP | 443 HTTPS
Official Documentation and Further Reading
- RFC 1122 – Requirements for Internet Hosts
- RFC 793 – Transmission Control Protocol
- RFC 791 – Internet Protocol
- RFC 768 – User Datagram Protocol
- IANA Service Name and Port Number Registry
- Cisco Networking Basics Documentation
I hope this cheat sheet saves you the back-and-forth searching I used to do when I was first learning this stuff. Keep it handy for exam prep, interview practice, or the next time a production issue has you questioning whether the problem is DNS (it’s usually DNS).