Читать книгу Networking All-in-One For Dummies - Lowe Doug, Doug Lowe - Страница 116

A protocol is simply a set of rules that enable effective communications to occur. You encounter protocols every day and probably don’t even realize it. When you pay for groceries with a debit card, the clerk tells you how much the groceries cost, and then you swipe your debit card in the card reader, punch in your security code, indicate whether you want cash back, enter the amount of the cash back if you so indicated, and verify the total amount. You then cross your fingers behind your back and say a quiet prayer while the machine authorizes the purchase. Assuming the amount is authorized, the machine prints out your receipt.

Here’s another example of an everyday protocol: making a phone call. You probably take most of the details of the phone-calling protocol for granted, but it’s pretty complicated if you think about it:

 When you pick up a phone, you listen for a dial tone before dialing the number (unless you’re using a cellphone). If you don’t hear a dial tone, you know that someone else in your family is talking on the phone, or something is wrong with your phone.

 When you hear the dial tone, you dial the number of the party you want to reach. If the person you want to call is in the same area code, you simply dial that person’s seven-digit phone number. If the person is in a different area code, you dial 1, the three-digit area code, and the person’s seven-digit phone number.

 If you hear a series of long ringing tones, you wait until the other person answers the phone. If the phone rings a certain number of times with no answer, you hang up and try again later. If you hear a voice say, “Hello,” you begin a conversation with the other party. If the person on the other end of the phone has never heard of you, you say, “Sorry, wrong number,” hang up, and try again.

 If you hear a voice that rambles on about how they’re not home but they want to return your call, you wait for a beep and leave a message.

 If you hear a series of short tones, you know the other person is talking to someone else on the phone. So you hang up and try again later.

 If you hear a sequence of three tones that increase in pitch, followed by a recorded voice that says “We’re sorry …” you know that the number you dialed is invalid. Either you dialed the number incorrectly, or the number has been disconnected.

You get the point. Exchanges — using a debit card or making a phone call — follow the same rules every time they happen.

Computer networks depend upon many different types of protocols. These protocols are very rigidly defined, and for good reason. Network interfaces must know how to talk to other network interfaces to exchange information, operating systems must know how to talk to network interfaces to send and receive data on the network, and application programs must know how to talk to operating systems to know how to retrieve a file from a network server.

Protocols come in many different types. At the lowest level, protocols define exactly what type of electrical signal represents a 1 and what type of signal represents a 0. At the highest level, protocols allow (say) a computer user in the United States to send an email to another computer user in New Zealand — and in between are many other levels of protocols. You find out more about these levels of protocols (often called “layers”) in the upcoming section, “Seeing the Seven Layers of the OSI Reference Model.”

Protocols tend to be used together in matched sets called protocol suites. The two most popular protocol suites for networking are TCP/IP and Ethernet. TCP/IP, originally developed for Unix networks, is the protocol of the Internet and most local area networks (LANs). Ethernet is a low-level protocol that spells out the electrical characteristics of the network hardware used by most LANs.