1264 lines
36 KiB
HTML
1264 lines
36 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>TCP/IP Networks</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Network Administrators Guide"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Introduction to Networking"
|
|
HREF="x-087-2-intro.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="History"
|
|
HREF="x-087-2-intro.history.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="UUCP Networks"
|
|
HREF="x-087-2-intro.uucp.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux Network Administrators Guide</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x-087-2-intro.history.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 1. Introduction to Networking</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x-087-2-intro.uucp.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP"
|
|
>1.2. TCP/IP Networks</A
|
|
></H1
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
Modern networking applications require a sophisticated approach to
|
|
carrying data from one machine to another. If you are managing a Linux
|
|
machine that has many users, each of whom may wish to simultaneously
|
|
connect to remote hosts on a network, you need a way of allowing them
|
|
to share your network connection without interfering with each
|
|
other. The approach that a large number of modern networking protocols
|
|
uses is called <I
|
|
CLASS="EMPHASIS"
|
|
>packet-switching</I
|
|
>. A
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>packet</I
|
|
> is a small chunk of data that is
|
|
transferred from one machine to another across the network. The
|
|
switching occurs as the datagram is carried across each link in the
|
|
network. A packet-switched network shares a single network link among
|
|
many users by alternately sending packets from one user to another
|
|
across that link.</P
|
|
><P
|
|
> The solution that
|
|
Unix systems, and subsequently many non-Unix systems, have adopted is
|
|
known as TCP/IP. When talking about TCP/IP networks you will hear the
|
|
term <I
|
|
CLASS="EMPHASIS"
|
|
>datagram</I
|
|
>, which technically has a special
|
|
meaning but is often used interchangeably with
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>packet</I
|
|
>. In this section, we will have a look at
|
|
underlying concepts of the TCP/IP protocols.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.INTRO"
|
|
>1.2.1. Introduction to TCP/IP Networks</A
|
|
></H2
|
|
><P
|
|
>
|
|
TCP/IP traces its origins to a research project funded by the United States
|
|
Defense Advanced Research Projects Agency (DARPA) in 1969. The ARPANET was an
|
|
experimental network that was converted into an operational one in 1975 after
|
|
it had proven to be a success.</P
|
|
><P
|
|
>
|
|
|
|
In 1983, the new protocol suite TCP/IP was adopted as a standard, and
|
|
all hosts on the network were required to use it. When ARPANET
|
|
finally grew into the Internet (with ARPANET itself passing out of
|
|
existence in 1990), the use of TCP/IP had spread to networks beyond
|
|
the Internet itself. Many companies have now built corporate TCP/IP
|
|
networks, and the Internet has grown to a point at which it could
|
|
almost be considered a mainstream consumer technology. It is difficult
|
|
to read a newspaper or magazine now without seeing reference to the
|
|
Internet; almost everyone can now use it.</P
|
|
><P
|
|
> For something concrete to look at as we
|
|
discuss TCP/IP throughout the following sections, we will consider
|
|
Groucho Marx University (GMU), situated somewhere in Fredland, as an
|
|
example. Most departments run their own Local Area Networks, while
|
|
some share one and others run several of them. They are all
|
|
interconnected and hooked to the Internet through a single high-speed
|
|
link.</P
|
|
><P
|
|
> Suppose your Linux box is connected to a LAN of Unix hosts at the Mathematics
|
|
department, and its name is <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>erdos</SPAN
|
|
>. To
|
|
access a host at the Physics department, say
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>,
|
|
you enter the following command:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>$ <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>rlogin quark.physics</B
|
|
></TT
|
|
>
|
|
Welcome to the Physics Department at GMU
|
|
(ttyq2) login:</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>
|
|
At the prompt, you enter your login name, say
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>andres</SPAN
|
|
>, and your password. You are then
|
|
given a shell<A
|
|
NAME="X-087-2-FNIT02"
|
|
HREF="#FTN.X-087-2-FNIT02"
|
|
>[1]</A
|
|
> on <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>, to which you
|
|
can type as if you were sitting at the system's console. After you exit the
|
|
shell, you are returned to your own machine's prompt. You have just used one
|
|
of the instantaneous, interactive applications that TCP/IP provides: remote
|
|
login.</P
|
|
><P
|
|
>
|
|
|
|
|
|
While being logged into <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>,
|
|
you might also want to run a graphical user interface application,
|
|
like a word processing program, a graphics drawing program, or even a
|
|
World Wide Web browser. The X windows system is a fully network-aware
|
|
graphical user environment, and it is available for many different
|
|
computing systems. To tell this application that you want to have its
|
|
windows displayed on your host's screen, you have to set the
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>DISPLAY</SPAN
|
|
> environment variable:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>$ <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>DISPLAY=erdos.maths:0.0</B
|
|
></TT
|
|
>
|
|
$ <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>export DISPLAY</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>If you now start your application, it will contact your X server instead of
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>'s, and display all its windows
|
|
on your screen. Of course, this requires that you have X11 runnning on
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>erdos</SPAN
|
|
>. The point here is that TCP/IP
|
|
allows <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>erdos</SPAN
|
|
> to send X11 packets back and
|
|
forth to give you the illusion that you're on a single system. The network
|
|
is almost transparent here.</P
|
|
><P
|
|
>
|
|
Another very important application in TCP/IP networks is NFS, which
|
|
stands for <I
|
|
CLASS="EMPHASIS"
|
|
>Network File System</I
|
|
>. It is another
|
|
form of making the network transparent, because it basically allows
|
|
you to treat directory hierarchies from other hosts as if they
|
|
were local file systems and look like any other directories on your
|
|
host. For example, all users' home directories can be kept on a
|
|
central server machine from which all other hosts on the LAN mount
|
|
them. The effect is that users can log in to any machine and find
|
|
themselves in the same home directory. Similarly, it is possible to
|
|
share large amounts of data (such as a database, documentation or
|
|
application programs) among many hosts by maintaining one copy of
|
|
the data on a server and allowing other hosts to access it. We will
|
|
come back to NFS in <A
|
|
HREF="x-087-2-nfs.html"
|
|
>Chapter 14</A
|
|
>.</P
|
|
><P
|
|
>Of course, these are only examples of what you can do with TCP/IP networks.
|
|
The possibilities are almost limitless, and we'll introduce you to more as you
|
|
read on through the book.</P
|
|
><P
|
|
>We will now have a closer look at the way TCP/IP works. This information will
|
|
help you understand how and why you have to configure your machine. We will
|
|
start by examining the hardware, and slowly work our way up.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.HISTORY"
|
|
>1.2.2. Ethernets</A
|
|
></H2
|
|
><P
|
|
>
|
|
|
|
The most common type of LAN hardware is known as <I
|
|
CLASS="EMPHASIS"
|
|
>Ethernet</I
|
|
>.
|
|
In its simplest form, it consists of a single cable with hosts attached to it
|
|
through connectors, taps, or transceivers. Simple Ethernets are relatively
|
|
inexpensive to install, which together with a net transfer rate of 10, 100,
|
|
or even 1,000 Megabits per second, accounts for much of its popularity.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
Ethernets come in three flavors: <I
|
|
CLASS="EMPHASIS"
|
|
>thick</I
|
|
>,
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>thin</I
|
|
>, and <I
|
|
CLASS="EMPHASIS"
|
|
>twisted pair</I
|
|
>.
|
|
Thin and thick Ethernet each use a coaxial cable, differing in
|
|
diameter and the way you may attach a host to this cable. Thin
|
|
Ethernet uses a T-shaped “BNC” connector, which you insert
|
|
into the cable and twist onto a plug on the back of your computer.
|
|
Thick Ethernet requires that you drill a small hole into the cable,
|
|
and attach a transceiver using a “vampire tap.” One or
|
|
more hosts can then be connected to the transceiver. Thin and thick
|
|
Ethernet cable can run for a maximum of 200 and 500 meters
|
|
respectively, and are also called 10base-2 and 10base-5. The
|
|
“base” refers to “baseband modulation” and
|
|
simply means that the data is directly fed onto the cable without any
|
|
modem. The number at the start refers to the speed in Megabits per
|
|
second, and the number at the end is the maximum length of the cable
|
|
in hundreds of metres. Twisted pair uses a cable made of two pairs of
|
|
copper wires and usually requires additional hardware known as
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>active hubs</I
|
|
>. Twisted pair is also known as
|
|
10base-T, the “T” meaning twisted pair. The 100 Megabits
|
|
per second version is known as 100base-T.</P
|
|
><P
|
|
>To add a host to a thin Ethernet installation, you have to disrupt
|
|
network service for at least a few minutes because you have to cut the
|
|
cable to insert the connector. Although adding a host to a thick
|
|
Ethernet system is a little complicated, it does not typically bring
|
|
down the network. Twisted pair Ethernet is even simpler. It uses a
|
|
device called a “hub,” which serves as an interconnection
|
|
point. You can insert and remove hosts from a hub without interrupting
|
|
any other users at all.</P
|
|
><P
|
|
>Many people prefer thin Ethernet for small networks because it is very
|
|
inexpensive; PC cards come for as little as US $30 (many
|
|
companies are literally throwing them out now), and cable is in the
|
|
range of a few cents per meter. However, for large-scale
|
|
installations, either thick Ethernet or twisted pair is more
|
|
appropriate. For example, the Ethernet at GMU's Mathematics Department
|
|
originally chose thick Ethernet because it is a long route that the
|
|
cable must take so traffic will not be disrupted each time a host
|
|
is added to the network. Twisted pair installations are now very
|
|
common in a variety of installations. The Hub hardware is dropping in
|
|
price and small units are now available at a price that is attractive
|
|
to even small domestic networks. Twisted pair cabling can be
|
|
significantly cheaper for large installations, and the cable itself is
|
|
much more flexible than the coaxial cables used for the other Ethernet
|
|
systems. The network administrators in GMU's mathematics department
|
|
are planning to replace the existing network with a twisted pair
|
|
network in the coming finanical year because it will bring them up to
|
|
date with current technology and will save them significant time when
|
|
installing new host computers and moving existing computers around.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
One of the drawbacks of Ethernet technology is its limited cable length, which
|
|
precludes any use of it other than for LANs. However, several Ethernet
|
|
segments can be linked to one another using repeaters, bridges, or routers.
|
|
Repeaters simply copy the signals between two or more segments so that all
|
|
segments together will act as if they are one Ethernet. Due to timing
|
|
requirements, there may not be more than four repeaters between any two hosts
|
|
on the network. Bridges and routers are more sophisticated. They analyze
|
|
incoming data and forward it only when the recipient host is not on the local
|
|
Ethernet.</P
|
|
><P
|
|
>
|
|
Ethernet works like a bus system, where a host may send packets (or
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>frames</I
|
|
>) of up to 1,500 bytes to another host on the same
|
|
Ethernet. A host is addressed by a six-byte address hardcoded into the
|
|
firmware of its Ethernet network interface card (NIC). These addresses are
|
|
usually written as a sequence of two-digit hex numbers separated by colons,
|
|
as in <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>aa:bb:cc:dd:ee:ff</SPAN
|
|
>.</P
|
|
><P
|
|
> A
|
|
frame sent by one station is seen by all attached stations, but only
|
|
the destination host actually picks it up and processes it. If two
|
|
stations try to send at the same time, a
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>collision</I
|
|
> occurs. Collisions on an Ethernet are
|
|
detected very quickly by the electronics of the interface cards and
|
|
are resolved by the two stations aborting the send, each waiting a
|
|
random interval and re-attempting the transmission. You'll hear lots
|
|
of stories about collisions on Ethernet being a problem and that
|
|
utilization of Ethernets is only about 30 percent of the available
|
|
bandwidth because of them. Collisions on Ethernet are a
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>normal</I
|
|
> phenomenon, and on a very busy Ethernet
|
|
network you shouldn't be surprised to see collision rates of up to
|
|
about 30 percent. Utilization of Ethernet networks is more
|
|
realistically limited to about 60 percent before you need to start
|
|
worrying about it.<A
|
|
NAME="X-087-2-FNIT03"
|
|
HREF="#FTN.X-087-2-FNIT03"
|
|
>[2]</A
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.OTHER-HARDWARE"
|
|
>1.2.3. Other Types of Hardware</A
|
|
></H2
|
|
><P
|
|
>In larger installations, such as Groucho Marx University, Ethernet is usually
|
|
not the only type of equipment used. There are many other data communications
|
|
protocols available and in use. All of the protocols listed are supported by
|
|
Linux, but due to space constraints we'll describe them briefly. Many of the
|
|
protocols have HOWTO documents that describe them in detail, so you should
|
|
refer to those if you're interested in exploring those that we don't describe
|
|
in this book.</P
|
|
><P
|
|
>
|
|
|
|
At Groucho Marx University, each department's LAN is linked to the
|
|
campus high-speed “backbone” network, which is a fiber
|
|
optic cable running a network technology called <I
|
|
CLASS="EMPHASIS"
|
|
>Fiber
|
|
Distributed Data Interface</I
|
|
> (FDDI). FDDI uses an entirely
|
|
different approach to transmitting data, which basically involves
|
|
sending around a number of <I
|
|
CLASS="EMPHASIS"
|
|
>tokens</I
|
|
>, with a station
|
|
being allowed to send a frame only if it captures a token. The main
|
|
advantage of a token-passing protocol is a reduction in collisions.
|
|
Therefore, the protocol can more easily attain the full speed of the
|
|
transmission medium, up to 100 Mbps in the case of FDDI. FDDI, being
|
|
based on optical fiber, offers a significant advantage because its
|
|
maximum cable length is much greater than wire-based technologies. It
|
|
has limits of up to around 200 km, which makes it ideal for linking
|
|
many buildings in a city, or as in GMU's case, many buildings on a
|
|
campus.</P
|
|
><P
|
|
> Similarly, if there is any IBM
|
|
computing equipment around, an IBM Token Ring network is quite likely
|
|
to be installed. Token Ring is used as an alternative to Ethernet in
|
|
some LAN environments, and offers the same sorts of advantages as FDDI
|
|
in terms of achieving full wire speed, but at lower speeds (4 Mbps or
|
|
16 Mbps), and lower cost because it is based on wire rather than
|
|
fiber. In Linux, Token Ring networking is configured in almost
|
|
precisely the same way as Ethernet, so we don't cover it specifically.</P
|
|
><P
|
|
>Although it is much less likely today than in the past, other LAN
|
|
technologies, such as ArcNet and DECNet, might be installed. Linux
|
|
supports these too, but we don't cover them here.</P
|
|
><P
|
|
>
|
|
Many national networks operated by
|
|
Telecommunications companies support packet switching
|
|
protocols. Probably the most popular of these is a standard named
|
|
X.25. Many Public Data Networks, like Tymnet in the U.S., Austpac in
|
|
Australia, and Datex-P in Germany offer this service. X.25 defines a
|
|
set of networking protocols that describes how data terminal
|
|
equipment, such as a host, communicates with data communications
|
|
equipment (an X.25 switch). X.25 requires a synchronous data link, and
|
|
therefore special synchronous serial port hardware. It is possible to
|
|
use X.25 with normal serial ports if you use a special device called a
|
|
PAD (Packet Assembler Disassembler). The PAD is a standalone device
|
|
that provides asynchronous serial ports and a synchronous serial
|
|
port. It manages the X.25 protocol so that simple terminal devices can
|
|
make and accept X.25 connections. X.25 is often used to carry other
|
|
network protocols, such as TCP/IP. Since IP datagrams cannot simply be
|
|
mapped onto X.25 (or vice versa), they are encapsulated in X.25
|
|
packets and sent over the network. There is an experimental
|
|
implementation of the X.25 protocol available for Linux.</P
|
|
><P
|
|
>
|
|
A more recent protocol commonly offered by telecommunications
|
|
companies is called <I
|
|
CLASS="EMPHASIS"
|
|
>Frame Relay</I
|
|
>. The Frame Relay
|
|
protocol shares a number of technical features with the X.25 protocol,
|
|
but is much more like the IP protocol in behavior. Like X.25, Frame
|
|
Relay requires special synchronous serial hardware. Because of their
|
|
similarities, many cards support both of these protocols. An
|
|
alternative is available that requires no special internal hardware,
|
|
again relying on an external device called a Frame Relay Access Device
|
|
(FRAD) to manage the encapsulation of Ethernet packets into Frame
|
|
Relay packets for transmission across a network. Frame Relay is ideal
|
|
for carrying TCP/IP between sites. Linux provides drivers that support
|
|
some types of internal Frame Relay devices.</P
|
|
><P
|
|
>
|
|
If you need higher speed networking that can carry many different
|
|
types of data, such as digitized voice and video, alongside your usual
|
|
data, ATM (Asynchronous Transfer Mode) is probably what you'll be
|
|
interested in. ATM is a new network technology that has been
|
|
specifically designed to provide a manageable, high-speed, low-latency
|
|
means of carrying data, and provide control over the Quality of
|
|
Service (Q.S.). Many telecommunications companies are deploying ATM
|
|
network infrastructure because it allows the convergence of a number
|
|
of different network services into one platform, in the hope of
|
|
achieving savings in management and support costs. ATM is often used
|
|
to carry TCP/IP. The Networking-HOWTO offers information on the Linux
|
|
support available for ATM.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Frequently, radio amateurs use their radio equipment to network their
|
|
computers; this is commonly called <I
|
|
CLASS="EMPHASIS"
|
|
>packet
|
|
radio</I
|
|
>. One of the protocols used by amateur radio operators
|
|
is called AX.25 and is loosely derived from X.25. Amateur radio
|
|
operators use the AX.25 protocol to carry TCP/IP and other protocols,
|
|
too. AX.25, like X.25, requires serial hardware capable of synchronous
|
|
operation, or an external device called a “Terminal Node
|
|
Controller” to convert packets transmitted via an asynchronous
|
|
serial link into packets transmitted synchronously. There are a
|
|
variety of different sorts of interface cards available to support
|
|
packet radio operation; these cards are generally referred to as being
|
|
“Z8530 SCC based,” and are named after the most popular
|
|
type of communications controller used in the designs. Two of the
|
|
other protocols that are commonly carried by AX.25 are the NetRom and
|
|
Rose protocols, which are network layer protocols. Since these
|
|
protocols run over AX.25, they have the same hardware
|
|
requirements. Linux supports a fully featured implementation of the
|
|
AX.25, NetRom, and Rose protocols. The AX25-HOWTO is a good source of
|
|
information on the Linux implementation of these protocols.</P
|
|
><P
|
|
>Other types of Internet access involve dialing up a central system
|
|
over slow but cheap serial lines (telephone, ISDN, and so on). These
|
|
require yet another protocol for transmission of packets, such as SLIP
|
|
or PPP, which will be described later.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.IP"
|
|
>1.2.4. The Internet Protocol</A
|
|
></H2
|
|
><P
|
|
>
|
|
Of course, you wouldn't want your networking to be limited to one
|
|
Ethernet or one point-to-point data link. Ideally, you would want to
|
|
be able to communicate with a host computer regardless of what type of
|
|
physical network it is connected to. For example, in larger
|
|
installations such as Groucho Marx University, you usually have a
|
|
number of separate networks that have to be connected in some way. At
|
|
GMU, the Math department runs two Ethernets: one with fast machines
|
|
for professors and graduates, and another with slow machines for
|
|
students. Both are linked to the FDDI campus backbone network.</P
|
|
><P
|
|
>
|
|
|
|
|
|
This connection is handled by a dedicated host called a
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>gateway</I
|
|
> that handles incoming and outgoing
|
|
packets by copying them between the two Ethernets and the FDDI fiber
|
|
optic cable. For example, if you are at the Math department and want
|
|
to access <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
> on the
|
|
Physics department's LAN from your Linux box, the networking software
|
|
will not send packets to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>
|
|
directly because it is not on the same Ethernet. Therefore, it has to
|
|
rely on the gateway to act as a forwarder. The gateway (named
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>sophus</SPAN
|
|
>) then forwards these
|
|
packets to its peer gateway <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>niels</SPAN
|
|
> at the Physics department, using
|
|
the backbone network, with <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>niels</SPAN
|
|
> delivering it to the destination
|
|
machine. Data flow between <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>erdos</SPAN
|
|
> and <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
> is shown in <A
|
|
HREF="x-087-2-intro.tcpip.html#X-087-2-INTRO.FIG.IP-FLOW"
|
|
>Figure 1-1</A
|
|
>.</P
|
|
><DIV
|
|
CLASS="FIGURE"
|
|
><A
|
|
NAME="X-087-2-INTRO.FIG.IP-FLOW"
|
|
></A
|
|
><P
|
|
><B
|
|
>Figure 1-1. The three steps of sending a datagram from erdos to quark</B
|
|
></P
|
|
><P
|
|
><IMG
|
|
SRC="lag2_0101.jpg"></P
|
|
></DIV
|
|
><P
|
|
>
|
|
This scheme of directing data to a remote host is called
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>routing</I
|
|
>, and packets are often referred to as
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>datagrams</I
|
|
> in this context. To facilitate things,
|
|
datagram exchange is governed by a single protocol that is independent
|
|
of the hardware used: IP, or <I
|
|
CLASS="EMPHASIS"
|
|
>Internet Protocol</I
|
|
>.
|
|
In <A
|
|
HREF="x-087-2-issues.html"
|
|
>Chapter 2</A
|
|
>, we will cover IP and the issues of
|
|
routing in greater detail.</P
|
|
><P
|
|
>
|
|
|
|
The main benefit of IP is that it turns physically dissimilar networks into
|
|
one apparently homogeneous network. This is called internetworking, and the
|
|
resulting “meta-network” is called an
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>internet</I
|
|
>. Note the subtle difference here between
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>an</I
|
|
> internet and <I
|
|
CLASS="EMPHASIS"
|
|
>the</I
|
|
> Internet.
|
|
The latter is the official name of one particular global internet.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
Of course, IP also requires a hardware-independent addressing
|
|
scheme. This is achieved by assigning each host a unique 32-bit number
|
|
called the <I
|
|
CLASS="EMPHASIS"
|
|
>IP address</I
|
|
>. An IP address is usually
|
|
written as four decimal numbers, one for each 8-bit portion, separated
|
|
by dots. For example, <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>
|
|
might have an IP address of <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>0x954C0C04</SPAN
|
|
>, which would be written as
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>149.76.12.4</SPAN
|
|
>. This format is
|
|
also called <I
|
|
CLASS="EMPHASIS"
|
|
>dotted decimal notation</I
|
|
> and sometimes
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>dotted quad notation</I
|
|
>. It is increasingly going
|
|
under the name IPv4 (for Internet Protocol, Version 4) because a new
|
|
standard called IPv6 offers much more flexible addressing, as well as
|
|
other modern features. It will be at least a year after the release of
|
|
this edition before IPv6 is in use.</P
|
|
><P
|
|
>
|
|
You will notice that we now have three different types of addresses:
|
|
first there is the host's name, like <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>, then there are IP addresses, and
|
|
finally, there are hardware addresses, like the 6-byte Ethernet
|
|
address. All these addresses somehow have to match so that when you
|
|
type <B
|
|
CLASS="COMMAND"
|
|
>rlogin quark</B
|
|
>, the networking software can be
|
|
given <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>'s IP address; and
|
|
when IP delivers any data to the Physics department's Ethernet, it
|
|
somehow has to find out what Ethernet address corresponds to the IP
|
|
address.</P
|
|
><P
|
|
>We will deal with these situations in <A
|
|
HREF="x-087-2-issues.html"
|
|
>Chapter 2</A
|
|
>.
|
|
For now, it's enough to remember that these steps of finding addresses are
|
|
called <I
|
|
CLASS="EMPHASIS"
|
|
>hostname resolution</I
|
|
>, for mapping hostnames onto IP
|
|
addresses, and <I
|
|
CLASS="EMPHASIS"
|
|
>address resolution</I
|
|
>, for mapping the latter
|
|
to hardware addresses.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.SLIP"
|
|
>1.2.5. IP Over Serial Lines</A
|
|
></H2
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
On serial lines, a “de facto” standard exists known as SLIP, or
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>Serial Line IP</I
|
|
>. A modification of SLIP known as CSLIP,
|
|
or <I
|
|
CLASS="EMPHASIS"
|
|
>Compressed SLIP</I
|
|
>, performs compression of IP headers
|
|
to make better use of the relatively low bandwidth provided by most serial
|
|
links. Another serial protocol is PPP, or the
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>Point-to-Point Protocol</I
|
|
>. PPP is more modern than
|
|
SLIP and includes a number of features that make it more attractive. Its
|
|
main advantage over SLIP is that it isn't limited to transporting IP
|
|
datagrams, but is designed to allow just about any protocol to be carried
|
|
across it.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.TCP"
|
|
>1.2.6. The Transmission Control Protocol</A
|
|
></H2
|
|
><P
|
|
>
|
|
Sending datagrams from one host to another is not the whole story. If you
|
|
log in to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>, you want to have a
|
|
reliable connection between your <B
|
|
CLASS="COMMAND"
|
|
>rlogin</B
|
|
> process on
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>erdos</SPAN
|
|
> and the shell process on
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>. Thus, the information sent
|
|
to and fro must be split up into packets by the sender and reassembled into
|
|
a character stream by the receiver. Trivial as it seems, this involves a
|
|
number of complicated tasks.</P
|
|
><P
|
|
>A very important thing to know about IP is that, by intent, it is not
|
|
reliable. Assume that ten people on your Ethernet started downloading
|
|
the latest release of Netscape's web browser source code from GMU's
|
|
FTP server. The amount of traffic generated might be too much for the
|
|
gateway to handle, because it's too slow and it's tight on memory. Now
|
|
if you happen to send a packet to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>, <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>sophus</SPAN
|
|
> might be out of buffer space for a
|
|
moment and therefore unable to forward it. IP solves this problem by
|
|
simply discarding it. The packet is irrevocably lost. It is therefore
|
|
the responsibility of the communicating hosts to check the integrity
|
|
and completeness of the data and retransmit it in case of error.</P
|
|
><P
|
|
>This process is performed by yet another protocol, <I
|
|
CLASS="EMPHASIS"
|
|
>Transmission
|
|
Control Protocol</I
|
|
> (TCP), which builds a reliable service on top of IP. The
|
|
essential property of TCP is that it uses IP to give you the illusion of a
|
|
simple connection between the two processes on your host and the remote
|
|
machine, so you don't have to care about how and along which route your data
|
|
actually travels. A TCP connection works essentially like a two-way pipe that
|
|
both processes may write to and read from. Think of it as a telephone
|
|
conversation.</P
|
|
><P
|
|
>
|
|
TCP identifies the end points of such a connection by the IP addresses
|
|
of the two hosts involved and the number of a
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>port</I
|
|
> on each host. Ports may be viewed as
|
|
attachment points for network connections. If we are to strain the
|
|
telephone example a little more, and you imagine that cities are like
|
|
hosts, one might compare IP addresses to area codes (where numbers map
|
|
to cities), and port numbers to local codes (where numbers map to
|
|
individual people's telephones). An individual host may support many
|
|
different services, each distinguished by its own port number.</P
|
|
><P
|
|
> In the <B
|
|
CLASS="COMMAND"
|
|
>rlogin</B
|
|
> example, the client application
|
|
(<B
|
|
CLASS="COMMAND"
|
|
>rlogin</B
|
|
>) opens a port on <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>erdos</SPAN
|
|
> and connects to port 513 on
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>, to which the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>rlogind</B
|
|
> server is known to listen. This action
|
|
establishes a TCP connection. Using this connection,
|
|
<B
|
|
CLASS="COMMAND"
|
|
>rlogind</B
|
|
> performs the authorization procedure and
|
|
then spawns the shell. The shell's standard input and output are
|
|
redirected to the TCP connection, so that anything you type to
|
|
<B
|
|
CLASS="COMMAND"
|
|
>rlogin</B
|
|
> on your machine will be passed through the
|
|
TCP stream and be given to the shell as standard input.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.UDP"
|
|
>1.2.7. The User Datagram Protocol</A
|
|
></H2
|
|
><P
|
|
>
|
|
|
|
Of course, TCP isn't the only user protocol in TCP/IP networking. Although
|
|
suitable for applications like <B
|
|
CLASS="COMMAND"
|
|
>rlogin</B
|
|
>, the overhead
|
|
involved is prohibitive for applications like NFS, which instead uses a
|
|
sibling protocol of TCP called UDP, or
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>User Datagram Protocol</I
|
|
>. Just like TCP, UDP allows an
|
|
application to contact a service on a certain port of the remote machine, but
|
|
it doesn't establish a connection for this. Instead, you use it to send single
|
|
packets to the destination service—hence its name.</P
|
|
><P
|
|
>Assume you want to request a small amount of data from a database
|
|
server. It takes at least three datagrams to establish a TCP
|
|
connection, another three to send and confirm a small amount of data
|
|
each way, and another three to close the connection. UDP provides us
|
|
with a means of using only two datagrams to achieve almost the same
|
|
result. UDP is said to be connectionless, and it doesn't require us to
|
|
establish and close a session. We simply put our data into a datagram
|
|
and send it to the server; the server formulates its reply, puts the
|
|
data into a datagram addressed back to us, and transmits it
|
|
back. While this is both faster and more efficient than TCP for simple
|
|
transactions, UDP was not designed to deal with datagram loss. It is
|
|
up to the application, a name server for example, to take care of
|
|
this.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.PORTS"
|
|
>1.2.8. More on Ports</A
|
|
></H2
|
|
><P
|
|
> Ports may be viewed
|
|
as attachment points for network connections. If an application wants
|
|
to offer a certain service, it attaches itself to a port and waits for
|
|
clients (this is also called <I
|
|
CLASS="EMPHASIS"
|
|
>listening</I
|
|
> on the
|
|
port). A client who wants to use this service allocates a port on its
|
|
local host and connects to the server's port on the remote host. The
|
|
same port may be open on many different machines, but on each machine
|
|
only one process can open a port at any one time.</P
|
|
><P
|
|
>An important property of ports is that once a connection has been
|
|
established between the client and the server, another copy of the
|
|
server may attach to the server port and listen for more clients.
|
|
This property permits, for instance, several concurrent remote logins
|
|
to the same host, all using the same port 513. TCP is able to tell
|
|
these connections from one another because they all come from
|
|
different ports or hosts. For example, if you log in twice to
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
> from <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>erdos</SPAN
|
|
>, the first
|
|
<B
|
|
CLASS="COMMAND"
|
|
>rlogin</B
|
|
> client will use the local port 1023, and the
|
|
second one will use port 1022. Both, however, will connect to the same
|
|
port 513 on <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>quark</SPAN
|
|
>. The two
|
|
connections will be distinguished by use of the port numbers used at
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>erdos</SPAN
|
|
>.</P
|
|
><P
|
|
>
|
|
|
|
This example shows the use of ports as rendezvous points, where a client
|
|
contacts a specific port to obtain a specific service. In order for a client
|
|
to know the proper port number, an agreement has to be reached between the
|
|
administrators of both systems on the assignment of these numbers. For
|
|
services that are widely used, such as <B
|
|
CLASS="COMMAND"
|
|
>rlogin</B
|
|
>, these
|
|
numbers have to be administered centrally. This is done by the IETF
|
|
(Internet Engineering Task Force), which regularly releases an RFC titled
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>Assigned Numbers</I
|
|
> (RFC-1700). It describes, among other
|
|
things, the port numbers assigned to well-known services. Linux uses a file
|
|
called <TT
|
|
CLASS="FILENAME"
|
|
>/etc/services</TT
|
|
> that maps service names to
|
|
numbers.</P
|
|
><P
|
|
>It is worth noting that although both TCP and UDP connections rely on ports,
|
|
these numbers do not conflict. This means that TCP port 513, for example, is
|
|
different from UDP port 513. In fact, these ports serve as access points for
|
|
two different services, namely <B
|
|
CLASS="COMMAND"
|
|
>rlogin</B
|
|
> (TCP) and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>rwho</B
|
|
> (UDP).
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-INTRO.TCPIP.SOCKETS"
|
|
>1.2.9. The Socket Library</A
|
|
></H2
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In Unix operating systems, the software performing all the tasks and
|
|
protocols described above is usually part of the kernel, and so it is
|
|
in Linux. The programming interface most common in the Unix world is
|
|
the <I
|
|
CLASS="EMPHASIS"
|
|
>Berkeley Socket Library</I
|
|
>. Its name derives
|
|
from a popular analogy that views ports as sockets and connecting to
|
|
a port as plugging in. It provides the <TT
|
|
CLASS="FUNCTION"
|
|
>bind</TT
|
|
> call
|
|
to specify a remote host, a transport protocol, and a service that a
|
|
program can connect or listen to (using <TT
|
|
CLASS="FUNCTION"
|
|
>connect</TT
|
|
>,
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>listen</TT
|
|
>, and <TT
|
|
CLASS="FUNCTION"
|
|
>accept</TT
|
|
>). The
|
|
socket library is somewhat more general in that it provides not only a
|
|
class of TCP/IP-based sockets (the <TT
|
|
CLASS="FUNCTION"
|
|
>AF_INET</TT
|
|
>
|
|
sockets), but also a class that handles connections local to the
|
|
machine (the <TT
|
|
CLASS="FUNCTION"
|
|
>AF_UNIX</TT
|
|
> class). Some implementations
|
|
can also handle other classes, like the XNS (<I
|
|
CLASS="EMPHASIS"
|
|
>Xerox
|
|
Networking System</I
|
|
>) protocol or X.25.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In Linux, the socket library is part of the standard
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>libc</TT
|
|
> C library. It supports the
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>AF_INET</TT
|
|
> and <TT
|
|
CLASS="FUNCTION"
|
|
>AF_INET6</TT
|
|
> sockets
|
|
for TCP/IP and <TT
|
|
CLASS="FUNCTION"
|
|
>AF_UNIX</TT
|
|
> for Unix domain
|
|
sockets. It also supports <TT
|
|
CLASS="FUNCTION"
|
|
>AF_IPX</TT
|
|
> for Novell's
|
|
network protocols, <TT
|
|
CLASS="FUNCTION"
|
|
>AF_X25</TT
|
|
> for the X.25 network
|
|
protocol, <TT
|
|
CLASS="FUNCTION"
|
|
>AF_ATMPVC</TT
|
|
> and
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>AF_ATMSVC</TT
|
|
> for the ATM network protocol and
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>AF_AX25</TT
|
|
>, <TT
|
|
CLASS="FUNCTION"
|
|
>AF_NETROM</TT
|
|
>, and
|
|
<TT
|
|
CLASS="FUNCTION"
|
|
>AF_ROSE</TT
|
|
> sockets for Amateur Radio protocol
|
|
support. Other protocol families are being developed and will be
|
|
added in time.</P
|
|
></DIV
|
|
></DIV
|
|
><H3
|
|
CLASS="FOOTNOTES"
|
|
>Notes</H3
|
|
><TABLE
|
|
BORDER="0"
|
|
CLASS="FOOTNOTES"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNIT02"
|
|
HREF="x-087-2-intro.tcpip.html#X-087-2-FNIT02"
|
|
>[1]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>The shell is a command-line interface to the Unix operating system. It's
|
|
similar to the DOS prompt in a Microsoft Windows environment, albeit much
|
|
more powerful.</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNIT03"
|
|
HREF="x-087-2-intro.tcpip.html#X-087-2-FNIT03"
|
|
>[2]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
> The Ethernet
|
|
FAQ at <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>http://www.faqs.org/faqs/LANs/ethernet-faq/</SPAN
|
|
>
|
|
talks about this issue, and a wealth of detailed historical and
|
|
technical information is available at Charles Spurgeon's Ethernet web
|
|
site at <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>http://wwwhost.ots.utexas.edu/ethernet/</SPAN
|
|
>.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-intro.history.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-intro.uucp.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>History</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-intro.html"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>UUCP Networks</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |