The labs on this site need JavaScript to run. The same content is written out below.
Learn › Networking › Transport layer
TCP connections and retransmission
When a packet is lost, who notices and sends it again?
TCP establishes a connection before it sends data, and it receives acknowledgments that tell it how far the data has been received. If no acknowledgment arrives, it sends the data again. UDP sends without any of that procedure.
Checked against documentation and standards · Checked against the TCP specification (RFC 9293)
Concepts in this lab
- TCP and UDP
- The two main ways of transporting data on the internet. TCP establishes a connection before communication, guarantees that data arrives complete and in order, and sends data again if there is a problem. UDP sends data without a connection and does not guarantee arrival or order, but in return it is lightweight and fast. HTTP/1.1, HTTP/2, and database connections use TCP, and real-time video and voice and DNS mainly use UDP.
- Three-way handshake
- The three-step process used to establish a TCP connection. The client sends a connection request (SYN), the server sends its acceptance together with its own connection request (SYN+ACK), and the client acknowledges it (ACK). After both sides have confirmed that they can send to and receive from each other, data transfer starts.
- Flow control and congestion control
- Both are TCP functions that adjust the sending rate. Flow control adjusts the amount sent to match what the receiver can handle, so that the receiver does not overflow. Congestion control senses how congested the network is and decreases or increases the amount sent, to prevent congestion across the whole network.
Try these
- Default settings — TCP, no loss. It establishes a connection, sends the data, and receives acknowledgments.
- A lost data packet — No acknowledgment arrives, so the data is sent again.
- A lost connection request — With no reply, the sender waits and then tries again.
- The same loss with UDP — The lost datagram stays lost.
Running with the default settings
- Step 1: the client sends a SYN, which says "I want to connect." It announces the starting number (100) that it will use.
- Step 2: the server answers, "Received (ACK), and I will connect too (SYN)." ack=101 means "I have received up to 100, so send 101 next."
- Step 3: the client acknowledges the SYN of the server. Both sides have now confirmed that "what I send arrives, and what the other side sends reaches me." The connection is established.
- It splits the data into segments, numbers them, and sends them.
- The server acknowledges: "I have received up to 106, so send 107 next."
- It sends the second segment.
- It sends the third segment.
- The server acknowledges: "I have received everything up to 115."
- When there is nothing left to send, each side sends "I am finished (FIN)," has it acknowledged, and closes the connection.
Result of this run
- TCP detects a loss from the sequence numbers and acknowledgments and sends the data again, and even if segments arrive in the wrong order, it puts them in order by number before passing them to the application. The application never learns about the loss. The price is the round trip to establish the connection and, when a loss happens, the delay of also waiting for the data that follows.
- Flow control adjusts the sending so that it does not exceed what the receiver can handle, and congestion control slows the sending down when the network is congested. When a loss occurs, TCP assumes the network is congested and lowers its sending rate.
Code
// TCP: connect first, then send
Socket socket = new Socket("shop.example", 443); // the three-way handshake happens here
OutputStream out = socket.getOutputStream();
out.write(data); // the operating system splits it into segments and
// handles acknowledgment, retransmission, and ordering
socket.close(); // close the connection
Assumptions of this model
This is a small example in which "Hello, world!!!" is split into three pieces and sent. The numbers (seq, ack) are arbitrary values chosen to make the example easier to follow, and each character is counted as 1 byte (ASCII text), so the three pieces are 6, 6, and 3 bytes. The timing of retransmission is simplified. Besides the timer expiring, real TCP also retransmits right away when the same acknowledgment arrives three times in a row (three duplicate ACKs). The principles of the three-way handshake and of retransmission follow the TCP specification (RFC 9293).
Previous lab: Sockets and ports · Next lab: TCP and UDP