AN OVERVIEW TO OSI NETWORKING MODEL AND TCP/IP
Installing the Linux operating system is only the first step toward
creating a fully functional departmental server or Web site. Almost all
computers are now networked in some way to other devices therefore a
basic understanding of networking and issues related to the topic will
be essential to feeling comfortable with Linux servers.
Familiarity with the concepts explained in the following sections
will help answer many of the daily questions often asked by
friends, and even yourself. It will help make the road to Linux mastery
less perilous, a road that begins with an understanding of the OSI
networking model and TCP/IP.
THE OSI NETWORKING MODEL:
The Open System Interconnection (OSI) model, developed by the
International Organization for Standardization, defines how the various
hardware and software components involved in data communication should
interact with each other.
In the OSI model each component along the data communications
path is assigned a layer of responsibility, in other words. Each layer extracts the permit, or header
information, it needs from the data and uses this information to
correctly forward what's left to the next layer. This layer also strips
away its permit and forwards the data to the next layer, and so the
cycle continues for seven layers.
The very first layer of the OSI model describes the transmission
attributes of the cabling or wireless frequencies used at each "link" or
step along the way. Layer 2 describes the error correction
methodologies to be used on the link; layer 3 ensures that the data can
hop from link to link on the way to the final destination described in
its header. When the data finally arrives, the layer 4 header is used to
determine which locally installed software application should receive
it. The application uses the guidelines of layer 5 to keep track of the
various communications sessions it has with remote computers and uses
layer 6 to verify that the communication or file format is correct.
Finally, layer 7 defines what the end user will see in the form of an
interface, be it graphical on a screen or otherwise. A description of
the functions of each layer in the model can be seen in below Table.

