hedrick@topaz.rutgers.edu (Charles Hedrick) (07/03/87)
The following is a revised (and I hope final) version of the TCP/IP
introduction I posted a week ago. It takes into account comments that
I got from a number of helpful people, and adds a good deal of extra
material. Originally, I intended it to give my own staff enough
background to read the RFC's. It appears that there was a need for a
bit more general introduction. I have tried to do that, to the extent
that I could.
Various people asked for permission to distribute it to their staff
(or even customers). I have added a copyright that tries to make it
clear that this is OK.
If you don't have TCP/IP, and this convinces you that you should get
it, the NIC (whose address is given in the last section) has a list of
implementations. However these days, most equipment vendors can
supply TCP/IP, or point you to a 3rd party who can.
This posting is in two parts, because inews claimed that postings over
64K bytes were a bad idea.
-----------------------------------
Introduction
to
the Internet Protocols
C R
C S
Computer Science Facilities Group
C I
L S
RUTGERS
The State University of New Jersey
3 July 1987
This is an introduction to the Internet networking protocols (TCP/IP).
It includes a summary of the facilities available and brief
descriptions of the major protocols in the family.
Copyright (C) 1987, Charles L. Hedrick. Anyone may reproduce this
document, in whole or in part, provided that: (1) any copy or
republication of the entire document must show Rutgers University as
the source, and must include this notice; and (2) any other use of
this material must reference this manual and Rutgers University, and
the fact that the material is copyright by Charles Hedrick and is used
by permission.
Unix is a trademark of AT&T Technologies, Inc.
Table of Contents
1. What is TCP/IP? 1
2. General description of the TCP/IP protocols 5
2.1 The TCP level 7
2.2 The IP level 10
2.3 The Ethernet level 11
3. Well-known sockets and the applications layer 12
3.1 An example application: SMTP 15
4. Protocols other than TCP: UDP and ICMP 17
5. Keeping track of names and information: the domain system 18
6. Routing 20
7. Details about Internet addresses: subnets and broadcasting 21
8. Datagram fragmentation and reassembly 23
9. Ethernet encapsulation: ARP 24
10. Getting more information 25
i
This document is a brief introduction to TCP/IP, followed by advice on
what to read for more information. This is not intended to be a
complete description. It can give you a reasonable idea of the
capabilities of the protocols. But if you need to know any details of
the technology, you will want to read the standards yourself.
Throughout the text, you will find references to the standards, in the
form of "RFC" or "IEN" numbers. These are document numbers. The final
section of this document tells you how to get copies of those
standards.
1. What is TCP/IP?
TCP/IP is a set of protocols developed to allow cooperating computers
to share resources across a network. It was developed by a community
of researchers centered around the ARPAnet. Certainly the ARPAnet is
the best-known TCP/IP network. However as of June, 87, at least 130
different vendors had products that support TCP/IP, and thousands of
networks of all kinds use it.
First some basic definitions. The most accurate name for the set of
protocols we are describing is the "Internet protocol suite". TCP and
IP are two of the protocols in this suite. (They will be described
below.) Because TCP and IP are the best known of the protocols, it
has become common to use the term TCP/IP or IP/TCP to refer to the
whole family. It is probably not worth fighting this habit. However
this can lead to some oddities. For example, I find myself talking
about NFS as being based on TCP/IP, even though it doesn't use TCP at
all. (It does use IP. But it uses an alternative protocol, UDP,
instead of TCP. All of this alphabet soup will be unscrambled in the
following pages.)
The Internet is a collection of networks, including the Arpanet,
NSFnet, regional networks such as NYsernet, local networks at a number
of University and research institutions, and a number of military
networks. The term "Internet" applies to this entire set of networks.
The subset of them that is managed by the Department of Defense is
referred to as the "DDN" (Defense Data Network). This includes some
research-oriented networks, such as the Arpanet, as well as more
strictly military ones. (Because much of the funding for Internet
protocol developments is done via the DDN organization, the terms
Internet and DDN can sometimes seem equivalent.) All of these
networks are connected to each other. Users can send messages from
any of them to any other, except where there are security or other
policy restrictions on access. Officially speaking, the Internet
protocol documents are simply standards adopted by the Internet
community for its own use. More recently, the Department of Defense
issued a MILSPEC definition of TCP/IP. This was intended to be a more
formal definition, appropriate for use in purchasing specifications.
However most of the TCP/IP community continues to use the Internet
standards. The MILSPEC version is intended to be consistent with it.
Whatever it is called, TCP/IP is a family of protocols. A few provide
1
"low-level" functions needed for many applications. These include IP,
TCP, and UDP. (These will be described in a bit more detail later.)
Others are protocols for doing specific tasks, e.g. transferring files
between computers, sending mail, or finding out who is logged in on
another computer. Initially TCP/IP was used mostly between
minicomputers or mainframes. These machines had their own disks, and
generally were self-contained. Thus the most important "traditional"
TCP/IP services are:
- file transfer. The file transfer protocol (FTP) allows a user on
any computer to get files from another computer, or to send files
to another computer. Security is handled by requiring the user
to specify a user name and password for the other computer.
Provisions are made for handling file transfer between machines
with different character set, end of line conventions, etc. This
is not quite the same thing as more recent "network file system"
or "netbios" protocols, which will be described below. Rather,
FTP is a utility that you run any time you want to access a file
on another system. You use it to copy the file to your own
system. You then work with the local copy. (See RFC 959 for
specifications for FTP.)
- remote login. The network terminal protocol (TELNET) allows a
user to log in on any other computer on the network. You start a
remote session by specifying a computer to connect to. From that
time until you finish the session, anything you type is sent to
the other computer. Note that you are really still talking to
your own computer. But the telnet program effectively makes your
computer invisible while it is running. Every character you type
is sent directly to the other system. Generally, the connection
to the remote computer behaves much like a dialup connection.
That is, the remote system will ask you to log in and give a
password, in whatever manner it would normally ask a user who had
just dialed it up. When you log off of the other computer, the
telnet program exits, and you will find yourself talking to your
own computer. Microcomputer implementations of telnet generally
include a terminal emulator for some common type of terminal.
(See RFC's 854 and 855 for specifications for telnet. By the
way, the telnet protocol should not be confused with Telenet, a
vendor of commercial network services.)
- computer mail. This allows you to send messages to users on
other computers. Originally, people tended to use only one or
two specific computers. They would maintain "mail files" on
those machines. The computer mail system is simply a way for you
to add a message to another user's mail file. There are some
problems with this in an environment where microcomputers are
used. The most serious is that a micro is not well suited to
receive computer mail. When you send mail, the mail software
expects to be able to open a connection to the addressee's
computer, in order to send the mail. If this is a microcomputer,
it may be turned off, or it may be running an application other
than the mail system. For this reason, mail is normally handled
by a larger system, where it is practical to have a mail server
running all the time. Microcomputer mail software then becomes a
2
user interface that retrieves mail from the mail server. (See
RFC 821 and 822 for specifications for computer mail. See RFC
937 for a protocol designed for microcomputers to use in reading
mail from a mail server.)
These services should be present in any implementation of TCP/IP,
except that micro-oriented implementations may not support computer
mail. These traditional applications still play a very important role
in TCP/IP-based networks. However more recently, the way in which
networks are used has been changing. The older model of a number of
large, self-sufficient computers is beginning to change. Now many
installations have several kinds of computers, including
microcomputers, workstations, minicomputers, and mainframes. These
computers are likely to be configured to perform specialized tasks.
Although people are still likely to work with one specific computer,
that computer will call on other systems on the net for specialized
services. This has led to the "server/client" model of network
services. A server is a system that provides a specific service for
the rest of the network. A client is another system that uses that
service. (Note that the server and client need not be on different
computers. They could be different programs running on the same
computer.) Here are the kinds of servers typically present in a
modern computer setup. Note that these computer services can all be
provided within the framework of TCP/IP.
- network file systems. This allows a system to access files on
another computer in a somewhat more closely integrated fashion
than FTP. A network file system provides the illusion that disks
or other devices from one system are directly connected to other
systems. There is no need to use a special network utility to
access a file on another system. Your computer simply thinks it
has some extra disk drives. These extra "virtual" drives refer
to the other system's disks. This capability is useful for
several different purposes. It lets you put large disks on a few
computers, but still give others access to the disk space. Aside
from the obvious economic benefits, this allows people working on
several computers to share common files. It makes system
maintenance and backup easier, because you don't have to worry
about updating and backing up copies on lots of different
machines. A number of vendors now offer high-performance
diskless computers. These computers have no disk drives at all.
They are entirely dependent upon disks attached to common "file
servers". (See RFC's 1001 and 1002 for a description of
PC-oriented NetBIOS over TCP. In the workstation and
minicomputer area, Sun's Network File System is more likely to be
used. Protocol specifications for it are available from Sun
Microsystems.)
- remote printing. This allows you to access printers on other
computers as if they were directly attached to yours. (The most
commonly used protocol is the remote lineprinter protocol from
Berkeley Unix. Unfortunately, there is no protocol document for
this. However the C code is easily obtained from Berkeley, so
implementations are common.)
3
- remote execution. This allows you to request that a particular
program be run on a different computer. This is useful when you
can do most of your work on a small computer, but a few tasks
require the resources of a larger system. There are a number of
different kinds of remote execution. Some operate on a command
by command basis. That is, you request that a specific command
or set of commands should run on some specific computer. (More
sophisticated versions will choose a system that happens to be
free.) However there are also "remote procedure call" systems
that allow a program to call a subroutine that will run on
another computer. (There are many protocols of this sort.
Berkeley Unix contains two servers to execute commands remotely:
rsh and rexec. The man pages describe the protocols that they
use. The user-contributed software with Berkeley 4.3 contains a
"distributed shell" that will distribute tasks among a set of
systems, depending upon load. Remote procedure call mechanisms
have been a topic for research for a number of years, so many
organizations have implementations of such facilities. The most
widespread commercially-supported remote procedure call protocols
seem to be Xerox's Courier and Sun's RPC. Protocol documents are
available from Xerox and Sun. There is a public implementation
of Courier over TCP as part of the user-contributed software with
Berkeley 4.3. An implementation of RPC was posted to Usenet by
Sun, and also appears as part of the user-contributed software
with Berkeley 4.3.)
- name servers. In large installations, there are a number of
different collections of names that have to be managed. This
includes users and their passwords, names and network addresses
for computers, and accounts. It becomes very tedious to keep
this data up to date on all of the computers. Thus the databases
are kept on a small number of systems. Other systems access the
data over the network. (RFC 822 and 823 describe the name server
protocol used to keep track of host names and Internet addresses
on the Internet. This is now a required part of any TCP/IP
implementation. IEN 116 describes an older name server protocol
that is used by a few terminal servers and other products to look
up host names. Sun's Yellow Pages system is designed as a
general mechanism to handle user names, file sharing groups, and
other databases commonly used by Unix systems. It is widely
available commercially. Its protocol definition is available
from Sun.)
- terminal servers. Many installations no longer connect terminals
directly to computers. Instead they connect them to terminal
servers. A terminal server is simply a small computer that only
knows how to run telnet (or some other protocol to do remote
login). If your terminal is connected to one of these, you
simply type the name of a computer, and you are connected to it.
Generally it is possible to have active connections to more than
one computer at the same time. The terminal server will have
provisions to switch between connections rapidly, and to notify
you when output is waiting for another connection. (Terminal
servers use the telnet protocol, already mentioned. However any
real terminal server will also have to support name service and a
4
number of other protocols.)
- network-oriented window systems. Until recently, high-
performance graphics programs had to execute on a computer that
had a bit-mapped graphics screen directly attached to it.
Network window systems allow a program to use a display on a
different computer. Full-scale network window systems provide an
interface that lets you distribute jobs to the systems that are
best suited to handle them, but still give you a single
graphically-based user interface. (The most widely-implemented
window system is X. A protocol description is available from
MIT's Project Athena. A reference implementation is publically
available from MIT. A number of vendors are also supporting
NeWS, a window system defined by Sun. Both of these systems are
designed to use TCP/IP.)
Note that some of the protocols described above were designed by
Berkeley, Sun, or other organizations. Thus they are not officially
part of the Internet protocol suite. However they are implemented
using TCP/IP, just as normal TCP/IP application protocols are. Since
the protocol definitions are not considered proprietary, and since
commercially-support implementations are widely available, it is
reasonable to think of these protocols as being effectively part of
the Internet suite. Note that the list above is simply a sample of
the sort of services available through TCP/IP. However it does
contain the majority of the "major" applications. The other
commonly-used protocols tend to be specialized facilities for getting
information of various kinds, such as who is logged in, the time of
day, etc. However if you need a facility that is not listed here, we
encourage you to look through the current edition of Internet
Protocols (currently RFC 1011), which lists all of the available
protocols, and also to look at some of the major TCP/IP
implementations to see what various vendors have added.
2. General description of the TCP/IP protocols
TCP/IP is a layered set of protocols. In order to understand what
this means, it is useful to look at an example. A typical situation
is sending mail. First, there is a protocol for mail. This defines a
set of commands which one machine sends to another, e.g. commands to
specify who the sender of the message is, who it is being sent to, and
then the text of the message. However this protocol assumes that
there is a way to communicate reliably between the two computers.
Mail, like other application protocols, simply defines a set of
commands and messages to be sent. It is designed to be used together
with TCP and IP. TCP is responsible for making sure that the commands
get through to the other end. It keeps track of what is sent, and
retransmitts anything that did not get through. If any message is too
large for one datagram, e.g. the text of the mail, TCP will split it
up into several datagrams, and make sure that they all arrive
correctly. Since these functions are needed for many applications,
they are put together into a separate protocol, rather than being part
5
of the specifications for sending mail. You can think of TCP as
forming a library of routines that applications can use when they need
reliable network communications with another computer. Similarly, TCP
calls on the services of IP. Although the services that TCP supplies
are needed by many applications, there are still some kinds of
applications that don't need them. However there are some services
that every application needs. So these services are put together into
IP. As with TCP, you can think of IP as a library of routines that
TCP calls on, but which is also available to applications that don't
use TCP. This strategy of building several levels of protocol is
called "layering". We think of the applications programs such as
mail, TCP, and IP, as being separate "layers", each of which calls on
the services of the layer below it. Generally, TCP/IP applications
use 4 layers:
- an application protocol such as mail
- a protocol such as TCP that provides services need by many
applications
- IP, which provides the basic service of getting datagrams to
their destination
- the protocols needed to manage a specific physical medium, such
as Ethernet or a point to point line.
TCP/IP is based on the "catenet model". (This is described in more
detail in IEN 48.) This model assumes that there are a large number
of independent networks connected together by gateways. The user
should be able to access computers or other resources on any of these
networks. Datagrams will often pass through a dozen different
networks before getting to their final destination. The routing
needed to accomplish this should be completely invisible to the user.
As far as the user is concerned, all he needs to know in order to
access another system is an "Internet address". This is an address
that looks like 128.6.4.194. It is actually a 32-bit number. However
it is normally written as 4 decimal numbers, each representing 8 bits
of the address. (The term "octet" is used by Internet documentation
for such 8-bit chunks. The term "byte" is not used, because TCP/IP is
supported by some computers that have byte sizes other than 8 bits.)
Generally the structure of the address gives you some information
about how to get to the system. For example, 128.6 is a network
number assigned by a central authority to Rutgers University. Rutgers
uses the next octet to indicate which of the campus Ethernets is
involved. 128.6.4 happens to be an Ethernet used by the Computer
Science Department. The last octet allows for up to 254 systems on
each Ethernet. (It is 254 because 0 and 255 are not allowed, for
reasons that will be discussed later.) Note that 128.6.4.194 and
128.6.5.194 would be different systems. The structure of an Internet
address is described in a bit more detail later.
Of course we normally refer to systems by name, rather than by
Internet address. When we specify a name, the network software looks
it up in a database, and comes up with the corresponding Internet
address. Most of the network software deals strictly in terms of the
6
address. (RFC 882 describes the name server technology used to handle
this lookup.)
TCP/IP is built on "connectionless" technology. Information is
transfered as a sequence of "datagrams". A datagram is a collection
of data that is sent as a single message. Each of these datagrams is
sent through the network individually. There are provisions to open
connections (i.e. to start a conversation that will continue for some
time). However at some level, information from those connections is
broken up into datagrams, and those datagrams are treated by the
network as completely separate. For example, suppose you want to
transfer a 15000 octet file. Most networks can't handle a 15000 octet
datagram. So the protocols will break this up into something like 30
500-octet datagrams. Each of these datagrams will be sent to the
other end. At that point, they will be put back together into the
15000-octet file. However while those datagrams are in transit, the
network doesn't know that there is any connection between them. It is
perfectly possible that datagram 14 will actually arrive before
datagram 13. It is also possible that somewhere in the network, an
error will occur, and some datagram won't get through at all. In that
case, that datagram has to be sent again.
Note by the way that the terms "datagram" and "packet" often seem to
be nearly interchangable. Technically, datagram is the right word to
use when describing TCP/IP. A datagram is a unit of data, which is
what the protocols deal with. A packet is a physical thing, appearing
on an Ethernet or some wire. In most cases a packet simply contains a
datagram, so there is very little difference. However they can
differ. When TCP/IP is used on top of X.25, the X.25 interface breaks
the datagrams up into 128-byte packets. This is invisible to IP,
because the packets are put back together into a single datagram at
the other end before being processed by TCP/IP. So in this case, one
IP datagram would be carried by several packets. However with most
media, there are efficiency advantages to sending one datagram per
packet, and so the distinction tends to vanish.
2.1 The TCP level
Two separate protocols are involved in handling TCP/IP datagrams. TCP
(the "transmission control protocol") is responsible for breaking up
the message into datagrams, reassembling them at the other end,
resending anything that gets lost, and putting things back in the
right order. IP (the "internet protocol") is responsible for routing
individual datagrams. It may seem like TCP is doing all the work.
And in small networks that is true. However in the Internet, simply
getting a datagram to its destination can be a complex job. A
connection may require the datagram to go through several networks at
Rutgers, a serial line to the John von Neuman Supercomputer Center, a
couple of Ethernets there, a series of 56Kbaud phone lines to another
NSFnet site, and more Ethernets on another campus. Keeping track of
the routes to all of the destinations and handling incompatibilities
among different transport media turns out to be a complex job. Note
7
that the interface between TCP and IP is fairly simple. TCP simply
hands IP a datagram with a destination. IP doesn't know how this
datagram relates to any datagram before it or after it.
It may have occurred to you that something is missing here. We have
talked about Internet addresses, but not about how you keep track of
multiple connections to a given system. Clearly it isn't enough to
get a datagram to the right destination. TCP has to know which
connection this datagram is part of. This task is referred to as
"demultiplexing." In fact, there are several levels of demultiplexing
going on in TCP/IP. The information needed to do this demultiplexing
is contained in a series of "headers". A header is simply a few extra
octets tacked onto the beginning of a datagram by some protocol in
order to keep track of it. It's a lot like putting a letter into an
envelope and putting an address on the outside of the envelope.
Except with modern networks it happens several times. It's like you
put the letter into a little envelope, your secretary puts that into a
somewhat bigger envelope, the campus mail center puts that envelope
into a still bigger one, etc. Here is an overview of the headers that
get stuck on a message that passes through a typical TCP/IP network:
We start with a single data stream, say a file you are trying to send
to some other computer:
......................................................
TCP breaks it up into manageable chunks. (In order to do this, TCP
has to know how large a datagram your network can handle. Actually,
the TCP's at each end say how big a datagram they can handle, and then
they pick the smallest size.)
.... .... .... .... .... .... .... ....
TCP puts a header at the front of each datagram. This header actually
contains at least 20 octets, but the most important ones are a source
and destination "port number" and a "sequence number". The port
numbers are used to keep track of different conversations. Suppose 3
different people are transferring files. Your TCP might allocate port
numbers 1000, 1001, and 1002 to these transfers. When you are sending
a datagram, this becomes the "source" port number, since you are the
source of the datagram. Of course the TCP at the other end has
assigned a port number of its own for the conversation. Your TCP has
to know the port number used by the other end as well. (It finds out
when the connection starts, as we will explain below.) It puts this
in the "destination" port field. Of course if the other end sends a
datagram back to you, the source and destination port numbers will be
reversed, since then it will be the source and you will be the
destination. Each datagram has a sequence number. This is used so
that the other end can make sure that it gets the datagrams in the
right order, and that it hasn't missed any. (See the TCP
specification for details.) TCP doesn't number the datagrams, but the
octets. So if there are 500 octets of data in each datagram, the
first datagram might be numbered 0, the second 500, the next 1000, the
next 1500, etc. Finally, I will mention the Checksum. This is a
number that is computed by adding up all the octets in the datagram
8
(more or less - see the TCP spec). The result is put in the header.
TCP at the other end computes the checksum again. If they disagree,
then something bad happened to the datagram in transmission, and it is
thrown away. So here's what the datagram looks like now.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| your data ... next 500 octets |
| ...... |
If we abbreviate the TCP header as "T", the whole file now looks like
this:
T.... T.... T.... T.... T.... T.... T....
You will note that there are items in the header that I have not
described above. They are generally involved with managing the
connection. In order to make sure the datagram has arrived at its
destination, the recipient has to send back an "acknowledgement".
This is a datagram whose "Acknowledgement number" field is filled in.
For example, sending a packet with an acknowledgement of 1500
indicates that you have received all the data up to octet number 1500.
If the sender doesn't get an acknowledgement within a reasonable
amount of time, it sends the data again. The window is used to
control how much data can be in transit at any one time. It is not
practical to wait for each datagram to be acknowledged before sending
the next one. That would slow things down too much. On the other
hand, you can't just keep sending, or a fast computer might overrun
the capacity of a slow one to absorb data. Thus each end indicates
how much new data it is currently prepared to absorb by putting the
number of octets in its "Window" field. As the computer receives
data, the amount of space left in its window decreases. When it goes
to zero, the sender has to stop. As the receiver processes the data,
it increases its window, indicating that it is ready to accept more
data. Often the same datagram can be used to acknowledge receipt of a
set of data and to give permission for additional new data (by an
updated window). The "Urgent" field allows one end to tell the other
to skip ahead in its processing to a particular octet. This is often
useful for handling asynchronous events, for example when you type a
control character or other command that interrupts output. The other
fields are beyond the scope of this document.
9
2.2 The IP level
TCP sends each of these datagrams to IP. Of course it has to tell IP
the Internet address of the computer at the other end. Note that this
is all IP is concerned about. It doesn't care about what is in the
datagram, or even in the TCP header. IP's job is simply to find a
route for the datagram and get it to the other end. In order to allow
gateways or other intermediate systems to forward the datagram, it
adds its own header. The main things in this header are the source
and destination Internet address (32-bit addresses, like 128.6.4.194),
the protocol number, and another checksum. The source Internet
address is simply the address of your machine. (This is necessary so
the other end knows where the datagram came from.) The destination
Internet address is the address of the other machine. (This is
necessary so any gateways in the middle know where you want the
datagram to go.) The protocol number tells IP at the other end to
send the datagram to TCP. Although most IP traffic uses TCP, there
are other protocols that can use IP, so you have to tell IP which
protocol to send the datagram to. Finally, the checksum allows IP at
the other end to verify that the header wasn't damaged in transit.
Note that TCP and IP have separate checksums. IP needs to be able to
verify that the header didn't get damaged in transit, or it could send
a message to the wrong place. For reasons not worth discussing here,
it is both more efficient and safer to have TCP compute a separate
checksum for the TCP header and data. Once IP has tacked on its
header, here's what the message looks like:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP header, then your data ...... |
| |
If we represent the IP header by an "I", your file now looks like
this:
IT.... IT.... IT.... IT.... IT.... IT.... IT....
Again, the header contains some additional fields that have not been
discussed. Most of them are beyond the scope of this document. The
flags and fragment offset are used to keep track of the pieces when a
datagram has to be split up. This can happen when datagrams are
forwarded through a network for which they are too big. (This will be
discussed a bit more below.) The time to live is a number that is
decremented whenever the datagram passes through a system. When it
goes to zero, the datagram is discarded. This is done in case a loop
10
develops in the system somehow. Of course this should be impossible,
but well-designed networks are built to cope with "impossible"
conditions.
At this point, it's possible that no more headers are needed. If your
computer happens to have a direct phone line connecting it to the
destination computer, or to a gateway, it may simply send the
datagrams out on the line (though likely a synchronous protocol such
as HDLC would be used, and it would add at least a few octets at the
beginning and end).
2.3 The Ethernet level
However most of our networks these days use Ethernet. So now we have
to describe Ethernet's headers. Unfortunately, Ethernet has its own
addresses. The people who designed Ethernet wanted to make sure that
no two machines would end up with the same Ethernet address.
Furthermore, they didn't want the user to have to worry about
assigning addresses. So each Ethernet controller comes with an
address builtin from the factory. In order to make sure that they
would never have to reuse addresses, the Ethernet designers allocated
48 bits for the Ethernet address. People who make Ethernet equipment
have to register with a central authority, to make sure that the
numbers they assign don't overlap any other manufacturer. Ethernet is
a "broadcast medium". That is, it is in effect like an old party line
telephone. When you send a packet out on the Ethernet, every machine
on the network sees the packet. So something is needed to make sure
that the right machine gets it. As you might guess, this involves the
Ethernet header. Every Ethernet packet has a 14-octet header that
includes the source and destination Ethernet address, and a type code.
Each machine is supposed to pay attention only to packets with its own
Ethernet address in the destination field. (It's perfectly possible
to cheat, which is one reason that Ethernet communications are not
terribly secure.) Note that there is no connection between the
Ethernet address and the Internet address. Each machine has to have a
table of what Ethernet address corresponds to what Internet address.
(We will describe how this table is constructed a bit later.) In
addition to the addresses, the header contains a type code. The type
code is to allow for several different protocol families to be used on
the same network. So you can use TCP/IP, DECnet, Xerox NS, etc. at
the same time. Each of them will put a different value in the type
field. Finally, there is a checksum. The Ethernet controller
computes a checksum of the entire packet. When the other end receives
the packet, it recomputes the checksum, and throws the packet away if
the answer disagrees with the original. The checksum is put on the
end of the packet, not in the header. The final result is that your
message looks like this:
11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet destination address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet source address (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP header, then TCP header, then your data |
| |
...
| |
| end of your data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If we represent the Ethernet header with "E", and the Ethernet
checksum with "C", your file now looks like this:
EIT....C EIT....C EIT....C EIT....C EIT....C
When these packets are received by the other end, of course all the
headers are removed. The Ethernet interface removes the Ethernet
header and the checksum. It looks at the type code. Since the type
code is the one assigned to IP, the Ethernet device driver passes the
datagram up to IP. IP removes the IP header. It looks at the IP
protocol field. Since the protocol type is TCP, it passes the
datagram up to TCP. TCP now looks at the sequence number. It uses
the sequence numbers and other information to combine all the
datagrams into the original file.
The ends our initial summary of TCP/IP. There are still some crucial
concepts we haven't gotten to, so we'll now go back and add details in
several areas. (For detailed descriptions of the items discussed here
see, RFC 793 for TCP, RFC 791 for IP, and RFC's 894 and 826 for
sending IP over Ethernet.)
3. Well-known sockets and the applications layer
So far, we have described how a stream of data is broken up into
datagrams, sent to another computer, and put back together. However
something more is needed in order to accomplish anything useful.
There has to be a way for you to open a connection to a specified
computer, log into it, tell it what file you want, and control the
transmission of the file. (If you have a different application in
mind, e.g. computer mail, some analogous protocol is needed.) This is
done by "application protocols". The application protocols run "on
top" of TCP/IP. That is, when they want to send a message, they give
the message to TCP. TCP makes sure it gets delivered to the other
end. Because TCP and IP take care of all the networking details, the
12
applications protocols can treat a network connection as if it were a
simple byte stream, like a terminal or phone line.
Before going into more details about applications programs, we have to
describe how you find an application. Suppose you want to send a file
to a computer whose Internet address is 128.6.4.7. To start the
process, you need more than just the Internet address. You have to
connect to the FTP server at the other end. In general, network
programs are specialized for a specific set of tasks. Most systems
have separate programs to handle file transfers, remote terminal
logins, mail, etc. When you connect to 128.6.4.7, you have to specify
that you want to talk to the FTP server. This is done by having
"well-known sockets" for each server. Recall that TCP uses port
numbers to keep track of individual conversations. User programs
normally use more or less random port numbers. However specific port
numbers are assigned to the programs that sit waiting for requests.
For example, if you want to send a file, you will start a program
called "ftp". It will open a connection using some random number, say
1234, for the port number on its end. However it will specify port
number 21 for the other end. This is the official port number for the
FTP server. Note that there are two different programs involved. You
run ftp on your side. This is a program designed to accept commands
from your terminal and pass them on to the other end. The program
that you talk to on the other machine is the FTP server. It is
designed to accept commands from the network connection, rather than
an interactive terminal. There is no need for your program to use a
well-known socket number for itself. Nobody is trying to find it.
However the servers have to have well-known numbers, so that people
can open connections to them and start sending them commands. The
official port numbers for each program are given in "Assigned
Numbers".
Note that a connection is actually described by a set of 4 numbers:
the Internet address at each end, and the TCP port number at each end.
Every datagram has all four of those numbers in it. (The Internet
addresses are in the IP header, and the TCP port numbers are in the
TCP header.) In order to keep things straight, no two connections can
have the same set of numbers. However it is enough for any one number
to be different. For example, it is perfectly possible for two
different users on a machine to be sending files to the same other
machine. This could result in connections with the following
parameters:
Internet addresses TCP ports
connection 1 128.6.4.194, 128.6.4.7 1234, 21
connection 2 128.6.4.194, 128.6.4.7 1235, 21
Since the same machines are involved, the Internet addresses are the
same. Since they are both doing file transfers, one end of the
connection involves the well-known port number for FTP. The only
thing that differs is the port number for the program that the users
are running. That's enough of a difference. Generally, at least one
end of the connection asks the network software to assign it a port
number that is guaranteed to be unique. Normally, it's the user's
end, since the server has to use a well-known number.
13