Charles M. Kozierok The TCP-IP Guide

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

Acknowl-

edgment Number

Acknowledgment Number: When the ACK bit is set, this segment is

serving as an acknowledgment (in addition to other possible duties) and

this field contains the sequence number the source is next expecting the

destination to send. See the topic describing TCP data transfer for details.

Data Offset

1/2

(4 bits)

Data Offset: Specifies the number of 32-bit words of data in the TCP

header. In other words, this value times four equals the number of bytes in

the header, which must always be a multiple of four. It is called a “data

offset” since it indicates by how many 32-bit words the start of the data is

offset from the beginning of the TCP segment.

Reserved

3/4

(6 bits)

Reserved: 6 bits reserved for future use; sent as zero.

Control Bits

3/4

(6 bits)

Window 2

Window: Indicates the number of octets of data the sender of this segment

is willing to accept from the receiver at one time. This normally corre-

sponds to the current size of the buffer allocated to accept data for this

connection. This field is, in other words, the current receive window size for

the device sending this segment, which is also the send window for the

recipient of the segment. See the data transfer mechanics topic for details.

Table 157: TCP Segment Format (Page 2 of 3)

Field Name

Size

(bytes)

Description

Bit

s men

one

TCP

oes no

use a separa

orma

control messages. Instead, certain bits are set to indicate the communi-

cation of control information. The six bits are:

Subfield

Name

Size

(bytes)

Description

URG

1/8

(1 bit)

Urgent Bit: When set to 1, indicates that the priority

data transfer feature has been invoked for this

segment, and that the Urgent Pointer field is valid.

ACK

1/8

(1 bit)

Acknowledgment Bit: When set to 1, indicates that

this segment is carrying an acknowledgment, and the

value of the Acknowledgment Number field is valid and

carrying the next sequence expected from the desti-

nation of this segment.

PSH

1/8

(1 bit)

Push Bit: The sender of this segment is using the TCP

push feature, requesting that the data in this segment

be immediately pushed to the application on the

receiving device.

RST

1/8

(1 bit)

Reset Bit: The sender has encountered a problem and

wants to reset the connection.

SYN

1/8

(1bit)

Synchronize Bit: This segment is a request to

synchronize sequence numbers and establish a

connection; the Sequence Number field contains the

initial sequence number (ISN) of the sender of the

segment.

FIN

1/8

(1 bit)

Finish Bit: The sender of the segment is requesting

that the connection be closed.

Checksum 2

Checksum: A 16-bit checksum for data integrity protection, computed over

the entire TCP datagram plus a special “pseudo header” of fields. It is used

to protect the entire TCP segment against not just errors in transmission,

but also errors in delivery. Optional alternate checksum methods are also

supported.

Urgent Pointer 2

Urgent Pointer: Used in conjunction with the URG control bit for priority

data transfer. This field contains the sequence number of the last byte of

urgent data. See the priority data transfer topic for details.

Options Variable

Padding Variable

Padding: If the Options field is not a multiple of 32 bits in length, enough

zeroes are added to pad the header so it is a multiple of 32 bits.

Data Variable Data: The bytes of data being sent in the segment.

Table 157: TCP Segment Format (Page 3 of 3)

Field Name

Size

(bytes)

Description

ons:

TCP

es a gener

c mec

ng one or more

sets of optional data in a TCP segment. Each of the options can be either

one byte in length or variable in length. The first byte is the Option-Kind

subfield, and its value specifies the type of option, which in turn indicates

whether the option is just a single byte or multiple bytes. Options that are

many bytes consist of three fields:

Subfield

Name

Size

(bytes)

Description

Option-Kind 1 Option-Kind: Specifies the option type.

Option-Length 1

Option-Length: The length of the entire option in

bytes, including the Option-Kind and Option-

Length fields.

Option-Data Variable

Option-Data: The option data itself. In at least one

oddball case, this field is omitted (making Option-

Length equal to 2).

