660 likes | 685 Views
Transport Layer TCP/IP Protocols. A Guide to TCP/IP. 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
E N D
Transport Layer TCP/IP Protocols A Guide to TCP/IP Chapter 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
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
Understanding Connectionless Transport Protocols • 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 Chapter 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
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
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
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
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
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
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
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
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
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
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
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
UDP Port Numbers and Processes Chapter 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 sequencenumber tracking • An acknowledgement is a positive response, indicating a set of data arrived Chapter 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
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
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
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: • Ensure the destination host is available • Ensure the destination host is listening on the destination port number • Inform the destination host of the initiator’s sequence number so the two sides can track data as it is transferred Chapter 5
TCP Handshake Is a Three-Packet Process Chapter 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
Handshake Packet #2 • Host #2 defined its starting sequence number as 135471 Chapter 5
Handshake Packet #3 • Host 1’s sequence number is now 2371728 • The Acknowledgement Number field value is now set to 135472 Chapter 5
Handshake Packet #3 • The TcpMaxConnectRetransmission Registry setting defines the number of SYN retries sent when attempting to establish a TCP connection Chapter 5
TcpNumConnections Registry Setting Chapter 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
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
TCP Keep-Alive Process Chapter 5
TCP Connection Termination • The TCP connection termination process requires four packets Chapter 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
TCP Connection States Chapter 5
TCP Connection States Chapter 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
TCP Sequence and Acknowledgement Process Chapter 5
Simple Sequenced Communication Chapter 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
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
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
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
Network Window and Receiver Window Determine the Current Congestion Window Size Chapter 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
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
TCP Congestion Control Chapter 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
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