Show understanding of protocols (HTTP, FTP, POP3, IMAP, SMTP, BitTorrent) and their purposes

Cambridge A‑Level Computer Science (9618) – Topic 14.1 : Protocols (HTTP, FTP, POP3, IMAP, SMTP, BitTorrent)

1. Learning outcomes (mapped to Assessment Objectives)

• AO1 – Knowledge & understanding: Identify the purpose, typical ports, transport protocol, OSI/TCP‑IP layer and security features of each protocol.
• AO2 – Application of knowledge: Analyse a given scenario, select the most appropriate protocol and justify the choice (e.g., security, state‑management, performance).
• AO3 – Design, development & evaluation: Design a simple client‑server (or peer‑to‑peer) interaction using one of the protocols, implement a short program, and evaluate its strengths and weaknesses.

---

2. Syllabus checklist – have we covered everything?

Syllabus section (AS & A‑Level)	What the syllabus expects	Covered in these notes?
14.1 – Protocols (application layer)	Identify purpose, ports, transport, state‑management and security of HTTP, FTP, POP3, IMAP, SMTP, BitTorrent.	✓
13 – Data representation & file organisation (relevant to email & file transfer)	Explain how binary data is encoded for transmission (e.g., MIME, Base‑64).	✓ (see §5)
15 – System software (socket API, OS networking stack)	Describe how protocols are implemented using sockets and the role of the OS.	✓ (briefly in §3)
16 – Security	Identify encryption methods (TLS/SSL, FTPS, SFTP, POP3S, IMAPS, STARTTLS) and discuss their impact.	✓ (throughout)
17 – Networks (OSI/TCP‑IP model)	Place each protocol in the correct layer(s) and relate to transport mechanisms.	✓ (see §3)
Programming (Paper 4)	Write, test and evaluate a small program that uses one of the protocols.	✓ (see §6)

---

3. Where the protocols sit in the network model

OSI layer	TCP‑IP equivalent	Application‑layer protocols covered
7 – Application	Application	HTTP, FTP, POP3, IMAP, SMTP, BitTorrent, DNS, SSH
4 – Transport	Transport	TCP (reliable) – used by all except BitTorrent’s DHT (UDP)
3 – Network	Internet	IP (v4/v6)
2 – Data link	Link	Ethernet, Wi‑Fi (IEEE 802.11)
1 – Physical	Physical	Copper, fibre, wireless radio

All six protocols operate at the **Application layer**; they depend on TCP for reliable delivery (BitTorrent also uses UDP for its Distributed Hash Table).

---

4. Protocol summary (AO1 quick‑reference)

Protocol	Purpose	Typical port(s)	Transport	Model	State‑management	Security (default / recommended)
HTTP	Web resource retrieval (HTML, JSON, images …)	80 / 443 (HTTPS)	TCP	Client‑Server request/response	Stateless per request (cookies optional)	None → HTTPS (TLS) for confidentiality & integrity
FTP	Upload & download files	21 (control) / 20 (active data) or high ports (passive)	TCP (control + data)	Client‑Server (separate channels)	Stateful session (login, cwd, etc.)	None → FTPS (explicit/implicit TLS) or SFTP (SSH)
POP3	Retrieve mail, usually deleting after download	110 / 995 (POP3S)	TCP	Client‑Server	Stateless after each message retrieval	None → POP3S (TLS)
IMAP	Access & manipulate mail stored on a server	143 / 993 (IMAPS)	TCP	Client‑Server	Stateful (selected mailbox, flags, UID‑validity)	None → IMAPS (TLS)
SMTP	Send mail (client‑to‑server & server‑to‑server)	25 (MX), 587 (submission), 465 (SMTPS)	TCP	Client‑Server (relay)	Stateless per message transaction	None → STARTTLS or SMTPS (TLS)
BitTorrent	Distribute large files via a peer‑to‑peer swarm	6881‑6889 (default) or any high port	TCP (piece exchange) + UDP (DHT, trackerless)	Peer‑to‑Peer (swarm)	Stateful connections to many peers	None → optional protocol‑level encryption or VPN

---

5. Depth boxes – AO1, AO2 & AO3 for each protocol

5.1 HTTP – HyperText Transfer Protocol

5.2 FTP – File Transfer Protocol

5.3 POP3 – Post Office Protocol version 3

5.4 IMAP – Internet Message Access Protocol

5.5 SMTP – Simple Mail Transfer Protocol

5.6 BitTorrent – Peer‑to‑Peer file distribution

---

6. Detailed protocol descriptions (expanded AO1)

6.1 HTTP – request/response walk‑through

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

<empty line>

Server response (simplified):

HTTP/1.1 200 OK
Date: Sun, 04 Jan 2026 12:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1024

