You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
The TCP/IP model (also called the Internet Protocol Suite) is the layered architecture that underpins all communication on the Internet. Rather than solving the enormous problem of "make any application on any machine talk to any other machine anywhere" in one go, TCP/IP splits it into four cooperating layers, each responsible for one well-defined job and each speaking only to the layers directly above and below it.
At A-Level you must know the four layers and their functions, the key protocols at each layer, and — most importantly — how data is encapsulated as it passes down the stack at the sender and de-encapsulated as it passes up the stack at the receiver. You should also be confident on ports and sockets, which are how a single host directs incoming data to the correct application.
The "TCP/IP" name is a little misleading: although TCP and IP are its two most famous protocols, the suite contains dozens of protocols spread across the four layers. The name simply honours the two that do the heavy lifting of reliable transport (TCP) and internetwork addressing/routing (IP). Throughout this lesson, keep asking of any protocol: which layer does it sit at, and what concern does that layer handle? — that single habit makes the whole topic coherent.
This lesson addresses the Communication and networking area of the AQA A-Level Computer Science (7517) specification, specifically the content on the TCP/IP protocol stack. It covers the four-layer model (application, transport, network/internet, and link), the role and responsibility of each layer, the principal protocols operating at each, the process of encapsulation as data descends the stack, and the use of ports and sockets to identify endpoints. It builds directly on the communication methods content (the link layer) and feeds into the network protocols and IP addressing content.
Layered models break the complex task of communication into smaller, manageable sub-tasks. The benefits are worth stating precisely because they are frequently examined:
To see modularity concretely: when you carry a laptop from a wired desk to a Wi-Fi café, only the link layer changes — Ethernet becomes 802.11. Everything above (your IP-based connections, your TCP sessions, your browser's HTTP) is unaffected because each layer presents the same interface to the one above regardless of how it does its own job. That clean separation is the entire payoff of layering, and it is why the model has survived decades of changing physical technologies.
flowchart TB
A["Layer 4 — Application<br/>(HTTP, FTP, SMTP, DNS, ...)"]
T["Layer 3 — Transport<br/>(TCP, UDP)"]
N["Layer 2 — Network / Internet<br/>(IP, ICMP, ARP)"]
L["Layer 1 — Link / Network Interface<br/>(Ethernet, Wi-Fi)"]
A --> T --> N --> L
L --> N --> T --> A
| Layer | Name | Function | Key Protocols |
|---|---|---|---|
| 4 | Application | Provides network services directly to user applications | HTTP, HTTPS, FTP, SMTP, POP3, IMAP, DNS, DHCP, SSH |
| 3 | Transport | End-to-end communication, segmentation, ports, flow control, error recovery | TCP, UDP |
| 2 | Network / Internet | Logical addressing and routing of packets across networks | IP (IPv4, IPv6), ICMP, ARP |
| 1 | Link (Network Interface) | Physical addressing, framing, transmission over the physical medium | Ethernet, Wi-Fi (802.11) |
The application layer is where user-facing network services operate. It defines the protocols that applications use to format and exchange their data. It does not worry about how the data crosses the network — that is delegated downwards. A web browser, for instance, knows how to phrase an HTTP request and interpret the response, but it has no idea whether the bits will travel over Wi-Fi, Ethernet or a mobile connection; it simply hands its message to the transport layer and trusts the layers beneath to deliver it.
| Protocol | Purpose |
|---|---|
| HTTP / HTTPS | Web page requests and responses (HTTPS adds encryption via TLS) |
| FTP | File transfer between client and server |
| SMTP | Sending email |
| POP3 / IMAP | Retrieving email |
| DNS | Resolving domain names to IP addresses |
| DHCP | Automatically assigning IP configuration to devices |
| SSH | Secure remote terminal access |
Note that the application layer in the four-layer TCP/IP model absorbs the work that the seven-layer OSI model would spread across its application, presentation and session layers. AQA's specification uses the four-layer model, so treat the application layer as the single top layer where named protocols like HTTP and SMTP live.
The transport layer provides end-to-end communication between processes (applications) on different hosts. It takes the application's data, breaks it into manageable pieces, attaches a header carrying port numbers (so the data reaches the right application), and — for TCP — manages reliable, ordered delivery. The choice made at this layer — TCP or UDP — is one of the most consequential in networking, because it determines whether the application gets reliability and ordering or raw speed, and the layers above and below are unaffected by it.
| Feature | Detail |
|---|---|
| Connection | Connection-oriented — establishes a connection first via the three-way handshake (SYN → SYN-ACK → ACK) |
| Reliability | Guaranteed delivery — uses acknowledgements (ACKs) and retransmission of lost segments |
| Ordering | Segments are numbered, so data is reassembled in the correct order |
| Flow control | Uses a sliding window to stop a fast sender overwhelming a slow receiver |
| Error checking | A checksum detects corrupted segments |
| Use | Web, email, file transfer — anything needing reliable delivery |
| Feature | Detail |
|---|---|
| Connection | Connectionless — no handshake, datagrams sent immediately |
| Reliability | No guarantee — no ACKs, no retransmission |
| Ordering | None — datagrams may arrive out of order |
| Flow control | None |
| Error checking | Optional checksum only |
| Use | Live streaming, VoIP, online gaming, DNS queries — speed/low latency over reliability |
| Feature | TCP | UDP |
|---|---|---|
| Connection | Connection-oriented | Connectionless |
| Reliability | Reliable (ACKs + retransmit) | Unreliable (best effort) |
| Ordering | Ordered (sequence numbers) | Unordered |
| Speed/overhead | Slower, higher overhead | Faster, minimal overhead |
| Header size | 20+ bytes | 8 bytes |
Exam Tip: When comparing TCP and UDP, always pair each with a justified use-case. TCP for reliable delivery (a web page must arrive complete and in order); UDP for low latency where the odd lost packet does not matter (a dropped frame in a live video is better than a stall while it is retransmitted). Examiners award marks for the reasoning, not just the label.
TCP's promise of reliable, ordered delivery rests on three mechanisms working together, and being able to describe them earns marks at the top band:
// 1. Establish the connection — the three-way handshake
Client -> Server : SYN (I want to talk; my sequence number is X)
Server -> Client : SYN-ACK (OK; I acknowledge X, my sequence number is Y)
Client -> Server : ACK (I acknowledge Y; connection is open)
// 2. Reliable, ordered transfer
// Each segment carries a sequence number. The receiver returns an
// ACK for data it has received. If the sender gets no ACK within a
// timeout, it RETRANSMITS the segment. Sequence numbers let the
// receiver reorder segments that arrive out of order and discard
// duplicates.
// 3. Flow control via a sliding window
// The receiver advertises a 'window' = how much data it can currently
// buffer. The sender may have at most that much unacknowledged data
// in flight, preventing a fast sender swamping a slow receiver.
The three-way handshake (SYN → SYN-ACK → ACK) synchronises sequence numbers and confirms both ends are ready before any data flows — this is what makes TCP "connection-oriented". Acknowledgements and retransmission provide reliability: anything not acknowledged is sent again. Sequence numbers provide ordering and duplicate detection. The sliding window provides flow control. UDP has none of these — it simply fires datagrams and forgets them, which is precisely why it is faster but unreliable.
The network (internet) layer handles logical addressing (IP addresses) and routing — choosing a path for packets across many interconnected networks.
| Protocol | Purpose |
|---|---|
| ICMP | Error reporting and diagnostics (e.g. the messages behind ping) |
| ARP | Resolves an IP address to a MAC (physical) address on the local network |
The link layer handles the physical transmission of data over the medium (copper, fibre, radio). It deals with:
A crucial distinction: MAC addresses are local and unchanging per interface; IP addresses are logical and used for routing across networks. As a packet travels, the destination IP stays the same end to end, but the source/destination MAC addresses are rewritten at every hop.
This IP/MAC interplay is best seen as a journey. Suppose host A (192.168.0.5) sends a packet to a distant server (93.184.216.34):
1. A compares the destination IP to its own network using its subnet mask.
The server is NOT on A's local network, so A must send the packet to
its DEFAULT GATEWAY (its router).
2. A uses ARP to find the MAC address of the gateway, then builds a frame:
- destination IP = 93.184.216.34 (unchanged, the final target)
- destination MAC = the GATEWAY's MAC (the next hop only)
3. The router receives the frame, strips the link-layer header, reads the
destination IP, consults its routing table, and decides the next hop.
It builds a NEW frame with a NEW destination MAC (the next router) but
the SAME destination IP, and forwards it.
4. Step 3 repeats router by router across the internet, the destination IP
staying constant while the MAC addresses change at every hop, until the
packet reaches the server's local network and is delivered to it.
The lesson: the destination IP address is the end-to-end address (where the packet is ultimately going), whereas the destination MAC address only ever names the next hop on the current physical link. This is why routing is a network-layer job and framing is a link-layer job — and exactly the kind of distinction that separates top-band answers.
It can seem odd that the protocol at the heart of the internet does not guarantee delivery. The design is deliberate: keeping IP simple and stateless lets routers forward packets extremely fast without tracking every conversation, and it lets the network reroute around failures freely. Reliability is layered on top (by TCP) only for the applications that need it, while applications that prefer speed (over UDP) are not burdened with it. This separation of concerns — dumb, fast core; smart endpoints — is a defining principle of the internet's architecture.
As data moves down the stack at the sender, each layer wraps the data from the layer above by adding its own header (and, at the link layer, a trailer). This is encapsulation. At the receiver the reverse happens — each layer strips off and reads its own header — which is de-encapsulation.
Consider a browser sending the text of an HTTP request:
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.