The OSI model was developed as an attempt to explain hundreds, if not thousands, of different protocols made by different manufacturers that needed to play together. The ISO declared the OSI seven-layer model as the tool for manufacturers of networking equipment to find common ground between multiple protocols, enabling them to create standards for interoperability of networking software and hardware.
It also helps in troubleshooting as you can go from lower layer to the upper one by one and try to understand if the problem occurred on this or on upper level. As soon as you understand on which layer the problem occurred, you essentially know where to look further. In view that many network problem are mindbogglingly complex this allow structure troubleshooting in hierarchical fashion. Which is a big plus, over random poking at different possibilities.
That's why the "idealized" and somewhat detached form reality OSI model is still thought and needs to be known to all networking techs and Unix syadmins and knowledge of ot is required to pass the exam.
Today’s world, however, is dominated by TCP/IP protocol. And OSI model doesn’t correctly describes actual layer used in TCP/IP. A particular protocol’s exact location in the OSI model is often a contested debate. The TCP/IP model fixes this ambiguity, at least for commonly used protocols. Because of its tight protocol-to-layer integration, the TCP/IP model is a descriptive model, which correctons to howe thing actually are working. While the OSI seven-layer model is a conceptual model, an idelised model that is helpful in understand the hierarchy in conceptual layers NEtwrk stack but little more.
The TCP/IP model shows its power in its ability to describe what happens at each layer to the data that goes from one computer to another. The Application layer programs create the data. The Transport layer breaks the data into chunks, putting those chunks into TCP segments or UDP datagrams. The Internet layer adds the IP addressing and creates the IP packets. The Link layer wraps the IP packet into an Ethernet frame, with the MAC address information and a frame check sequence (FCS). Now the data is ready to hit the wire (or airwaves).
The TCP/IP model consists of just four layers:
The Internet layer doesn’t care about the type of data an IP packet carries, nor does it care whether the data gets there in good order or not. Those jobs are for the next layer: the Transport layer.
Some protocols, like the popular Post Office Protocol (POP) used for sending e-mail messages, require that the e-mail client and server verify that they have a good connection before a message is sent. This makes sense because you don’t want your e-mail message to be a corrupted mess when it arrives.
Alternatively, a number of TCP/IP protocols simply send data without first waiting to verify that the receiving system is ready. When using Voice over IP (VoIP), for example, the call is made without verifying first whether another device is there.
The connection-oriented protocol is called Transmission Control Protocol (TCP). The connectionless protocol is called User Datagram Protocol (UDP).
To see the Transport layer in action, strip away the IP addresses from an IP packet. What’s left is a chunk of data in yet another container called a TCP segment. TCP segments have many other fields that ensure the data gets to its destination in good order. These fields have names such as Checksum, Flags, and Acknowledgement. Chapter 7 goes into more detail on TCP segments, but, for now, just know that TCP segments have fields that ensure the connection-oriented communication works properly. Figure 2-48 shows a typical (although simplified) TCP segment.
Data comes from the Application layer applications. The Transport layer breaks that data into chunks, adding port numbers and sequence numbers, creating the TCP segment. The Transport layer then hands the TCP segment to the Internet layer that, in turn, creates the IP packet.
UDP also gets data from the Application layer programs and adds port and sequencing numbers to create a container called a UDP datagram. A UDP datagram lacks most of the extra fields found in TCP segments, simply because UDP doesn’t care if the receiving computer gets its data.
Let me be clear: you don’t choose TCP or UDP. The people who developed the applications decide which protocol to use. When you fire up your Web browser, for example, you’re using TCP because Web browsers use an Application layer protocol called HTTP. HTTP is built on TCP.
TCP/IP uses a unique port numbering system that gives each application a unique number between 1 and 65535. Some of these port numbers are very famous. The protocol that makes Web pages work, HTTP, uses port 80, for example.
Although we can say that the OSI model’s Presentation layer fits inside the TCP/IP model’s Application layer, no application requires any particular form of presentation as seen in the OSI model. Standard formats are part and parcel with TCP/IP protocols. For example, all e-mail messages use an extremely strict format called MIME. All e-mail servers and clients read MIME without exception.
In the OSI model, we describe the API—the smarts that make applications network-aware—as being part of the Application layer. While this is still true for the TCP/IP model, all applications designed for TCP/IP are, by definition, network-aware. There is no such thing as a “TCP/IP word processor” or a “TCP/IP image editor” that requires the added ability to know how to talk to a network—all TCP/IP applications can talk to the network, as long as they are part of a network. And every TCP/IP application must be a part of a network to function: Web browsers, e-mail clients, multiplayer games, and so on.
Don’t think that the TCP/IP model is any simpler than the OSI model just because it only uses four layers. With the arguable exception of the Presentation layer, everything you saw in the OSI model is also found in the TCP/IP model
The Internet Protocol (IP) works at the Internet layer, taking data chunks from the Transport layer, adding addressing, and creating the final IP packet. The Internet Protocol software then hands the IP packet to NIC card driver for encapsulation into an Ethernet frame.
There are two types of IP addesses, one older, but still dominant is called IPv4 and consists of 4 bytes (32 bits). Most commonly IPv4 addresses are represented in so called decimal notation with value of each byte rerepresent b a number in the range of 0-255 separated byt dots. For example.
10.182.145.19
There is also a newer longer type of IP address called IPv6. it was created because in 90th people thouth that we will run out of IPv4 addresses soon. But advanced in IP netwroking such as address translation alleviated this problem for several decades. Currently it is mostly used by US military. Knowledge of IPv6 networking is not currently need for RHSCA exam. You can get more information from wikipedia.
NOTE: IPv6 is enabled by default on most devices and need to be explicitly disabled if you do not use it. Otherwise it can be used as "stealth" protocol with your netwrk by chackers and god know whom.
There is also a third protocol called the Internet Control Message Protocol (ICMP). Regular users and sysadmins usually use with within a limited number of utilities such as ping and traceroute. For the most part, ICMP operate as administrative protocol for TCP connections and is not visible to users. Only ping is widely used. for example
root@lustwz99:/root # ping 10.194.181.78 PING 10.194.181.78 (10.194.181.78) 56(84) bytes of data. 64 bytes from 10.194.181.78: icmp_seq=1 ttl=64 time=1.22 ms 64 bytes from 10.194.181.78: icmp_seq=2 ttl=64 time=0.344 ms 64 bytes from 10.194.181.78: icmp_seq=3 ttl=64 time=0.321 ms 64 bytes from 10.194.181.78: icmp_seq=4 ttl=64 time=0.326 ms 64 bytes from 10.194.181.78: icmp_seq=5 ttl=64 time=0.320 ms 64 bytes from 10.194.181.78: icmp_seq=6 ttl=64 time=0.308 ms 64 bytes from 10.194.181.78: icmp_seq=7 ttl=64 time=0.312 ms
Ping will show the round trip time (RTT)—some call this the real transfer time—for the ICMP packet, usually in seconds. If ping can’t find the host, the packet will time out and ping will show you that information too.
When thinking about the Internet layer, remember the following three protocols:
The full IP packet header has 14 different fields. As you would expect, the destination and source IP addresses are part of the Network/Internet layer. Other fields include version, header length, and more. Dissecting the entire set of fields isn’t important, but here are a few descriptions just to whet your appetite:
There are two major transport level protocols
When moving data from one system to another, the TCP/IP protocol suite needs to know if the communication is connection-oriented or connectionless. When you want to be positive that the data moving between two systems gets there in good order, use a connection-oriented application. If it’s not a big deal for data to miss a bit or two, then connectionless is the way to go. The connection-oriented protocol used with TCP/IP is called the Transmission Control Protocol (TCP). The connectionless one is called the User Datagram Protocol (UDP).
Let me be clear: you don’t choose TCP or UDP. The people who developed the applications decide which protocol to use. When you fire up your Web browser, for example, you’re using TCP because Web browsers use an Application layer protocol called HTTP. HTTP is built on TCP.
Probably 99% percent of all TCP/IP applications use TCP—that’s probably why we call this protocol suite “TCP/IP” and not “UDP/IP.” TCP is a connection-oriented protokol that means that it requires both the sending and receiving machines to acknowledge each sent packet as well as presence and readiness to send and receive data. We call this process ACK/NACK or just ACK TCP also chops up data into segments, gives the segments a sequencing number, and then verifies that all sent segments were received and reassembles them in right order (as they can arrive to the target host in a different order then they were sent). If a segment goes missing, the receiving system requests the missing segments.
Networking uses various protocols to transfer data such as Transfer Control Protocol (TCP), User Datagram Protocol (UDP), or Internet Control Message Protocol (ICMP). Every protocol has specific properties: TCP is typically used when the network communication must be reliable and delivery must be guaranteed; UDP is used when it must be fast and guaranteed delivery does not count. It is also very useful for transfer of data over high latency networks, for example via WAN.
Within TCP family the most prominent are ssh (port 22, HTTP port 80, and telnet port 23)
To identify these services, port addresses are used. Every service has a specific port address, such as port 80 for HTTP,or port 22 for a Secure Shell (SSH) server
the sender ports and the receiver are typically different. Those are destination (reciever) address port. Source address port is usually randon and in above 1024.