Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

normal UNIX user interface concepts of standard input (stdin), standard output (stdout) and

standard error (stderr) also apply to rsh, so you can use it to execute a remote command

and redirect the output to a local file. For example, this command would let a user get a

listing of his or her home directory on the server “<somehost>” and store it in the local file

“remotelist”:

rsh <somehost> ls -l >remotelist

Key Concept: The remote shell or rsh command is similar to the Berkeley rlogin

command, but instead of opening a login session on a remote host, it executes a

single, user-provided command. rsh can be helpful for users who need to perform a

quick operation on a remote host, and can also be employed by other programs to

automate network tasks.

rsh Security Concerns and ssh

Since rsh is based on rlogin, all of the concerns that apply to rlogin are also relevant here,

especially with regard to security. (We no more want an unauthorized user running

commands on our servers than logging in to them!) As with rlogin, newer versions of rsh

support more advanced authentication options than the original software. Also, just as

slogin is a newer, more secure version of rlogin, there is a program called ssh (secure shell)

that replaces rsh on many systems.

Note: On some systems, if rsh is entered without a command specified to execute,

then an interactive remote session is established, exactly as if the rlogin command

had been entered instead of rsh.

Other Berkeley Remote ("r") Commands (rcp, ruptime, rwho)

The rlogin and rsh commands are the generic members of the Berkeley “r” family of

programs that allow remote access to a host. To complement these, a small number of

specific remote commands were also defined. These are essentially remote versions of

some of the more common UNIX functions—instead of the command being applied to only

one system, however, it is used between two systems or across all systems on a TCP/IP

network.

All of these commands are based on rlogin the same way that rsh is. They work in the same

way, but instead of opening up a session or passing a user-specified command to the

remote host, they execute a particular function. The following are the most common of

these remote commands and briefly, how each is used:

☯ Remote Copy (rcp): This is the remote version of the UNIX copy (cp) command; it

allows a file to be copied between the local host and the remote host, or between two

remote hosts. The usual syntax is basically the same as the regular cp command, but

the source and/or destination is specified as being on a remote host.

The rcp command can be used in a manner similar to FTP, but is much simpler and

less capable. Or to put it another way: rcp is to FTP, what rlogin is to Telnet. (That’s not

a perfect analogy, but it’s pretty close.)

☯ Remote Uptime (ruptime): The UNIX command uptime is used to display how long a

computer has been running since it was last booted, along with information related to

its current load. ruptime is the remote version of this command; it displays the current

status of each machine on the network (up or down), how long each up machine has

been up since its last boot, and its load statistics.

☯ Remote Who (rwho): This is the remote version of the who command. Where who

shows all the users logged on to the host where it is run, rwho shows all users logged

on to all machines on the network.

The ruptime and rwho commands both rely on the presence of the rwhod (remote who

daemon) running in the background on networked machines. These processes routinely

share information with each other about host uptime and who is logged on to each system,

so it can be quickly displayed when either ruptime or rwho is run.

On some operating systems, other remote commands may also be implemented. As with

rlogin and rsh, security issues may apply to these commands, and there may be efficiency

concerns with others (such as rwho). For these reasons, on many networks these

commands are no longer used.

Internet Relay Chat Protocol (IRC)

The primary advantage that electronic mail offers over conventional mail is speed. Instead

of having to wait for days or weeks for a message to be delivered, it usually arrives in

minutes or even seconds. This makes electronic mail far more useful than the regular

postal service for most types of information transfer. There are some cases, however,

where speed of delivery is not sufficient to make electronic mail an ideal mechanism for

communication. One such case is where a dialog is required between two parties.

Consider that even though electronic mail may be delivered very quickly, it uses a

decoupled model of communication. When person A sends an e-mail to person B, the

message may show up in B’s inbox in a matter of seconds, but B may not in fact be around

to read it at the time it arrives. B might not see the message until hours later; he would then

send a response to A, who in turn might not see it for a while. If the subject they are

discussing requires several dozen iterations of this sort, it could take a very long time before

the exchange is completed.

In the real world, of course, most of us would never use mail for such a conversation,

preferring instead that high-tech communication device that we call… the telephone. ☺

Many people using computers realized that it would be useful to have a way for two or more

people to interactively discuss issues in a manner similar to a telephone conversation. In

the online world, this is commonly called chatting, and one of the first and most important

application protocols designed to implement it in TCP/IP was the Internet Relay Chat

Protocol (IRC).

IRC History and Standards

Prior to the widespread use of the Internet, people with computers would often commu-

nicate by dialing in to a bulletin board system (BBS) or other proprietary service. IRC was

originally created by a gentleman from Finland named Jarkko Oikarinen, based on his

experience with chat applications on BBSes. He wrote the first client and server software in

1988; the protocol was later formally defined in RFC 1459, Internet Relay Chat Protocol

published May 1993. In April 2000, the IRC standard was revised and enhanced with

several new extended capabilities, and published as a set of four smaller documents: RFCs

2810 through 2813. Each of these focuses on one particular area of IRC functionality.

Note: RFC 1459 has the RFC status “Experimental”, and the RFC 2810 to 2813

group is designated “Informational”. This makes IRC optional; it need not be imple-

mented on TCP/IP devices.

IRC Communication Model and Client/Server Operation

IRC is an interesting protocol in that it is not based strictly on the standard client/server

model of TCP/IP protocol operation. IRC servers are TCP/IP machines that run IRC server

software. They are configured with information that allows them to establish TCP connec-

tions to each other; TCP is used because the connections are maintained over a long

period of time and reliable transport of data is required. Server connections are used to

exchange control information and user data, forming a logical IRC network at the appli-

cation level, which allows any server to send to any other using intermediate servers as

conduits. Servers are managed by IRC operators (IRCops) who have special privileges that

allow them to ensure that everything runs smoothly on the network.

The IRC network forms the backbone of the IRC communication service. A user can access

the network by running IRC client software on any TCP/IP-enabled device. The user enters

the name of one of the servers on the network and establishes a TCP connection to that

server. This causes the user to be connected directly to one server, and thus, indirectly to

all of the others on the network. This allows that user to send and receive messages to and

from all other users connected either to the user’s server or other servers.

Group Messaging and IRC Channels

The most common type of communication in IRC is group messaging, which is accom-

plished using IRC channels. A channel is a virtual meeting place of sorts, and is also

sometimes called a chat room (though IRC purists scoff at the use of that term.) Every IRC

network has hundreds or even thousands of different channels, each of which is dedicated

to a particular type of discussion, ranging from the serious to the silly. For example, a group

of people interested in talking about meteorology could establish a channel called

“#weather” where they would meet regularly to discuss various aspects of climatology and

interesting weather events.

IRC is an inherently text-based protocol (though it is also possible to use IRC clients to

transfer arbitrary files between users, including images and executable programs.) To

communicate in a channel, all a user needs to do is enter text in the appropriate spot on the

IRC client program; this text is automatically sent to every other member of the channel.

The IRC network handles the relaying of these messages in real time from one user, to that

user’s connected server, to other servers in the network, and then to all user machines on

those servers. When other users see the first user’s message they can reply with messages

of their own, which will in turn be propagated across the network. Each IRC user chooses a

nickname (often abbreviated nick) that is like a “handle” used for communication while

connected to the network.

Individual Messaging

IRC also supports one-to-one communication, which can be used for private conversation.

To use this method, all a user needs is the nickname of another user to whom he or she

wants to talk; he or she uses a special command to send messages directly to that user,

who can respond in kind. This is not a secure form of communication, since the messages

are not encrypted, and they pass through servers where they could be monitored. However,

there is so much traffic on a typical IRC network that any given message is unlikely to be

monitored, so there is not much concern (unless you work for the CIA or just developed a

cure for the common cold or something. ☺)

The IRC protocol defines a rich command set that allows users to perform essential

functions, such as joining or leaving a channel, changing nicknames, changing servers,

setting operating modes for channels and so forth. The exact command set and features

available depends both on the specific software used for the user’s IRC client, and the

features available on the IRC network itself, not all of which run the same version of the

protocol.

IRC became very popular in the early 1990s because of the powerful way that it allows

users from anywhere on the Internet to meet and share information dynamically. Not only

does it act like a text-based “telephone”, it allows users across the globe to communicate

without the expense of a long-distance call.

IRC and the Modern Internet

One of the most important characteristics of IRC is its open-ended nature: it gives every

person the freedom to communicate in whatever way he or she considers best. For

example, every IRC channel has an owner, who has certain rights related to how the

channel is used, including the ability to decide who should be allowed in the channel and

who not. This may seem autocratic, but IRC lets anyone start a new channel instantly and

become that channel’s owner, without the need for prior registration or authorization. This

means that if you don’t like how a particular channel is run, you can start your own with a

minimum of fuss; you are not forced to adhere to anyone’s rules, other than the rules set

forth for the server (which are usually just intended to prevent abuse.)

This same principle extends to the IRC networks themselves as well—there isn’t just one

single IRC network, there are dozens of different ones. Some are large, well-established

networks that may have over 100 servers and thousands of users, while others are smaller

and devoted to specific areas of interest or geographical regions. Anyone can set up their

own IRC network if they have the hardware and software, and some organizations have in

fact set up private, dedicated IRC servers for their own use.

IRC is considered by many to be the most important “ancestor” of the related interactive

applications collectively known as instant messaging. These services are offered by several

organizations, including America Online (AOL), Yahoo! and Microsoft’s MSN. The idea

behind them is very similar to that of IRC; each allows a message sent by one user to be

displayed immediately to another, though most are focused primarily on user-to-user

messages rather than groups. Instant messaging has in fact surpassed IRC in overall use,

perhaps due to the large subscriber base of services like AOL. However, IRC is still widely

used by thousands of enthusiasts on a daily basis for both entertainment and business

purposes.

TCP/IP Administration and Troubleshooting Utilities and

Protocols

The first two large subsections of the large section devoted to TCP/IP applications and

application protocols discussed file and message transfer applications, and interactive and

remote access applications, respectively. These are the classical applications that are most

often employed by the users of TCP/IP internetworks. Since they are the means by which

users communicate, they can be considered in some ways the “raison d’être” of TCP/IP and

the Internet itself.

In contrast, this third subsection is a bit different. It doesn’t describe applications designed

for end-users. Rather, it discusses a set of TCP/IP troubleshooting utilities and protocols,

which are normally the province of internetwork administrators. Even though millions of

people use TCP/IP every day without even knowing that these applications exist—much

less how they work—they are critically important to those who maintain TCP/IP internet-

works. Since many of you are studying TCP/IP so that you can implement and administer

this technology, understanding how these applications work is well worth your time.

In this section I provide an overview description of a number of software utilities that are

commonly employed to help set up, configure and maintain TCP/IP internetworks. These

programs allow a network administrator to perform functions such as checking the identity

of a host; verifying connectivity between two hosts; checking the path of routers between

devices; examining the configuration of a computer; looking up a DNS domain name; and

much more.

Note: The goal of this section is to provide explanations of the general purpose

and function of troubleshooting utilities, so you will know how they can help you

manage TCP/IP networks. As part of these descriptions, I demonstrate the typical

syntax used to invoke each utility in both UNIX and Windows. While I have tried to be quite

complete in these depictions, they are intended only to give you a better idea of what these

programs can do—this section should not be considered a reference manual for these

utilities. Due to variations in software implementations, please consult your operating

system documentation for the details on exactly how each program should be used on your

own network. On Windows systems, try “<program> /?” to see the syntax of the program;

on UNIX/Linux try “man <program>”.

Background Information: Many of the software tools described in this section are

designed to manage the operation of other TCP/IP protocols, such as the Internet

Protocol, Domain Name System or Dynamic Host Configuration Protocol. To fully

appreciate how these utilities work, you need to understand the basics of these and other

key TCP/IP protocols. In particular, a number of the utilities discussed here communicate

use ICMP messages, so I would recommend familiarity with ICMP before proceeding.

TCP/IP Host Name Utility (hostname)

They say the best place to start is at the beginning. Therefore, in examining TCP/IP admin-

istration and troubleshooting utilities, why not begin with the basics? One of the most

fundamental of tasks in diagnosing problems with a networked computer is identifying it.

Just as the first thing we usually do when we meet someone is exchange names, one of the

first actions an administrator takes when accessing a device is to determine its name, if it is

not known. This is accomplished using the hostname utility.

You may recall from our discussion of TCP/IP name systems that there are two different

ways that hosts can be named. The first way is to manually assign “flat” names to devices

using host tables or equivalent means; this is most often used for devices that not going to

be accessed on the public Internet. The second is to give a device a domain name within

the Domain Name System (DNS). The hostname utility can be used for both types of

named hosts, but it functions in a slightly different way for each.

On most systems, including Windows and many UNIX implementations, the hostname

utility is very, very simple. When the command is entered by itself on a line with no

arguments, it displays the full name of the host. If it is entered with the “-s” (“short”)

parameter, then if the host name is a fully qualified DNS domain name, only the local label

of the node is shown and not the full domain name; if the host has a flat (non-DNS) name

the parameter has no effect. A simple example is shown in Table 284.

The hostname utility is also intended to allow an administrator to set the name of a host.

The syntax for this is also simple; you just supply the name of the host as a parameter, as

follows:

hostname <new_hostname>

However, in most implementations, the use of the hostname command for setting a device’s

name is either disabled or restricted. In Windows systems, a special applet in the Control

Panel is used to set the device’s name; attempting to set it using hostname will result in an

error message. In UNIX, the super-user of the system can use hostname to set the device’s

name, but it is more common for this to be done by other means, such as editing the config-

uration file /etc/hosts. Obviously, if a simple flat name is being assigned to this host, the

administrator has full control over it, while if DNS is used then the proper procedures for

registering the name must be followed.

In most operating systems, the “-s” parameter is the only one that this command supports.

The parameter is not supported on all implementations of the “hostname” command,

however; on some of these, if you use “hostname -s”, the system may report its host name

Table 284: Using the hostname Utility To Check A Host Name

% hostname

fearn.pair.com

% hostname -s

fearn

as being “-s”. On certain Linux systems, a few additional parameters are included that allow

different ways for the host name to be displayed, as well as some miscellaneous functions

such as showing the version number of the program.

Note: One point worth mentioning is that the hostname utility is not, strictly

speaking, tied into the operation of DNS or other formal mechanisms for identifying

a host. It simply displays what the administrator has set it to show. Obviously it

makes sense for this to be set to the host’s DNS name, but there may be exceptions.

Key Concept: The simplest and most basic of TCP/IP administrative utilities is

hostname, which returns the name of the host upon which it is run.

TCP/IP Communication Verification Utility (ping/ping6)

One of the most common classes of problems that network administrators are often called

upon to solve is an inability of two hosts to communicate. For example, a user on a

corporate network might not be able to retrieve one of his files from a local server, or

another user might be having difficulty loading her favorite Web site. In these and many

similar situations, one important step in diagnosing the problem is to verify that basic

communication is possible between the TCP/IP software stacks on the two machines. This

is most often done using the ping utility, or ping6 in IPv6 implementations.

Note: Some people say that “ping” is an acronym for “Packet Internet Groper”,

while others insist that it is actually based on the use of the term to refer to a sonar

pulse sent by a submarine to check for nearby objects. I really don’t know which of

these is true, but I prefer the second explanation. Consider that the utility works in a way

similar to a sonar “ping”, and that it was originally written by a gent named Mike Muuss, who

worked at the US Army Ballistics Research Laboratory. The first explanation is weaker; it’s

possible, but the phrase “Packet Internet Groper” isn’t really grammatical, and I don’t even

want to think about what it is this utility is supposed to be “groping”! ☺

The ping diagnostic utility is one of the most commonly used, and is present in just about

every TCP/IP implementation. It is usually implemented and accessed as a command-line

utility, though there are also now graphical and menu-based versions of the program on

some operating systems.

Operation of the ping Utility

The ping utility is implemented using ICMP Echo (Request) and Echo Reply messages. As

explained in the topic discussing these message types, they are designed specifically for

these sorts of diagnostic purposes. When Device A sends an ICMP Echo message to

device B, device B responds by sending an ICMP Echo Reply message back to device A.

The same functionality exists in ICMPv6, the IPv6 version of ICMP; the ICMPv6 Echo and

Echo Reply messages only differ from the IPv4 ones slightly in their field structure.

This would seem to indicate that ping would be an extremely simple utility that would send

one Echo message and wait to see if an Echo Reply was received back; if so, then this

would provide that the two devices were able to communicate, and if not, this would indicate

a problem somewhere on the internetwork between the two. However, almost all ping

implementations are much more complex than this. They use multiple sets of Echo and

Echo Reply messages, along with considerable internal logic, to allow an administrator to

determine all of the following, and more:

☯ Whether or not the two devices can communicate;

☯ Whether congestion or other problems exist that might allow communication to

succeed sometimes but cause it to fail in others, seen as packet loss—if so, how bad

the loss is;

☯ How much time it takes to send a simple ICMP message between devices, which

gives an indication of the overall latency between the hosts, and also indicates if there

are certain types of problems.

Basic ping Use

The most basic use of the ping command is to enter it by itself with the IP address of a host.

Virtually all implementations also allow a host name to be used, which will be resolved to an

IP address automatically. When the utility is invoked with no additional options, default

values are used for parameters such as what size message to send, how many messages

to be sent, how long to wait for a reply, and so on. The utility will transmit a series of Echo

messages to the host and report back whether or not a reply was received for each; if a

reply is seen, it will also indicate how long it took for the response to be received. When the

program is done, it will provide a statistical summary showing what percentage of the Echo

messages received a reply, and the average amount of time for them to be received.

Table 285 shows an example using the ping command on a Windows XP computer (mine!),

which by default sends four 32-byte Echo messages and allows four seconds before

considering an Echo message lost. I use a satellite Internet connection that has fairly high

latency and also occasionally drops packets. This isn’t great for me, but it is useful for illus-

trating how ping works.

Methods of Diagnosing Connectivity Problems Using ping

Most people find that using ping with default settings is enough for their needs. In fact, the

utility can be used in this simplest form to perform a surprising number of diagnostic checks.

In many cases, the ping command can be used to diagnose connectivity problems by using

it multiple times in sequence, often starting with checks at or close to the transmitting device

and then proceeding outwards towards the other device with which the communication

problem has been observed. Some examples of how ping can be used in this way:

☯ Internal Device TCP/IP Stack Operation: By performing a ping on the device’s own

address, you can verify that its internal TCP/IP stack is working. This can also be done

using the standard IP loopback address, 127.0.0.1.

☯ Local Network Connectivity: If the internal test succeeds, it’s a good idea to do a

ping on another device on the local network, to verify that local communication is

possible.

☯ Local Router Operation: If there is no problem on the local network, it makes sense

to ping whatever local router the device is using to make sure it is operating and

reachable.

☯ Domain Name Resolution Functionality: If a ping performed on a DNS domain

name fails, you should try it with the device’s IP address instead. If that works, this

implies either a problem with domain name configuration or resolution.

☯ Remote Host Operation: If all the preceding checks succeed, you can try pinging a

remote host to see if it responds. If it does not, you can try a different remote host; if

that one works, it is possible that the problem is actually with the first remote device

itself and not with your local device.

Table 285: Verifying Communication Using the ping Utility

D:\aa>ping www.pcguide.com

Pinging pcguide.com [209.68.14.80] with 32 bytes of data:

Reply from 209.68.14.80: bytes=32 time=582ms TTL=56

Reply from 209.68.14.80: bytes=32 time=601ms TTL=56

Request timed out.

Reply from 209.68.14.80: bytes=32 time=583ms TTL=56

Ping statistics for 209.68.14.80:

Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

Minimum = 582ms, Maximum = 601ms, Average = 588ms