In the earliest days of electronic computers, each computer stood completely alone. Each new machine represented a unique design, with its own architecture, operating codes, and methods of storing data. The early computer engineers were staggeringly ingenious in coming up with different ways of representing binary information. On different machines, ones and zeroes were represented by switching vacuum tubes, or magnetized patches on rotating metal drums, or bright and dark spots on oscilloscope screens – even by patterns of sound waves travelling through tubes filled with mercury. But two storage methods quickly became standard, allowing data to be shared between machines: IBM punch cards and magnetic tapes. If you have ever seen a computer in an old movie from the 1960s, you probably saw the whirring tape machines and clattering card punches in among the huge banks of machinery with their innumerable blinking lights.
The trouble with punch cards and magnetic tapes is that they have to be physically carried from one computer to another, and that is a slow process. By the end of the fifties, the U.S. military was using dedicated telephone lines to link computers together electronically. The SAGE network, as it was called, allowed several large computers to quickly share incoming data from the radar stations that continuously scanned the skies in case of a Russian nuclear attack. This worked because all the computers in the SAGE network were identical, so there was no trouble about translation. Other early networks had the same limitation. They either connected similar mainframe computers together, or connected one computer to many identical terminals. There was no general way of connecting different computers on the same network.
The first major step in that direction came in 1969, when the Advanced Research Projects Agency, a part of the U.S. Department of Defense, set up a network called ARPANET. The Defense Department figured that if they let civilian researchers and universities use their network for whatever they liked (within reason), many brilliant minds would labour at improving the network, and the military budget would not have to pay for them all. This worked excellently well, and in the end, ARPANET became the most important predecessor of the Internet that we know and use today.
A number of different mainframe computers (four at first) were connected to ARPANET by means of machines called IMPs, or Interface Message Processors – what we now call routers. The IMPs were standardized, and data travelled between them in a common format. The programmers at each site were responsible for writing software to connect their own mainframe to its IMP. To simplify things, the IMP accepted data in small chunks called packets. Just as the Post Office sends messages inside envelopes, and normally doesn’t look inside them, the IMP transmitted the packets and did not concern itself with what kind of data they contained. Once the packets reached the computer at the receiving end, it was the programmers’ job to write the software that put them back together in the correct order, and translated them into a format that the computer was able to use.
The IMP’s job, like the Post Office’s, was to find some way to deliver the data to its destination. If there was no direct connection between the transmitting and receiving sites, the IMP looked for an indirect connection and passed the data on. This made the system more reliable. Suppose you want to send data from point A to point D. There is no direct wire connecting them, but both points are connected to point B. Your IMP sends out requests along all the wires, asking who has a connection to D; and when B answers, it ships the data to point B and lets that IMP take over the job. But then it turns out that the link between B and D is broken, because some fool with a bulldozer has dug up the buried cable. The IMP at B looks around and sees that point C is also connected to D. It sends the data there, bypassing the broken link, and the packets arrive at their destination.
This ability to reroute traffic around broken links made the ARPANET system flexible and robust. There has long been a legend that it was built that way to withstand a nuclear attack, so that if one point on the network was blown to kingdom come, the rest of the network would continue to function. That is not actually true; but the fact that it could cope with such an emergency gave the Defense Department a powerful incentive to keep funding the project.
Eventually, ARPANET, and other networks like it around the world, came to connect thousands of different sites. Some were connected to the network by point-to-point cables, some by Telex lines, some by ordinary telephone connections, some by radio, some by satellite. The computers involved used different languages, different operating systems, different character encodings – even different numbers of bits in a byte. (Universities often used DEC computers, which employed 7-bit ASCII to encode text; commercial sites generally used IBM machines and the 8-bit EBCDIC code.) The difficulties of moving packets over so many kinds of connections, and translating the data between so many standards, became overwhelming. By the late 1970s it became clear that the whole computer industry would have to adopt a set of standards for network connections, and two different groups went to work to develop such standards. In 1984, after long negotiations between the two groups, they agreed on a joint standard that was flexible enough to accommodate all the important networks in existence: the OSI Reference Model.
The OSI model does not actually specify a particular connection method, or a particular character code, or in any other way choose one technical standard over another. What it does is break the task of network communications into seven layers, each with its own well-defined set of jobs to do. It also specifies the basic rules by which each layer communicates with the ones above and below it. This approach was so successful that every networking standard in use today uses some variation on the OSI model. Not every standard uses seven layers. The Microsoft standard recognizes five layers, for instance, and TCP/IP only four. But they all obey the same principles, and you can ‘map’ each standard onto the OSI model in a straightforward way. For instance, Microsoft treats OSI layers 5, 6, and 7 as a single chunk, and TCP/IP treats layers 1 and 2 as one; but they all break down the tasks in the same general way, and in the same order.
Here are the seven layers of the original OSI model, from bottom to top:
1: Physical. This is where the actual signals are sent from one point to another – by wire, or radio, or fibre-optic cable, or what have you. Someone once jokingly suggested using carrier pigeons to transmit Internet data, and such a system was actually set up. It was very slow, but it worked, and gave its creators some insight into the problems of extending the Internet to vessels in deep space, where radio signals may take hours to travel back to Earth.
Any medium of transmission could theoretically be used on the physical layer, as long as it follows the rules for exchanging data with the data link layer above it. In the early days of the Internet, when the Soviet Union still existed and communications there were heavily censored, some Russian dissidents used ham radio for the physical layer. That allowed them to talk to one another and hear from the outside world. The KGB could shut down individual ham operators but could never take down the whole network, because the routing protocols developed for ARPANET allowed the surviving operators to find alternate routes.
2: Data link. This layer does ‘node-to-node’ data transfer. Once two devices have found each other over the Internet and made a connection, the data link layer directs the traffic between them and checks for transmission errors.
3: Network. This layer accepts data packets from the transport layer above, and converts them into the ‘frames’ that are handled by the data link layer below. It also handles the job of locating the recipient on the Internet, which may require routing across a number of separate but interconnected networks. The transport layer only needs to give this layer a packet and an address to send it to; it need not concern itself with the details after that. Taken together, these first three layers do the work of the IMPs on the original ARPANET.
4: Transport. This is where a long message is divided into packets, and each packet gets tagged with the proper address. The transport layer may also check to see whether all the packets have been delivered, and resend any data that did not arrive. At the receiving end, the transport layer reassembles the packets into the original message and, if applicable, sends a confirmation back to the sender that everything has been received (or not).
TCP, one of the main software components of the modern Internet, works mostly on the transport layer. Because it does check for missing packets and resend them, it requires a steady two-way communication that is too slow for things like streaming video, voice-over-IP telephones, or online gaming. For these uses, TCP is swapped out and replaced with a protocol called UDP, which does not bother with such niceties. One missing packet in a telephone call means only a few milliseconds of silence, and even a whole string of missing packets in a video signal will only cause your TV to drop one frame of the picture. As for gaming, if your Internet connection is unreliable, you might lose so many packets that your frame rate suffers and the game becomes jerky and unresponsive. This is good news for your local computer store, because you will probably blame your machine and drop several hundred dollars on a new graphics card, instead of getting the better Internet service that you actually need.
5: Session. This is the ‘hello and goodbye’ layer. If you need to set up a formal communication channel between two computers, this is where it is done. Many kinds of network traffic don’t require this, but if a task requires multiple back-and-forth messages to be sent, the session layer opens up the communication and then makes sure it is gracefully shut down when the job is finished.
6: Presentation. Roughly speaking, data formats are translated here. For instance, whether your computer’s software uses ASCII, or EBCDIC, or Unicode to represent text characters, the presentation layer translates them into a standard code known by the whole network, and back again at the receiving end. If your data needs to be compressed, ‘zipped’, encrypted, or bundled up into an XML file for transmission, these functions are performed by the presentation layer (and then decompressed, unzipped, decrypted or unbundled at the other end).
7: Application. This does not refer to ‘applications’ like Chrome or Microsoft Outlook, but to the hidden programs in your operating system that actually establish different kinds of Internet connections, such as email, web pages, file transfers, data streaming, and the specialized forms of communication used by online games. When you type a web address into your browser, the part before the colon (https:, ftp:, mailto:, etc.) tells the browser which one of these programs to use.
In the actual working systems that you and I use to connect to the Internet, layers 5 through 7 are usually combined. Of course, this combined mega-layer can be swapped out and replaced, like any other part of the system. An Android phone, an iOS phone, a Windows PC, a Linux PC, and a Mac all use different software to do the work of these layers, but because the OSI model keeps those functions separate, the rest of the Internet doesn’t care and all those different devices are interchangeable.
Speak Your Mind