Figure 216: TCP Segment Format

Source Port Destination Port

Sequence Number

Acknowledgment Number

Data Offset Reserved Control Bits Window

Urgent Pointer

Option-Kind #1 Option-Length #1 Option-Data #1

Option-Kind #N Option-Length #N

Padding

Data

4 8 12 16 20 24 28 320

Urgent Bit

(URG)

Acknow l-

edgment

Bit

(ACK)

Pus h Bit

(PSH)

Res et Bit

(RST)

Synch-

ronize Bit

(SYN)

Finish Bit

(FIN)

Option-Data #N

...

Checksum

TCP Options and Option Field Values

Table 158 shows the main options currently defined for TCP.

I have not shown every TCP option in Table 158, just the basic ones defined in RFC 793

and a few others that are interesting and correspond to features described elsewhere in the

Guide. Note that most options are sent only in connection request (SYN) segments. This

Table 158: TCP Options

Option-

Kind

Option-

Length

Option-Data Description

0— —

End Of Option List: A single byte option that marks the end of all

options included in this segment. This only needs to be included

when the end of the options doesn't coincide with the end of the

TCP header.

1 — —

No-Operation: A “spacer” that can be included between options to

align a subsequent option on a 32-bit boundary if needed.

Maximum

Segment

Size Value

Maximum Segment Size: Conveys the size of the largest

segment the sender of the segment wishes to receive. Used only

in connection request (SYN) messages.

3 3

Window Size

Shift Bits

Window Scale: Implements the optional window scale feature,

which allows devices to specify much larger window sizes than

would be possible with the normal Window field. The value in

Option-Data specifies the power of two that the Window field

should be multiplied by to get the true window size the sender of

the option is using. For example, if the value of Option-Data is 3,

this means values in the Window field should be multiplied by 8,

assuming both devices agree to use this feature. This allows very

large windows to be advertised when needed on high-performance

links. See the topic on data transfer for more.

42 —

Selective Acknowledgment Permitted: Specifies that this device

supports the selective acknowledgment (SACK) feature. This was

implemented as a two-byte option with no Option-Data field,

instead of a single-byte option like End Of Option List or No-

Operation. This was necessary because it was defined after the

original TCP specification, so an explicit option length had to be

indicated for backwards compatibility.

5 Variable

Blocks Of

Data Selec-

tively

Acknowl-

edged

Selective Acknowledgment: Allows devices supporting the

optional selective acknowledgment feature to specify non-

contiguous blocks of data that have been received so they are not

retransmitted if intervening segments do not show up and need to

be retransmitted.

14 3

Alternate

Checksum

Algorithm

Alternate Checksum Request: Lets a device request that a

checksum generation algorithm other than the standard TCP

algorithm be used for this connection. Both devices must agree to

the algorithm for it to be used.

15 Variable

Alternate

Checksum

Alternate Checksum: If the checksum value needed to implement

an alternate checksum is too large to fit in the standard 16-bit

Checksum field, it is placed in this option.

includes the Maximum Segment Size, Window Scale, Selective Acknowledgement

Permitted and Alternate Checksum Request options above. In contrast, Selective Acknowl-

edgment and Alternate Checksum options appear in regular data segments, when used.

TCP Checksum Calculation and the TCP "Pseudo Header"

The Transmission Control Protocol is designed to provide reliable data transfer between a

pair of devices on an IP internetwork. Much of the effort required to ensure reliable delivery

of data segments is of necessity focused on the problem of ensuring that data is not lost in

transit. But there's another important critical impediment to the safe transmission of data:

the risk of errors being introduced into a TCP segment during its travel across the

internetwork.

Detecting Transmission Errors Using Checksums

If the data gets where it needs to go but is corrupted and we do not detect the corruption,

this is in some ways worse than it never showing up at all. To provide basic protection

against errors in transmission, TCP includes a 16-bit Checksum field in its header. The idea