AN OVERVIEW TO TCP/IP:
TCP/IP is a universal standard suite of protocols used to provide
connectivity between networked devices. It is part of the larger OSI
model upon which most data communications is based.
One component of TCP/IP is the Internet Protocol (IP) which is
responsible for ensuring that data is transferred between two addresses
without being corrupted.
For manageability, the data is usually split into multiple pieces
or packets each with its own error detection bytes in the control
section or header of the packet. The remote computer then receives the
packets and reassembles the data and checks for errors. It then passes
the data to the program that expects to receive it.
How does the computer know what program needs the data? Each IP
packet also contains a piece of information in its header called the
type field. This informs the computer receiving the data about the type
of layer 4 transportation mechanism being used.
The two most popular transportation mechanisms used on the
Internet are Transmission Control Protocol (TCP) and User Datagram
Protocol (UDP).
When the type of transport protocol has been determined, the
TCP/UDP header is then inspected for the "port" value, which is used to
determine which network application on the computer should process the
data.
TCP opens up a virtual connection between the client and server
programs running on separate computers so that multiple and/or sporadic
streams of data can be sent over an indefinite period of time between
them. TCP keeps track of the packets sent by giving each one a sequence
number with the remote server sending back acknowledgment packets
confirming correct delivery. Programs that use TCP therefore have a
means of detecting connection failures and requesting the retransmission
of missing packets. TCP is a good example of a connection-oriented
protocol.
How TCP Establishes A Connection:
Any form of communication requires some form of acknowledgement for
it to become meaningful. Someone knocks on the door to a house, the
person inside asks "Who is it?", to which the visitor replies, "It's
me!" Then the door opens. Both persons knew who was on the other side of
the door before it opened and now a conversation can now begin.
TCP acts in a similar way. The server initiating the connection
sends a segment with the SYN bit set in TCP header. The target replies
with a segment with the SYN and ACK bits set, to which the originating
server replies with a segment with the ACK bit set. This SYN, SYN-ACK,
ACK mechanism is often called the "three-way handshake".
The communication then continues with a series of segment
exchanges, each with the ACK bit set. When one of the servers needs to
end the communication, it sends a segment to the other with the FIN and
ACK bits set, to which the other server also replies with a FIN-ACK
segment also. The communication terminates with a final ACK from the
server that wanted to end the session.
This is the equivalent of ending a conversation by saying "I
really have to go now, I have to go for lunch", to which the reply is "I
think I'm finished here too, see you tomorrow..." The conversation ends
with a final "bye" from the hungry person.
Here is a modified packet trace obtained from the tethereal program.
hostA -> hostB TCP 1443 > http [SYN] Seq=9766 Ack=0 Win=5840 Len=0 hostB -> hostA TCP http > 1443 [SYN, ACK] Seq=8404 Ack=9767 Win=5792 Len=0 hostA -> hostB TCP 1443 > http [ACK] Seq=9767 Ack=8405 Win=5840 Len=0 hostA -> hostB HTTP HEAD/HTTP/1.1 hostB -> hostA TCP http > 1443 [ACK] Seq=8405 Ack=9985 Win=54 Len=0 hostB -> hostA HTTP HTTP/1.1 200 OK hostA -> hostB TCP 1443 > http [ACK] Seq=9985 Ack=8672 Win=6432 Len=0 hostB -> hostA TCP http > 1443 [FIN, ACK] Seq=8672 Ack=9985 Win=54 Len=0 hostA -> hostB TCP 1443 > http [FIN, ACK] Seq=9985 Ack=8673 Win=6432 Len=0 hostB -> hostA TCP http > 1443 [ACK] Seq=8673 Ack=9986 Win=54
In this trace, the sequence number represents the serial number of
the first byte of data in the segment. So in the first line, a random
value of 9766 was assigned to the first byte and all subsequent bytes
for the connection from this host will be sequentially tracked. This
makes the second byte in the segment number 9767, the third number 9768
etc. The acknowledgment number or Ack, not to be confused with the ACK
bit, is the byte serial number of the next segment it expects to
receive from the other end, and the total number of bytes cannot exceed
the Win or window value that follows it. If data isn't received
correctly, the receiver will re-send the requesting segment asking for
the information to be sent again. The TCP code keeps track of all this
along with the source and destination ports and IP addresses to ensure
that each unique connection is serviced correctly.
UDP, TCP's "Connectionless" Cousin:
UDP is a connectionless protocol. Data is sent on a "best effort"
basis with the machine that sends the data having no means of verifying
whether the data was correctly received by the remote machine. UDP is
usually used for applications in which the data sent is not
mission-critical. It is also used when data needs to be broadcast to all
available servers on a locally attached network where the creation of
dozens of TCP connections for a short burst of data is considered
resource-hungry.
TCP and UDP Ports:
The data portion of the IP packet contains a TCP or UDP segment sandwiched inside. Only the TCP segment header contains sequence information, but both the UDP and the TCP segment headers track the port being used. The source/destination port and the source/destination IP addresses of the client & server computers are then combined to uniquely identify each data flow.
Certain programs are assigned specific ports that are
internationally recognized. For example, port 80 is reserved for HTTP
Web traffic, and port 25 is reserved for SMTP e-mail. Ports below 1024
are reserved for privileged system functions, and those above 1024 are
generally reserved for non-system third-party applications.
Usually when a connection is made from a client computer requesting data to the server that contains the data:
- The client selects a random previously unused "source" port greater than 1024 and queries the server on the "destination" port specific to the application. If it is an HTTP request, the client will use a source port of, say, 2049 and query the server on port 80 (HTTP)
- The server recognizes the port 80 request as an HTTP request and passes on the data to be handled by the Web server software. When the Web server software replies to the client, it tells the TCP application to respond back to port 2049 of the client using a source port of port 80.
- The client keeps track of all its requests to the server's IP address and will recognize that the reply on port 2049 isn't a request initiation for "NFS", but a response to the initial port 80 HTTP query.
Each IP packet has a Time to Live (TTL) section that keeps track of
the number of network devices the packet has passed through to reach its
destination. The server sending the packet sets the initial TTL value,
and each network device that the packet passes through then reduces this
value by 1. If the TTL value reaches 0, the network device will discard
the packet.
This mechanism helps to ensure that bad routing on the Internet
won't cause packets to aimlessly loop around the network without being
removed. TTLs therefore help to reduce the clogging of data circuits
with unnecessary traffic.
Remember this concept as it will be helpful in understanding the traceroute troubleshooting technique.
The ICMP Protocol and Its Relationship to TCP/IP:
There is another commonly used protocol called the Internet Control Message Protocol (ICMP). It is not strictly a TCP/IP protocol, but TCP/IP-based applications use it frequently.
ICMP provides a suite of error, control, and informational
messages for use by the operating system. For example, IP packets will
occasionally arrive at a server with corrupted data due to any number of
reasons including a bad connection; electrical interference, or even
misconfiguration. The server will usually detect this by examining the
packet and correlating the contents to what it finds in the IP header's
error control section. It will then issue an ICMP reject message to the
original sending machine saying that the data should be re-sent because
the original transmission was corrupted.
ICMP also includes echo and echo reply messages used by the Linux
ping command to confirm network connectivity. ICMP TTL expired messages
are also sent by network devices back to the originating server
whenever the TTL in a packet is decremented to zero.

Comments
Post a Comment