the same IP address as well as for multiple applications to originate traffic using separate source ports, allowing return traffic to get back to the correct application.
Finally, the fourth and last layer in the TCP/IP model is the Application layer. While it shares the same name as layer 7 in the OSI model, it encompasses all of the functions of layers 5–7 of the OSI model. Applications reside here. If they need presentation functions or session management, the applications take care of all of that and those functions aren't broken out and described separately from the application itself.
As you can see, the TCP/IP model is quite a bit simpler to think about than the OSI model. If you want to get fine-grained about functionality, though, the OSI model is better as a reference point. Ultimately, they are both just for conceptualizing and referring to the functions without specific reference to the protocols in use.
Protocol Data Units
We've talked about the various layers of the two communication models. Ultimately, the purpose for those models is to build different means for multiple systems to communicate with one another. The protocols don't exist for the purpose of the protocols. They exist to be able to effectively and efficiently send data from one system to another. The data is wrapped up with the different headers from each layer that allow the receiving system to identify where the data is headed, including what application.
As different protocols add their headers, encapsulating the data that is already there, the result is a different chunk of data than what was there before the protocol got its say. The resulting chunk of data, just as the chunk of data that started out, is called a protocol data unit (PDU). Each layer of the communications stack has a different protocol data unit associated with it. This means that at most layers, we use a different word to describe the chunk of data, or protocol data unit, we are looking at.
In order to talk about the different words, we are going to start at the very top of the stack. This is because when a message is being prepared for sending, it starts at the application. The application creates data. The protocol data unit at the application layer is just “data.” As we move down through the presentation and session layers, we are still talking about just data. You may not actually be working with protocols in layers 5–7, so there isn't really a PDU associated with it. It's just the data until we get to layer 4 of the OSI model.
Once we get to the transport layer, whether we are talking about the OSI model or the TCP/IP model, we are talking about the data that has the transport headers stacked on top. After those headers, which include the source and destination port numbers, are in place, you have a segment if you are using TCP and a datagram if you are using the User Datagram Protocol (UDP). The segment or datagram is then handed to IP to add some additional headers.
The IP headers include the source and destination IP address as well as some additional information, including indications as to whether what we have is a just a fragment of a larger communication stream or just an individual message. Once the IP headers are on and sitting atop the TCP or UDP headers, you have a packet. A few protocols may be in use at layer 2, including Ethernet, Asynchronous Transfer Mode (ATM), Point to Point Protocol (PPP), or 802.11 (WiFi). No matter what the protocol is, there will be a set of headers that includes the source and destination MAC addresses. Once the layer 2 headers are on, you have a frame. The frame is what is placed onto the network.
Once the frame is converted to the right signaling mechanism, either an optical signal or an electrical signal, we are looking at bits. In the end, no matter what data you are sending, it is sent a bit at a time. If you are looking at the data as it is passing across the network, you are looking at a stream of bits. Later on, we'll look at more details of the different protocols you will see as we start pulling these messages – frames, packets, segments, and datagrams – apart.
Request for Comments
The very first request for comment (RFC) was written in 1969 by Steve Crocker. Crocker created RFCs and not only wrote the first, but wrote several others as well over the years. RFCs make available on the Internet the best possible technical description of protocols and processes. In 1969, the Advanced Research Projects Agency (ARPA) awarded a contract to Bolt, Beraneck, and Newman (BBN) to design and build a network that was capable of including hosts from around the country. The idea was to connect research facilities at universities and government agencies in order to facilitate collaboration and allow for more efficient use of limited computing resources. At the time, computers were very large and very expensive, so being able to network the computers that did exist allowed for research to be conducted across the country without having to necessarily duplicate computing resources.
BBN had to design and build the very first system that was capable of moving packets from one system to another over the telephony network that was in place at the time. Initially, the device used to create the network was called the Interface Message Processor (IMP). You may think of it as a router, considering what it does. Such devices simply didn't exist, though, so the functionality of a router was handled in a specialized interface built into a Honeywell computer with software designed to move messages from the computer on site to the network, on its way to the destination IMP. The very first RFC specified the software that was to run on the IMP. Just as a point of history and also to give you a sense of what an RFC looks like, you can see the very first part of the very first RFC in Figure 2.2.
Figure 2.2 : The top of RFC 1.
In addition to historical curiosities, RFCs provide detailed design documentation for processes and protocols. Of course, there is also the occasional joke, like the periodic April Fool's Day RFC that introduces protocols like the transmission of IP datagrams over avian carrier. This RFC was issued in 1990 and was inspired by a scene from the movie Monty Python and the Holy Grail. Much more to the point, though, if you are ever interested in knowing how a particular protocol like TCP, IP, UDP, HTTP, or any of hundreds of other protocols, enhancements and processes, works, you can get the last word by reading the RFC.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
