Practical TCP/IP and Ethernet Networking- P29 pot

7 Host-to-host (transport) layer protocols Objectives When you have completed this chapter you should be able to: • Explain the basic functions of the host-to-host layer • Explain the basic operation of TCP and UDP • Explain the fundamental differences between TCP and UDP • Decide which protocol (TCP or UDP) to use for a particular application • Explain the meaning of each field in the TCP and UDP headers The host-to-host communications layer (also referred to as the service layer, or as the transport layer in terms of the OSI model) is primarily responsible for ensuring end-to- end delivery of packets transmitted by the Internet protocol (IP). This additional reliability is needed to compensate for the lack of reliability in IP. There are only two relevant protocols residing in the host-to-host communications layer, namely TCP (transmission control protocol) and UDP (user datagram protocol). In addition to this, the host-to-host layer includes the APIs (application programming interfaces) used by programmers to gain access to these protocols from the process/ application layer. Host-to-host (transport) layer protocols 123 Figure 7.1 TCP and UDP within the ARPA model 7.1 TCP (transmission control protocol) 7.1.1 Basic functions TCP is a connection-oriented protocol and is therefore reliable, although this word is used in a data communications context and not in an everyday sense. TCP establishes a connection between two hosts before any data is transmitted. Because a connection is set up beforehand, it is possible to verify that all packets are received on the other end and to arrange re-transmission in the case of lost packets. Because of all these built-in functions, TCP involves significant additional overhead in terms of processing time and header size. TCP includes the following functions: • Fragmentation of large chunks of data into smaller segments that can be accommodated by IP. The word ‘segmentation’ is used here to differentiate it from the ‘fragmentation’ performed by IP • Data stream reconstruction from packets received • Receipt acknowledgment • Socket services for providing multiple connections to ports on remote hosts • Packet verification and error control • Flow control • Packet sequencing and reordering In order to achieve its intended goals, TCP makes use of ports and sockets, connection oriented communication, sliding windows, and sequence numbers/acknowledgments. 124 Practical TCP/IP and Ethernet Networking 7.1.2 Ports Whereas IP can route the message to a particular machine on the basis of its IP address, TCP has to know for which process (i.e. software program) on that particular machine it is destined. This is done by means of port numbers ranging from 1 to 65 535. Port numbers are controlled by IANA (the Internet Assigned Numbers Authority) and can be divided into three groups. Well known ports, ranging from 1 to 1023, have been assigned by IANA and are globally known to all TCP users. For example, HTTP uses port 80. Registered ports are registered by IANA in cases where the port number cannot be classified as well known, yet it is used by a significant number of users. Examples are port numbers registered for Microsoft Windows or for specific types of PLCs. These numbers range from 1024 to 49 151, the latter being 75% of 65 536. A third class of port numbers is known as ephemeral ports. These range from 49 151 to 65 535 and can be used by anyone on an ad-hoc basis. 7.1.3 Sockets In order to identify both the location and application to which a particular packet is to be sent, the IP address (location) and port number (process) is combined into a functional address called a socket. The IP address is contained in the IP header and the port number is contained in the TCP or UDP header. In order for any data to be transferred under TCP, a socket must exist both at the source and at the destination. TCP is also capable of creating multiple sockets to the same port. 7.1.4 Sequence numbers A fundamental notion in the TCP design is that every BYTE of data sent over the TCP connection has a unique 32-bit sequence number. Of course this number cannot be sent along with every byte, yet it is nevertheless implied. However, the sequence number of the FIRST byte in each segment is included in the accompanying TCP header, for each subsequent byte that number is simply incremented by the receiver in order to keep track of the bytes. Before any data transmission takes place, both sender and receiver (e.g. client and server) have to agree on the initial sequence numbers (ISNs) to be used. This process is described under ‘establishing a connection’. Since TCP supports full duplex operation, both client and server will decide on their initial sequence numbers for the connection, even though data may only flow in one direction for that specific connection. The sequence number, for obvious reasons, cannot start at 0 every time, as it will create serious problems in the case of short-lived multiple sequential connections between two machines. A packet with a sequence number from an earlier connection could easily arrive late, during a subsequent connection. The receiver will have difficulty in deciding whether the packet belongs to a former or to the current connection. It is easy to visualize a similar problem in real life. Imagine tracking a parcel carried by UPS if all UPS agents started issuing tracking numbers beginning with 0 every morning. The sequence number is generated by means of a 32-bit software counter that starts at 0 during boot-up and increments at a rate of about once every 4 microseconds (although this varies depending on the operating system being used). When TCP establishes a connection, the value of the counter is read and used as the initial sequence number. This creates an apparently random choice of the initial sequence number. Host-to-host (transport) layer protocols 125 At some point during a connection the counter could rollover from 65 535 and start counting from 0 again. The TCP software takes care of this. 7.1.5 Acknowledgment numbers TCP acknowledges data received on a PER SEGMENT basis, although several consecutive segments may be acknowledged at the same time. The acknowledgment number returned to the sender to indicate successful delivery equals the number of the last byte received +1, hence it points to the next expected sequence number. For example: 10 bytes are sent, with sequence number 33. This means that the first byte is numbered 33 and the last byte is numbered 42. If received successfully, an acknowledgment number (ACK) of 43 will be returned. The sender now knows that the data has been received properly, as it agrees with that number. TCP does not issue selective acknowledgments, so if a specific segment contains errors, the acknowledgement number returned to the sender will point to the first byte in the defective segment. This implies that the segment starting with that sequence number, and all subsequent segments (even though they may have been transmitted successfully) have to be retransmitted. From the previous paragraph it should be clear that a duplicate acknowledgement received by the sender means that there was an error in the transmission of one or more bytes following that particular sequence number. Please note that the sequence number and the acknowledgment number in one header are NOT related at all. The former relates to outgoing data, the latter refers to incoming data. During the connection establishment phase the sequence numbers for both hosts are setup independently, hence these two numbers will never bear any resemblance to each other. 7.1.6 Sliding windows Obviously there is a need to get some sort of acknowledgment back to ensure that there is a guaranteed delivery. This technique, called positive acknowledgment with retransmission, requires the receiver to send back an acknowledgment message within a given time. The transmitter starts a timer so that if no response is received from the destination node within a given time, another copy of the message will be transmitted. An example of this situation is given in Figure 7.2. 126 Practical TCP/IP and Ethernet Networking Figure 7.2 Positive acknowledgment philosophy The sliding window form of positive acknowledgment is used by TCP, as it is very time consuming waiting for each individual acknowledgment to be returned for each packet transmitted. Hence the idea is that a number of packets (with cumulative number of bytes not exceeding the window size) are transmitted before the source may receive an acknowledgment to the first message (due to time delays, etc). As long as acknowledgments are received, the window slides along and the next packet is transmitted. During the TCP connection phase each host will inform the other side of its permissible window size. For example, for Windows 95/98 this is typically 8K or around 8192 bytes. This means that, using Ethernet, 5 full data frames comprising 5 × 1460 = 7300 bytes can be sent without acknowledgment. At this stage the window size has shrunk to less than 1000 bytes, which means that unless an ACK is generated, the sender will have to pause its transmission. 7.1.7 Establishing a connection A three-way SYN/ SYN_ACK/ACK handshake (as indicated in Figure 7.3) is used to establish a TCP connection. As this is a full duplex protocol it is possible (and necessary) for a connection to be established in both directions at the same time. . sockets, connection oriented communication, sliding windows, and sequence numbers/acknowledgments. 124 Practical TCP/IP and Ethernet Networking 7.1.2 Ports Whereas IP can route the message. message will be transmitted. An example of this situation is given in Figure 7.2. 126 Practical TCP/IP and Ethernet Networking Figure 7.2 Positive acknowledgment philosophy The sliding. TCP and UDP • Explain the fundamental differences between TCP and UDP • Decide which protocol (TCP or UDP) to use for a particular application • Explain the meaning of each field in the TCP and