When talking about protocols, it is probably best to separate them into categories. The first category that I will separate protocols into is what we might call the multiplicity category. Protocols can either be for communication between two entities or more than two entities. While the protocols for only two entities ae simpler, I will discuss them later as they are almost universally dependent on protocols that allow for more than two entities for their usefulness.
There are a number of requirements for a protocol meant for more than two entities:
The most common method of sharing bandwidth is to break the data to be sent into packets, then to take turns sending these packets. This also allows the ability to send data to different recipients by interspersing packets, rather than sending everything to one, then sending everything to the next, and so on.
Since we have our data divided into packets, this presents us with a fairly logical method of attaching addresses to our packets - we simply say that the first n bytes of each packet will contain the address, and the rest will contain the data. These first n bytes are generally called the head, or header. In most protocols, the header will contain more information than just the name of the recipient. Timestamps, the length of the data, a sequence number, and other such pieces of information are often included.
Since there's no reason to waste perfectly good words by coming up with new ones, the problem of deciding what packets go where is called routing. Sometimes a protocol will get around the problem of routing by using a flat network - every packet goes to every computer and the one whose name matches the address pays attention. Other protocols will either build complex tables of who is where, or employ naming conventions to help route packets quickly and efficiently. Hierarchichal naming is an obvious choice. The basic idea is that one's full name begins with a general location that everyone knows how to get to, and then contains sub-locations that the people in that general area will know how to find.
It might have occurred to you that since the data portion of a packet should be able to contain anything, why not another packet? The answer is that there is no reason and in fact it's often done. This practice is sometimes called tunneling. For an example, let's say that you have two networks using protocol a and that one each of these networks, there is a computer that is connected to a network which uses protocol b. If any other computers on the two separate networks which to communicate to each other, the most logical method is for them to send their protocol a packets to one of the gateway machines (which speaks both a and b). This machine sends all of the a packet in a b packet over to the b-speaking computer on the other network, who then strips out the a packet and sends it out on its local a network.
Having just read about tunneling protocols, it may have occurred to you that one veryy obvious use of tunneling protocols is to establish communication between two computers using a wide audience protocol and then to tunnel a protocol for two inside of that communication. Of course, you'd be right! This is an extraordinarily common practice. Perhaps the most famous example of this is TCP/IP.
Anyhow, protocols for two are used primarily because they save on bandwidth. If someone else has already figured out the work of getting your data to where it needs to go, there's no reason to include addresses. There is also no need to worry about sharing bandwidth as those issues have already been dealt with, so one is free to just get to the business at hand.
While there are useful protocols for two (TCP comes to mind), the majority of them are built for a special purpose. SMTP for example is built to handle the business of transfering email. By concentrating on this, it handles the problem efficiently and effetively. The same is true for web traffic and the HTTP protocol.
Networking is not a very new concept in human history, but computers have made networking more efficient and powerful than it had been before. Hopefully all this has made sense, but I fear that it was also a bit abstract. Since the particular protocols commonly used today are worth talking about anyhow, you might want to read about specific protocols.