behind a checksum is very straight-forward: take a string of data bytes and add them all

together. Then send this sum with the data stream and have the receiver check the sum. In

TCP, a special algorithm is used to calculate this checksum by the device sending the

segment; the same algorithm is then employed by the recipient to check the data it received

and ensure that there were no errors.

The checksum calculation used by TCP is a bit different than a regular checksum algorithm.

A conventional checksum is performed over all the bytes that the checksum is intended to

protect, and can detect most bit errors in any of those fields. The designers of TCP wanted

this bit error protection, but also desired to protect against other type of problems.

Increasing The Scope of Detected Errors: the TCP Pseudo Header

To this end, a change was made in how the TCP checksum is computed. This special TCP

checksum algorithm was eventually also adopted for use by the User Datagram Protocol

(UDP).

Instead of computing the checksum over only the actual data fields of the TCP segment, a

12-byte TCP pseudo header is created prior to checksum calculation. This header contains

important information taken from fields in both the TCP header and the IP datagram into

which the TCP segment will be encapsulated. The TCP pseudo header has the format

shown in Table 159 and Figure 217.

Once this 96-bit header has been formed, it is placed in a buffer, following which the TCP

segment itself is placed. Then, the checksum is computed over the entire set of data

(pseudo header plus TCP segment). The value of the checksum is placed into the

Checksum field of the TCP header, and the pseudo header is discarded—it is not an actual

part of the TCP segment and is not transmitted. This process is illustrated in Figure 218.

Note: The Checksum field is itself part of the TCP header and thus one of the

fields over which the checksum is calculated, creating a “chicken and egg”

situation of sorts. This field is assumed to be all zeroes during calculation of the

checksum.

Table 159: TCP “Pseudo Header” For Checksum Calculation

Field Name

Size

(bytes)

Description

Source Address 4

Source Address: The 32-bit IP address of the originator of the datagram,

taken from the IP header.

Destination

Address

Destination Address: The 32-bit IP address of the intended recipient of

the datagram, also from the IP header.

Reserved 1 Reserved: 8 bits of zeroes.

Protocol 1

Protocol: The Protocol field from the IP header. This indicates what

higher-layer protocol is carried in the IP datagram. Of course, we already

know what this protocol is, it's TCP! So, this field will normally have the

value 6.

TCP Length 2

TCP Length: The length of the TCP segment, including both header and

data. Note that this is not a specific field in the TCP header; it is computed.

Figure 217: TCP “Pseudo Header” For Checksum Calculation

Source Address

(from IP Header)

Destination Address

(from IP Header)

Reserved

Protocol

(from IP Header)

TCP Segment Length

(computed)

4 8 12 16 20 24 28 320

When the TCP segment arrives at its destination, the receiving TCP software performs the

same calculation. It forms the pseudo header, prepends it to the actual TCP segment, and

then performs the checksum (setting the Checksum field to zero for the calculation as

before). If there is a mismatch between its calculation and the value the source device put

in the Checksum field, this indicates that an error of some sort occurred and the segment is

normally discarded.

Advantages of the Pseudo Header Method

So, why bother with this “pseudo header”? The source and destination devices both

compute the checksum using the fields in this pseudo header. This means that if, for any

reason, the two devices don't use the same values for the pseudo header, the checksum

will fail. Now, when we consider what's in the header, we find that this means the checksum

now protects against not just errors in the TCP segment fields but also against:

☯ Incorrect Segment Delivery: If there is a mismatch in the Destination Address

between what the source specified and what the destination that got the segment

used, the checksum will fail. The same will happen if the Source Address does not

match.

☯ Incorrect Protocol: If a datagram is routed to TCP that actually belongs to a different

protocol for whatever reason, this can be immediately detected.

☯ Incorrect Segment Length: If part of the TCP segment has been omitted by accident,

the lengths the source and destination used won't match and the checksum will fail.

