EMZETT.Protocol
In short: A fixed set of rules defining how two systems communicate with each other — which messages are exchanged in which order, in which format and with which meaning.
In more detail: A protocol specifies the syntax (structure of the messages, e.g. header fields) as well as the semantics (what a message causes) and the sequence (e.g. who sends first). Only because two systems “speak” the same protocol do they understand each other — the OSI model arranges the various protocols (Ethernet, IP, TCP, HTTP etc.) in layers, each building on the one below.
In Depth
You can think of a protocol like a negotiating language between two people who don’t share a language, which was precisely agreed in advance: both sides have to stick exactly to the same grammar (syntax), the same meaning of the individual terms (semantics) and the same order of conversation (timing/sequence) — if even one side deviates from it, the communication fails, even if both “somehow mean the same thing”. That’s exactly why network protocols are specified down to the last bit in official standards documents (RFCs at the IETF) instead of being described loosely.
Protocols typically build on each other (OSI model): an HTTP request “trusts” that TCP below it takes care of reliable delivery; TCP in turn trusts that IP basically routes the packets to the right network. This layering allows one protocol to be swapped without touching the others — e.g. HTTP can be transported over IPv6 just as well as over IPv4 without anything having to change in the HTTP protocol itself.
Standardisation: why RFCs are so important
For different manufacturers (router makers, browser developers, operating system vendors) to be able to write mutually compatible software at all, protocols have to be documented publicly and precisely. The IETF (Internet Engineering Task Force) publishes “Requests for Comments” (RFCs) for this — despite the modest name, once they reach standard status, RFCs are the binding technical specification of a protocol, often precise down to individual bit fields. A new device that wants to implement TCP, for example, has to stick exactly to the corresponding RFC, otherwise communication with existing TCP implementations won’t work reliably.
Connection-oriented versus connectionless
A fundamental distinction between protocols is whether they work connectionlessly or connection-oriented. Connection-oriented protocols such as TCP establish a defined state before the actual data exchange (e.g. via a handshake) and monitor it throughout the entire communication. Connectionless protocols such as UDP send each packet independently, without prior agreement or ongoing state management — simpler and faster, but without built-in guarantees.
See also: OSI model, Network protocols, Connectionless protocol