Conceptually, a protocol is no more than an agreement. So the real question is why an agreement is needed at all, which boils down to the chaos and unstructuredness (probably only from the perspective of humans) in the core of engineering. In some sense, the most intriguing part of engineering, which is similar to art, is to construct the best structures in an orderly fashion so that various utilities can be created with ease.

OK, I know that sounds like bullshit. But let’s go concrete.

Think about TCP. What we want is a reliable communication channel while facing us are randomly arriving packets. They could be of different sizes, contain errors or not, arrive in weird order, etc., which are messy. How can we make these wild packets meaningful? I guess the first thing we need to do is an agreement. (I actually wonder if this is true sometimes.）

Let’s try a trivial one: Alice and Bob agree to discard whatever they receive. Deal! This is by no means very useful, but is indeed a protocol that allows complete confidence at both sides in the meaning of the messages, which is nothing. To make it a bit romantic, maybe Alice can send in the packets her secret love for Bob, which would end up blowing in the wind because Bob will discard them anyway without a peek. An agreement is an agreement :)

Obviously this is not satisfactory, so let’s improve our protocol: Alice and Bob agree that whenever and whatever they receive a packet, however long the packet is, it simply means “I love you”. Good, at least now the packets convey some human understandable meaning, though it never changes. But it is not hard at all to allow some dynamics. For example let’s just do a minor tweak to our protocol: packets longer than 10 mean “ I love you” and all other packets are “I hate you”. These messages are still hard-coded in the protocol, but it is easy to see that Alice and Bob already have some weak control over the messages.

Now let’s turn to a more interesting trick - reordering. Suppose Alice wants to ask Bob “do not I love you”. The first option is to send this entire sentence in just one packet. This would work, but has disadvantages like expensiveness to resend on failures. I will not go into the details but directly follow the second option to explain what reordering is. With this approach, Alice would send five separate packets in the order of “do”-“not”-“I”-“love”-“you”. Unfortunately, they may arrive misleadingly as “I” “do” “not” “love” “you”. To address this issue, Alice and Bob can make an agreement that a sequence number will be prepended to each packet, making the sentence “1do”-“2not”-“3I”-“4love”-“5you”. Now the original message can always be assembled properly regardless of the arriving order.

Of course we can enforce more structures and continue perfecting our protocol, but you got the idea. A protocol is just an agreement to solve the problem of unstructuredness.

Now the only question left is why we need so many different protocols. The answer is simple - because we have so many different kinds and levels of unstructuredness! For the last time let’s take Alice expressing love for Bob as an example. But to illustrate how general the idea of a protocol can be, let’s make this happen in the world of everyday life rather than computer science. Alice wants to write a love letter to Bob, which is comprised of several paragraphs. Every paragraph consists a couple of sentences, which can be further broken down to words and characters. That’s already quite a few protocols involved! The vocabulary protocol transforms characters into words. The grammar protocol assembles words into sentences, which are elevated to paragraphs and passages by some other protocols (which I don’t really know) of cohesion and cohesiveness. As long as these protocols are agreed on, the love from Alice should be well understood, hopefully :-)