<!DOCTYPE html>
<html> … </html>

Key points:

• Header fields are case‑insensitive and end with \r.
• Message body length is indicated by Content‑Length or Transfer‑Encoding: chunked.
• HTTPS adds a TLS handshake before the HTTP request.

6.2 FTP – active vs. passive data connections

1. Active mode (client behind no firewall):
   • Client sends PORT h1,h2,h3,h4,p1,p2 (its IP + high‑port).
   • Server opens data connection from port 20 to the client’s specified port.
2. Passive mode (client behind firewall/NAT):
   • Client sends PASV.
   • Server replies with 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
   • Client initiates TCP connection to the supplied IP/port.

Encryption options:

• FTPS (explicit): client sends AUTH TLS on the control channel (still port 21).
• SFTP: separate protocol over SSH (port 22), not FTP‑compatible but often taught together.

6.3 POP3 – session example (plain)

+OK POP3 server ready
USER alice
+OK password required
PASS secret
+OK maildrop has 3 messages (12345 octets)
STAT
+OK 3 12345
LIST
+OK 3 messages:
1 4000
2 3500
3 4850
.
RETR 1
+OK 4000 octets
[message data]
.
DELE 1
+OK message 1 deleted
QUIT
+OK goodbye

6.4 IMAP – stateful example (TLS on port 993)

a LOGIN alice secret
b SELECT INBOX
c FETCH 2 (FLAGS BODY[HEADER.FIELDS (FROM SUBJECT DATE)])
d STORE 2 +FLAGS \Seen
e LOGOUT

Responses are prefixed with the same tag (a, b, …) so the client can match them with commands.

6.5 SMTP – extended transaction with authentication

EHLO client.example.com
250‑client.example.com Hello
250‑STARTTLS
250‑AUTH PLAIN LOGIN
STARTTLS
[TLS handshake]
EHLO client.example.com
AUTH LOGIN
334 VXNlcm5hbWU6
YWxpY2U=          (base64 “alice”)
334 UGFzc3dvcmQ6
c2VjcmV0          (base64 “secret”)
235 2.7.0 Authentication successful
MAIL FROM:<alice@client.example.com>
250 2.1.0 OK
RCPT TO:<bob@server.org>
250 2.1.5 OK
DATA
354 End data with <CRLF>.<CRLF>
Subject: Test mail
From: Alice <alice@client.example.com>
To: Bob <bob@server.org>

Hello Bob,
This is a test.
.
250 2.0.0 OK: queued as 12345
QUIT
221 2.0.0 Bye

6.6 BitTorrent – piece request/response cycle

1. Client contacts tracker (HTTP GET) → receives list of peers.
2. Client establishes TCP connections to a subset of peers.
3. Client sends request message: piece index, begin offset, length.
4. Peer replies with piece message containing the raw data.
5. Client verifies the SHA‑1 hash of the piece; if correct, marks it as “have”.
6. Client then “unchokes” other peers, allowing them to request pieces in return.

Optional encryption (protocol‑level) masks the payload to avoid ISP throttling.

---

7. Comparative overview (quick revision)

Aspect	HTTP	FTP	POP3	IMAP	SMTP	BitTorrent
Primary use	Web page & resource retrieval	File upload/download	Email download (delete after)	Email management on server	Email sending (client‑to‑server & server‑to‑server)	Large‑file distribution via swarm
Communication model	Client‑Server request/response	Client‑Server (control + data)	Client‑Server	Client‑Server	Client‑Server (relay)	Peer‑to‑Peer (swarm)
State‑management	Stateless per request	Stateful session	Stateless after each download	Stateful (mailbox, flags)	Stateless per message	Stateful connections to many peers
Transport	TCP (or TLS over TCP)	TCP (control + data)	TCP	TCP	TCP (STARTTLS/SMTPS optional)	TCP (piece exchange) + UDP (DHT)
Typical ports	80 / 443	21 / 20 (active) or high (passive)	110 / 995	143 / 993	25 / 587 / 465	6881‑6889 (default) or any high port
Default security	None → HTTPS (TLS)	None → FTPS / SFTP	None → POP3S (TLS)	None → IMAPS (TLS)	None → STARTTLS / SMTPS (TLS)	None → optional encryption or VPN

---

8. Practical activity (Paper 4 – Programming)

Task: Write a short program that demonstrates a real‑world use of one of the protocols. Choose either HTTP, FTP or SMTP.

8.1 Example – HTTP GET using Python requests

import requests

url = 'https://example.com'
response = requests.get(url)          # HTTPS → TLS encryption
print('Status:', response.status_code)
print('Headers:', response.headers)
print('Body preview:', response.text[:200])

8.2 Extension – FTP download (ftplib)

