5 chapter 51 transport layer tcp/ip protocols a guide to tcp/ip

Chapter 5 1

5

Transport Layer TCP/IP Protocols

A Guide to TCP/IP

Chapter 5 2

5

Objectives

After reading this chapter and completing the exercises you will be able to:

• Understand The concepts involved in connectionless and connection-oriented transport protocols, including the function of port number

• Explain why connectionless protocols require less overhead and offer faster performance than connection-oriented protocols

• Understand the key features and functions of the User Datagram Protocol (UDP)

Chapter 5 3

5

Objectives

After reading this chapter and completing the exercises you will be able to:

• Explain the mechanisms that drive segmentation, reassembly, and retransmission for the Transmission Control Protocol (TCP)

• Explain how TCP connections are managed through setup, maintenance, and teardown phases

• Identify key UDP and TCP port addresses

• Understand both customary and appropriate uses and application services that involve either UDP or TCP transport protocols

Chapter 5 4

5

• Connectionless protocols provide the simplest kind of transport services because they simply package messages, taken as is from the TCP/IP Application layer, into datagrams

• A datagram slaps a header onto the higher-layer data and passes it to the IP layer, where that datagram is fitted with an IP header and packetized, after which it may be transmitted across the network

Understanding Connectionless Transport Protocols

Chapter 5 5

5

Understanding Connectionless Transport Protocols

• This method is called best-effort delivery

• UDP runs up to 40% faster than TCP, under some conditions, because it does next to nothing

• It’s also typical for connectionless protocols to handle the following kinds of tasks:

– Message checksum

– Higher-layer protocol identification

Chapter 5 6

5

User Datagram Protocol (UDP)

• It’s appropriate to provide the following detailed description for UDP:

– No reliability mechanisms

– No delivery guarantees

– No connection handling

– Identifies Application layer protocol conveyed

– Checksum for entire message carried in UDP header

– No buffering services

– No segmentation

Chapter 5 7

5

UDP Header Fields and Functions

• When the Protocol field of an IP header contains the value 17 (0x11), the UDP header follows the IP header

Chapter 5 8

5

UDP Header Fields and Functions

• UDP is defined in RFC 768

• The UDP header contains only four fields:

– Source Port Number field

– Destination Port Number field

– UDP Length field

– UDP Checksum field

Chapter 5 9

5

UDP Header Fields and Functions

Source Port Number Field

• The Source Port Number field defines the application or process that sends the packet using the UDP transport

• In some cases, a temporary port number is used

• Port numbers are defined in three ranges:

– Well-known port numbers

– Registered port numbers

– Dynamic port numbers

Chapter 5 10

5

UDP Header Fields and Functions

Well-Known Port Numbers (0 through 1023)

• Well-known port numbers are assigned to the key or core services that systems offer

• Well-known port numbers are between 0 and 1023

Registered Port Numbers (1024 through 49151)

• Registered port numbers are assigned to industry applications and processes, for example, 1433 is assigned to the Microsoft SQL Server process

Chapter 5 11

5

UDP Header Fields and Functions

Dynamic Port Numbers (49152 through 65535)

• Dynamic ports (also referred to as ephemeral ports) are used as temporary ports for specific communications

• In most cases, an application or process can use the same number, whether it is running over UDP or TCP, because the UDP and TCP port numbers assigned are the same

Chapter 5 12

5

UDP Header Fields and Functions

Destination Port Number Field

• This field value defines the destination

application or process that uses the IP and TCP

headers

• In some instances, the source destination port

numbers are the same for client and server

processes

Chapter 5 13

5

UDP Header Fields and Functions

Length Field

• The Length field defines the length of the packet from the UDP header to the end of valid data (not including any data link padding, if padding is required)

• This field provides a redundant measurement because this information can be determined using the IP header value, and the knowledge that the UDP header is eight bytes long

Chapter 5 14

5

UDP Header Fields and Functions

• Examine the

interpretation of the

Length fields shown in

Figure 5-2:

– IP Header Length = 5

(denoted in 4-byte

increments)

– IP Total Length = 52

– UDP Length = 32

