I am confused as to how the TCP actually works. I have read in several books and articles that it is responsible for the rearranging of transmitted datagrams at the receiving host. However, I have been reading RFC 793, and can't find such specification. On the other hand, RFC 791 (Internet Protocol) explicitly states that the Internet Protocol is responsible for rearranging sent packets at the receiving host. Any help? Thank you!
7
-
1Have you looked at the wikipedia article? If so, what is there that is unclear?– soandosCommented Apr 5, 2012 at 2:32
-
I have read those but I need some quoted references.– WikiWitzCommented Apr 5, 2012 at 2:34
-
Like RFC675? (found at the bottom)?– soandosCommented Apr 5, 2012 at 2:35
-
From wikipedia: "Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data,...". Where's the reference to that?– WikiWitzCommented Apr 5, 2012 at 2:43
-
The section header is "Case 2: TCP receives a FIN from the network," look in that paragraph. You could have just used ctrl+f...– soandosCommented Apr 5, 2012 at 2:46
|
Show 2 more comments
2 Answers
From the perspective of IP, a packet is a single unit of data. It may be fragmented as it traverses devices with different MTU (maximum transmission unit), and is responsible for putting those fragments back together at the other end. So a 1500 byte packet may get split into 5 fragments as it traverses part of the network with a 300 MTU and then the packet is reconstructed at the other end.
TCP on the other hand deals with streams of data, consisting of any number of IP packets. So it is TCPs responsibility to ensure that 1) the order of the packets in the stream are correct (when passed up to the next layer), and 2) they all make it through - or indicate an error otherwise
So they are both responsible for data sequence within their own layers.
But each ISO layer has no knowledge of upper layers. So it simply isn't possible for IP to re-arrange packets in the correct sequence for TCP - the sequence that TCP expects packets to be in is meaningless to IP. In the same way that TCP cannot ensure that an HTTP call is correctly configured, or for ethernet to know that an IP packet is correctly addressed.
Bottom line up front the IP protocol has no concept of what the order of your data is. IP packets are individual entities with no relation to each other. The IP protocol's only responsibility is to get the packet from point A to point B. It can deal with packet fragmentation that has occurred because of smaller MTUs in transit then at the sender, and it will put fragments back together at the receiver, but it has no tool with which to order your data.
TCP is a partnered protocol with the IP protocol. The TCP protocol provides what is referred to as the transport layer of the TCP/IP suite. The transport layer consists of the TCP and UDP protocols. TCP provide state and delivery confirmation packets that are sent over IP. UDP is stateless and really only provides a lightweight mapping of IP addresses to port numbers, it gets used a lot in streaming applications or where fast and small is better than reliable.
TCP provides some the key functionality of making sure that you receive all of your packets. Once the two clients establish a TCP connection every packet that is sent between the two of them is accounted for as it arrives, based on a sequence number and the packet length. This is done with the Sliding Window Data Transfer and Acknowledgment system.
The key to the system is that each acknowledgment packet from the receiver only acknowledges the last packet received in a continuous stream from the sender. So if packets 1, 2 & 4 arrive at the sender they are passed to TCP from IP without any processing. However, TCP will only ACK receipt of up to packet 2 (and implicitly packet 1), because it can tell that there should have been a packet 3 based on the sequence number and the packet length.
Depending on the implementation of TCP at the sending system packets 3 and 4 again to ensure that they are received. The time before resend is based on timing built into the implementation of TCP on the computer and can change based on the speed of the network and the performance of the link. Over time if you have an unreliable link the number of packets that will be sent without ACK of previous packets will get smaller.
Again, bottom line, IP doesn't know what order your packets belong in. I only understands how to get the packet from here to there.