import ftplib, ssl

host = 'ftp.example.org'
username = 'alice'
password = 'secret'

# Connect in passive mode and enable TLS (FTPS explicit)
ftps = ftplib.FTP_TLS(host)
ftps.login(username, password)
ftps.prot_p()               # Switch data channel to TLS
ftps.cwd('/pub')
filename = 'report.pdf'
with open(filename, 'wb') as f:
    ftps.retrbinary(f'RETR {filename}', f.write)
ftps.quit()

8.3 Extension – SMTP mail (smtplib)

import smtplib, ssl
from email.message import EmailMessage

msg = EmailMessage()
msg['Subject'] = 'Test invoice'
msg['From'] = 'alice@example.com'
msg['To'] = 'bob@client.org'
msg.set_content('Please find the invoice attached.')

smtp_server = 'mail.example.com'
port = 587                     # submission
context = ssl.create_default_context()

with smtplib.SMTP(smtp_server, port) as server:
    server.ehlo()
    server.starttls(context=context)
    server.ehlo()
    server.login('alice@example.com', 'secret')
    server.send_message(msg)

8.4 Test plan (AO3)

Test case	Input	Expected output	Pass/Fail criteria
HTTP – valid URL	https://example.com	Status 200, body contains “”	Pass if status 200 and body preview length > 50
FTP – correct credentials	user/pass, existing file	File saved locally, size matches server	Pass if file size diff < 1 %
SMTP – authentication failure	wrong password	SMTP 535 error	Pass if exception raised and error code captured

8.5 Evaluation prompts (AO3)

• How does TLS affect latency for each protocol?
• What are the security risks of using the plain version?
• Which protocol required the most code to achieve a secure connection?
• How would you adapt the program for batch processing (e.g., multiple files or emails)?

---

9. Linking protocols to the wider A‑Level syllabus

• 13 – Data representation & file organisation: MIME types for email (SMTP/POP3/IMAP) and Base‑64 encoding for binary attachment transfer.
• 15 – System software: Socket API (e.g., socket(), connect(), listen()) underpins all six protocols; OS networking stack handles TCP/UDP multiplexing.
• 16 – Security: Comparison of encryption mechanisms (TLS, SSH, VPN) and discussion of confidentiality, integrity and authentication for each protocol.
• 17 – Networks: Mapping of protocols to OSI/TCP‑IP layers reinforces understanding of layered architecture.
• Paper 4 – Programming: The practical activity satisfies the requirement to design, implement and evaluate a small networked application.

---

10. Action‑oriented review of the lecture notes (relative to the Cambridge International AS & A Level Computer Science 9618 syllabus – 2026)

Area of focus	What the syllabus requires	Typical short‑falls in classroom notes	Concrete suggestions to bring the notes into line
Coverage of all required topics	Every sub‑topic listed in the syllabus (e.g., “Binary‑coded decimal”, “Compression”, “Security & privacy”, “Ethics & ownership”, A‑Level extensions such as floating‑point representation, RISC vs CISC, AI – graphs & neural nets, exception handling).	Often only the core protocols are mentioned; peripheral topics like compression or ethical issues are omitted.	Insert a checklist slide at the start of each chapter mapping headings to exact syllabus items; add a 5‑minute “gap‑filler” box for any missing sub‑item with definition, key properties and an exam‑style question.
Depth and accuracy (AO1‑AO3)	AO1 – factual knowledge; AO2 – analysis/application; AO3 – design, programming, evaluation.	Notes give high‑level over‑views but lack algorithmic detail, pseudo‑code, or state‑transition diagrams required for AO2/AO3.	For every protocol include a “Depth Box” (as shown in Section 5) that separates AO1 facts, AO2 decision‑making flowcharts, and AO3 design/implementation activities. Verify terminology against the official syllabus glossary.
Use of correct terminology	Distinguish clearly between TCP, IP, UDP, TLS, SSL, FTPS, SFTP, etc.	Occasional conflation of “TCP” with “IP” or omission of “TLS vs. SSL”.	Provide a glossary table (Appendix A) and colour‑code terms in the notes (e.g., transport = blue, security = red).
Practical programming links	Paper 4 requires a short program that uses a protocol, a test plan and evaluation.	Only a single HTTP example is usually given.	Expand the practical activity to include FTP and SMTP alternatives (see Section 8) and supply a template test‑plan table.
Linking to other syllabus areas	Show how protocols relate to data representation, system software, security and networks.	Connections are mentioned in passing or omitted.	Add a “Linkage” subsection after each protocol (e.g., MIME for email, socket API for implementation, TLS for security) as done in Section 9.

---

11. Appendix A – Quick glossary (key terms)

• TCP (Transmission