TCP (Transmission Control Protocol) Originally defined in RFC 793 (September 1981) UDP features: multiplexing + protection against bit errors Ports, checksum Connection-oriented Establishment and teardown of the connections Reliable Missing or corrupt segments are detected and retransmitted Stream-based, in-order delivery The sender writes bytes into a TCP connection and the receiver reads bytes out of the TCP connection Full duplex Each TCP connection supports a pair of byte streams, one flowing in each direction Flow control Keep sender from overrunning receiver (end-to-end issue) Congestion Control Keep sender from overrunning network Algorithm tries to fill available capacity
Data Link vs. Transport At the heart of TCP is the sliding window algorithm TCP runs over the Internet rather than a point-to-point link Many important differences TCP potentially connects many different hosts Explicit connection establishment and teardown Some shared information to enable the sliding window algorithm to start Different RTT (Round Trip Times) LANs vs. satellite networks, peak hour Variations in the RTT are even possible during a single TCP connection that lasts only a few minutes Adaptive timeout mechanism Potentially long delay in network Packets may be reordered as they cross the Internet TCP has to be prepared for very old packets to suddenly show up at the receiver, potentially confusing the sliding window algorithm Maximum Segment Lifetime (MSL) Since IP throws packets away after their TTL expires, TCP assumes that each packet has a maximum lifetime The current recommended setting is 120 s (conservative estimation) Different capacity at destination Multiple TCP connections supported at the same time TCP must include a mechanism that each side uses to learn what resources (e.g., how much buffer space) the other side is able to apply to the connection Different network capacity The sender has no idea what links will be traversed to reach the destination
TCP Overview Application process Client Server Application process The client process passes a stream of data through the socket The application reads the stream of data from the receive buffer TCP TCP Send Buffer TCP Segments Receive Buffer Basic Data Transfer (RFC 793): The TCP is able to transfer a continuous stream of octets in each direction between its users by packaging some number of octets into segments for transmission through the internet system. In general, the TCPs decide when to block and forward data at their own convenience. Current status of the sliding window mechanism Maximum Segment Size (MSS): MTU of the directly connected network, minus the size of the TCP and IP headers standard MSS for TCP = 536 bytes (576 20-20) push operation timer
Source Port Destination Port TCP Header Sequence Number Acknowledgment Source Port: 16 bits The source port number Destination Port: 16 bits The destination port number HLen Resrvd Flags Checksum AdvertisedWindow UrgPtr The SrcPort and DstPort, plus the SRc and Dst IP addresses, combine to uniquely identify each TCP connection (SrcPort, SrcIPAddr,DstPort,DstIPAddr) TCP demux key Options (variable) Checksum: 16 bits The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the TCP header, TCP data and the pseudo header. Required in both IPv4 and IPv6. HdrLen (Data Offset): 4 bits The number of 32 bit words in the TCP Header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits long. Reserved: 6 bits Reserved for future use. Must be zero.
TCP Header: Sliding window algorithm Sequence Number: 32 bits The sequence number of the first data octet in this segment (except when SYN is present). If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1. Acknowledgment Number: 32 bits If the ACK control bit is set this field contains the value of the next Sequence Number the sender of the segment is expecting to receive. Once a connection is established this is always sent. Advertised Window: 16 bits The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept. Sequence Number (Data) Acknowledgment + AdvertisedWindow Sequence Number (Data) Acknowledgment + AdvertisedWindow
TCP Flags Control Bits: 6 bits (from left to right) URG: Urgent Pointer field significant This flag is used to identify incoming data as 'urgent'. Such incoming segments do not have to wait until the previous segments are consumed by the receiving end but are sent directly and processed immediately Out-of-band signalling Interrupt/abort character sequence in remote login session ACK: Acknowledgment field significant PSH: Push Function A push causes the TCP to promptly forward and deliver data up to that point to the receiver The Push flag is usually set on the last segment of a file to prevent buffer deadlocks RST: Reset the connection if a packet is sent to a host in order to establish a connection, and there is no such service waiting to answer at the remote host, then the host would automatically reject the request and then send a reply with the RST flag set SYN: Synchronize sequence numbers the SYN flag is set when establishing the classical 3-way handshake between two hosts FIN: No more data from sender This flag is used to tear down the virtual connections Urgent Pointer: 16 bits This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set.
TCP Connection Management Connection establishment (Three-Way handshake) TCP sender, receiver establish connection before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info (e.g. RcvWindow) Connection setup is an asymmetric activity: one side does a passive open and the other side does an active open client: connection initiator server: contacted by client The two sides begin sending data only after this connection establishment phase is over Connection termination Connection teardown is symmetric: each side has to close the connection independently As soon as a participant is done sending data, it closes one direction of the connection The other side can keep the other half of the bidirectional connection open and continue sending data
Initial Sequence Number (ISN) The protocol places no restriction on a particular connection being used over and over again. New instances of a connection will be referred to as incarnations of the connection. How does the TCP identify duplicate segments from previous incarnations of the connection? The connection is being opened and closed in quick succession, The connection breaks with loss of memory and is then reestablished To avoid confusion TCP must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation. When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since TCP assumes that segments will stay in the network no more than the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 hours we can reasonably assume that ISN's will be unique. For a connection to be established or initialized, the two TCPs must synchronize on each other's initial sequence numbers. This is done in an exchange of connection establishing segments carrying a control bit called "SYN" (for synchronize) and the initial sequence numbers. As a shorthand, segments carrying the SYN bit are also called SYNs The solution requires a suitable mechanism for picking an initial sequence number and a slightly involved handshake to exchange the ISN's.
Three-Way Handshake active participant (client) A timer is scheduled for each of the first two segments, and if the expected response is not received, the segment is retransmitted SYN+ACK, SeqNum=y Ack=x+1 SYN SeqNum=x ACK, SeqNum=x+1 Ack=y+1 passive participant (server) The Acknowledgement Field identifies the next sequence number expected, thereby implicitly acknowledging all earlier sequence numbers ACK, SeqNum=x+1 Ack=y+1 First data segment
TCP State-Transition diagram States involved in opening a connection States involved in closing a connection
As the connection progresses, the connection moves from state to state according to the arcs TCP State-Transition diagram All Connections start in the CLOSED state The local application process invokes an operation on TCP States of the connection Each arc is labelled with a tag of the form event/action A segment arrives from the peer TimeOut based Retransmissions are NOT shown in the diagram
client SYN server Three-Way Handshake SYN+ACK ACK
Normal Connection Termination The application process on both sides of the connection must independently close its half of the connection Initiator Sequence FIN ACK Responder Sequence If only one side closes the connection, it is still available to receive data from the other side FIN ACK
TIME_WAIT State The TIME-WAIT state is required since the local side of the connection does not know if its ACK was successfully delivered Retransmission of the FIN segment Delayed packets FIN ACK FIN ACK SYN FIN
Connection Termination Simultaneous Close It is also possible for two devices to try to terminate a connection simultaneously. This term simultaneously does not mean that they both decide to shut down at exactly the same time. It simply means that one host decides to shut down and sends a FIN, but the other host sends its own FIN before receiving it. FIN FIN ACK ACK Both devices crosses the same states
Connection Termination- Rare transition Initiator Sequence FIN FIN+ACK Responder Sequence ACK
Connection Termination - Summary