The Logic Behind the TCP SACK Mechanism
The logic of this article revolves around the TCP SACK mechanism. First, it explores the necessity of the SACK mechanism in TCP communication. Next, it demonstrates real-world applications of SACK by capturing packets using Wireshark. Finally, it extends the discussion to related concepts that often accompany SACK, emphasizing that the SACK mechanism is integral to understanding TCP and effective data transmission. To effectively address real-world problems, the SACK mechanism must collaborate with other TCP protocols!
Why Is the TCP SACK Mechanism Necessary?
Before discussing why it is necessary SACK
, we should first understand TCP
a mechanism for receiving data: it can only confirm continuous data, and it can only consume the previous continuous data.
TCP is never able to acknowledge data it has received correctly but that is not contiguous
A receiving TCP prevents applications from consuming data beyond a hole because of the byte stream abstraction it provides.
For example:
For example, the two packets sender
are sent 10
: #1
, #2
, #3
, #4
, #5
, #6
, #7
, #8
, #9
, #10
, but #5
they are lost in the middle. For sender
and receiver
, it is like a “hole”hole
in the middle of the data .
tcp
receiver
The receiver ack
can only say “received” #4
, which means it should be received #5
. Once again, because the tcp
protocol ack
mechanism can only receive continuous data, if #5
it is lost, even if #6
, #7
, #8
, #9
, #10
all arrive receiver
, receiver
it cannot #5
tell sender
me that it was just lost , and I don’t know whether #5
the subsequent packets have arrived .sender
sender
What should it do now ? sender
Not knowing the specific situation, it can only resend #5
, #6
, #7
, #8
, #9
, #10
all at once.
Like the situation above: in the process of sending a series of data, the middle data packets are likely to be lost. If they are resent every time, firstly, the efficiency is low, and secondly, the network link bandwidth is wasted.
It would be great if sender
you could know that there was a hole in the data you sent (a packet was lost), so sender
you can send the missing data accordingly .
sender
How can we know this information? We can only rely on receiver
the cooperation of others and tell the “hole” generated in the sending process receiver
according to our own receiving situation.sender
If a TCP sender were able to learn of the existence of holes at the receiver, it could better select which particular TCP segments to retransmit when segments are lost or otherwise missing at the receiver.
That’s right, the so-called SACK
. Selective Acknowledgement
It selective
refers to the above select lost segments to retransmit
, how can one word “wonderful” describe it.
This is the end SACK
of our introduction to the concepts. Next, we will learn SACK
the details based on real cases.
Real-World Applications of the TCP SACK Mechanism
After catching them, you will find that SACK
they often appear with two good brothers.
They are Wireshark Expert Infos
” TCP previous segment not captured
” and ” TCP Dup ACK
” in the text box.
Let’s take a look at the data packet capture below~
The sender sender
‘s port is 30000
and the receiver receiver
‘s port is 1479
.
Before giving a detailed analysis, you can take a look at it yourself and pay attention to the meaning of the table header.
So, now let’s start the analysis.
Bag #10415
receiver
Say: Hey, I have received all the previous data. Next, please seq=9163441
send the data from the beginning.
ps
: TCP Len
The length is 0
, indicating that this packet is just a ack
packet and does not carry any application data
Bag #10416
sender
Say: OK, I will start seq=9163441
sending from the beginning, and I will start sending 1320 bytes
the next data packet from the beginning.seq=9164761
ps
: Everything is fine here.
Bag #10417
Accidents are starting to happen. How do you know? wireshark
The prompt is ” TCP previous segment not captured
“.
Why? Because the data is discontinuous.
10416
The number packet said that the next one seq=9164761
would be sent from the beginning, but in 10417
the number packet seq=9175321
, there was still a lot of data in the middle that had not been sent!
wireshark
Realizing that there might be some problems in the middle, we were reminded immediately.
This is what I said at the beginning, sending packets continuously, but data was lost in the middle, but SACK
this event can be recorded. Let’s see 10418
how to deal with it!
Bag #10418
receiver
:I declare two things, 1) my Ack=9164761
, which means #10416
I received the data of the number packet. 2) my TCP Option
has SACK
information, 9175321-9176641
which means #10417
I received the content of the number. sender
Do you know?
Bag #10419
sender
: #10417
I continue to send the following content (I haven’t realized that I need to retransmit some of the previous data)
Bag #10420
receiver
:Ahem, I repeat, my Ack=9164761
, indicates that #10416
I received the data of the packet with the number , this is not the first time I have done Ack
this seq
( TCP Dup ACK
), please sender
note. Secondly, I received the rest of the data packets you sent, please see the part TCP Option
in mine SACK
.
Did you suddenly realize it? To make things clearer, let’s take a look at the captured packets again from a global perspective:
First, let’s look at the red and blue arrow parts: receiver
It keeps declaring itself ack=9164761
, indicating that it has received ack
all the data before it in sequence, but it repeatedly declares ( TCP Dup Ack
) that it has only received this continuously, and the following data packets may be one or more segments of data. For details, please see SACK
the information in my .
Then there is receiver
the SACK information in the packet. The green box indicates receiver
the data segment that may be lost. The left range starts from seq=9175321
, which is exactly #10417
the data content sent by the packet. As sender
the data is continuously sent, the right range receiver
of SACK
continues to expand, which can be seen from the yellow box.
Extended Questions
Can all senders and receivers use the SACK mechanism?
No, whether sack
the mechanism can be used is determined during the three-way handshake process.
As long as both parties are in TCP Option
the process of explicitly turning it on SACK permitted
, it means that in the subsequent data transmission process, SACK
the mechanism can be used to speed up the recovery of data transmission.
Why do we need TCP Dup Ack? What does it do?
One sentence answer: receiver
By SACK
notifying the actual machine of sender
possible missing data, Dup Ack
it can be informed sender
to resend.
Dup Ack
As the name suggests, it is receiver
a repetitive statement that I have received a certain package. If you think about it carefully, it is actually SACK
an indispensable auxiliary.
For network links, in addition to packet loss, disorder may also occur.
For example #1,2,3,4,5
, the messages were originally sent in sequence, but after passing through an asymmetric network link, they became disordered and receive
the received order was 13245
.
receiver
Receive #1
, then send ack=#1
.
receiver
Received #3
, means sent ack=#1
, sack=#3
.
sender
Do we need to send it immediately after receiving it #2
? No, because receiver
it will be received right after #2
, and the gap caused by the missing data will be filled. Because this scenario is just disordered, there is no need to retransmit it?
So how can we distinguish out-of-order packets from packet loss? In fact, this is very difficult. What TCP
the protocol can do is to try to distinguish them, which is the so-called compromise.
TCP
How do you think this needs to be retransmitted?
ack
If you receive the same packet three or more times in a row within a certain period of time Dup Ack
, wireshark
you will think that the packet sender
needs to be retransmitted. Otherwise, sender
you don’t need to pay too much attention to this information.
About SACK
, have I expressed myself clearly?