Chapter 5 15

5

UDP Header Fields and Functions

Checksum Field

• The UDP Checksum field is optional

• If a checksum is used, the checksum calculation is performed on the contents of the entire datagram—namely the UDP header (except the UDP Checksum field itself), the datagram payload, and a pseudo-header that is derived from the IP header

Chapter 5 16

5

UDP Port Numbers and Processes

• Both UDP and TCP use port numbers to define the source and destination processes or applications

• Figure 5-4 shows how packets are demultiplexed, based on the type number, protocol number, and port number

Chapter 5 17

5

UDP Port Numbers and Processes

Chapter 5 18

5

Understanding Connection-Oriented Protocols

• Connection-oriented protocols create a logical connection directly between two peers on an internetwork

• Connection-oriented protocols track the transfer of data, and ensure it arrives successfully through acknowledgements and sequence number tracking

• An acknowledgement is a positive response, indicating a set of data arrived

Chapter 5 19

5

Understanding Connection-Oriented Protocols

• Connection-oriented peers use sequence number tracking to identify the amount of data transferred, and any out-of-order packets

• Connection-oriented protocols have a timeout mechanism that indicates when a host waited too long for a communication, and such communication should be assumed lost

• Connection-oriented protocols also have a retry mechanism that enables them to recover lost data by retransmitting it a specified number of times

Chapter 5 20

5

Transmission Control Protocol (TCP)

• TCP offers connection-oriented services with sequencing, error recovery, and a sliding window mechanism

• Because of TCP’s end-to-end reliability and flexibility, TCP is the preferred transport method for applications that transfer large quantities of data and require reliable delivery services

• TCP hosts create a virtual connection with each other using a handshake process

Chapter 5 21

5

Transmission Control Protocol (TCP)

• TCP transfers data as a continuous stream of bytes, with no knowledge of the underlying messages or message boundaries that might be contained in that byte stream

Chapter 5 22

5

TCP Startup Connection Process (TCP Handshake)

• TCP offers a connection-oriented transport that begins with a handshake between two hosts

• One host initiates the handshake to another host to:

(a) Ensure the destination host is available

(b) Ensure the destination host is listening on the destination port number

(c) Inform the destination host of the initiator’s sequence number so the two sides can track data as it is transferred

Chapter 5 23

5

TCP Handshake Is a Three-Packet Process

Chapter 5 24

5

Handshake Packet #1

• In the initial packet, the sender, Host #1, inserts a self-assigned initial sequence number in the TCP header Sequence Number field (21371727)

Chapter 5 25

5

Handshake Packet #2

• Host #2

defined its

starting

sequence

number as

135471

Chapter 5 26

5

Handshake Packet #3

• Host 1’s sequence

number is now

2371728

• The

Acknowledgement

Number field value

is now set to

135472

Chapter 5 27

5

Handshake Packet #3

• The TcpMaxConnectRetransmission Registry setting

defines the number of SYN retries sent when

attempting to establish a TCP connection

Chapter 5 28

5

TcpNumConnections Registry Setting

Chapter 5 29

5

TCP Half-Open Connections

• TCP half-open connections occur when the handshake process does not end successfully with a final ACK

• The half-open connection communication sequence occurs in the following order:SYN >>>>>

>>>>>ACK SYN

>>>>>ACKSYN

>>>>>ACKSYN

• One Denial of Service (DoS) attack—the SYN attack—uses this two-way handshake with the incrementing source port to overload the destination

Chapter 5 30

5

TCP Keep-Alive Process

• Once the TCP connection is established, a keep-alive process can maintain the connection when there is no data sent across the wire

• The Application layer may perform keep-alive processes, such as the NetWare watchdog process, that maintains a connection between a NetWare host and server

Chapter 5 31

5

TCP Keep-Alive Process

Chapter 5 32

5

TCP Connection Termination

• The TCP

connection

termination

process

requires

four

packets

Chapter 5 33

5

TCP Connection States

• TCP communications go through a series of connection states, as listed in Table 5-7

• You can control the Time Wait delay, which is the amount of time that a TCP host waits before reusing parameters

