Presentation is loading. Please wait.

Presentation is loading. Please wait.

Transport Layer TCP/IP Protocols

Similar presentations


Presentation on theme: "Transport Layer TCP/IP Protocols"— Presentation transcript:

1 Transport Layer TCP/IP Protocols
A Guide to TCP/IP Chapter 5

2 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 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 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

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 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 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 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 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 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 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 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 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 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 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 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 UDP Port Numbers and Processes
Chapter 5

18 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 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 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 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 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

23 TCP Handshake Is a Three-Packet Process
Chapter 5

24 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 ( ) Chapter 5

25 Handshake Packet #2 Host #2 defined its starting sequence number as Chapter 5

26 Handshake Packet #3 Host 1’s sequence number is now 2371728
The Acknowledgement Number field value is now set to Chapter 5

27 Handshake Packet #3 The TcpMaxConnectRetransmission Registry setting defines the number of SYN retries sent when attempting to establish a TCP connection Chapter 5

28 TcpNumConnections Registry Setting
Chapter 5

29 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 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 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 TCP Keep-Alive Process
Chapter 5

32 TCP Connection Termination
The TCP connection termination process requires four packets Chapter 5

33 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 TCP Connection States Chapter 5

35 TCP Connection States Chapter 5

36 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 TCP Sequence and Acknowledgement Process
Chapter 5

38 Simple Sequenced Communication
Chapter 5

39 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 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 TCP Error-Detection and Error-Recovery Process
Chapter 5

42 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 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 Network Window and Receiver Window Determine the Current Congestion Window Size
Chapter 5

45 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 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 TCP Congestion Control
Chapter 5

48 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 Window Slides Based on Acknowledgements Received
Chapter 5

50 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 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 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 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 Decoded TCP Header Chapter 5

55 TCP Header Fields and Functions
Flags Field Chapter 5

56 TCP Flag Settings (continued)
Chapter 5

57 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 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 TCP Header Fields and Functions
TCP Options Field(s) This Options field is … well, optional Chapter 5

60 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 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 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 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 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 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 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), (SMTP), where potentially important data must be delivered whole and intact, or not at all (and flagged with an error message) Chapter 5


Download ppt "Transport Layer TCP/IP Protocols"

Similar presentations


Ads by Google