Protocols: The Rules of the Conversation

Protocols: The Rules of the Conversation

What you'll learn

• Define what a protocol is, and the three kinds of information every protocol must specify
• Walk the classic phone-call analogy and map each of its steps onto a real TCP session
• Explain why TCP/IP is called a protocol suite, and place its main members by layer
• Choose between TCP and UDP for a given application, and say why
• Identify three different protocols, by name and by evidence, in your own capture

This lesson builds on Chapter 5 of Dr. Tahseen Al-Doori's Network Essentials, which opens the protocol story that Modules 4 and 5 will finish: ports and applications, the full three-way handshake, DNS and DHCP each get their own lesson later. Today is about the concept that holds them all together.

Why raw data can't just be "sent"

The previous lesson's envelope story answered where questions: an address gets the letter to the right building. But an address is not enough for communication — imagine the letter arrives written in a language the reader doesn't know, with no greeting, no signature, and no way to tell whether pages are missing. Delivery succeeded; communication failed.

For two computers to genuinely communicate, both sides must agree, in advance, on the rules of the exchange. Those agreed rules are a protocol. Every protocol, whatever its purpose, has to answer the same four questions the book poses:

1. Who starts, and how? What does an opening move look like?
2. How does the receiver signal that it is ready — or not ready — to take data?
3. What format is the data in, so the receiver can interpret it?
4. How does everyone know the exchange is over, rather than broken?

Leave any one unanswered and communication collapses: nobody dares speak first, or nobody knows the message ended. Humans improvise around such gaps; computers cannot. A protocol nails every answer down in advance — which is exactly what makes machine communication possible at all.

The phone-call analogy

A classic analogy from Dr. Al-Doori's course asks you to replay an ordinary phone call to a business contact and notice how many rules you follow without thinking.

You dial a specific number — an opening move aimed at one receiver. Their phone rings: the network is asking whether they are ready. They pick up and say "Hello?" — a ready signal, and an invitation. You answer with a greeting and identify yourself — because a voice alone may not be enough. You state why you are calling. The conversation proceeds in turns, with little confirmations ("mm-hm," "right") assuring the speaker they are still being heard. When the business is done, you signal the end — "thanks, that's everything I needed" — and then both of you say goodbye before either hangs up. Hanging up mid-sentence would be a fault in the protocol, and both sides would know it: that is what "getting cut off" means.

Count what just happened: an initiation rule, a readiness rule, an identification rule, turn-taking with acknowledgments, and a two-sided closing rule. You have been executing a full communication protocol since childhood — nobody wrote it down, but everyone agrees on it, and that agreement is the whole point. Computer protocols are the same etiquette with nothing left implicit.

The three ingredients of every protocol

Chapter 5 distills what a written protocol must actually contain, and the list is worth memorizing because you will recognize it in every specification you ever read:

