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 TCPa 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 senderare sent 10: #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, but #5they are lost in the middle. For senderand receiver, it is like a “hole”hole in the middle of the data .
tcpreceiverThe receiver ackcan only say “received” #4, which means it should be received #5. Once again, because the tcpprotocol ackmechanism can only receive continuous data, if #5it is lost, even if #6, #7, #8, #9, #10all arrive receiver, receiverit cannot #5tell senderme that it was just lost , and I don’t know whether #5the subsequent packets have arrived .sender
senderWhat should it do now ? senderNot knowing the specific situation, it can only resend #5, #6, #7, #8, #9, #10all 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 senderyou could know that there was a hole in the data you sent (a packet was lost), so senderyou can send the missing data accordingly .
senderHow can we know this information? We can only rely on receiverthe cooperation of others and tell the “hole” generated in the sending process receiveraccording 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 AcknowledgementIt selectiverefers to the above select lost segments to retransmit, how can one word “wonderful” describe it.
This is the end SACKof our introduction to the concepts. Next, we will learn SACKthe details based on real cases.
Real-World Applications of the TCP SACK Mechanism
After catching them, you will find that SACKthey 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 30000and 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
receiverSay: Hey, I have received all the previous data. Next, please seq=9163441send the data from the beginning.
ps: TCP LenThe length is 0, indicating that this packet is just a ackpacket and does not carry any application data
Bag #10416
senderSay: OK, I will start seq=9163441sending from the beginning, and I will start sending 1320 bytesthe next data packet from the beginning.seq=9164761
ps: Everything is fine here.
Bag #10417
Accidents are starting to happen. How do you know? wiresharkThe prompt is ” TCP previous segment not captured“.
Why? Because the data is discontinuous.
10416The number packet said that the next one seq=9164761would be sent from the beginning, but in 10417the number packet seq=9175321, there was still a lot of data in the middle that had not been sent!
wiresharkRealizing 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 SACKthis event can be recorded. Let’s see 10418how to deal with it!
Bag #10418
receiver：I declare two things, 1) my Ack=9164761, which means #10416I received the data of the number packet. 2) my TCP Optionhas SACKinformation, 9175321-9176641which means #10417I received the content of the number. senderDo you know?
Bag #10419
sender: #10417I 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 #10416I received the data of the packet with the number , this is not the first time I have done Ackthis seq( TCP Dup ACK), please sendernote. Secondly, I received the rest of the data packets you sent, please see the part TCP Optionin 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: receiverIt keeps declaring itself ack=9164761, indicating that it has received ackall 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 SACKthe information in my .
Then there is receiverthe SACK information in the packet. The green box indicates receiverthe data segment that may be lost. The left range starts from seq=9175321, which is exactly #10417the data content sent by the packet. As senderthe data is continuously sent, the right range receiverof SACKcontinues to expand, which can be seen from the yellow box.
Extended Questions
Can all senders and receivers use the SACK mechanism?
No, whether sackthe mechanism can be used is determined during the three-way handshake process.
As long as both parties are in TCP Optionthe process of explicitly turning it on SACK permitted , it means that in the subsequent data transmission process, SACKthe 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: receiverBy SACKnotifying the actual machine of senderpossible missing data, Dup Ackit can be informed senderto resend.
Dup AckAs the name suggests, it is receivera repetitive statement that I have received a certain package. If you think about it carefully, it is actually SACKan 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 receivethe received order was 13245.
receiverReceive #1, then send ack=#1.
receiverReceived #3, means sent ack=#1, sack=#3.
senderDo we need to send it immediately after receiving it #2? No, because receiverit 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 TCPthe protocol can do is to try to distinguish them, which is the so-called compromise.
TCPHow do you think this needs to be retransmitted?
ackIf you receive the same packet three or more times in a row within a certain period of time Dup Ack, wiresharkyou will think that the packet senderneeds to be retransmitted. Otherwise, senderyou don’t need to pay too much attention to this information.
About SACK, have I expressed myself clearly?