There are many many protocols in use today. Common services provided by a protocol are routing and reliability. A route is a sequence of machines (or gateways) which are used to move a packet from the source to the destination. A simple routing protocol might only contain the destination of the packet, and the machines along the way would make the decisions about how to get it there. Other routing protocols might contain information about how fast the packet should be moved and how important it is that it not be lost. These can affect the decisions about which network path to use.
Another service typically provided by protocols is reliability. When a packet is sent from a machine, it is gone. The network promises the machine that it will attempt to deliver the packet uncorrupted to the destination, but it is making no guarentees. If it is important that the packet arrive, then the protocol must provide some mechanism for doing this.
Reliability has two aspects. The first is that the packet arrive at all. Protocols which implement this usually do so by having the destination machine send a message back to the source when the packet arrives, acknowledging that it got the packet. The source machine sends the message and waits a given amount of time for the ack (acknowledgement packet), and if it doesn't arrive in that time, retransmits the message.
For this to work, each message needs to have a unique identification, so the destination machine can tell the source which message arrived (there may be several in transit at any time). Usually a packet is identified by the source machine id number and a serial number, unique to the source machine.
When machine danube sends a packet to another machine, it generates a serial number (by incrementing the number of the last packet it sent), places this number in a field in the packet header, and sends it. It waits to hear from the destination that this packet has been received before deleting the memory buffer used to hold the message. If it doesn't hear before the timeout it retransmits. After some number of retransmits it decides that for some reason it is not possible at this time to communicate with that machine and reports an error.
The other aspect of reliability is corruption detection. The bits in a packet can sometimes be changed when they are transmitted over the network. There are various error detecting and correcting procedures which can be used to deal with this. The easiest thing to do is compute the parity of all of the bits in the packet (that is, take the sum of the bits and mod the result by two). This is not that good because, while it will detect when one bit has been changed, it will not notice if two bits were changed.
The check sum is a kind of a strengthening of the parity check idea. For each packet the source machine runs a procedure which computes a fairly large number (say 32 bits) according to the bits in the packet. One possibility is to break the packet into 4 byte words, treat these words as numbers, and add the numbers together ignoring overflow. This checksum is added to the packet. The receiving end computes the same function on the packet (minus the checksum field of course) and compares the two numbers. If they are different it reports a corrupted packet transmission to the source.
There are more elaborate schemes, called error correcting codes, which add enough information to every byte of the message to correct one changed bit and to detect when one or two bits in the byte have been changed. Such things are called error correcting codes.
A final service which simple protocols might provide is fragmentation. Sometimes the network hardware won't allow the transmission of packets larger than a certain size. Often it is not the first network, but some intermediate network between the source and the destination, which has the limitation on size. Since the user doesn't know, and doesn't want to know, about all of the networks between her and the destination machine, the protocol should hide this limitation transparently. In other words, the software should make it seem like you can transmit any size packet, and if the size exceeds the maximum size the hardware supports, the software should manage transmitting the packet without the users intervention.
The protocol, when given a large packet, breaks it up into small enough packets and transmits them separately. This is called fragmentation. The fragments themselves may be fragmented again by another network, so the whole packet may arrive in many pieces of varying sizes. The receiving end is responsible for collecting all of the fragments, putting them in the correct order (the order of receipt is not necessarily the order of transmission) and presents the destination process with the large message as it was transmitted.