Before entering today's topic, let me throw a few questions. This article raises a total of 23 questions.
The TCP handshake must be three times? Must TCP wave four times?
Why is there fast retransmission, and timeout retransmission is not enough? Why is there a SACK and why is there a D-SACK?
We all know that there is a sliding window. What should I do if the sliding window is reduced to 0 because the receiver is too busy? The sender is waiting forever?
What is Silly Window?
Why is congestion control needed for sliding window flow control?
Fast retransmission must rely on three repeated ACKs?
In this article, I want to go through TCP from the shallower to the deeper, instead of bluntly moving out various knowledge points, starting from the problem, and then looking at TCP from the perspective of development and evolution.
At first I had a lot of questions when I was studying computer network. My mind was full of 100,000 whys, and the network was very complicated. After so many years of development, there are really too many things. Today, I am roughly speaking. Tell me about my understanding of these points of TCP.
Okay, let's not talk more nonsense, and start serving the dishes.
What problem is TCP used to solve?
TCP stands for Transmission Control Protocol. It can be seen that it is a transmission control protocol. The focus is on this control.
What to control?
Control reliable, orderly transmission and end-to-end flow control. Is it enough? Not enough, it needs to be more intelligent, so it needs to add congestion control, which needs to be considered for the overall network.
This is the journey of you, me, and others, and safety depends on everyone.
Why is TCP and IP layer control not enough?
We know that the network is implemented in layers, and the network protocol is designed for communication. In fact, communication can be completed from the link layer to the IP layer.
You see that the link layer is indispensable. After all, our computers are connected to each other through links, and then IP serves as an address function, so we can communicate with each other through IP.
So why do you add a TCP layer? Isn't the control over the IP layer over?
The reason for extracting a TCP layer to achieve control is because the IP layer involves more devices. A piece of data needs to pass through many devices to transmit on the network, and the devices need to be addressed by IP.
Assuming that the IP layer is controlled, does the involved equipment need to care about many things? Is the overall transmission efficiency greatly compromised?
Let me give an example. If A wants to transmit a building block to F, but it cannot be directly transmitted to it, it needs to pass through the transfer stations of B, C, D, and E. There are two situations here:
-
Assuming that BCDE needs to care about whether the building block is wrong, unpack the package and take a closer look. If there is no problem, put it back again, and finally reach F's hands.
-
Assuming that BCDE doesn't care about the building blocks, just forward any package and it will be over. The final F will check whether the building block is wrong or not.
What kind of efficiency do you think? Obviously it is the second type. The forwarding device does not need to care about these things, just forward it and it's done!
Therefore, the control logic is separated into the TCP layer and let the real receiver handle it, so that the overall transmission efficiency of the network is high.
What exactly is a connection?
We already know why we need to separate the TCP layer, and what this layer is mainly used for, let's take a look at how it does it.
We all know that TCP is connection-oriented, so what is this connection? Did you really pull a line to connect the end to the end?
The so-called connection is actually that both parties maintain a state, and the change of state is maintained through each communication, so that it seems that there is a line associated with each other.
TCP protocol header
Before going further, we need to take a look at some TCP header formats, which are very basic and important.
The picture comes from the network
I won't explain them one by one, but focus on the key points.
First of all, you can see that TCP packets have only ports and no IP.
Seq is Sequence Number, which is used to solve the problem of disorder.
ACK is the Acknowledgement Numer, which is used to solve the packet loss situation and tell the sender that I have received the packet.
The flag bit is the TCP flags used to mark the type of this packet, and is used to control the state of the TPC.
The window is a sliding window, Sliding Window, used for flow control.
Three handshake
After clarifying the main points of the protocol header, let's look at the three-way handshake.
The three-way handshake is really a commonplace question, but do you really understand it? Not on the surface? Can you extend something else?
Let's take a look at the familiar process first.
The picture comes from the network
First of all, why the handshake is necessary, in fact, is mainly to initialize the Seq Numer. The full name of SYN is Synchronize Sequence Numbers. This sequence number is used to ensure the sequence of data transmission afterwards.
What you want to say is to test to ensure that the sending and receiving functions of both parties are normal. I don't think there is a problem, but I think the key is to synchronize the serial number.
Why is it three times? Take me and you as an example. First of all, I tell you my initial serial number. You heard it and I said you received it.
Then you tell me your initial serial number, and then I tell you that I have received it.
This seems like four times? If you really press it once, it will be four times, but the middle step can be combined, that is, when you tell me that you know my initial serial number, you will also tell me your initial serial number.
Therefore, the four-way handshake can be reduced to three.
But you have never thought about such a situation. You and I spoke at the same time, told each other the initial serial number together, and then responded separately. Isn't this a four-way handshake?
Let me draw a picture to be clearer.
See if it’s a four-way handshake? But the specifics still depend on the implementation. Some implementations may not allow this to happen, but this does not affect our thinking, because the focus of the handshake is to synchronize the initial sequence number, which also completes the synchronization. The goal.
The value of the initial serial number ISN
I wonder if you have thought about what the value of ISN should be set to? Code hard to start from scratch?
Imagine if you write a value, such as 0, then suppose the connection has been established, the client has also sent many packets, such as the 20th packet, and then the client restarts after the network is disconnected, the port number is still the previous one, and then the serial number Starting from 0 again, the server returns the ack of the 20th packet. Is the client stupid?
Therefore, RFC793 believes that ISN should be bound to a fake clock. ISN increases by one every four microseconds. When it exceeds 2 to the 32th power, it starts from 0 again, and it takes about four and a half hours for ISN to wrap around.
Therefore, the ISN becomes an incremental value, and the real implementation needs to add some random values to it to prevent illegal elements from guessing the ISN.
How to deal with SYN timeout?
That is, the client sends a SYN to the server and then it hangs. At this time, the server sends a SYN+ACK, but there is no reply. What should I do?
What I think of in my mind is to retry, but I can’t retry multiple times in rapid succession. Think about it. If the client goes offline, you have to give it some time to recover, so you need to retry slowly, step by step. .
In Linux, the default is to retry 5 times, and it is a stepwise retry. The interval is 1s, 2s, 4s, 8s, 16s. After the fifth time, you have to wait 32s to know the result of this retry, so Said to wait a total of 63s to disconnect.
SYN Flood attack
You see that without SYN timeout, it will take the server 63s to disconnect. In other words, the server needs to maintain this resource within 63s, so criminals can construct a large number of clients to send SYNs to the server, but they just don't return the server.
The picture comes from the network
As a result, the server's SYN queue is exhausted, and normal connection requests cannot be processed.
So what to do?
You can enable tcp_syncookies, then the SYN queue is not used.
After the SYN queue is full, TCP generates a special serial number (ie cookie) based on its own ip, port, then the other party's ip, port, the other party's SYN serial number, time stamp and other operations to generate a special serial number (ie cookie) and send it back. If the other party is a normal client, it will Send this serial number back, and then the server establishes a connection based on this serial number.
Or adjust tcp_synack_retries to reduce the number of retries, set tcp_max_syn_backlog to increase the number of SYN queues, and set tcp_abort_on_overflow to directly refuse the connection when the SYN queue is full.
Why wave four times?
Four waved hands and three handshake pairs form a pair. They are also the first-line stars in TCP. Let us revisit the familiar picture.
The picture comes from the network
Why do I need to wave four times? Because TCP is a full-duplex protocol, that is to say, both parties must be closed, and each party sends FIN and responds ACK to the other party.
It's like I told you that my data is finished, and then you receive it if you reply. Then you tell me that your data is finished, and then I reply to you and I received it.
So it looks like four times.
It can be seen from the figure that the status of the active closing party is FIN_WAIT_1 to FIN_WAIT_2 and then to TIME_WAIT, while the passive closing party is CLOSE_WAIT to LAST_ACK.
Does the state of waving four times have to change like this?
Must the state change like this? Let's look at another picture.
The picture comes from the network
It can be seen that both parties actively initiate a disconnect request, so each is the active initiator. The state will go from FIN_WAIT_1 to the transition state of CLOSING and then to TIME_WAIT.
Is it necessary to wave four times?
Assuming that the client has no data to send to the server, so it sends a FIN to the server to indicate that it has finished sending the data and will not send it anymore. If the server still has data to send to the client at this time, it will reply ack first, and then continue to send the data.
After the server data is sent, send a FIN to the client to indicate that it has also been sent, and then wait for the ACK from the client. In this case, there will be four waves of hands.
So if the client sends the FIN to the server and the server has no data to the client, then the server can send the ACK together with its FIN to the client, and then wait for the client's ACK, so that it doesn't just wave three times?
Why should there be TIME_WAIT?
After receiving the FIN from the receiver and replying to the ACK, the disconnect initiator does not directly enter the CLOSED state, but performs a wave of waiting with a waiting time of 2MSL.
MSL is Maximum Segment Lifetime, that is, the longest survival time of a message. The MSL time defined by RFC 793 is 2 minutes. The actual implementation of Linux is 30s, so 2MSL is one minute.
So why wait for 2MSL?
-
It is afraid that the passive closing party does not receive the final ACK. If the passive party does not arrive due to network reasons, it will send a FIN again. At this time, if the active closing party is already CLOSED, it is foolish, so wait a while.
-
Suppose that the connection is immediately disconnected, but the connection is reused, that is, the five-tuple is exactly the same, and the sequence number is still in the appropriate range. Although the probability is low, it is theoretically possible, then the new connection will be closed. The connection link Some residual data interferes with the above, so a certain amount of time is given to process some residual data.
What will happen when waiting for 2MSL?
If the server actively closes a large number of connections, a large amount of resources will be occupied, and the resources will not be released until 2MSL.
If the client actively closes a large number of connections, then those ports in 2MSL are all occupied, and there are only 65535 ports. If the ports are exhausted, it will not be able to initiate a connection, but I think the probability is very low, so many Port How many connections do you want to establish?
How to solve the problems caused by 2MSL?
Fast recycling, that is, recycling without waiting for 2MSL. The parameter of Linux is tcp_tw_recycle, and tcp_timestamps is enabled by default.
In fact, we have already analyzed why we need to wait for 2MSL above, so if the waiting time is decisive, the problems mentioned above will occur.
So it is not recommended to open it, and this parameter has been clicked after Linux 4.12 version.
A friend mentioned this stuff in the group not long ago.
When I asked, NAT was there.
The phenomenon is that the requesting end requests the static resources of the server and occasionally there will be a response in about 20-60 seconds. From the packet capture, the requesting end has not responded for three consecutive SYNs.
For example, if you are in a school, you may have a public network IP, and then turn on tcp_tw_recycle (when tcp_timestamps is also turned on), the timestamp must be incremented in the connection request for the same IP within 60 seconds, otherwise it is considered expired The packet will be dropped.
With so many machines in the school, you cannot guarantee that the timestamps are consistent, so problems will arise.
So this thing is not recommended.
Reuse, that is, turning on tcp_tw_reuse of course also requires tcp_timestamps.
There is an important point here, tcp_tw_reuse is used for the connection initiator, and our server is basically connected to the passive receiver.
When a new connection is initiated, tcp_tw_reuse can reuse connections in the TIME_WAIT state for more than 1 second, so it does not reduce the pressure on our server at all.
It reuses the connection of the initiator in TIME_WAIT.
There is also a SO_REUSEADDR, which some people will confuse with tcp_tw_reuse. First, tcp_tw_reuse is a kernel option and SO_REUSEADDR is a user mode option.
Then SO_REUSEADDR is mainly used when you start the service. If the port at this time is occupied and the connection is in the TIME_WAIT state, then you can reuse this port. If it is not TIME_WAIT, it will give you an Address already in use.
So these two things don't seem to work, and tcp_tw_reuse and tcp_tw_recycle actually violate the TCP protocol. When I say yes, when I get old, you secretly let go?
Either reduce the MSL time, but it is not very safe, or adjust the tcp_max_tw_buckets to control the number of TIME_WAIT, but the default value is already very large by 180,000. This thing should be used to counter DDos attacks.
So my suggestion is that the server should not actively shut down, and put the active shutdown party on the client. After all, our server is a one-to-many service, and our resources are more precious.
Attack yourself
There is also a very shameful solution. What I was thinking about was to attack myself.
Socket has an option called IP_TRANSPARENT, which can bind a non-local address, and then the server will write down the IP and port of the connection, for example, write it to a local place.
Then start a service. If the resources on the server are in short supply, you can set a certain time. After a long time, you will tell the service about the ip and port of the other party in the TIME_WAIT state.
Then the service uses IP_TRANSPARENT to pretend to be the previous client to initiate a request to the server, and then the server will send an ACK to the real client when it receives it. The client is closed, and it says what you are doing, so it returns a RST , And then the server terminates the connection.
What problem does the timeout retransmission mechanism solve?
Earlier we mentioned that TCP must provide reliable transmission, and the network is unstable. If the transmitted packet is not received by the other party but must be guaranteed to be reliable, then it must be retransmitted.
The reliability of TCP depends on the confirmation number. For example, if I send you 4 packets of 1, 2, 3, and 4, if you tell me you want 5 now, it means that you have received the first four packets. That's how it is. .
But it should be noted here that SeqNum and ACK are both in the number of bytes, that is to say, suppose you have received 1, 2, 4 but you can’t ACK 5 without receiving 3. If you return 5, the sender thinks You received everything before 5.
Therefore, it can only reply to confirm the largest continuous received packet, which is 3.
The sender is not sure whether the two packets 3 and 4 have not arrived yet or have been lost, so the sender needs to wait. The waiting time is more particular.
If you are too impatient, the ACK may already be on the road, and your retransmission is a waste of resources. If it is too sloppy, then the receiver is anxious. Why hasn't this dead man sent a package? Thanks for all the flowers I waited for.
So the time to wait for retransmission over time is very important, how to do it? Smart friends may have thought of it right away. You can estimate how long it takes to go back and forth normally. I just waited so long.
The time for this round trip is called RTT, that is Round Trip Time, and then according to this time, the time RTO for retransmission over time is set, that is, Retransmission Timeout.
However, there is probably no choice but to refer to RTT for RTO, but how to calculate it? First of all, it must be sampling, and then a wave of weighted average will get RTO.
The formula defined by RFC793 is as follows:
1、先采样 RTT 2、SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT) 3、RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]
ALPHA is a smoothing factor with a value between 0.8 and 0.9, UBOUND is the upper bound of the timeout time-1 minute, LBOUND is the lower bound-1 second, and BETA is a delay variance factor with a value between 1.3 and 2.0.
But there is still a problem. The RTT sampling time uses the time from the beginning of the data transmission to the time when the ACK is received as the sample value or the time from the retransmission time to the ACK time as the sample value?
The picture comes from the network
As you can see from the figure, one time is considered long and one time is short. This is a bit difficult, because you don't know who the ACK is replying to.
So what to do? I don’t want to sample the back and forth of the retransmission. I don’t know who is responding to this ACK. I don’t care about it, and I just sample the normal back and forth.
This is the Karn / Partridge algorithm, RTT without sampling and retransmission.
However, there will be problems with retransmission without sampling. For example, the network is suddenly bad at a certain moment. If you don’t care about retransmission, then calculate the RTO according to the normal RTT, then the timeout period is too short, so the network is very poor In this case, crazy retransmissions increase the load on the network.
Therefore, Karn algorithm is very rude to make a retransmission, I will double the current RTO, hum! It's that simple and rude.
But this kind of average calculation is easy to smooth out a sudden big fluctuation, so another algorithm is called Jacobson / Karels Algorithm.
It calculates the latest RTT and smoothed SRTT to get the proper RTO. I will not post the formula. Anyway, I don't understand it. If I don't understand, I won't beep.
Why do we need a fast retransmission mechanism?
The timeout retransmission is driven by time. If the network condition is really bad, the timeout retransmission is okay, but if the network condition is good, it just happens to be packet loss, then there is no need to wait so long.
So the data-driven retransmission is called fast retransmission. What does it mean? That is, if the sender receives the same confirmation number from the other party three times in a row, the data will be retransmitted immediately.
Because the same ACK is received three times in a row to prove that the current network status is ok, it is confirmed that the packet is lost, so it is retransmitted immediately. There is no need to wait so long.
The picture comes from the network
It seems perfect, but have you ever thought that I sent the 4 packets of 1, 2, 3, and 4, but 2 was not received by the other party, 1, 3, and 4 were received, and then no matter if it is timeout retransmission or fast Anyway, the other party will return ACK 2.
Should we retransmit 2, 3, 4 or just 2 at this time?
What problem is the introduction of SACK to solve?
SACK is Selective Acknowledgment, and it is introduced to solve the problem that the sender does not know which data to retransmit.
Let's take a look at the picture below.
The picture comes from the network
SACK means that the receiver will send back the data it has received so that the sender knows which data the other party has received, so it can selectively send the missing data.
As shown in the figure, I was informed by ACK that I want to start with 5500 data, and keep updating SACK, 6000-6500 I received, 6000-7000 data I received, 6000-7500 data I received, the sender is very clear Knowing that the 5500-5999 wave of data should have been lost, so it was retransmitted.
And if the data is multiple discontinuous, SACK can also be sent, such as SACK 0-500, 1000-1500, 2000-2500. It means that these paragraphs have been received.
What is D-SACK?
D-SACK is actually an extension of SACK. It uses the first paragraph of SACK to describe the discontinuous data sequence number that is repeatedly received. If the range described in the first paragraph is covered by ACK, it means that it is repeated. For example, I have ACK to 6000. Give me back SACK 5000-5500?
To put it bluntly, it is to compare the received ACK from the feedback in the first paragraph. The parameter is tcp_dsack, which is enabled by default after Linux 2.4.
What's the use of knowing to repeat?
1. Knowing that it is repeated means that the other party has received the packet just now, so the ACK packet returned is lost. 2. Is the package out of order, and the package sent first arrives later? 3. Are you too anxious and the RTO is too small? 4. Is it copied by the data and is one step ahead?
Why do you use sliding windows?
We already know that TCP has sequence numbers and retransmissions, but this is not enough, because we are not stunned, we need to control the sending rate according to the situation, because the network is complex and changeable, and sometimes it will be blocked. , And sometimes very smooth.
Therefore, the sender needs to know the receiver's situation, so as to control the sending rate, so as not to blindly send and then the receiver can't accept it.
Therefore, TCP has something called a sliding window for flow control, that is, the receiver tells the sender how much data I can receive, and then the sender can send data based on this information.
The following is the window maintained by the sender, which is circled in black.
The picture comes from the network
In the figure, #1 is the data that has received ACK, #2 is the data that has been sent but has not received ACK, and #3 is the data that can be sent in the window but has not yet been sent. #4 is the data that cannot be sent yet.
Then the 36-51 ACK was received at this time, and 46-51 bytes were sent, so the window slid to the right.
Picture from the Internet
There is also a complete picture on the TCP/IP Guide, which is very clear. Let's take a look.
What if the window of the receiver's reply is always 0?
As mentioned above, the sending method controls how much data can be sent according to the window of the receiver's response. If the receiver keeps responding with 0, then the sender is stuck?
Think about it, the data sent by the sender is ACKed, but the response window is 0. The sender is afraid to send it at this time, so I can’t wait forever. When will the window remain 0? ?
So TCP has a Zero Window Probe technology. After the sender knows that the window is 0, it will detect whether the receiver is okay, that is, send a ZWP packet to the receiver.
See the implementation in detail, you can send multiple times, and then there is an interval. After multiple times, you can directly RST.
Suppose the receiver responds with a very small window every time?
Imagine if the receiver says that I can still receive 1 byte every time, should the sender send it?
The TCP + IP header is only 40 bytes. This transmission is not cost-effective. If you keep sending it stupidly, it is called Silly Window.
What to do, think about it, the sender waits and waits for fattening to send again, or the receiver consciously, the data is less than a threshold and tells the sender that the window is 0 at this time, forget it, and wait for fattening before telling to send end.
The solution that the sender is waiting for is the Nag algorithm. I believe this algorithm can be known by just looking at the code.
Simply put, the current data and window that can be sent are greater than or equal to MSS and sent immediately, otherwise, judge whether the ACK of the previously sent packet has come back, and send it again, or save the data.
The receiver's conscious solution is David D Clark's solution. If the window data is less than a certain threshold, tell the sender window 0 not to send, wait until the data is greater than or equal to MSS or accept the buffer to free up half of the space, and then set the normal window value to sender.
By the way, the Nag algorithm has to mention delayed confirmation. The Nag algorithm is waiting for the receiver's confirmation, and turning on the delayed confirmation will delay the sending of the confirmation. It will wait for the subsequent packet to be received and then confirm together or wait for a while. Respond to confirm if the information is gone.
This waits for each other, and then the delay is very large, and the two cannot be turned on at the same time.
Why is there congestion control when there is a sliding window?
As I mentioned earlier, congestion control is added because TCP not only cares about the situation between the two ends, but also needs to know the overall network situation. After all, the road will be smooth if everyone is observing the rules.
Earlier we mentioned retransmission. If regardless of the overall situation of the network, it must be that the other party did not give an ACK, then I would retransmit without thinking.
If the network condition is very bad at this time and all connections are retransmitted like this mindlessly, is the network condition worse and more congested?
Then the more congestion, the more retransmission, keep rushing! Then it's GG.
So a congestion control is needed to avoid sending in this situation.
How to do congestion control?
There are mainly the following steps to do it:
1. Start slowly and explore the way. 2. Congestion avoidance, I feel almost slowed down. 3. Congestion occurs fast retransmission/recovery
Slow start means that the new driver starts slowly on the road, initializes cwnd (Congestion Window) to 1, and then cwnd++ every time an ACK is received, and every time an RTT passes, cwnd = 2*cwnd.
There is an index in the linearity, and a linear increase in the index.
Then when a threshold is reached, that is, ssthresh (slow start threshold), it enters the congestion avoidance phase.
At this stage, cwnd = cwnd + 1/cwnd every time an ACK is received and every RTT is cwnd++.
It can be seen that all increase linearly.
Then it keeps increasing until the packet loss occurs. It has been analyzed that there are two types of retransmissions, one is timeout retransmission, and the other is fast retransmission.
If a timeout retransmission occurs, it means that the situation is a bit bad, so directly set ssthresh to half of the current cwnd, and then cwnd directly changes to 1, entering the slow start phase.
If it is fast retransmission, then there are two implementations, one is TCP Tahoe, which handles the same as timeout retransmission.
One is TCP Reno. This implementation is to set cwnd = cwnd/2, and then set ssthresh to the current cwnd.
Then enter the fast recovery phase, set cwnd = cwnd + 3 (because there are three fast retransmissions), retransmit the packet specified by DACK, if you receive another DACK, then cwnd++, if you receive a normal ACK, then set cwnd to ssthresh size, enter the congestion avoidance phase.
It can be seen that the specified packet was retransmitted after the quick recovery. It may be that many packets are lost, and then other packets can only wait for timeout to retransmit. Timeout retransmission will cause cwnd to be halved, and it will be exponential if triggered multiple times. The level drops.
So I made a New Reno, and added a New. It is to improve the fast recovery without SACK. It will observe whether the response ACK of the packet specified by DACK is the largest ACK that has been sent, for example, you sent 1 , 2, 3, 4, the other party did not receive 2, but 3, 4 are received, so after you retransmit 2, the ACK must be 5, indicating that this packet is lost.
Otherwise, there are other packets that are lost. If one packet is lost, the process is the same as before. If there are other packets that are lost, the retransmission will continue until the ACK is all and then exit the fast recovery phase.
To put it simply, it has been detected that all packets have been received before ending this link.
There is also a FACK, which is based on SACK as a congestion control in the retransmission process. Compared with the New Reno above, we know that it has SACK, so there is no need to try them one by one. I will not expand on the specifics.
What other congestion control algorithms?
There are so many from the wiki.
Originally, I wanted to beep a few words, and then deleted it after the beep. I felt that I said it was the same as I didn't say it. I wanted to go deeper but the strength did not allow it. It was a bit melancholy.
Everyone, please check it out by yourself, or wait until I'm successful in my cultivation and then come back.
to sum up
Having said so much, let's summarize it.
TCP is connection-oriented. It provides reliable and orderly transmission and also provides flow control and congestion control. The TCP layer is extracted separately instead of being implemented at the IP layer because there are more devices to use at the IP layer, which adds complex logic. Not cost-effective.
The three-way handshake is mainly to define the initial sequence number to lay the foundation for subsequent transmissions. The four waved hands are because TCP is a full-duplex protocol, so both parties have to say goodbye.
When SYN times out, retry in steps. If there is a SYN attack, you can increase the number of queues by half, or reduce the number of retries, or simply refuse.
TIME_WAIT is afraid that the other party did not receive the last ACK, and then sent a FIN, and it is also waiting to process the remaining data on the network, for fear of affecting the new connection.
TIME_WAIT is not recommended to be small, or to destroy the TIME_WAIT mechanism. If you really want to, you can turn on fast recovery or reuse, but pay attention to the benefits.
The timeout retransmission is to ensure that the peer can receive the packet. The fast retransmission is to avoid the need to wait for such a long timeout when the packet is occasionally lost. SACK is to let the sender know which to retransmit.
D-SACK is to let the sender know that the reason for this retransmission is that the other party really didn't receive it or that he was too impatient. The RTO was so small that his eyes would not be blackened.
The sliding window is to balance the sending rate of the sender and the receiving rate of the receiver, so as not to send out blindly. Of course, you need to pay attention to the Silly Window. At the same time, you must also pay attention to the Nag algorithm and the delayed confirmation cannot be used together.
The sliding window is not enough, there must be congestion control, because you and me, safety depends on everyone, TCP has to jump out and look at the current situation.
At last
At this point it is almost the same, but there are still many details. The TCP protocol is too complicated. This may be the least pictured in my article. You can see that it is too complicated to draw my picture hahaha.
Today, I just talked about it. If there are any mistakes, please contact me backstage as soon as possible.
