Main content
Course: Content items for courses > Unit 17
Lesson 5: Transporting packetsTransmission Control Protocol (TCP)
The Transmission Control Protocol (TCP) is a transport protocol that is used on top of IP to ensure reliable transmission of packets.
TCP includes mechanisms to solve many of the problems that arise from packet-based messaging, such as lost packets, out of order packets, duplicate packets, and corrupted packets.
Since TCP is the protocol used most commonly on top of IP, the Internet protocol stack is sometimes referred to as TCP/IP.
Packet format
When sending packets using TCP/IP, the data portion of each IP packet is formatted as a TCP segment.
Each TCP segment contains a header and data. The TCP header contains many more fields than the UDP header and can range in size from
The TCP header shares some fields with the UDP header: source port number, destination port number, and checksum. To remember how those are used, review the UDP article.
From start to finish
Let's step through the process of transmitting a packet with TCP/IP.
Step 1: Establish connection
When two computers want to send data to each other over TCP, they first need to establish a connection using a three-way handshake.
The first computer sends a packet with the SYN bit set to
The SYN and ACK bits are both part of the TCP header:
In fact, the three packets involved in the three-way handshake do not typically include any data. Once the computers are done with the handshake, they're ready to receive packets containing actual data.
Step 2: Send packets of data
When a packet of data is sent over TCP, the recipient must always acknowledge what they received.
The first computer sends a packet with data and a sequence number. The second computer acknowledges it by setting the ACK bit and increasing the acknowledgement number by the length of the received data.
The sequence and acknowledgement numbers are part of the TCP header:
Those two numbers help the computers to keep track of which data was successfully received, which data was lost, and which data was accidentally sent twice.
Step 3: Close the connection
Either computer can close the connection when they no longer want to send or receive data.
A computer initiates closing the connection by sending a packet with the FIN bit set to 1 (FIN = finish). The other computer replies with an ACK and another FIN. After one more ACK from the initiating computer, the connection is closed.
Detecting lost packets
TCP connections can detect lost packets using a timeout.
After sending off a packet, the sender starts a timer and puts the packet in a retransmission queue. If the timer runs out and the sender has not yet received an ACK from the recipient, it sends the packet again.
The retransmission may lead to the recipient receiving duplicate packets, if a packet was not actually lost but just very slow to arrive or be acknowledged. If so, the recipient can simply discard duplicate packets. It's better to have the data twice than not at all!
Handling out of order packets
TCP connections can detect out of order packets by using the sequence and acknowledgement numbers.
When the recipient sees a higher sequence number than what they have acknowledged so far, they know that they are missing at least one packet in between. In the situation pictured above, the recipient sees a sequence number of #73 but expected a sequence number of #37. The recipient lets the sender know there's something amiss by sending a packet with an acknowledgement number set to the expected sequence number.
Sometimes the missing packet is simply taking a slower route through the Internet and it arrives soon after.
Other times, the missing packet may actually be a lost packet and the sender must retransmit the packet.
In both situations, the recipient has to deal with out of order packets. Fortunately, the recipient can use the sequence numbers to reassemble the packet data in the correct order.
🙋🏽🙋🏻♀️🙋🏿♂️Do you have any questions about this topic? We'd love to answer—just ask in the questions area below!
Want to join the conversation?
When handling out-of-order packets, how does sending the expected acknowledgement number indicate to the sender that something is amiss? How would the sender know if it had to re-send the package if it was lost?(11 votes)
Imagine you want to send the letters of the alphabet to a friend over the Internet.
You send ('a', 1), ('b', 2), ('c', 3), one by one to your friend. The numbers are used in case the packets/messages arrive out of order.
Now, suppose the friend gets ('b', 2), but then ('d', 4). It's missing 'c' because it expects a continuous increase of numbers and 3 is missing. So your friend asks you to resend the letter at position 3 (this is the idea behind the expected acknowledgement number).
As mentioned in the article, it may be just that ('c', 3) is taking longer to arrive and so in that case, the sender sends a duplicate message, but duplicates are typically dropped by the receiver.
A helpful way to think about these numbers is that they synchronize the data so both parties have the same "view" of it.
Imagine if we didn't have a universal notion of time. Then, the sender's view of time would be different from the receivers. Hence, they synchronize their "view" of time by communicating numbers.
Hope this helps!(53 votes)
- What does the article mean "setting the ACK bit and increasing the acknowledgement number by the length of the data received"?(8 votes)
Say you want to send a message that's 32 bytes long.
So you check if the receiver is there. The receiver answers with ACK #1. That means something like "hullo I can hear you".
Now you send the message of 32 bytes and the receiver responds with ACK #33, that means "I got your message and received a total of 33 bytes from you". (the additional byte comes from the introduction).
Now if you send another message thats 100 bytes long, the receiver would respond with ACK #133, meaning "I got 133 bytes from you".
That way you can see if the connection works without the receiver sending you the entire message back and you having to read it.(16 votes)
- Hi. Following up on Carita's question below? How does the sender know that a packet is missing if the recipient only responds with "Ack [expected packet number]"? Is an Ack for a missing packet somehow different from an Ack for a received packet to trigger the sender to resend the missing packet?(5 votes)
- Good question, this is a central concern in protocol development: how to deal with ambiguity.
A sender also keeps their sequence number to synchronize, so if they receive an Ack[packet_number] not matching their current sequence number, they can distinguish between a missing packet and sending new packets.
An Ack for a missing packet is not any different from an Ack for a received packet. It is the fact that the sender has their own current sequence number, which in some sense is their own "time", that enables them to distinguish.
Hope this helps!(9 votes)
While the recipient is reassembling the packets, does it keep all those packets in the RAM?(8 votes)
Question: How does a computer know that it is dealing with TCP or UDP since the receiver can not initially know before hand what type of protocol to use? Does the computer need to pre-install a program that recognizes such protocols if so which programs?(4 votes)
There is a header on every packet that (by order of IANA) denotes whether a packet is TCP or UDP. If the header is for TCP, the NIC knows to throw back an ACK packet. This is all firmware and so low level not many people would want to mess with it.(8 votes)
Hello,
I'm looking at the Transmission Control Protocol page (I'm trying to ask a question under that page, but all I'm seeing is the comments from the User Datagram Protocol page, so I'm not sure where this is actually going to post). It keeps mentioning a sequence number. What exactly is a sequence number, and how does it change as more data is sent? For example, in the last section, it has the numbers 1 and 37 for the sequence, and 73 and 37 for the acknowledgement. Where are these numbers coming from?(5 votes)
I believe that these numbers represent different packages and the order they were sent in - ex: you send a 3 text messages and they're flagged as a sequence of message 1,2 and 3 in the order they were sent(3 votes)
- "In the situation pictured above, the recipient sees a sequence number of #73 but expected a sequence number of #37.”
Why is the expected sequence number 37 in this case? Is the sequence number also incremented like the acknowledgment number based upon the bytes received in the data? Or is the sequence number incremented according to the sequence of the packets (which makes more sense here)?(5 votes)- 37 is indicating the acknowledge number. Since the ACK bit is set to one, adding the ACK bit + the amount of data in the packet gives us 37. I believe the sequence number is incremented based on how much information is in the packet. Hope this helps!(1 vote)
Why bring in Transmission Control Protocol when it can lead to bigger problems than it's used to having?(2 votes)- TCP gives a reliable network connection, ensuring that all packets arrive (if possible) and are assembled in the correct order. Generally, these benefits outweigh its extra network usage which is why TCP is usually used instead of UDP or just IP.(6 votes)
- Question 1: who decides which transport protocol is used? Udp vs TCP. is UDP restricted to some specific packet or something like that?
Question 2: can i choose what transport protocol is used at any given time?
Question 3: The data i want to send is broken in small packets. Can those packets be delivered using different protocols, or are they obliged to use the same protocol for the whole set of packets that belong to that data(5 votes)- Udp is the corruption detection protocol. TCP is the reliable’s transmission protocol. Both are used every time you send packets, and no, you can’t choose which one to use because both are needed. Packets all use the same protocols, not matter their path.(0 votes)
What is meant by the term "offset" mentioned in the TCP segment illustration?(4 votes)