What's clever about the pseudo header is that by using it for the checksum calculation, we

can provide this protection without actually needing to send the fields in the pseudo header

itself. This eliminates duplicating the IP fields used in the pseudo header within the TCP

header, which would be redundant and wasteful of bandwidth. The drawback of the pseudo

header method is that it makes checksum calculation take more time and effort (though this

is not much of an issue today.)

Figure 218: TCP Header Checksum Calculation

To calculate the TCP segment header’s Checksum field, the TCP pseudo header is first constructed and

placed, logically, before the TCP segment. The checksum is then calculated over both the pseudo header and

the TCP segment. The pseudo header is then discarded.

Source

Address

Dest

Address

Reserved

Protocol

TCP

Length

TCP Header

Check-

sum

TCP Data

Pseudo-Header

Checksum Calculated Over Pseudo Header and TCP Segment

TCP Segment

In the context of today's modern, high-speed, highly-reliable networks, the use of the

pseudo header sometimes seems “archaic”. How likely is it that a datagram will be

delivered to the wrong address? Not very. At the time TCP was created, however, there was

significant concern that there might not be proper “end-to-end” checking of the delivery of

datagrams at the IP level. Including IP information in the TCP checksum was seen as a

useful additional level of protection.

Of course, there is one interesting implication of the TCP pseudo header: it violates the

architectural layering principles that the designers of TCP sought to respect in splitting TCP

and IP up. For the checksum, TCP must know IP information that technically it “shouldn't”.

TCP checksum calculation requires, for example, that the protocol number from the IP

header be given to the TCP layer on the receiving device from the IP datagram that carried

the segment. The TCP pseudo header is a good example of a case where strict layering

was eschewed in favor of practicality.

Finally, TCP also supports an optional method of having two devices agree on an alter-

native checksum algorithm. This must be negotiated during connection establishment.

Key Concept: TCP checksums are computed over not just the TCP segment but

also over a TCP pseudo header that contains the length of the TCP segment as well

as the IP Source Address, Destination Address and Protocol fields. Since these

fields are part of the checksum, if the segment is received by the wrong device, or has the

incorrect Protocol field or segment length, it will be rejected. The technique is clever

because the checksum can provide this protection even though the pseudo header itself is

not actually transmitted.

TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size

TCP segments are the messages that carry data between TCP devices. The Data field is

where the actual data being transmitted is carried, and since the length of the Data field in

TCP is variable, this raises an interesting question: how much data should we put into each

segment? With protocols that accept data in blocks from the higher layers there isn't as

much of a question, but TCP accepts data as a constant stream from the applications that

use it. This means it must decide how many bytes to put into each message that it sends.

A primary determinant of how much data to send in a segment is the current status of the

sliding window mechanism on the part of the receiver. When Device A receives a TCP

segment from Device B, it examines value of the Window field to know the limit on how

much data Device B is allowing Device A to send in its next segment. There are also

important issues in the selection and adjustment of window size that impact the operation of

the TCP system as a whole, which are discussed in the reliability section.

In addition to the dictates of the current window size, each TCP device also has associated

with it a ceiling on TCP size—a segment size that will never be exceeded regardless of how

large the current window is. This is called the maximum segment size (MSS). When

deciding how much data to put into a segment, each device in the TCP connection will

choose the amount based on the current window size, in conjunction with the various

algorithms described in the reliability section, but it will never be so large that the amount of

data exceeds the MSS of the device to which it is sending.

Note: I need to point out that the name “maximum segment size” is in fact

misleading. The value actually refers to the maximum amount of data that a

segment can hold—it does not include the TCP headers. So if the MSS is 100, the

actual maximum segment size could be 120 (for a regular TCP header) or larger (if the

segment includes TCP options).

Maximum Segment Size Selection

The selection of the MSS is based on the need to balance various competing performance

and implementation issues in the transmission of data on TCP/IP networks. The main TCP