• The default Time Wait delay is four minutes, as recommended by RFC 792

• To control the Time Wait delay, set the TcpTimedWaitDelay Registry value, as shown in Table 5-8

Chapter 5 34

5

TCP Connection States

Chapter 5 35

5

TCP Connection States

Chapter 5 36

5

TCP Sequence and Acknowledgement Process

• The sequence and acknowledgement process guarantees that packets are ordered properly and protects against missing segments

• During the handshake process, each side of the connection selects its own starting sequence number

• During the TCP startup and teardown sequences, the Sequence Number and Acknowledgement Number fields increment by one, even though no valid data is sent or received

Chapter 5 37

5

TCP Sequence and Acknowledgement Process

Chapter 5 38

5

Simple Sequenced Communication

Chapter 5 39

5

TCP Error-Detection and Error-Recovery Process

• The first error-detection and error-recovery mechanism is the retransmission timer

• The value specified by this timer is referred to as the retransmission timeout (RTO)

• In Windows 2000, the maximum retransmission count is set in the TcpMaxDataRetransmissions Registry setting, as shown in Table 5-9

Chapter 5 40

5

TCP Error-Detection and Error-Recovery Process

• Figure 5-13 provides an example of the retransmit timer and process in action

• Note that the retransmissions do not fall on exact exponential boundaries

Chapter 5 41

5TCP Error-Detection

and Error-Recovery Process

Chapter 5 42

5

TCP Congestion Control

• Congestion is the overloading of the network or a receiver

• Overloading a receiver occurs when the number of data bytes is greater than the advertised window

• The current window is always the lesser of what the network and receiver can handle

• When TCP data is received, it is placed in this TCP buffer area

Chapter 5 43

5

TCP Congestion Control

• TCP has four defined congestion control mechanisms to ensure the most efficient use of bandwidth, and quick error and congestion recovery

• TCP supports windowing—the process of sending numerous data packets in sequence without waiting for an intervening acknowledgement

• The four mechanisms, defined in detail in RFC 2581, are:

– Slow start – Congestion Avoidance

– Fast Retransmit – Fast Recovery

Chapter 5 44

5Network Window and

Receiver Window Determine the Current Congestion Window Size

Chapter 5 45

5

TCP Congestion Control

Slow Start

• When a TCP host starts up, the size of the congestion window is not known

• The initial value of the window being used is twice the sender’s MSS setting

Congestion Avoidance

• Once the window size has increased using the Slow Start algorithm, if an error occurs (a timeout), the window size is divided in half

• Next, the Congestion Avoidance algorithm is used to increase the window size in a linear manner

Chapter 5 46

5

TCP Congestion Control

Fast Retransmit/Fast Recovery

• When an out-of-order data segment is received, the receiver should immediately send duplicate ACKs

• The Fast Recovery process dictates that when a host receives three duplicate ACKs, it must immediately start retransmitting the lost segments, without waiting for the retransmission timer to expire

Chapter 5 47

5

TCP Congestion Control

Chapter 5 48

5

TCP Sliding Window

• TCP supports a sliding window mechanism—if you look at the data that is sent, and you move a window over it, the left side of the window is the data that was acknowledged

• As you can see in Figure 5-15, the data set A+B was sent and acknowledged

• There are some interesting exceptions to the standard windowing operations

Chapter 5 49

5

Window Slides Based on Acknowledgements Received

Chapter 5 50

5

TCP Sliding Window

• For example, the Nagle algorithm (named after John Nagle, author of RFC 896) defines that when small data segments are being sent, but not acknowledged, no other small segments an be sent

• Another interesting aspect of TCP windowing is the Silly Window Syndrome (SWS)

• SWS is caused when enough data is sent to a TCP host to fill its receiver buffer, thereby putting the receiver in a zero-window state

Chapter 5 51

5

TCP Header Fields and Functions

• You should recognize some characteristics of the TCP header, such as the Source and Destination Port Number fields

• The definitions for the Source Port Number Field and Destination Port Number Field are the same as those for the UDP fields

Chapter 5 52

5

TCP Header Fields and Functions

Sequence Number Field

