Every protocol behaviour on this page is stated against the document that defines it — the current IETF RFC — and every port number against the IANA service-name registry, not against memory.
Read the vocabulary first; every term used on this page is defined there before it is used. Study the worked example, then cover it and work the numbered exercises. Do not open the solutions until you have written a real attempt.
Many course materials still cite RFC 2616 for HTTP/1.1 and RFC 2821 for SMTP. Both are obsolete. HTTP is now split across RFC 9110 (semantics), 9111 (caching) and 9112 (HTTP/1.1), published June 2022; SMTP is RFC 5321, published 2008. Nothing taught at the level of this page changed — the methods, the status codes and the command sequences are the same — so an older citation is not a wrong answer, just an old one. This site cites the current documents and says so when it departs from a common teaching convention.
The one idea everything hangs on#
Suppose you write a chat app. You write two programs: one that runs on a phone and one that runs on a server. You do not write anything that runs on the routers and switches in between, and you could not if you wanted to.
That is not a simplification for beginners. It is how the Internet is built. Devices in the network core move packets and do not run user applications. Application code lives only on end systems — the hosts at the edge.
Applications run on end systems, never in the network core. That is why a new application can spread across the whole Internet in a week: nothing in the middle has to be changed, upgraded, or even told that it exists.
Every other idea on this page is a consequence. If the application exists only at the edges, then the two edges have to agree on what to say to each other — a protocol. The operating system has to know which of the many programs on a host a message is for — a port. And the application has to decide what it wants from the transport layer underneath it — TCP or UDP.
Vocabulary, before anything uses it#
One sentence each. Read them now; the rest of the page assumes them.
| Term | What it means |
|---|---|
| End system | Any device at the edge of the network that runs applications — a laptop, a phone, a server. |
| Network core | The routers and switches in the middle, which forward packets and do not run user applications. |
| Process | A program while it is actually running on a host. |
| Client process | The process that starts a conversation. |
| Server process | The process that is already running and waits to be contacted. |
| Socket | The doorway between a process and the network, through which it hands messages out and takes them in. |
| Port number | A 16-bit number identifying which process on a host a message is for. |
| IP address | The number identifying a host on the Internet — 32 bits in IPv4, 128 bits in IPv6. |
| Application-layer protocol | The agreed rules for the messages two application processes exchange. |
| Open protocol | A protocol whose definition is published, so anyone can write an implementation that interoperates. |
| Proprietary protocol | A protocol controlled by one vendor and not published for others to implement. |
| RFC | A numbered document published by the IETF; the ones that define protocols are where an open protocol is written down. |
| Client-server architecture | A shape in which an always-on server is contacted by clients that never contact each other. |
| Peer-to-peer (P2P) | A shape in which end systems talk directly to one another, each both requesting and providing service. |
| Self-scalability | The property of P2P that each new peer brings service capacity as well as service demand. |
| Reliable data transfer | A guarantee that everything sent arrives, uncorrupted and in order. |
| Flow control | Stopping a fast sender from overwhelming a slow receiver. |
| Congestion control | Slowing a sender down when the network itself is overloaded. |
| Connection-oriented | Requiring a handshake that sets up state at both ends before any data is sent. |
| Elastic application | An application that works at whatever throughput it is given, just faster or slower. |
| Loss-tolerant application | An application that still functions usefully when some data never arrives. |
An application is not a protocol. The Web is an application; HTTP is the protocol it speaks. Email is an application; SMTP, POP3 and IMAP are protocols it speaks. When a question asks you to pair them, the left column is what a person is doing and the right column is the named, written-down set of rules for doing it.
An application-layer protocol is not a transport protocol. TCP and UDP sit one layer down and are never the answer to “which application-layer protocol?” — they are what application-layer protocols run on top of.
Client-server and peer-to-peer#
An application can take one of two shapes, and the difference comes down to where the always-on machine is — or whether there is one at all.
| Client-server | Peer-to-peer | |
|---|---|---|
| Always-on host | Yes — the server | No |
| Who talks to whom | Clients talk to the server, never to each other | Peers talk directly to peers |
| Addressing | The server needs a permanent, well-known IP address | Peers may have changing IP addresses |
| Availability | Clients may be intermittently connected | Peers are intermittently connected |
| Scaling | Add servers — data centres exist for exactly this | Self-scaling: each new peer adds capacity |
| Management | Simple — one place to look | Complex — no single point of control |
The Web is client-server: your browser is a client, a web server is a server, and two browsers never fetch pages from each other. BitTorrent is peer-to-peer: the machine downloading a file is simultaneously uploading pieces of it to strangers.
Self-scalability is the one genuine advantage of P2P worth naming in an answer. In client-server, ten times the users means ten times the load on the same server. In P2P, ten times the peers means ten times the demand and ten times the capacity, because every new peer arrives carrying an upload link of its own.
The two shapes are not mutually exclusive. A P2P application still contains client processes and server processes: in any single exchange, the peer that starts it is acting as the client and the peer that answers is acting as the server. Client and server describe roles in one conversation, not permanent identities.
Processes, sockets, and why an IP address is not enough#
Two processes on the same machine can talk through the operating system. Two processes on different machines have exactly one option: exchange messages across the network. Each process reaches the network through a socket — think of it as a door in the wall of the process. The sending process shoves a message out through its door and relies on everything beyond the door to get it to the door of the receiving process.
The application developer controls everything on the near side of the socket. The operating system controls everything on the far side, including which transport protocol is used and how the bytes actually travel. The socket is precisely the line between what you write and what you rely on.
Now the question that appears on nearly every exam. A host has one IP address. Is that enough to identify the process a message is meant for?
No. A single host runs many processes at once — a web server, a mail server and an SSH daemon can all sit on one machine behind one address. The IP address gets the packet to the right host. The port number gets it to the right process on that host. An identifier is both of them together.
Servers listen on well-known ports so that clients know where to knock without being told. These are assigned by IANA and are worth knowing cold:
| Service | Port | Transport |
|---|---|---|
| HTTP | 80 | TCP |
| HTTPS | 443 | TCP |
| SMTP, server to server | 25 | TCP |
| SMTP submission, client to server | 587 | TCP |
| POP3 | 110 | TCP |
| IMAP | 143 | TCP |
| DNS | 53 | UDP, and TCP for large replies |
| SSH | 22 | TCP |
| FTP control connection | 21 | TCP |
The server’s port is fixed; the client’s is not. Your browser does not use port 80. It picks an unused high-numbered ephemeral port for itself and sends to port 80. That is why a capture shows something like 54321 → 80 going out and 80 → 54321 coming back. Expect this on a packet-capture question, where reading the port pair backwards is the standard mistake.
What an application-layer protocol actually defines#
The word “protocol” gets used loosely in conversation. On an exam it has four specific parts, and a complete answer names all of them:
- The types of message exchanged — for example, request and response.
- The syntax of each message: what fields it contains and how those fields are delimited.
- The semantics of each field: what the information in it actually means.
- The rules governing when a process sends a message and how it responds to one it receives.
Open protocols are published, and publication is what makes interoperability possible. Firefox and Apache were written by different people who never met; they work together because both were written against the same public document. Proprietary protocols are controlled by one vendor and not published, so only that vendor’s software speaks them.
Openness is about whether the specification is published, not about whether the software is free. A closed-source browser speaking HTTP is still using an open protocol.
What the application needs, and what TCP and UDP give it#
An application needs some combination of four things from the layer below it. Naming them is half of every transport-choice question:
| Requirement | The question it answers | Something that needs it |
|---|---|---|
| Data integrity | Must every byte arrive, uncorrupted? | File transfer, web pages, email |
| Timing | Must it arrive soon? | Internet telephony, interactive games |
| Throughput | Does it need a guaranteed minimum rate? | Streaming video |
| Security | Must it be encrypted and authenticated? | Anything carrying a password |
And here is what the Internet actually offers. This is a table worth being able to reproduce from memory:
| Service | TCP | UDP |
|---|---|---|
| Reliable data transfer | Yes | No |
| In-order delivery | Yes | No |
| Flow control | Yes | No |
| Congestion control | Yes | No |
| Connection setup | Required | None |
| Timing guarantee | No | No |
| Minimum throughput guarantee | No | No |
| Security | No — TLS adds it separately | No |
Reliability is not speed. TCP guarantees that your bytes arrive, in order. It guarantees nothing about when, and nothing about how much bandwidth you get. Writing “TCP is faster” or “TCP guarantees the data arrives on time” is the most common way to lose the mark here. Notice that the last three rows of the table above are identical in both columns.
Neither one is secure by itself. HTTPS is not a different transport protocol; it is HTTP running over TLS, which runs over TCP. If a question asks what services TCP provides, encryption is not on the list.
So why does UDP exist at all, if it offers strictly less? Because “less” is sometimes exactly right. There is no handshake to wait through before the first byte, no retransmission holding newer data behind older data, no congestion controller throttling you back, and a much smaller header. For a single short query with a single short answer — a DNS lookup — or for live audio where a re-sent packet would arrive too late to play, paying for reliability buys nothing and costs delay.
Worked example#
A messaging application delivers typed messages between users. Messages must never be lost or reordered, but they are short and there is no minimum bandwidth to hit. Name the transport protocol it should use, and justify the choice by service rather than by preference.
Step 1 — List what the application requires. Walk the four requirements in order instead of guessing. Data integrity: yes, a dropped or reordered message is a visible failure to the user. Timing: mild — a delay of a second is tolerable. Throughput: elastic, no minimum. Security: not asked about here.
Step 2 — Match those against what each transport offers. Only one of the two provides reliable, in-order delivery, and reliable in-order delivery is the requirement that made the list.
Needs reliability and ordering → TCP
Step 3 — Name the price and accept it. A complete answer says what is being given up: a connection handshake before the first message, and a congestion controller that will slow the sender when the network is busy. The application accepts both, because a message that silently vanishes is worse than a message that is slightly late.
The requirement named as a service (“reliable, in-order delivery”) rather than as an adjective (“because TCP is better”); the protocol; and the tradeoff accepted in exchange. Three sentences is plenty, as long as all three parts are there.
Practice#
Work all eight before reading anything below them. Write the answers out in sentences — the exam will ask for sentences, and an answer you can only think in fragments is not an answer you have.
- A new application becomes popular worldwide in a month, and not one router is modified. Why is that possible?
- A host with one IP address is running a web server and a mail server. A message arrives for the mail server. What in the message got it to the right one of the two, and why was the IP address not enough?
- Name the four things an application-layer protocol definition specifies.
- Somebody says “we chose TCP because we need messages delivered within 50 milliseconds.” What is wrong with that sentence?
- Give the one real advantage of peer-to-peer over client-server, and name the property.
- A capture shows a segment sent to port 80, and the reply coming from port 80 to port 51488. Which end is the server, and what is port 51488?
- Which of these are application-layer protocols: HTTP, TCP, DNS, UDP, SMTP? Say what the others are instead.
- An application streams live audio and would rather drop a syllable than pause. Which transport should it use, and what specifically is it declining?
Solutions#
If your answer is wrong, do not just read the solution and move on. Find the first sentence where your reasoning diverged from the one below, then redo the problem from that point. The value is in locating the divergence, not in seeing the right answer.
- Applications live at the edge. Because application software runs only on end systems. Routers and switches in the core forward packets and do not run user applications, so nothing in the middle has to know the new application exists.
- The port number, because one host runs many processes. The port number in the transport-layer header. The IP address identifies the host, and a host runs many processes at once, so the address alone cannot say which of them a message belongs to. A process is identified by the IP address and the port number together.
- Message types, syntax, semantics, rules. The types of messages exchanged; the syntax of a message — its fields and how they are delimited; the semantics of those fields, meaning what the values signify; and the rules for when a process sends a message and how it responds to one.
- TCP makes no timing guarantee. TCP provides reliable, in-order delivery, flow control and congestion control. It does not guarantee timing or a minimum throughput. Needing 50 ms delivery is not a reason to pick TCP, because neither Internet transport protocol promises it.
- Self-scalability. Each new peer brings service capacity as well as service demand, so the system scales as it grows instead of loading a fixed set of servers harder. A second acceptable answer: no always-on infrastructure is required.
- Port 80 is the server; 51488 is the client ephemeral port. The end using port 80 is the server, because 80 is the well-known port a web server listens on. Port 51488 is an ephemeral port the client operating system picked for this one connection; it is not fixed and means nothing outside this conversation.
- HTTP, DNS and SMTP. HTTP, DNS and SMTP are application-layer protocols. TCP and UDP are transport-layer protocols — they are what application-layer protocols run on top of, and they are never the answer to an application-layer question.
- UDP, declining reliability. UDP. It is declining reliable delivery, and with it retransmission — which is the point, because a packet re-sent after the moment it should have played is worthless to live audio. It also does without connection setup and congestion control.
Test-readiness checklist#
Tick these honestly. Each one names a thing you can do, not a topic you have seen.
- ☐ I can say why an application can spread across the Internet with no change to the core.
- ☐ I can name the four parts of an application-layer protocol definition without looking.
- ☐ I can explain in one sentence why an IP address alone cannot identify a process.
- ☐ I can write the TCP and UDP service lists side by side and get the timing and throughput rows right.
- ☐ I can give the well-known port for HTTP, HTTPS, SMTP, POP3, IMAP and DNS from memory.
- ☐ I can tell an application apart from the protocol it speaks, in both directions.
- ☐ I can name the one real advantage of P2P and use the word for it.
- ☐ I can read a port pair in a packet capture and say which end is the server.
When a question asks “why this protocol?”, answer with a service — reliable transfer, ordering, flow control, congestion control, connection setup. Never with a comparative adjective. “Because it is more reliable” earns part marks. “Because the application cannot tolerate loss or reordering, and only TCP provides reliable in-order delivery” earns all of them.
Frequently asked questions#
Is TCP an application-layer protocol?
No. TCP and UDP are transport-layer protocols. Application-layer protocols such as HTTP, SMTP and DNS run on top of them. If a question asks for an application-layer protocol and the answer is TCP, the answer is at the wrong layer.
Why is a port number needed if the host already has an IP address?
Because one host runs many processes at once. The IP address delivers the packet to the host; the port number identifies which process on that host it is for. A process is addressed by the two together.
Does TCP guarantee that data arrives quickly?
No. TCP guarantees that data arrives, uncorrupted and in order. It makes no promise about delay and no promise about minimum throughput, and neither does UDP. This is the single most common misstatement on transport-choice questions.
What is the real advantage of peer-to-peer?
Self-scalability. Every new peer brings upload capacity along with its demand, so total capacity grows with the user base instead of concentrating load on a fixed set of servers. The cost is complex management and peers that come and go.
If UDP provides less than TCP, why does anything use it?
Because everything TCP adds costs something. UDP has no connection handshake to wait through, no retransmissions holding newer data behind older data, no congestion controller throttling the sender, and a smaller header. For a single short query and reply, or for live media where a late packet is useless anyway, that trade is worth making.
Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written.
Test yourself in the free Kestrel Exams app
Topic-selectable practice — offline, no ads, no account. A networking question bank is not built yet; every other subject is open.
Choose your subject →