TRANSMISSION CONTROL PROTOCOL/INTERNET
PROTOCOL (TCP/IP)
In the 1970s, the Department of Defense commissioned the development of the
TCP/IP suite of protocols to provide interoperability among computers. The protocols
emerged from research that spanned three decades. ARPANET, as it was
called in its early days, was a loosely confederated collection of networks operated
by colleges, universities, and defense-related companies and agencies.
In late 1989, the original ARPANET evolved into a network that subsequently
became the Internet. Internet is a collection of independent networks that are
interconnected to act as a coordinated unit. Commercial companies operate the
networks, but each is independent and no single body has overall control. The
IETF controls the structure of the protocols, which compensate for the unreliability
of the underlying IP network and insulate users from the need to understand
the network’s physical and addressing architecture.
The original Internet had four primary purposes:
_ To provide electronic mail service to the users
_ To support file transfer between hosts
_ To permit users to log on remote computers
_ To provide users with access to information databases
A TCP/IP Internet fits in a three-layer framework atop the physical and
datalink layers as shown in Figure 6-5, which compares TCP/IP to the OSI model.
The TCP/IP and OSI protocols do not correspond directly, and the boundaries
between layers are not identical, but they share the layered concept and have corresponding
functions. The application services layer defines the interface to the
TCP/IP network.
The primary application layer protocols are SMTP for e-mail, FTP for file
transfers, terminal emulation protocol (TELNET) to enable users to run commands
on a remote computer over the network, and HTTP to support database
access through Web browsers.
TCP/IP is a suite of protocols that coordinate to support an Internet, which is
a collection of network segments. Figure 6-6 illustrates broadly how a TCP/IP network
functions. The protocol stack runs on hosts that may be part of the same segment
or independent of each other. We assume that both hosts are connected to a
LAN, and that a router interfaces the LAN to a wide area network. A single carrier
may provide the WAN, or as the figure shows, the WANs may be separate and interconnected
with routers. Before any data can be transferred, TCP sets up a connection
with its peer at the receiving endpoint. The application, receiving an indication that
the connection is established and TCP is ready, sends a data stream across the interface.
TCP segments the data stream, appends a transport header, and hands it to IP.
The IP portion of the protocol appends a datagram header, which contains the
receiver’s IP address, and hands a packet stream to the router. The router consults its
tables, decides which route to use, and forwards the packet stream to the next router
in sequence until they reach the destination. TCP at the receiving host checks for
errors, acknowledges the packets, strips the headers, and hands the data stream to
the application. This section examines the principal protocols in more detail.
Transmission Control Protocol (TCP)
TCP is a connection-oriented guaranteed-delivery protocol that interoperates with
IP to deliver packets across a network. The transmitting and sending ends of the
circuit exchange setup packets to establish a connection before information packets
begin to flow. TCP/IP is independent of the physical medium. The protocol
makes use of the physical and datalink layers on the LAN. Between the LANs, the
WAN protocols handle packet transfer. TCP accepts data streams from the application
program, breaks them into datagram size, and hands them to IP for routing
across the network. TCP on the receiving end checks for errors, reassembles the
original data stream, and passes it to the application. TCP handles packet sequencing,
flow control, retransmission of errored or missing packets, and deletion of
duplicate packets. TCP can be used with a variety of packet level protocols, but it
is usually paired with IP.
TCP can support either go back-n or selective repeat packet acknowledgment.
Under go back-n, when the receiving end acknowledges packets, it sends the
sequence number of the next packet it is prepared to accept, which communicates
to the sender the number of the last correctly received packet. The sender transmits
the next packet in sequence plus all subsequent packets, whether they were
in error or not. Under selective acknowledgment, the receiver acknowledges
specific packets. The acknowledgment process provides a convenient method of
flow control known as “sliding-window.” If the receiving end has plenty of space
in its buffers, it sends a window message to the sender indicating how many
packets it is prepared to receive before it sends an acknowledgment. When the
buffer begins to overflow, it reduces the size of the window in its next acknowledgment.
In this way, the protocol keeps the sending end from overrunning its
buffer space and keeps the network operating at maximum throughput. At the
worst extreme, the receiver could acknowledge packets one at a time, which would
slow data transfer to a minimum.
The sending TCP sets a retransmit timer for each packet. This timer specifies
how long to wait for acknowledgment before assuming the packet failed to reach
the destination. When the timer expires, the sending host resends the packet
and waits twice as long as the time set in the preceding window. Each time an
acknowledgment is not received, the retransmit timer doubles. This process may
result in duplicate packets, so the receiving TCP host must be prepared to discover
and discard duplicates.
TCP delivers packets to specific ports or sockets depending on the application.
Both TCP and UDP, which is discussed next, use 16-bit values called port numbers
to identify the TOS requested by the application. Certain applications normally
use well-known ports. For example, FTP uses port 21, HTTP uses port 80, and
TELNET uses port 25. The port identification, which is contained in the TCP
header, aids the receiving application in identifying the type of data being
received.
User Datagram Protocol (UDP)
Error correction delays packet flow. To a data application, delay is either invisible
or appears as a longer response time, which may be annoying but does not affect
integrity. Voice and interactive video are less tolerant of delays. Too much delay
results in users talking over each other, making it difficult to communicate.
Furthermore, errors are inconsequential to voice and video. TCP, therefore, is not
an appropriate protocol for these time-sensitive applications. Voice and video, as
well as other protocols such as SNMP, use UDP for the transport protocol. UDP is
a connectionless protocol that contains no provision for error correction, packet
sequencing, or retransmission.
A UDP datagram has considerably less overhead than TCP. The header
contains only the source and destination ports, the length of the data block, and a
checksum for verifying the header. Voice and video packets are normally quite
small. To minimize transmission time, it is desirable to keep the transport header
as short as possible.
Internet Protocol (IP)
Routers at IP nodes usually have multiple paths for delivering packets. When a
packet arrives, a router reads the destination address, consults its internal routing
table to determine the appropriate route, and forwards the datagram over the
physical network to the destination. Routing tables are either static or dynamic.
Static tables are set in the router’s software and remain until they are reconfigured.
Static tables are appropriate when the router has a limited number of
choices, but they are inflexible and unable to adapt to changing circumstances.
Routers with dynamic tables exchange messages to keep each other updated with
network changes such as circuit failures and route reconfiguration.
An IP datagram contains a header that is 20 octets or more in length plus a
data field that can be up to 65,535 octets long. The maximum length permitted by
a network is called its maximum transfer unit (MTU). For example, Ethernet has an
MTU of 1500 octets. When it is necessary to send an IP datagram across a network
with a short MTU, IP divides the datagram into fragments and reassembles it at
the destination, a process called fragmentation.
IP is an unreliable best effort protocol. Each node along the network
attempts to forward packets to the next node, but if it is unsuccessful, it is permitted
to discard the packet. Routers attempt to forward messages to the destination
over the shortest path, but there is no assurance that a packet is always
heading toward its destination, so packets can arrive out of sequence. Every
packet contains a TTL counter that has a maximum value of 255 s. Each router that
forwards a datagram decrements the TTL by one. If a router receives a packet with
an expired TTL timer, it discards the packet. This process prevents undelivered
packets from traveling the Internet forever. A protocol known as Internet Control
Message Protocol (ICMP) reports errors and messages regarding datagram delivery
and alerts the sender when a destination is unreachable.
To clarify the way these protocols interact, assume an e-mail application
such as Microsoft Outlook originates an e-mail message and sends it to an e-mail
server across Ethernet. As shown in Figure 6-7, the application sends a data stream
to TCP, which chops it into packets, appends a TCP header, and sends it to IP for
routing. IP appends a header containing the sending and receiving addresses,
TOS, and other such information, and hands it to the Ethernet LLC. The LLC
appends a header containing, among other things, the receiving MAC address,
and arranges for transmission across the physical medium. If the sending driver
does not have the MAC address of the receiver in its cache memory, it sends an
Address Resolution Protocol (ARP) request, which is discussed later, to determine
it. The receiving MAC, recognizing its address, strips the Ethernet header and
passes the packet to IP, and on up to the mail server through TCP.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment