Charles M. Kozierok The TCP-IP Guide

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

Key Concept: In most TCP/IP client/server communications, the client uses a

random ephemeral port number and sends a request to the appropriate reserved

port number at the server’s IP address. The server sends its reply back to whatever

port number it finds in the Source Port field of the request.

TCP/IP Sockets and Socket Pairs: Process and Connection Identification

The preceding topics have illustrated the key difference between addressing at the level of

the Internet Protocol, and addressing as it is seen by application processes. To summarize,

at layer three, an IP address is all that is really important for properly transmitting data

between IP devices. In contrast, application protocols must be concerned with the port

assigned to each instance of the application, so they can properly use TCP or UDP.

Sockets: Process Identification

What this all means is that the overall identification of an application process actually uses

the combination of the IP address of the host it runs on—or the network interface over

which it is talking, to be more precise—and the port number which has been assigned to it.

This combined address is called a socket. Sockets are specified using the following

notation:

So, for example, if we have a Web site running on IP address 41.199.222.3, the socket

corresponding to the HTTP server for that site would be 41.199.222.3:80.

Figure 199: TCP/IP Client/Server Application Port Mechanics

This highly simplified example shows how clients and servers use port numbers for a request.reply exchange.

The client is making an HTTP request and sends it to the server at HTTP’s well-known port number, 80. Its

port number for this exchange is the pseudo-randomly-selected 3,022. The server sends its reply back to that

port number, which it reads from the request.

Source 177.41.72.6 3022

Destination 41.199.222.3 80

Request

Source 41.199.222.3 80

Destination 177.41.72.6 3022

Response

Internet

Client

177.41.72.6

Server

41.199.222.3

Key Concept: The overall identifier of a TCP/IP application process on a device is

the combination of its IP address and port number, which is called a socket.

You will also sometimes see a socket specified using a host name instead of an IP address,

like this:

To use this descriptor, the name must first be resolved to an IP address using DNS. For

example, you might find a Web site URL like this: “http://www.thisisagreatsite.com:8080”.

This tells the Web browser to first resolve the name “www.thisisagreatsite.com” to an IP

address using DNS, and then send a request to that address using the non-standard server

port 8080, which is occasionally used instead of port 80 since it resembles it. (See the

discussion of application layer addressing using URLs for much more.)

The socket is a very fundamental concept to the operation of TCP/IP application software.

In fact, it is the basis for an important TCP/IP application program interface (API) with the

same name: sockets. A version of this API for Windows is called Windows Sockets or

WinSock, which you may have heard of before. These APIs allow application programs to

easily use TCP/IP to communicate.

Socket Pairs: Connection Identification

So, the exchange of data between a pair of devices consists of a series of messages sent

from a socket on one device to a socket on the other. Each device will normally have

multiple such simultaneous conversations going on. In the case of TCP, a connection is

established for each pair of devices for the duration of the communication session. These

connections must be managed, and this requires that they be uniquely identified. This is

done using the pair of socket identifiers for each of the two devices that are connected.

Key Concept: Each device may have multiple TCP connections active at any given

time. Each connection is uniquely identified using the combination of the client

socket and server socket, which in turn contains four elements: the client IP address

and port, and the server IP address and port.

Let's return to the example we used in the previous topic (Figure 199). We are sending an

HTTP request from our client at 177.41.72.6 to the Web site at 41.199.222.3. The server for

that Web site will use well-known port number 80, so its socket is 41.199.222.3:80, as we

saw before. We have been ephemeral port number 3,022 for our Web browser, so the client

socket is 177.41.72.6:3022. The overall connection between these devices can be

described using this socket pair:

(41.199.222.3:80, 177.41.72.6:3022)

For much more on how TCP identifies connections, see the topic on TCP ports and

connection identification in the section on TCP fundamentals.

Unlike TCP, UDP is a connectionless protocol, so it obviously doesn't use connections. The

pair of sockets on the sending and receiving devices can still be used to identify the two

processes exchanging data, but since there are no connections the socket pair doesn't

have the significance that it does in TCP.

Common TCP/IP Applications and Assigned Well-Known and Registered

Port Numbers

The great popularity of the TCP/IP protocol suite has led to the development of literally

thousands of different applications and protocols. Most of these use the client/server model

of operation that we discussed earlier in this section. Server processes for a particular

application are designed to use a particular reserved port number, with clients using an

ephemeral (temporary) port number to initiate a connection to the server.

Management of Reserved Port Numbers

To ensure that everyone agrees on which port numbers server applications for each appli-

cation should use, they are centrally managed by the Internet Assigned Numbers Authority

(IANA). Originally, IANA kept the list of well-known and registered port numbers in a lengthy

text document, along with all the many other parameters for which IANA was centrally

responsible (such as IP Protocol field numbers, Type and Code field values for ICMP, and

so on). These were published on a periodic basis in Internet (RFC) standards documents

titled Assigned Numbers.

This system worked fine in the early days of the Internet, but by the mid-1990s, these

values were changing so rapidly that using the RFC process was not feasible. It was too

much work to keep publishing them, and the RFC was practically out of date the day after it

was put out.

The last Assigned Numbers

standard was RFC 1700, published in October 1994. After that

time, IANA moved to a set of World Wide Web documents containing the parameters they

manage. This allowed IANA to keep the lists constantly up to date, and for TCP/IP users to

be able to get more current information. RFC 1700 was officially obsoleted in 2002.

On The Web: Complete information on all the parameters maintained by IANA can

be found at http://www.iana.org/numbers.html. The URL of the file containing TCP/

UDP port assignments is http://www.iana.org/assignments/port-numbers.

The document mentioned above is the definitive list of all well-known and registered TCP

and UDP port assignments. Each port number is assigned a short keyword, with a brief

description of the protocol that uses it. There are two problems with this document. The first

is that it is incredibly long: over 10,000 lines of text. Most of the protocols mentioned in

those thousands of lines are for obscure applications that you have probably never heard of

before (I certainly have never heard of most of them!) This makes it hard to easily see the

port assignments for the protocols that are most commonly used.

The other problem with this document is that it shows the same port number as reserved for

both TCP and UDP for an application. As I mentioned earlier, TCP and UDP port numbers

are actually independent, so one could in theory assign TCP port 80 to one server appli-

cation type and UDP port 80 to another. It was believed that this would lead to confusion, so

with very few exceptions, the same port number is shown in the list for the same application

for both TCP and UDP. This makes sense, but showing this in the list has a drawback: you

can't tell which protocol the application actually uses, and which has just been reserved for

consistency.

Given all that, I've decided to include a couple of summary tables here that show the well-

known and registered port numbers for the most common TCP/IP applications, and

indicated whether the protocol uses TCP, UDP or both.

Common Well-Known Port Numbers and Applications

Table 146 lists the well-known port numbers for the most common TCP/IP application

protocols.

Table 146: Common TCP/IP Well-Known Port Numbers and Applications (Page 1 of 2)

Port # TCP / UDP Keyword

Protocol

Abbrevi-

ation

Application or Protocol Name / Comments

7 TCP + UDP echo — Echo Protocol

9 TCP + UDP discard — Discard Protocol

11 TCP + UDP systat — Active Users Protocol

13 TCP + UDP daytime — Daytime Protocol

17 TCP + UDP qotd QOTD Quote Of The Day Protocol

19 TCP + UDP chargen — Character Generator Protocol

20 TCP ftp-data

FTP

(data)

File Transfer Protocol (default data port)

21 TCP ftp

FTP

(control)

File Transfer Protocol (control / commands)

23 TCP telnet — Telnet Protocol

25 TCP smtp SMTP Simple Mail Transfer Protocol

37 TCP + UDP time — Time Protocol

43 TCP nicname — Whois Protocol (also called “Nicname”)

53 TCP + UDP domain DNS Domain Name Server (Domain Name System)

67 UDP bootps

BOOTP /

DHCP

Bootstrap Protocol /

Dynamic Host Configuration Protocol (Server)

Common Registered Port Numbers and Applications

The registered port numbers are by definition for protocols that are not standardized using

the RFC process, so they are mostly esoteric applications that I don’t feel there is much

point in listing at length. Table 147 shows a few that I feel are of particular interest:

68 UDP bootpc

BOOTP /

DHCP

Bootstrap Protocol /

Dynamic Host Configuration Protocol (Client)

69 UDP tftp TFTP Trivial File Transfer Protocol

70 TCP gopher — Gopher Protocol

79 TCP finger — Finger User Information Protocol

80 TCP http HTTP Hypertext Transfer Protocol (World Wide Web)

110 TCP pop3 POP Post Office Protocol (version 3)

119 TCP nntp NNTP Network News Transfer Protocol

123 UDP ntp NTP Network Time Protocol

137 TCP + UDP netbios-ns — NetBIOS (Name Service)

138 UDP netbios-dgm — NetBIOS (Datagram Service)

139 TCP netbios-ssn — NetBIOS (Session Service)

143 TCP imap IMAP Internet Message Access Protocol

161 UDP snmp SNMP Simple Network Management Protocol

162 UDP snmptrap SNMP Simple Network Management Protocol (Trap)

179 TCP bgp BGP Border Gateway Protocol

194 TCP irc IRC Internet Relay Chat

443 TCP https

HTTP

over SSL

Hypertext Transfer Protocol over

Secure Sockets Layer

500 UDP isakmp IKE IPSec Internet Key Exchange

520 UDP router RIP Routing Information Protocol (RIP-1 and RIP-2)

521 UDP ripng RIPng Routing Information Protocol - “Next Generation”

Table 147: Common TCP/IP Registered Port Numbers and Applications

Port # TCP / UDP Keyword

Protocol

Abbrevi-

ation

Application or Protocol Name / Comments

1512 TCP + UDP wins WINS Microsoft Windows Internet Naming Service

1701 UDP l2tp L2TP Layer Two Tunneling Protocol

Table 146: Common TCP/IP Well-Known Port Numbers and Applications (Page 2 of 2)

Port # TCP / UDP Keyword

Protocol

Abbrevi-

ation

Application or Protocol Name / Comments

1723 TCP pptp PPTP Point-To-Point Tunneling Protocol

2049 TCP + UDP nfs NFS Network File System

6000 -

6063

TCP x11 X11 X Window System

Table 147: Common TCP/IP Registered Port Numbers and Applications

Port # TCP / UDP Keyword

Protocol

Abbrevi-

ation

Application or Protocol Name / Comments

TCP/IP User Datagram Protocol (UDP)

The very fact that the TCP/IP protocol suite bears the name of the Internet Protocol and the

Transmission Control Protocol suggests that these are the two key protocols in the suite: IP

at the network layer and TCP at the transport layer. It's no wonder, therefore, that many

people don't even realize that there is a second transport layer protocol in TCP/IP. Like a

shy younger brother, the User Datagram Protocol (UDP) sits in the shadows while TCP gets

the glory. Its fancier sibling deserves much of this limelight, since TCP is arguably the more

important of the two transport layer protocol. However, UDP itself fills a critical niche in the

TCP/IP protocol suite, allowing many applications to work at their best when using TCP

would be less than ideal.

In this section I describe the simpler and lesser-known TCP/IP transport protocol: the User

Datagram Protocol (UDP). I begin with an overview of the protocol and a discussion of its

history and standards. I outline how UDP operates, and describe the format used for UDP

messages. I conclude with a discussion of what sorts of applications use UDP, and the well-

known or registered ports that are assigned to them.

Note: There is also a protocol that is part of the NetBIOS/NetBEUI protocol suite

called the User Datagram Protocol, also abbreviated UDP. The two are of course

not the same.

UDP Overview, History and Standards

I suppose the “sibling rivalry” analogy I drew in the introduction to this section may be a little

bit silly. I highly doubt that protocols lie awake at night worrying about how much we use

them. ☺ However, it's interesting to discover just how important the User Datagram Protocol

(UDP) really is, given how little attention it gets compared to the Transmission Control

Protocol (TCP). In fact, in true older-sibling, spotlight-stealing fashion, we can't even really

understand the history of UDP without first discussing TCP.

In the topic that describes the history of TCP/IP, I explained that very early on in the devel-

opment of the protocol suite, there was only one protocol that handled the functions now

performed by both IP and TCP. This protocol, itself called TCP, provided network-layer

connectivity like IP, and also established connections, provided reliability and took care of

the typical transport-layer “quality” requirements as flow control and retransmission

handling that we associate with modern TCP.

It didn’t take long before the developers of the fledgling combined protocol quickly realized

that mixing these functions together was a mistake. While most conventional applications

needed the classic transport-layer reliability functions, some did not. These features intro-

duced overhead, which would have to be endured even by the applications where reliability

features were not needed at all. Worse, there were some applications where the features

were not only of no value, but actually a detriment, since even the small amount of lost

performance due to the overhead would be a problem.

The solution was to separate the original protocol into IP and TCP. Basic internetworking

was to be done by IP, and the reliability features by TCP. This paved the way for the

creation of an alternative transport-layer protocol for applications that didn't want or need

the features provided by TCP. This, of course, is the User Datagram Protocol (UDP).

There are two main attributes that come up again and again when describing UDP: simple

and fast. It is a simple protocol that uses a very straight-forward messaging structure that is

similar to the message format used by many other TCP/IP protocols (in contrast to the more

complex data structures—streams and segments—used by TCP). In fact, when you boil it

down, the only real goal of the protocol is to serve as an interface between networking

application processes running at the higher layers, and the internetworking capabilities of

IP. Like TCP, UDP layers on top of IP a method of transport-layer addressing (and hence,

process identification) through the use of UDP port numbers. It does include an optional

checksum capability for error-detection, but adds virtually no other functionality.

In fact, the best way to see for yourself the simplicity of UDP is to look at the standards that

define it. Or rather, I should say standard in the singular, because there is only one. UDP

was defined in RFC 768, User Datagram Protocol, in 1980. This document is all of three

pages in length, and has never needed to be revised.

UDP is a fast protocol specifically because it doesn't have all the bells and whistles of TCP.

This makes it unsuitable for use by many, if not most, typical networking applications. But

for some applications, this is exactly what they want from a transport layer protocol:

something that takes their data and quickly shuffles it down to the IP layer with a minimum

of fuss. In choosing to use UDP, the application writer takes it upon himself or herself to

take care of issues such as reliability and retransmissions, if they are needed. This can be a

recipe for success or failure, depending on the application and how carefully UDP is used.

Key Concept: The User Datagram Protocol (UDP) was developed for use by appli-

cation protocols that do not require reliability, acknowledgment or flow control

features at the transport layer. It is designed to be simple and fact, providing only

transport layer addressing in the form of UDP ports and an optional checksum capability,

and little else.

UDP Operation

Uh… Uh… After all these pages, I almost find myself at a loss for words. (Hey, don't skip to

the next topic, I said almost!) The simplicity of the User Datagram Protocol means that there

is not a great deal to say in describing its operation. It is designed to do as little as possible,

and little is exactly what it does.

What UDP Does

UDP's only real task is to take data from higher-layer protocols and place it in UDP

messages, which are then passed down to the Internet Protocol for transmission. The basic

steps for transmission using UDP are:

1. Higher-Layer Data Transfer: An application sends a message to the UDP software.

2. UDP Message Encapsulation: The higher-layer message is encapsulated into the

Data field of a UDP message. The headers of the UDP message are filled in, including

the Source Port of the application that sent the data to UDP, and the Destination Port

of the intended recipient. The checksum value may also be calculated.

3. Transfer Message To IP: The UDP message is passed to IP for transmission.

And that's about it. Of course, on reception at the destination device this short procedure is

reversed.

What UDP Does Not

In fact, UDP is so simple, that its operation is very often described in terms of what it does

not do, instead of what it does. As a transport protocol, some of the most important things

UDP does not do include the following:

☯ UDP does not establish connections before sending data. It just packages it and… off

it goes.

☯ UDP does not provide acknowledgments to show that data was received.

☯ UDP does not provide any guarantees that its messages will arrive.

☯ UDP does not detect lost messages and retransmit them.

☯ UDP does not ensure that data is received in the same order that they were sent.

☯ UDP does not provide any mechanism to manage the flow of data between devices, or

handle congestion.

Key Concept: The User Datagram Protocol (UDP) is probably the simplest in all of

TCP/IP. All it does is take application layer data passed to it, package it in a simplified

message format, and send it to IP for transmission.

If these characteristics sound similar to how I described the limitations of IP, you're paying

attention. UDP is basically just IP with transport-layer port addressing. (It is for this reason

that UDP is sometimes called a “wrapper” protocol, since all it does is wrap application data

in its simple message format and send it to IP.)

I should point out that despite the list above, there are a couple of limited feedback and

error checking mechanisms that do exist within UDP. One is the optional checksum

capability, which can allow detection of an error in transmission or the situation where a

UDP message is delivered to the wrong place; see the next topic for details. The other is

ICMP error reporting. For example, if a UDP message is sent that contains a destination

port number not recognized by the destination device, this will lead to the destination host

sending an ICMP Destination Unreachable message back to the original source. Of course,

ICMP exists for all IP errors of this sort, so I’m stretching a bit here; this isn't really part of

UDP.

UDP Message Format

What's the magic word when it comes to UDP? Right, simple. This is true of the operation of

the protocol, and it is also true of the format used for UDP messages. Interestingly,

however, it is here that we will actually encounter probably the only aspect of UDP that is

not simple. I bet that got you interested, huh? Okay, well, it was a worth a try. ☺

In keeping with the goal of efficiency, the UDP header is only eight bytes in length; this

contrasts with the TCP header size of 20 bytes or more. Table 148 and Figure 200 show the

format of UDP messages.

The Checksum Field and the UDP Pseudo Header

The UDP Checksum field is the one area where the protocol actually is a bit confusing. The

concept of a checksum itself is nothing new; they are used widely in networking protocols to

provide protection against errors. What's a bit odd is this notion of computing the checksum

over the regular datagram and also a pseudo header. What this means is that instead of

calculating the checksum over just the fields in the UDP datagram itself, the UDP software

first constructs a “fake” additional header that contains the following fields (Figure 201):

☯ The IP Source Address field.

☯ The IP Destination Address field.

Table 148: UDP Message Format

Field Name

Size

(bytes)

Description

Source Port 2

Source Port: The 16-bit port number of the process that originated the

UDP message on the source device. This will normally be an ephemeral

(client) port number for a request sent by a client to a server, or a well-

known/registered (server) port number for a reply sent by a server to a

client. See the section describing port numbers for details.

Destination Port 2

Destination Port: The 16-bit port number of the process that is the

ultimate intended recipient of the message on the destination device. This

will usually be a well-known/registered (server) port number for a client

request, or an ephemeral (client) port number for a server reply. Again, see

the section describing port numbers for details.

Length 2

Length: The length of the entire UDP datagram, including both header and

Data fields.

Checksum 2

Checksum: An optional 16-bit checksum computed over the entire UDP

datagram plus a special “pseudo header” of fields. See below for more

information.

Data Variable Data: The encapsulated higher-layer message to be sent.