Your shopping cart is empty!
TCP Error Recovery
To accomplish reliability, TCP numbers data bytes using the Sequence and Acknowledgment fields in the TCP header. Here you can see a web server is sending 1000 bytes of data to web browser and a sequence number 1000 is used in the TCP header. The web server sends another 1000 bytes of data with sequence number 2000 and yet another 1000 bytes of data with sequence number 3000. Next the web browser is sending acknowledgement to the server for successfully receiving of 3000 bytes. The 4000 in the acknowledgement field implies the next byte to be received.
TCP was designed to recover from node or line failures where the network propagates routing table changes to all router nodes. Since the update takes some time, TCP is slow to initiate recovery. The TCP algorithms are not tuned to optimally handle packet loss due to traffic congestion. Instead, the traditional Internet response to traffic problems has been to increase the speed of lines and equipment in order to say ahead of growth in demand.
TCP treats the data as a stream of bytes. It logically assigns a sequence number to each byte. The TCP packet has a header that says, in effect, "This packet starts with byte 379642 and contains 200 bytes of data." The receiver can detect missing or incorrectly sequenced packets. TCP acknowledges data that has been received and retransmits data that has been lost. The TCP design means that error recovery is done end-to-end between the Client and Server machine. There is no formal standard for tracking problems in the middle of the network, though each network has adopted some ad hoc tools.
TCP Flow Control
TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to receive and process it reliably. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate. For example, if a PC sends data to a smartphone that is slowly processing received data, the smartphone must regulate the data flow so as not to be overwhelmed.
TCP uses a sliding window flow control protocol. In each TCP segment, the receiver specifies in the receive window field the amount of additionally received data (in bytes) that it is willing to buffer for the connection. The sending host can send only up to that amount of data before it must wait for an acknowledgment and window update from the receiving host.
TCP sequence numbers and receive windows behave very much like a clock. The receive window shifts each time the receiver receives and acknowledges a new segment of data. Once it runs out of sequence numbers, the sequence number loops back to 0.
When a receiver advertises a window size of 0, the sender stops sending data and starts the persist timer. The persist timer is used to protect TCP from a deadlock situation that could arise if a subsequent window size update from the receiver is lost, and the sender cannot send more data until receiving a new window size update from the receiver. When the persist timer expires, the TCP sender attempts recovery by sending a small packet so that the receiver responds by sending another acknowledgement containing the new window size.
If a receiver is processing incoming data in small increments, it may repeatedly advertise a small receive window. This is referred to as the silly window syndrome, since it is inefficient to send only a few bytes of data in a TCP segment, given the relatively large overhead of the TCP header. TCP senders and receivers typically employ flow control logic to specifically avoid repeatedly sending small segments.
An image for TCP sequence numbers and receive windows behave very much like a clock. The receive window shifts each time the receiver receives and acknowledges a new segment of data. Once it runs out of sequence numbers, the sequence number loops back to 0.
Another illistration for flow control -
TCP does not perform any routing because it relies on it's lower layer IP/Network layer to perform all the routing. However, because IP does not guarantee end to end delivery it relies on TCP for error recovery and flow control.
Multiplexing is done by both TCP and UDP for deciding on how to deliver information to the appropriate computer. This is done using ports in the TCP Header field. Let's look at this scenario:
Computer 1 wants a web page from server 2 so it sends the request to it. What first happens is Computer 1 picks a random port to send the data from to the server. We all know that Port 80 is the destination port for the majority of all web pages so that never changes. Let's say that Compuer 1 chooses port 6789 to send from. Now, what we hvae just created here is a "socket" which is essentially just data inside the TCP header field used for mutliplexing.
Now Server 2 sees this information and uses the TCP header to form the "socket" which includes; IP address, transport Protocol and Port #. Sockets are used both ways because the server must send data back to the client, thus the server will create a socket. Lets examine what each socket looks like: (We use Fake IP addresses here for example)
Computer 1 (Sending data to the server): 10.0.0.1 - TCP - 80
That socket is used for sending data to the server; however, also remember that there is more information contained in the TCP header such as the source port from the originating computer (Computer 1). Now Sever 2 needs to send data back to that single Computer 1 (let's imagine that 100 other computers are connected to Server 2 as well) and to accomplish this it looks at the TCP header for the Port # and IP address and sends the data back to Computer 1 with this information. Although the way that the server tells how to send is with the unique port number used because you can have two computers in a remote LAN use the same IP address assigned to that subnet. Let's examine that socket:
Server 2 (Sending data back to Computer 1): 126.96.36.199 - TCP - 6789
The IP of Server 2 is 188.8.131.52 and it's using TCP as the transport layer protocol and sending the data back to Computer 1 on port 6789.
TCP also performs error recovery using sequence and acknowledgement fields in the TCP header. Each data byte (or segment) is numbered as a "Sequence" number when sent to a remote PC requesting it. Typically, the sequence number reflects the number of the first byte in the segment; however, this could also just be a random number so don't worry about this. You can actually setup a test environment with a client and a server and tun a program like Wireshare or tcpdump to examine a single transmission between a client and a server.
So lets assume that a client is sending data to a web server again:
Server 2 sends (3) 100 byte segments to Computer 1 (We will see later why it is only 3 100 byte segments and not 8 or 20). Once the server has sent those ordered bytes it awaits for a "Forward Ackniwledgement" from the client. The expected response should look like:
NO DATA - Acknowledgement=400
This indicates that the client recieved order bytes 100-300 and is expecting the next segment ordered 400. Let's assume that only ordered segments 100 and 300 were sent to Computer 1. The client recognizes that it doesn't have 200 and send a forward acknowledgement that looks like this;
NO DATA - Acknowledgement=300
Now the server knows that it didn't receive 200 so it resends that ordered segment and then the client responds;
NO DATA - Acknowledgement=400
Now the server knows it received ordered pairs 100-300 and to send the next ordered segments to the client. The sending server (Server 2) sets an "Acknowledgement time out" period where it waits a random time for a response and if that expires it resends ALL the data back to Computer 1.
TCP Data Segmentation
Segmentation is the process of carving up information into smaller pieces. The documentation for Transmission Control Protocol (TCP) refrers to what it calls 'data streams'. A data stream is really nothing more than a series of zeroes and ones that represent information. TCP receives data from an application and segments the data into pieces. This segmentation is necessary so that the information can be placed inside the TCP data field.
Once the data is segmented it is encapsulated within TCP. The TCP segment and TCP header is then passed down to Internet Protocol which stuffs the TCP segment and header into the payload of the IP datagram.
By segmenting the data, TCP creates chunks of data that can be routed separately over whatever connections are needed in order to reach the destination. Any of these segments can be retransmitted to replace the original segmentst that got lost or damaged in transmission.
TCP reassembles segments into a data stream and feeds that data stream to the application. The best known example of this activity is HTTP transfer of a web page. The web server loads a web page from disk, encapsulates the web page text in HTTP headers, the passes the HTTP encoded stream of text to TCP. TCP segments the text stream for transport across the network. The networking software (the stack) receives the TCP data segments and reassembles the HTTP stream of text, which your web browser reads, and renders as a web page.
TCP segment structure
Transmission Control Protocol accepts data from a data stream, segments it into chunks, and adds a TCP header creating a TCP segment. The TCP segment is then encapsulated into an Internet Protocol (IP) datagram. A TCP segment is "the packet of information that TCP uses to exchange data with its peers."
The term TCP packet, though sometimes informally used, is not in line with current terminology, where segment refers to the TCP PDU, datagram to the IP PDU and frame to the data link layer PDU:
A TCP segment consists of a segment header and a data section. The TCP header contains 10 mandatory fields, and an optional extension field (Options, orange background in table).
The data section follows the header. Its contents are the payload data carried for the application. The length of the data section is not specified in the TCP segment header. It can be calculated by subtracting the combined length of the TCP header and the encapsulating IP header from the total IP datagram length (specified in the IP header).
(The remaining options are obsolete, experimental, not yet standardized, or unassigned)