1. The rules — the procedures both sides execute: who sends what, in which situation, in what order. (In software, this is the protocol's logic — its state machine.)
2. The format — the exact syntax of the data: which fields exist, in what order, how many bits each occupies, what the values mean. This is the previous lesson's "header as a small database of fields," seen from the author's side of the desk.
3. The control information — how errors are detected and handled, how timing is managed, how the two sides stay synchronized when packets are lost, duplicated or delayed.

Rules, format, control. When Module 5 shows you a TCP header's sequence numbers, or Module 8 shows a retransmission storm in Wireshark, you are looking at ingredients 2 and 3 doing their jobs.

From phone call to TCP session

Now the payoff: the phone call is a TCP session, step for step. TCP — the Transmission Control Protocol, whose current specification is RFC 9293 — opens every connection with the three-way handshake you have already placed at the transport layer, and its steps map onto your call like this:

Even the failure cases translate. A wrong number — "who is this?" — is a connection refused. A line that goes dead mid-conversation is a timeout: acknowledgments stop arriving, and TCP knows the conversation did not finish properly, exactly as you would. Module 5 opens the hood on sequence numbers, windows and the precise flag mechanics; for now, own the shape: initiate, confirm readiness, exchange with acknowledgment, close from both sides.

A suite of cooperating protocols

No single protocol carries a web page to your screen. A name-lookup protocol finds the server's address, TCP manages reliable delivery, IP routes the packets, Ethernet or Wi-Fi delivers each local hop — different jobs, different rules, one result. A family of protocols designed independently but built to work together is a protocol suite, and the Internet's suite is named after its two stars: TCP/IP. As the previous lesson noted, the name undersells the cast — dozens of protocols cooperate under it, layered exactly where you would now expect:

Note ICMP's row, one more time. The previous lesson corrected a table from the book's Chapter 5 that lists ICMP beside TCP and UDP at the transport layer; you then verified the truth in your own capture — protocol number 1, riding directly inside IP, no ports. Internet layer. If an exam or an old study sheet tempts you otherwise, trust the header you saw with your own eyes.

TCP or UDP? The suite deliberately offers two transports, and another classic analogy from Dr. Al-Doori's course settles when to use which: TCP is the dependable old diesel workhorse — not the fastest thing on the road, but it always arrives, every parcel accounted for; UDP is the racing car — brilliantly quick, minimal baggage, and no promises. Web pages, email and file transfers ride TCP, because a missing piece ruins the result. Live video calls, online games and DNS lookups ride UDP, because a moment lost is better than a moment late — retransmitting a syllable of a video call would deliver it after the conversation has moved on. One professional nuance the book states well: network administrators do not choose the transport — application developers do. The administrator's job is to understand the choice and verify the protocol is doing what it promises, which is precisely what your Wireshark skills are for.

The book's protocol tables also list rivals from the era when suites competed — IPX and AppleTalk among them. TCP/IP won so completely that those names now appear only in history sections; you will meet them for one paragraph in Module 5, as a reminder that today's monoculture was once a contest.

From the textbook to 2026

The deep content of this lesson has barely aged: the four protocol questions, the three ingredients, and the phone-call-to-TCP mapping describe 2026 traffic exactly as they described 2007 traffic — TCP's handshake and close work today precisely as the book taught, now specified in RFC 9293. What changed is the cast list around them. Telnet, the book-era remote-administration protocol, sent everything readable on the wire and has been replaced by SSH (current); FTP has largely given way to secure transfer over SSH or HTTPS; and TLS encryption now wraps almost every application conversation by default — the web's move from HTTP to HTTPS being the visible example. One genuinely new actor deserves a name-drop: QUIC, a modern transport built on top of UDP, carried roughly a fifth of web requests as of the 2025 Cloudflare Radar year in review, a share flat since 2024; Module 5 tells that story. The lesson underneath is one to keep: rules outlive technologies. Protocols come and go; the questions they answer never change.

Activity: Spot Three Protocols in Your Capture

Your capture from the previous lab recorded a room full of conversations in different "languages." Time to identify three of them by name and evidence.

Instructions.

1. Open your saved first-capture file in Wireshark (File → Open). No capture file? No problem — repeat the previous lab's quick recipe: capture for about a minute while loading two websites and running one ping example.com, then stop.
2. Open Statistics → Protocol Hierarchy. Wireshark shows a tree of every protocol in your capture, nested by layer, with packet counts — the protocol suite as a living census of your own traffic. Notice how the tree's shape is the TCP/IP model.
3. Choose three different protocols from the tree, drawn from at least two different layers. Reliable choices: TCP (transport), DNS (application), ICMP (internet — your ping), ARP (network access), TLS (application), UDP (transport).
4. For each chosen protocol, type its name in lowercase into the display-filter bar at the top (dns, then icmp, then arp or tcp) and press Enter. The list narrows to just that protocol's packets. Click one line and read its details pane.
5. Record, for each: the protocol's name, its TCP/IP layer, and one piece of evidence from the details pane — for example: DNS — the domain name being looked up; ICMP — "Echo (ping) request"; TCP — the port pair; ARP — the "Who has...? Tell..." question in the Info column.
6. Clear the filter (the X at the right of the filter bar) between protocols.

Deliverable. A three-row table: protocol → TCP/IP layer → your evidence, plus one sentence stating which of the three rode inside another one you captured (hint: look at what carries DNS, or what carries ICMP).

Verification (how you know you got it right).

• Each of your three rows came from a different display filter, so the evidence cannot be from the same conversation misread three ways.
• The ping you ran last lab guarantees ICMP is present; loading websites guarantees TCP and TLS; nearly any live LAN shows ARP within a minute.
• Cross-check each protocol's layer against this lesson's suite table — and if you claimed ICMP for the transport layer, you know which erratum just caught you.
• If a filter unexpectedly shows nothing: dns can come up empty on modern systems because many browsers now encrypt name lookups inside HTTPS (a technique called DNS over HTTPS), hiding them from your capture — a very 2026 wrinkle that Module 5 explains. Simply choose a different protocol from the hierarchy — the census shows only what is truly there, which is itself the lesson.

Check yourself

1. A new intern asks: "Why can't my program just send the file? Why does everything need a protocol?" Using the four protocol questions, name two specific things that would fail without one.
2. In the phone-call analogy, which spoken moment corresponds to TCP's SYN, and which to its FIN? One phrase each.
3. Your capture shows this sequence for loading one page: a UDP packet asking for a site's address, then a TCP handshake to that address, then TLS-encrypted data. Name the three cooperating protocols in order of appearance (the first by its application-layer name) and give each one's TCP/IP layer.
4. Exam question, old study sheet: "Which of the following are transport-layer protocols: TCP, UDP, ICMP?" Give the correct answer and the one-sentence evidence from your own capture that settles it.
5. Two designs cross your desk: a bank-statement download service, and a live-scoreboard app pushing updates every second. Which transport does each want, and what does each design gain by its choice?
6. A protocol specification document has sections titled "Message format," "Retransmission timers," and "Connection state machine." Map each section to one of the three ingredients every protocol must define.

Answers

1. Any two of: neither side knows who transmits first (initiation undefined); the receiver may not be listening and the sender cannot tell (readiness undefined); the bytes arrive but cannot be interpreted (format undefined); the receiver cannot distinguish "transfer complete" from "connection died" (termination undefined).
2. SYN = dialing the number — the directed opening move. FIN = "that's everything, thanks" — announcing you are done, with the goodbye exchange as the acknowledged close.
3. DNS (application layer, riding in that UDP packet) finds the address; TCP (transport layer) opens and manages the reliable connection; TLS (application layer, carried inside TCP) encrypts the conversation. Three protocols, three jobs, one page load.
4. TCP and UDP only. ICMP is an internet-layer protocol: in your capture, ping traffic showed ICMP riding directly inside IP as protocol number 1, with no ports — the definitive disqualifier for a transport protocol.
5. The bank statement wants TCP: every byte must arrive, in order, verified — slower is acceptable, incomplete is not. The scoreboard wants UDP: an update lost is instantly replaced by the next one, so the app gains speed and simplicity and loses nothing that matters.
6. "Message format" → the format (syntax and fields). "Retransmission timers" → control information (error handling, timing, synchronization). "Connection state machine" → the rules (the procedures each side executes).

Key terms

• Protocol — the agreed rules that make communication possible: who starts, how readiness is signaled, what format the data takes, how the exchange ends.
• Protocol suite — a family of independently designed protocols built to cooperate; the Internet's is TCP/IP.
• SYN / SYN-ACK / ACK — the three moves of TCP's connection-opening handshake (mechanics in Module 5).
• FIN — TCP's "finished" signal, opening the two-sided close of a session.
• Connection-oriented — a transport that confirms readiness before data flows and acknowledges delivery (TCP).
• Connectionless — a transport that sends without setup or delivery guarantees (UDP).
• Display filter — Wireshark's mechanism for narrowing the packet list to one protocol or condition.
• Protocol Hierarchy — Wireshark's census of every protocol in a capture, nested by layer.
• QUIC — a modern UDP-based transport carrying a substantial but flat minority of web requests, roughly one in five as of the 2025 measurements (Module 5).

Summary

• A protocol answers four questions no communication can skip: who starts, how readiness is signaled, what format the data takes, and how the exchange ends.
• Every protocol specifies three ingredients: the rules (procedures), the format (field syntax), and control information (errors, timing, synchronization).
• The phone call maps directly onto TCP: dial = SYN, "hello" = SYN-ACK, your reply = ACK, conversation = acknowledged data flow, mutual goodbye = FIN and close.
• TCP/IP is a suite: DNS, HTTP/TLS, DHCP, TCP, UDP, IP, ICMP, Ethernet, Wi-Fi and ARP each do one job, layered exactly as the model predicts.
• TCP is the dependable workhorse (web, mail, files); UDP is the racing car (live media, games, lookups) — developers choose, administrators verify.
• ICMP belongs to the internet layer — your own capture is the proof that outlives any misprinted table.
• Suites and cast members age (Telnet → SSH, HTTP → HTTPS, rivals like IPX long gone; QUIC arriving), but the rules of conversation never do.

Next lesson

Module 2 gave networks their language: models, envelopes and rules. Module 3 gives them a body — the copper, glass and radio the signals actually ride, and how to choose between them.

Sources and further study

• Al-Doori, T., Network Essentials, Chapter 5 (TCP/IP Protocol Suite) — the protocol questions, the phone-call analogy, and the suite.
• RFC 9293, "Transmission Control Protocol (TCP)" — https://www.rfc-editor.org/info/rfc9293/ — TCP's current specification: handshake, acknowledgment, close.
• RFC 768, "User Datagram Protocol" — https://www.rfc-editor.org/info/rfc768/ — UDP's entire specification, famously three pages.
• RFC 792, "Internet Control Message Protocol" — https://datatracker.ietf.org/doc/html/rfc792 — ICMP, at the layer where it truly lives.
• Wireshark Wiki, "SampleCaptures" — https://wiki.wireshark.org/SampleCaptures — practice captures full of protocols to spot, if you want more hunting.