TCP, UDP, checksums and application protocols
Priority key · Priorities guide emphasis; they do not remove taught scope.
TCP and UDP from first principles priority/high
IP can route packets but does not promise that every packet arrives once and in order. The transport layer determines how applications deal with that delivery problem. TCP builds a reliable ordered byte stream over it; UDP supplies individual datagrams with fewer built-in delivery mechanisms.
Both are transport protocols and use port numbers to distinguish application endpoints. IP handles routing; the transport protocol determines additional delivery behaviour.
| TCP | UDP |
|---|---|
| Connection-oriented: establishes state before transferring ordinary application data | Connectionless datagrams; no TCP-style handshake |
| Reliable, ordered byte stream using sequence information, acknowledgements and retransmissions | Does not itself guarantee delivery, order or duplicate suppression |
| Flow/congestion control and greater protocol overhead | Smaller protocol overhead; the application decides what recovery is needed |
| Appropriate when complete ordered data matters, such as a file download | Appropriate for some time-sensitive traffic where waiting for old lost data is undesirable |
UDP is not universally “faster” and TCP is not selected because a file is large. Explain the application’s tolerance for loss, delay and ordering. Applications can add reliability above UDP.
Choose by the required delivery behaviour, not by “large file versus small file”. A tiny but critical message may need reliability; a large live stream may value timeliness over waiting for old data.
TCP establishment and reliability priority/high
The three-way handshake, with example initial sequence values x and y:
Client → Server: SYN, sequence x
Server → Client: SYN + ACK, sequence y, acknowledgement x+1
Client → Server: ACK, acknowledgement y+1This exchanges and acknowledges initial sequence information and establishes connection state at both ends. Do not describe the second message as only ACK; it also carries the server’s SYN.
Sequence numbers identify positions in the byte stream. An acknowledgement commonly indicates the next byte expected. If bytes numbered 100–149 arrive contiguously, the next expected number is 150. Lost/unacknowledged data can be retransmitted; received data can be ordered and duplicates recognised. The receive window supports flow control so the sender does not overwhelm the receiver. Connection establishment alone does not guarantee that every later packet succeeds. TCP specification, RFC9293.
Error detection priority/high
Separate three failure questions: Did any data arrive? (loss), is its content corrupted? (checksum), and is it the next data required? (sequence/order). The mechanisms answer different questions; a checksum alone cannot recover a missing packet or put segments in order.
A checksum is calculated from data/control fields and checked by the receiver to detect corruption. If a check fails, the unit may be discarded and a reliable protocol may arrange retransmission. A checksum is not a correction code and cannot guarantee detection of every possible error. A parity bit makes the number of 1 bits even or odd as specified; a single parity bit detects an odd number of flipped bits but can miss an even number. Distinguish bit corruption from packet loss: there may be nothing received on which to recompute a checksum.
Calculate the taught one’s-complement checksum priority/high
Split into the specified fixed-width words, add them, wrap any carry beyond the word width back into the low bits, then complement every bit. At the receiver, add all words including the checksum using the same arithmetic: an all-ones sum, or all-zero result after complementing, passes this check.
Small 4-bit illustration: 1101 + 1011 = 11000. Wrap the carry: 1000 + 1 = 1001. Complement gives checksum 0110. Receiver adds 1101 + 1011 + 0110 = 11110, wraps to 1110 + 1 = 1111, then complements to 0000. Real Internet checksum words are 16 bits; use the width specified in the question. IPv4’s header checksum covers its header, while TCP/UDP checksums also cover transport data and a pseudoheader.
Source: Network4, PDF p.6. “Accept” means the check did not detect corruption, not that every possible error is ruled out.
TCP termination priority/medium
Normal orderly closing can be shown as FIN → ACK → FIN → ACK, because each direction closes separately. One endpoint may finish sending while still receiving (half-close). If the other endpoint is ready to close too, its ACK and FIN can be combined, giving FIN → FIN+ACK → ACK. These are closing messages, distinct from SYN-based establishment. The acknowledgement of a FIN advances past its sequence position; label sequence and acknowledgement numbers separately.
Application protocols and address support priority/high
flowchart LR A[Join a network] -->|DHCP supplies configuration| B[Know local IP and gateway] B -->|DNS resolves server name| C[Know server address] C -->|Transport and routing deliver messages| D[HTTP request and response]
This is a conceptual path, not a rule that every request repeats DHCP and DNS; existing leases and cached DNS answers can be reused.
| Protocol | Purpose and usual exam distinction |
|---|---|
| HTTP / HTTPS | Request/response for web resources; HTTPS protects HTTP using TLS. |
| DNS | Resolves domain names to records such as IP addresses; caching reduces repeated queries. It does not allocate your device’s local IP. |
| DHCP | Supplies address configuration such as IP, subnet mask, gateway and DNS-server information. |
| SMTP | Sends/submits and relays email. |
| POP3 | Retrieves email, often with a download-oriented model; deletion depends on client settings. |
| IMAP | Accesses/manages mailbox state on the server, supporting synchronisation across clients. |
| FTP | Transfers files; ordinary FTP is not encrypted merely because it transfers a file. |
Conventional service ports: HTTP 80, HTTPS 443, SMTP relay 25, POP3 110, IMAP 143, FTP control 21 (active-mode data commonly 20), DNS 53, DHCP server 67/client 68. Ports are configurable and secure variants use other ports; match the version specified. DNS commonly uses UDP for ordinary queries and can also use TCP.
For DNS, the client asks a resolver. A valid cached answer can be reused; otherwise the resolver can consult the hierarchy, using root and top-level-domain servers to locate the authoritative name server. That server supplies the relevant records, which the resolver returns and may cache subject to their lifetime. A referral is not necessarily the final website IP.
DHCP dynamic allocation leases an address temporarily from a pool; a reservation/manual allocation associates a particular client with a chosen address. The simplified initial exchange is Discover → Offer → Request → Acknowledge: the client searches, a server offers configuration, the client requests an offer, and the server confirms the lease. Do not confuse this four-message exchange with TCP’s handshake.
A typical web path: obtain configuration → resolve the domain through DNS (possibly from cache) → route traffic towards the server → establish required transport/security → send the HTTP request → receive the response. Details depend on the protocol version; use the simplified TCP-based model when the question specifies it.
Worked example — original
A file download must reproduce every byte in order. TCP suits it because acknowledgement/retransmission and sequencing support reliable ordered delivery. A live voice application may prefer UDP because a late retransmission of an old audio segment may be less useful than continuing playback; the application must tolerate or manage loss. This is a requirements-based answer, not a memorised list of applications.
Practice
Exam focus: TCP/UDP and handshake questions occur in HCI 2023 Q1,2024 Q1 and 2025 Q2. HCI 2024 Q2 explicitly asks for DNS and DHCP’s allocation/lease process. The original 2024 Q1–2, PDF p.2 provides a useful combined question set. Checksum calculation is included because it is taught, not because its absence from those questions removes it.
Answering approach: name the mechanism → describe its action → explain how that action meets the requirement. For handshake diagrams, label direction and distinguish sequence from acknowledgement fields. For a checksum, show the carry wrap and complement instead of writing only the final bits.
11A — adapted from HCI 2024 Q1 and HCI 2025 Q2. Compare TCP and UDP on connection establishment and reliability. Write the three TCP handshake messages and explain what an acknowledgement of 801 means in a byte-stream example.
11B — adapted from HCI 2024 Q2. A new laptop joins a LAN and opens a website by domain name. Explain DHCP’s role and four-message exchange, then DNS’s role. Explain why “DNS gives the laptop its own leased IP address” is wrong.
Hints
11A: “801” is the next expected byte, not a count of successfully received packets. 11B: configuration and name resolution are different tasks.
Revision checklist
Tick an item only after demonstrating it without notes. For coding items, write or trace the solution and test relevant boundary cases.
- 11.1 Compare TCP and UDP by service guarantees, overhead and application needs.
- 11.2 Draw and explain the TCP three-way handshake with distinct sequence and acknowledgement fields.
- 11.3 Explain acknowledgements, sequence numbers, retransmissions, flow control and ordered delivery.
- 11.4 Calculate or trace a checksum using the procedure taught; explain its detection limits.
- 11.5 Explain connection termination in the form taught and recognise combined versus separate ACK/FIN messages.
- 11.6 Explain DNS resolution including the roles of client, resolver, cache and name servers at the taught level.
- 11.7 Explain DHCP allocation and the four-step lease exchange taught.
- 11.8 State the purposes and taught ports of HTTP/HTTPS, SMTP, POP3/IMAP, FTP, DNS and DHCP.
- 11.9 Trace a basic web request and distinguish sending email from retrieving it.
- 11.10 Apply any parity/error-detection method actually taught, keeping it separate from check-digit input validation.
Your mindmap framework
Use the following as branch labels. Add your own explanations, diagrams and examples; the framework deliberately leaves those blank.
- Transport → TCP / UDP / ports / suitability
- TCP lifecycle → establish / transfer reliably / close
- Error detection → checksum / method / limitations
- Application → DNS / DHCP / web / email / file transfer
- End-to-end scenario → lookup / connect / request / response
Source trail
School Network4–5; 9569 §§4.1.2–4.1.5.
HCI 2022 Q1(b), Q4(b–c); 2023 Q1, Q2(b); 2024 Q1(c), Q2; 2025 Q2(c–d).
Source guide records provenance and original-paper locations.