• This field contains a number that uniquely identifies the TCP segment

• This sequence number provides an identifier that enables TCP receivers to identify when parts of a communication stream are missing

• Each TCP host self-assigns its own sequence number

Chapter 5 53

5

TCP Header Fields and Functions

Acknowledgement Number Field

• The Acknowledgement Number field indicates the next expected sequence number from the other side of the communications

Data Offset (Field)

• This defines the length of the TCP header in 4-byte increments

• A value of five in this field indicates that the TCP header is 20 bytes long

Chapter 5 54

5

Decoded TCP Header

Chapter 5 55

5

TCP Header Fields and Functions

Flags Field

Chapter 5 56

5

TCP Flag Settings (continued)

Chapter 5 57

5

TCP Header Fields and Functions

Window Field

• This field indicates the size of the TCP receiver buffer in bytes

• A window size of zero indicates that a sender should stop transmitting—the receiver’s TCP buffer is full

Checksum Field

• This TCP checksum is a bit strange, just like the UDP checksum

• The checksum is performed on the contents of the TCP header and data (not including padding), as well as pseudo-header derived from the IP header

Chapter 5 58

5

TCP Header Fields and Functions

Urgent Pointer Field

• This field is only relevant if the URG pointer is set

• If the URG pointer is set, the receiver must examine this field to see where to look/read first in the packet

Chapter 5 59

5

TCP Header Fields and Functions

TCP Options Field(s)

• This Options field is … well, optional

Chapter 5 60

5

Common and Appropriate Uses for TCP and UDP

• Given that TCP is robust and reliable, and UDP is not, why would any Application layer protocol or service choose UDP for transport when TCP is readily available?

• The short answer to that question is overhead

• For some lightweight services, such as Microsoft Messenger Service, TCP is overkill, and UDP is used instead

Chapter 5 61

5

Common and Appropriate Uses for TCP and UDP

• For applications, such as RIP, that rely on regular updates of routing tables, and track timeout values as part of ordinary behavior, the extra reliability of TCP isn’t necessary, and UDP is used instead

• TCP was designed in an era when 300-bps communications was considered fast, and when noisy lines or intermittent communications problems made long-haul, reliable transmission of data inherently risky without access to a robust, reliable transport service

• TCP is a more important transport than UDP, and is still used for the majority of TCP/IP Application layer protocols and services

Chapter 5 62

5

Summary

• Transport protocols come in two types: connectionless, which are lightweight unreliable, and provide only best-effort delivery services; and connection-oriented, which provide robust, reliable end-to-end delivery services, including explicit acknowledgement, segmentation and reassembly of arbitrary-sized messages, connection negotiation and management mechanisms, and retransmission of missing or erroneous segments

Chapter 5 63

5

Summary

• The User Datagram Protocol, UDP, is the connectionless protocol associated with the TCP/IP protocol suite

• In keeping with its simple capabilities, the UDP header is short and simple, consisting primarily of a protocol identifier in the IP header, an optional checksum value, and source and destination port addresses for the Application layer protocols or processes on the sending and receiving ends of a transmission

Chapter 5 64

5

Summary

• The Transmission Control Protocol, TCP, is the heavyweight, connection-oriented protocol that helps name the TCP/IP protocol suite

• In keeping with its more diverse, more robust capabilities, the TCP header is longer and more complex, including a variety of flags, values, and message types used to deliver acknowledgements, manage traffic flow, request retransmissions, and negotiate connections between hosts

Chapter 5 65

5

Summary

• Appropriate (and historical) uses for UDP concentrate on Application layer services that manage their own reliability and connections, such as NFS, and on chatty protocols and services, such as DHCP, SNMP, or RIP that rely on simple controls and fail-safes, and broadcast or periodic transmissions to handle potential reliability, deliverability, or reachability problems

Chapter 5 66

5

Summary

• Appropriate (and historical) uses for TCP

concentrate on providing reliable delivery of

user services such as terminal emulation

(Telnet and remote utilities), file transfer

(FTP), e-mail (SMTP), where potentially

important data must be delivered whole and

intact, or not at all (and flagged with an error

message)