|
TCP/IP And Unix
In the early days of computing, operating systems were something the user built. Early computer systems came with a limited set of tools, which provided the capability to load, compile program routines, and perform basic I/O tasks. The “operating system” was developed by the programmer/users because everything was written in the assembler language specific to that computer (there was no Plug and Play in the early days). In the late 1960s, two fellows at Bell Labs, Dennis Ritchie and Ken Thompson, started working on a different approach to computer operating systems, known as UNIX. The goal was to develop a core operating system (the kernel) to manage the various hardware elements of the computer (CPU processing, memory management, storage I/O, and so on), plus an extensive set of tools that were easily ported to any hardware platform.
Although UNIX was the property of Bell Labs, it was made available to universities and research facilities for noncommercial use with no support. As a result of its wide distribution, a lab project became an operating system that was improved by a large community of academic programmers who saw its potential. The notion that “the documentation is the code” and that “programs should be small, and do one thing and do it well” came out of this giant collaborative effort. In 1974, some of the people involved with the development of ARPAnet and TCP/IP saw a similar synergy between UNIX and TCP/IP. Along with the integration of TCP/IP protocols into ARPAnet, an effort was started at the University of California at Berkeley to integrate TCP/IP into the UNIX implementation. This beta (experimental) TCP/IP stack was introduced in 1981 as the Berkeley Software Distribution (BSD) 4.1a release, and the production stack was BSD 4.2. The result of this integration enabled the majority of ARPAnet sites to connect through TCP/IP. Along with its status as a government standard, TCP/IP's wide use in the UNIX operating system ensured its place as the de facto networking standard.
| | | Layer 4: TCP and UDPTransmission Control Protocol (TCP) and User
Datagram Protocol (UDP) are the transport protocols (OSI Layer 4) for the TCP/IP
protocol suite. The transport layer, as you might recall, provides
the network-independent process connection services between host client/server applications.
These processes can be connection-oriented (similar to making a phone call),
an immediate point-to-point communication, or connectionless, like sending
a letter through the mail. After it is sent, it might or might not arrive
within a reasonable time frame, and if it gets lost, you can always send another. Connection-oriented processes are point-to-point communication streams.
These connections are thought of as virtual circuits (VCs).
Each VC connection is distinct and used only for host-to-host communication
for a single process. In other words, a host with multiple TCP communication
sessions would have a separate VC for each process. Connection-oriented transports
are used for interapplication communication processes that have the following
requirements: Dedicated connection setup and maintenance Delivery acknowledgment (by the destination host) Guaranteed byte-stream sequencing
Connectionless transport processes use standalone message units or datagrams to transport
interapplication data. Connectionless transport is faster than connection-
oriented transport because it does not have the flow control and data integrity
mechanisms. Connectionless transport is used when the application is looking
for fast data transport and needs to control the transmission process, such
as with remote file and print services and fast query response transactions.
The hallmarks of connectionless transport are as follows: The transport layer as a whole represents
the gateway of the host level communication process. The transport bridges
the internal data communication process and the network data communication
process. This is evident in the fact that the process of encapsulating the
application layer data into and out of wrappers occurs at this level. Figure 2.14 shows the relationship between the
layers and the wrapping of the data. This wrapping of ULP data is an outbound/inbound process. The ULP data follows this passthrough
process on leaving the source host and then follows the reverse on its arrival
at the destination host: Data stream is handed to the transport layer. ULP data is wrapped in the transport packet, which consists
of a header and the data. The transport packet is handed to the network layer. At the network layer, the transport packet is wrapped in the
network packet, which consists of the network header and the transport packet. The network packet is handed to the data link layer. At the data link layer, the network packet is wrapped in a
header and footer that are appropriate to the data-link protocol.
After the destination host receives the network packet, the process
is reversed and the data is handed back to the ULP. Remember that the transport protocol is
independent from the ULP and the LLP (Lower Layer Protocols). Its job is only
to provide data transport. The actual delivery is in part a joint effort between
the ULP and the LLP. TCP provides connection-oriented data
transport over dedicated process owned by a VC. It works over almost any type
of network and is designed to provide reliable data transport between nodes
over unreliable network delivery services. For TCP, reliable transport
means in-sequence, adjustable-rate, and error-free transmission of ULP data. TCP provides the following services to facilitate these transport goals: Full duplex—TCP connections are bidirectional. Continuous
data flow is provided to communicating with the ULPs. Data sequencing—Data is delivered to the ULP in the
byte order in which it was sent. TCP provides for transport level and below
data fragmentation. TCP assigns sequence numbers for each ULP data segment.
These sequence numbers are used at the peer end of the TCP session to reassemble
the ULP data back into its original form. If a sequence is lost, the peer
requests it to be resent, and the data is not sent to the ULP until all the
data is reassembled. Flow control—TCP uses a sliding window strategy to transmit
data. TCP establishes the speed of the entire path at the start of the session.
It then creates a window whose size is based on the speed of the path between
the source and destination. TCP uses the window to frame the amount of data
it will send at one time and uses the sequencing numbers to keep track of
each byte it transmits. TCP sends a burst of data and waits for confirmation
from the peer that all the data has been received. If no response is received,
TCP will retransmit the data until it gets an acknowledgment that the peer
has received all the data. TCP uses timers (to measure
between when the data was sent and the acknowledgment was received) to adjust
the size of the window to reflect changes in the path speed. TCP will always
send data at the rate of the slowest link. Error correction—TCP uses checksums to ensure that the
data is error free. Timely service notification—If conditions prevent the
maintenance of the required service, TCP will notify the ULP of the condition
and follow
the ULP response.
TCP uses the abstraction of ports (also referred to as sockets) to
describe its transport scheme. These ports are used by the hosts to establish
TCP VCs over which they can exchange ULP data. After the data exchange session
is complete, the TCP VC is torn down, and the ports are free to be used to
establish a TCP VC with another host. There are no rules for which ports are used to establish connections,
but there are a set of “known” reserved ports that are used for
services providing known application layer communication services. All ports
under 1024 are reserved for server use. For example, the SMTP listens on TCP
port 25, the Telnet service listens on port 23, and HTTP, the protocol used
for sending WWW data, listens on port 80. TCP establishes these client/server
interapplication connections using a three-way handshake connection scheme.
This process allows both sides to synchronize and establish the process endpoints. Figure 2.15 illustrates this connection process. To set up a TCP connection, the client host sends a SYN (synchronization) packet to the application
service port. The server host then sends a SYN and an ACK (acknowledgment)
to the client's originating TCP port confirming that the connection is established.
The client then sends an ACK back to the server. Now the dedicated VC is established
and full duplex data exchange can take place. TCP ports can support many simultaneous connections or processes. TCP
keeps these processes organized by using the process endpoints to track the
connections. The endpoint address is the process port number plus the IP address
of the host that started the connection. In this example, the process endpoint
on the server would be 192.160.33.20.2200 and the process endpoint on the
client would be 90.16.44.8.25. The most common TCP service ports are listed
in Table 2.12. Table 2.12. Common TCP Service Ports| Port Number | Service |
|---|
| 1 | TCPMUX | | 21 | FTP | | 20 | FTP-DATA | | 22 | SSH (Secure Shell) | | 23 | Telnet | | 25 | SMTP | | 53 | DNS (Domain Name Service) | | 80 | HTTP (WWW) | | 139 | WINS | | 119 | NNTP (Network News Transport Protocol) | | 110 | POP3 (Post Office Protocol) | | 543 | Klogin (Kerberos login) | | 544 | Kshell (Kerberos shell) | | 751 | Kpasswd
(Kerberos password) | | 750 | Kerberos server | | 512 | Berkeley rcommands | | 513 | login | | 443 | HTTPS
secure WWW server | | 2105 | eklogin (encrypted
Kerberos login) | | 2049 | NFS (Network File
System) |
The TCP header provides the means for communication about the TCP process between the
two TCP endpoints. The header (as shown in Figure
2.16) provides the data sequencing and acknowledgment information,
and serves as the facility for connection setup and disconnection. The TCP packet can be up to 65KB in size. Because TCP is network independent, packet size
limitation is not a priority. IP fragments the TCP packets into sizes it can
transport efficiently. The TCP header is 40 bytes in size, which is rather
large for a network packet header. The header is so large because it needs
to carry all the data control information. The header dedicates memory segments or fields to provide the information
needed to deliver and reassemble
the ULP data into an unaltered state. These fields are as follows: Source Port—This is the TCP port the process
is coming from. Destination Port—This is the TCP port the process
is sending data to. Sequence Number—This is the sequence number
for data contained in the packet. Acknowledgment Number—This field contains
the sequence number the sender expects to receive from the destination. Data Offset—This field indicates how large the TCP
header is. Control flags indicate the status of the TCP connection: SYN sets up TCP connections. ACK indicates if the information in the Acknowledgment field is relevant. RST resets TCP connections. PSH tells the destination that the DATA should be
delivered to the ULP upon delivery. FIN ends the TCP connection.
Window—This field is used to provide flow control information.
The value is the amount of
data the sender can accept.
|
|
| | | UDPThe connectionless transport service
of the TCP/IP protocol suite is user datagram protocol (UDP).
UDP uses the same port process abstraction that TCP uses. Its function is
to provide low-overhead, fast-transport service for ULP data transport. UDP
has none of the flow control and data synchronization mechanisms that TCP
offers. It processes one packet at a time and offers best-effort delivery
service. The UDP header (see Figure 2.17) is 32 bits long
and contains information on the source and destination ports, the packet size,
and an optional checksum for applications that require checksum support (BOOTP
and DHCP). Like TCP, UDP has a set of reserved ports used for different application
server data exchange points. The most commonly used UDP ports are shown in Table 2.13. Table 2.13. Commonly Used UDP Ports| Port Number | Service |
|---|
| 49 | TACACS authentication server | | 53 | DNS (Domain Name Service) | | 67 | BOOTP server | | 68 | BOOTP
client | | 69 | TFTP | | 137 | NetBIOS name service | | 138 | NetBIOS
datagram service | | 123 | NTP (Network Time
Protocol) | | 161 | SNMP (Simple Network
Management Protocol) | | 1645 | RADIUS authentication
server | | 1646 | RADIUS accounting server | | 2049 | NFS (Network File System) |
These ports are used by application layer servers to listen for UDP
datagrams from client applications on network hosts. Although the port abstraction
is similar to that of TCP, there is no VC “continuous datastream”
connection with UDP. In the case of client/server applications, the server
accepts datagrams on the known UDP port on a packet-by-packet basis. Server replies to client queries are returned
using the same packet-by-packet, best-effort delivery process. |
|
| | | The Application Layer Protocols of the TCP/IP SuiteNow that you have an understanding of how the network and transport
layers of the TCP/IP suite function, take a look at the application layer
protocols and services that make the network useful. The following sections outline the major application protocols. File Transfer Protocol (FTP) is used to exchange data between
two undefined hosts. FTP is uninterested in the types of hosts exchanging
data. Two TCP connections, ftp- control (TCP port 21) and ftp-data (TCP port
20), are used to perform the data exchange. FTP uses a host-authenticated
interactive client/server model. The client connects to the known ports, and
the server establishes the session(s) on the client's requesting port address. Trivial File Transfer Protocol (TFTP) is a
simple data exchange program. It is well suited for applications that require
basic file transfer service. TFTP uses a simple unauthenticated
client/server model. Because it is designed to operate under the simplest
conditions, it uses UDP. The server listens on UDP port 69. TFTP is primarily
used for bootstrap applications such as booting diskless workstations and
networking equipment. TFTP is also used for uploading and downloading configuration
and OS files to networking equipment that use flash and NVRAM memory for storage. Telnet is used to provide a
dedicated host-to-host communication session. It uses a connection-oriented
8-bit byte session to exchange character data. Its primary function is to
provide remote terminal service. To maintain host/terminal independence, the
Telnet protocol is assisted by network virtual terminal service
(NVT), as shown in Figure 2.18. An NVT is a pseudo-device that provides a standard terminal interface
used by both client and server. The NVT acts as a translation bridge between
the client and server by translating the local terminal commands into commands
that work on the remote system's terminal. Like FTP, it uses a host-authenticated interactive client/server model.
The server operates on TCP port 23. Like FTP, the client requests the service
at the known port and the server responds to the client's requesting port. Simple Mail Transfer Protocol (SMTP) is
the process for exchanging electronic mail between hosts. SMTP defines how
messages are passed from host to host. It is generally a noninteractive,
nonauthenticating client/server event and operates on TCP port 25. SMTP is
only involved with the activity of passing electronic mail, specifically the
address translation and formatting. How the mail is composed, sent, and stored
is managed by other protocols. The most common associated mail protocol is
Post Office Protocol (POP). Domain Name Service (DNS) is one of the most complex application
layer protocols of the TCP/IP suite. DNS provides the function of translating
the IP addresses of a host connected to the Internet into meaningful human
understandable names. DNS uses a tree-like naming structure to provide a naming
hierarchy. The upper level deals with the universal hierarchy, such as root:country:state:organization
(see Figure 2.19). At the organizational level, the domains are segmented into locally
administered domains and subdomains. These subdomains provide name translation for themselves and the branches below
them (see Figure 2.20). When a domain name request is made for a host outside of the locally
administered domain, the request is relayed to a caching DNS server or to
the server that is responsible for providing hostnames for the requested domain.
The DNS service uses both TCP and UDP for service delivery. TCP port 53 is used for server-to-server
data transfers. The data consists of the forward (hostname to IP address)
and reverse (IP address to hostname) translation files. Name requests are
performed using UDP. In order for a host to exchange data with other hosts, each host must
have its own distinct IP address. Reverse Address
Resolution Protocol (RARP) is the simplest
way to provide IP addresses to hosts. The server listens to broadcasts sent
across the Ethernet segment. If it receives a broadcast from a host with an
Ethernet address that it knows, it responds to the broadcast with the IP address
of the requesting host. This is great if all that's needed is an IP address,
and if the host and server are on the same Ethernet segment. RARP's functional
shortcomings leave it little place in today's networks. BOOTP, on the other hand, picks up where RARP leaves off. BOOTP uses
IP to provide IP configuration and boot service, hence the name BOOTP, for bootstrapping
protocol. The requesting host sends a BOOTP request, which is either answered by
a BOOTP server that has a configuration for the requesting station, or the
request is relayed to a BOOTP server on another Ethernet segment that contains
the host configuration information. The BOOTP server runs as a UDP service on port 68. Although there is
no interactive authentication, hosts must be configured in the BOOTP server
database and have corresponding BOOTP images in the TFTP server for the BOOTP
service to work. After the configuration information has been transferred
to the host, the BOOTP server then directs the host to the TFTP server where
the actual boot file resides. This boot file is then downloaded through TFTP and used to boot the
host. BOOTP provides more services than RARP, so the two cannot be compared
directly. BOOTP's capability to provide all the network configuration information
(default gateway, DNS servers, and so on), its capability to boot the host
from a remote server, and its capability to have service requests relayed
across separate Ethernet cable segments make BOOTP more versatile than RARP.
In terms of providing IP addresses to hosts, BOOTP is a better choice because
it uses IP and does not have
the direct hardware access requirement RARP has. BOOTP does not work well
in environments that are constantly changing (in other words, lots of laptops)
and where configuration information needs to be changed on a constant basis. Dynamic Host Configuration Protocol (DHCP) provides
IP host configuration services dynamically with no host configuration requirements.
To use DHCP, the host's IP implementation must support configuration
by DHCP. As with BOOTP, the host makes a DHCP broadcast request and the DHCP
server replies with configuration information. DHCP is different from BOOTP
in that the configuration information provided to the host is only temporary.
DHCP provides addresses to hosts in the form of leases. These
leases have limited life spans that are set by the server administrator. This
way, IP addresses are recycled as systems come on and leave the network. The
DHCP server operates on UDP port 68 and, like BOOTP, operates on an unauthenticated
client/server process. NOTE BOOTP needs to be supported by the host device. The IP address can be
entered in the host's boot flash, either obtained through RARP or by using
an IP broadcast (255.255.255.255) and the Ethernet address (like RARP) to
map the address. |
|
| | | RFCsRequests for Comments (RFCs) are the building blocks
of the Internet. All the protocols, applications, and standard operating procedures
(SOPs) start as RFCs. These comment documents are then taken by various standards
bodies and individuals and reviewed, implemented, and eventually published
as standards. The RFC process is the cornerstone of the open systems approach.
The following is a list of RFCs relevant to the topics covered in this chapter.
A good online resource for RFCs is http://www.it.kth.se/docs/rfc/.
|
|
|
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}