Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What if a TCP handshake segment is lost?

Tags:

In TCP 3-way handshake, 3 segments will be sent (SYN, SYN ACK, ACK). What if the third segment(ACK) is lost? Is the sender going to resend the segment or give up establishing the connection? And how do the two hosts know the segment is lost?

like image 371
ZHOU Avatar asked Apr 28 '13 04:04

ZHOU


People also ask

What happens when a TCP segment is lost?

TCP Retransmissions After sending a packet of data, the sender will start a retransmission timer of variable length. If it does not receive an acknowledgment before the timer expires, the sender will assume the segment has been lost and will retransmit it.

What happens if SYN ACK is lost?

In most cases though, even if that ACK was lost, there will be no resending for a very simple reason. Directly after the ACK, the host that opened the TCP protocol is likely to start sending data. That data will, as all TCP packets, have an ACK number, so the recipient would get an ACK that way.

Can the receiver know if ACK packet is missing?

The sender does not know whether a data packet was lost, an ACK was lost, or if the packet or ACK was simply overly delayed. In all cases, the action is the same: retransmit.

Is every TCP segment acknowledged?

SYN starts a connection; you'll usually only see it when the connection's being established. But all data being sent via TCP requires an ACK. Every byte sent must be accounted for, or it will be retransmitted (or the connection reset (closed), in severe cases).


1 Answers

TCP has a sequence number in all packets. Hence it's easy to know if a packet was lost or not. If a host doesn't get an ACK on a packet he just resends it.

In most cases though, even if that ACK was lost, there will be no resending for a very simple reason. Directly after the ACK, the host that opened the TCP protocol is likely to start sending data. That data will, as all TCP packets, have an ACK number, so the recipient would get an ACK that way. Hence, the sender of the SYN-ACK should reasonably not care that it didn't get the ACK, because it gets an "implicit" ACK in the following package.

The re-send of the SYN-ACK is only necessary of there no data is received at all.

Update: I found the place in the RFC that specified exactly this:

If our SYN has been acknowledged (perhaps in this incoming segment) the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent.

In other words, if the ACK is dropped but the next packet is not dropped, then everything is fine. Otherwise, the connection must be reset. Which makes perfect sense.

like image 81
Lennart Regebro Avatar answered Sep 29 '22 12:09

Lennart Regebro