standard, RFC 793, doesn't discuss MSS very much, which opened the potential for

confusion on how the parameter should be used. RFC 879 was published a couple of years

after the TCP standard to clarify this parameter and the issues surrounding it. Some issues

with MSS are fairly mundane; for example, certain devices are limited in the amount of

space they have for buffers to hold TCP segments, and therefore may wish to limit segment

size to a relatively small value. In general, though, the MSS must be chosen by balancing

two competing performance issues:

☯ Overhead Management: The TCP header takes up 20 bytes of data (or more if

options are used); the IP header also uses 20 or more bytes. This means that between

them a minimum of 40 bytes are needed for headers, all of which is non-data

“overhead”. If we set the MSS too low, this results in very inefficient use of bandwidth.

For example, suppose we set it to 40; if we did, a maximum of 50% of each segment

could actually be data; the rest would just be headers. Many segment datagrams

would be even worse in terms of efficiency.

☯ IP Fragmentation: TCP segments will be packaged into IP datagrams. As we saw in

the section on IP, datagrams have their own size limit issues: the matter of the

maximum transmission unit (MTU) of an underlying network. If a TCP segment is too

large, it will lead to an IP datagram is too large to be sent without fragmentation.

Fragmentation reduces efficiency and increases the chances of part of a TCP segment

being lost, resulting in the entire segment needing to be retransmitted.

TCP Default Maximum Segment Size

The solution to these two competing issues was to establish a default MSS for TCP that

was as large as possible while avoiding fragmentation for most transmitted segments. This

was computed by starting with the minimum MTU for IP networks of 576. All networks are

required to be able to handle an IP datagram of this size without fragmenting. From this

number, we subtract 20 bytes for the TCP header and 20 for the IP header, leaving 536

bytes. This is the standard MSS for TCP.

The selection of this value was a compromise of sorts. When this number is used, it means

that most TCP segments will be sent unfragmented across an IP internetwork. However, if

any TCP or IP options are used, this will cause the minimum MTU of 576 to be exceeded

and fragmentation to happen. Still, it makes more sense to allow some segments to be

fragmented rather than use a much smaller MSS to ensure that none are ever fragmented.

If we chose, say, an MSS of 400, we would probably never have fragmentation, but we'd

lower the data/header ratio from 536:40 (93% data) to 400:40 (91% data) for all segments.

Key Concept: TCP is designed to restrict the size of the segments it sends to a

certain maximum limit, to cut down on the likelihood that segments will need to be

fragmented for transmission at the IP level. The TCP maximum segment size (MSS)

specifies the maximum number of bytes in the TCP segment’s Data field, regardless of any

other factors that influence segment size. The default MSS for TCP is 536, which results

from taking the minimum IP MTU of 576 and subtracting 20 bytes each for the IP and TCP

headers.

Specifying a Non-Default MSS Value

Naturally, there are likely to be cases where the default MSS is non-ideal, so TCP provides

a means for a device to specify that the MSS it wants to use is either smaller or larger than

the default value of 536. A device can inform the other of the MSS it wants to use during the

connection establishment process. A device that chooses to do so includes in its SYN

message the TCP option called, appropriately, Maximum Segment Size. The other device

receives this option and records the MSS for the connection. Each device can specify the

MSS it wants for the segments it receives independently.

Note: The exchange of MSS values during setup is sometimes called MSS negoti-

ation. This is actually a misleading term, because it implies that the two devices

must agree on a common MSS value, which is not the case. The MSS value used

by each may be different, and there is in fact no negotiation at all.

Devices may wish to use a larger MSS if they know for a fact that the MTUs of the networks

the segments will pass over are larger than the IP minimum of 576. This is most commonly

the case when large amounts of data are sent on a local network; the process of path MTU

discovery is used to determine the appropriate MSS. A smaller MSS might be advisable if it

were known that a particular optional feature was in place that would consistently increase

the size of the IP header. Employing IPSec for security would be a good example.