Here’s a mind map from this article:
001. Could you tell me the difference between TCP and UDP?
First, a summary of the basic differences:
TCP is a connection-oriented, reliable, byte stream – based transport – layer protocol.
UDP is a connectionless transport layer protocol. (As simple as that, other TCP features are lost.)
Specifically, compared with UDP, TCP has three core features:
-
Connection-oriented. The so-called connection refers to the connection between the client and the server. TCP requires a three-way handshake to establish the connection before the two parties can communicate with each other, while UDP does not have the corresponding process of establishing the connection.
-
Reliability. TCP takes a lot of effort to ensure that connections are reliable. In what ways does reliability exist? One is stateful, the other is controllable.
TCP accurately records which data is sent, which data is received, and which data is not received, and ensures that the packets arrive in sequence without any errors. This is a state.
When it realizes that a packet is lost or that the network environment is poor, TCP adjusts its behavior according to the situation, controlling its own transmission speed or resend. It’s manageable.
UDP, by contrast, is stateless and uncontrollable.
- Byte stream oriented. UDP transmits data based on datagrams because it merely inherits the IP layer’s features, whereas TCP converts each IP packet into a byte stream in order to maintain state.
How about the TCP three-way handshake? Why three times instead of two or four times?
Love simulation
In a relationship, for example, the most important thing for two people to be together is to first affirm their ability to love and be loved. Now we’re going to simulate a three-way handshake.
For the first time:
M: I love you.
The woman received.
This proves that the man is capable of love.
The second:
W: I received your love, and I love you, too.
The man received it.
OK, what this shows is that women have the ability to love and be loved.
The third time:
M: I received your love.
The woman received.
It is now guaranteed that the man is capable of being loved.
This complete confirmation of each other’s ability to love and be loved, two people begin a sweet love.
Real shake hands
Of course, that’s bullshit, it doesn’t represent my values, but it’s about getting people to understand the whole handshake process, because it’s very similar. The three-way handshake corresponding to TCP also needs to confirm the capabilities of both parties: the ability to send and the ability to receive. This will result in the following three handshakes:
Both sides have been CLOSED since the beginning. Then the server starts listening to a port and enters the LISTEN state.
Then the client initiates a connection and sends SYN. The client becomes SYN-sent.
The server receives this, returns a SYN and an ACK(corresponding to the SYN from the client), and becomes syn-revd.
Then the client sends an ACK to the server, and the client becomes ESTABLISHED. After receiving an ACK, the server becomes in the ESTABLISHED state.
In addition, it should be noted that the figure shows that the SYN consumes a sequence number, and the corresponding ACK sequence number should be increased by 1 next time. Why? Just remember one rule:
The sequence number of TCP packets that need to be acknowledged by the peer end must be consumed.
A SYN requires peer acknowledgment but an ACK does not, so a SYN consumes a sequence number but an ACK does not.
Why not twice?
Root cause: The receiving capability of the client cannot be confirmed.
Analysis is as follows:
If twice, you now send a SYN packet for a handshake, but the packet persists on the current network. TCP considers it a lost packet and retransmits it. The two handshakes establish the connection.
That seems fine, but what if the stranded packet reaches the server after the connection is closed? By default, the connection is established as soon as the server receives and sends the corresponding packet, but now the client is disconnected.
As you can see, this is a waste of connection resources.
Why not four times?
The purpose of the three-way handshake is to confirm the ability of both parties to send and receive. How about the four-way handshake?
Sure, 100 times. But in order to solve the problem, three times is enough, and no more will help.
Can I carry data during a three-way handshake?
On the third handshake, you can carry it. The first two handshakes cannot carry data.
If the first two handshakes carry data, if someone wants to attack the server, he only needs to put a large amount of data in the SYN packet in the first handshake. Therefore, the server will consume more time and memory space to process the data, increasing the risk of the server being attacked.
By the time of the third handshake, the client is in the ESTABLISHED state and has been able to confirm that the server is receiving and sending data, so it is relatively safe to carry data.
What happens when you open them at the same time?
If both parties send SYN packets at the same time, what is the state change?
This is one possible scenario.
The status changes are as follows:
The sender sends a SYN packet to the receiver, and the receiver also sends a SYN packet to the sender.
After SYN is SENT, the status of both changes to SYN-SENT.
After receiving the SYN from each other, both states change to SYN-reVD.
It then responds with an ACK + SYN. After receiving the packet, both states change to ESTABLISHED.
This is the state transition in the simultaneous open case.
003: Talk about the TCP four wave process
Process and dismantling
In the beginning, both sides are in the ESTABLISHED state.
The client is about to disconnect and sends a FIN packet to the server. The position in the TCP packet is shown as follows:
After the server is sent, the client changes to fin-WAit-1. Note that the client is also in the half-close state. That is, the client cannot send packets to the server but can only receive packets.
After receiving the message, the server confirms it to the client, and the server enters the closed-wait state.
The client receives the acknowledgement from the server and changes to fin-Wait2.
The server then sends a FIN to the client and enters the last-ACK state.
After receiving the FIN message from the server, the client enters the time-wait state and then sends an ACK message to the server.
Note that the client needs to wait a long enough time, specifically, two MSLS (Maximum Segment Lifetime). If the client does not receive the retransmission request from the server within this time, it indicates that the ACK has successfully arrived and is waved off. Otherwise, the client resends the ACK.
Waiting for the meaning of 2MSL
What if I don’t wait?
If the server does not wait, the client directly sends packets to the client. When the server has a lot of data packets to send to the client, and the client port is occupied by a new application, the server receives useless data packets, causing confusion of data packets. So, the safest bet is to wait until all the packets from the server are dead before launching a new application.
So, isn’t it enough to say one Muslim, why wait for 2 Muslims?
- One MSL ensures that the last ACK message from the active close party in the four waves can reach the peer end
- One MSL ensures that the peer end does not receive the FIN packet retransmitted by ACK
This is what waiting for 2MSL means.
Why four waves instead of three?
After receiving a FIN packet, the server does not return a FIN packet immediately. The server can send a FIN packet only after all packets are sent. Therefore, sending an ACK indicates that the client has received the FIN. Sending the FIN after a certain period of time is delayed. That makes four waves.
What’s wrong with three waves?
This means that the server sends an ACK and a FIN in one wave, and the long delay may cause the client to think that the FIN has not reached the client, causing the client to repeatedly resend the FIN.
What happens when you shut it down?
If the client and server send FIN at the same time, how does the status change? As shown in the figure:
004: Describe the relationship between half-connection queues and SYN Flood attacks
Before the three-way handshake, the state of the server changes from CLOSED to LISTEN, and two queues are created internally: the half-connection queue and the full connection queue, namely the SYN queue and the ACCEPT queue.
Half connection queue
When a client sends a SYN to a server, and the server responds with an ACK and A SYN, the state changes from LISTEN to SYN_RCVD, and the connection is pushed into the SYN queue, or half-connection queue.
Full connection queue
When the client returns an ACK and the server receives it, the three-way handshake is complete. The connection is waiting to be picked up by the application. Before it is picked up, it is pushed to another Queue maintained by TCP, the Accept Queue.
Mechanism of SYN Flood attacks
SYN Flood attacks are typical DoS or DDoS attacks. The attack mechanism is simple: the client forges a large number of non-existent IP addresses in a short period of time and sends SYN packets to the server. On the server side, there are two dangerous consequences:
-
Processing a large number of SYN packets and returning the corresponding ACK will result in a large number of connections in the SYN_RCVD state, which will fill the entire half-connection queue and fail to process normal requests.
-
Because the IP address does not exist, the server cannot receive the ACK from the client for a long time. As a result, the server keeps resending data until the server resources are exhausted.
How to Respond to SYN Flood attacks?
- Increase the capacity of the HALF-connection queue by adding SYN connections.
- Reduce the number of SYN + ACK retries to avoid a large number of timeout resends.
- Received on the server using SYN Cookie technology
SYNInstead of allocating connection resources immediately after, it is based on thisSYNCalculates a Cookie, replies to the client with a second handshake, and replies on the clientACKTake this with youCookieThe server authenticates that the Cookie is valid before allocating the connection resource.
005: This section describes the TCP packet header fields
The packet header structure is as follows (unit: byte):
Please remember this picture!
Source port and target port
How do I identify a connection that uniquely identifies it? The answer is a quadruple of TCP connections — source IP, source port, destination IP, and destination port.
Why do TCP packets have no source IP address and destination IP address? This is because IP is already processed at the IP layer. TCP only needs to record the two ports.
The serial number
Sequence number refers to the Sequence number of the first byte of this paragraph.
As you can see from the figure, the sequence number is an unsigned integer of 4 bytes, that is, 32 bits, representing the range from 0 to 2^32-1. And if you get to the maximum then you loop to zero.
Serial numbers have two functions in TCP communication:
- Exchange initial sequence numbers in SYN packets.
- Make sure the packets are assembled in the correct order.
ISN
Initial Sequence Number: During the three-way handshake, SYN packets are exchanged between the two parties to exchange the ISN.
Instead of a fixed value, the ISN is increments by one every 4 ms and returns to 0 when overflows. This algorithm makes it difficult to guess the ISN. Then why do it?
If the ISN is predicted by an attacker, both the source IP address and the source port number are easily forged. After guessing the ISN, the attacker can directly forge an RST and force the connection to close. This is very dangerous.
A dynamically growing ISN makes it much harder to guess the ISN.
Confirmation no.
The ACK (Acknowledgment number). This is used to indicate the next sequence number to be received. All bytes smaller than the ACK have been received.
Flag bit
Common marker bits include SYN,ACK,FIN,RST, and PSH.
The LAST three are explained as follows: FIN: Indicates Finish, indicating that the sender is ready to disconnect.
RST: indicates Reset, which is used to forcibly disconnect the connection.
PSH: indicates Push. It tells the peer party that these data packets should be sent to the upper-layer application immediately after receiving them and cannot be cached.
The window size
It takes up two bytes, or 16 bits, but it’s actually not enough. So TCP introduced the window scaling option as a scaling factor for window scaling. This scaling factor ranges from 0 to 14, and the scaling factor expands the window value to the original 2 ^ n.
The checksum
It occupies two bytes to prevent packet damage during transmission. If a packet with incorrect checksum is encountered, TCP directly dismisses it and waits for retransmission.
optional
The optional format is as follows:
Common options are as follows:
- TimeStamp: indicates the TCP TimeStamp. Details are described later.
- MSS: indicates the maximum packet segment allowed by TCP to receive packets from the peer.
- SACK: Select the confirmation option.
- Window Scale: Window Scale option.
006: Talk about TCP fast open principle (TFO)
In the first section, we talked about the TCP three-way handshake. Some people might say that it is troublesome to have three handshakes every time. Can you optimize a little bit?
B: yes, you can. Today, let’s talk about this optimized TCP handshake process, also known as TCP Fast Open (TFO) principle.
The optimization process looks like this. Remember the SYN Cookie when we talked about SYN Flood attacks? This Cookie is not a browser Cookie and can also be used to implement TFO.
TFO process
Three handshakes in the first round
First, the client sends the SYN to the server and the server receives the SYN.
Pay attention to oh! Instead of immediately responding with a SYN + ACK, the server calculates a SYN Cookie, puts it in the Fast Open option of the TCP packet, and then returns it to the client.
The client gets the Cookie value and caches it. Three handshakes are completed normally.
So that’s the first three handshakes. The next three handshakes are different!
The next three handshakes
In the following three-way handshake, the client sends the cached Cookie, SYN, and HTTP requests (yes, you read that correctly) to the server. The server validates the validity of the Cookie and discards it if it is invalid. If it is valid, then SYN + ACK is normally returned.
Now the server can send an HTTP response to the client! This is the most significant change. The three-way handshake has not yet been established, but only after verifying the Cookie’s validity, the HTTP response can be returned.
Of course, the client has to send the ACK normally, otherwise how to call the three handshake.
The process is as follows:
Note: The client’s last handshake ACK does not have to wait until the server’s HTTP response arrives. The two processes are unrelated.
The advantage of TFO
The advantage of TFO is not in the first three handshakes, but in the later handshakes. After the Cookie of the client is obtained and verified, the HTTP response can be returned directly, making full use of 1 RTT(round-trip Time) for data transmission in advance. The accumulation is still a relatively big advantage.
007: Can you talk about the role of time stamps in TCP packets?
Timestamp is an optional header of a TCP packet. It consists of 10 bytes and is formatted as follows:
Kind (1 byte) + Length (1 byte) + Info (8 bytes)Copy the codeWhere kind = 8, length = 10, info consists of two parts: timestamp and timestamp echo, each containing 4 bytes.
So what do these fields do? What problems are they used to solve?
TCP timestamp solves two major problems:
- Calculate round-trip Time (RTT)
- Prevent sequence number winding problem
Calculate the round trip delay RTT
When there is no timestamp, the problem of calculating RTT is shown in the figure below:
If the start time of the first packet is taken as the start time, the problem in the left picture will appear, RTT is obviously larger, and the start time of the second one should be adopted.
If the start time of the second packet is taken as the start time, it will lead to the problem on the right. RTT is obviously small, and the start time of the first packet should be adopted.
In fact, whether the start time is based on the first or the second dispatch, it is not accurate.
In this case, introducing time stamps is a good solution to this problem.
For example, now A sends a message S1 to B, and B sends a reply message S2 containing ACK to A, then:
- step 1:When A sends it to B,
timestampIs the kernel time when host A sentta1. - step 2:When B replies the S2 packet to A,
timestampIs the time of host Btb.timestamp echoThe field is TA1 parsed from the S1 packet. - step 3:After A receives the S2 packet from B, the kernel time of host A is TA2, which can be obtained from the timestamp echo option in the S2 packet
ta1, which is the initial sending time of the packet corresponding to S2. And then you take ta2 minus ta1 and you get RTT.
Prevent sequence number rewinding problem
Now let’s simulate this problem.
The sequence number is actually in the range 0 to 2 ^ 32-1, but just for the sake of demonstration, let’s narrow it down a little bit, let’s say it’s in the range 0 to 4, so when we get to 4 we’re back to 0.
| The number of times the contract was sent | Send byte | Corresponding serial number | state |
|---|---|---|---|
| 1 | 0 ~ 1 | 0 ~ 1 | Successful receipt |
| 2 | 1 ~ 2 | 1 ~ 2 | Stuck in the network |
| 3 | 2 ~ 3 | 2 ~ 3 | Successful receipt |
| 4 | 3 ~ 4 | 3 ~ 4 | Successful receipt |
| 5 | 4 ~ 5 | 0 ~ 1 | Received successfully. Serial number starting at 0 |
| 6 | 5 ~ 6 | 1 ~ 2 | ????? |
Suppose on the sixth attempt, the packets that were previously stranded in the network come back, and then there are two packets with sequence numbers 1 or 2. How can we tell which packets are which? At this point, the problem of sequence number winding arises.
Timestamp can be used to solve this problem well, because every time the packet is sent, the kernel time of the packet sending machine is recorded in the packet, so even if the serial number of two packets is the same, the timestamp cannot be the same, so that two packets can be distinguished.
008: How is the TCP timeout retransmission time calculated?
TCP has the timeout retransmission mechanism, that is, if there is no reply to the packet after a certain period of time, the packet is retransmitted.
So how is this retransmission interval calculated?
Today we’re going to talk about that.
This Retransmission interval is also called a Retransmission TimeOut (RTO), and its calculation is closely related to the RTT mentioned in the previous section. Here we will introduce two main methods, one is the classical method and the other is the standard method.
Classic methods
The classic approach introduces a new SRTT(Smoothed round trip time) which does not make a new RTT. SRTT is updated according to a certain algorithm. Specifically, the calculation method is as follows (SRTT initial value is 0):
SRTT = (α * SRTT) + ((1Alpha) * RTT),Copy the codeWhere, α is the smoothing factor, the recommended value is 0.8, and the range is 0.8 ~ 0.9.
With SRTT in hand, we can calculate the value of RTO:
RTO = min(ubound, Max (lbound, β * SRTT))Copy the codeβ is the weighting factor, generally ranging from 1.3 to 2.0, lbound is the lower bound and ubound is the upper bound.
In fact, the algorithm process is very simple, but there are some limitations, that is, the performance is ok in the place where RTT is stable, but not in the place where RTT changes greatly, because the range of smoothing factor α is 0.8 ~ 0.9, RTT has little influence on RTO.
The standard method
In order to solve the problem that the classical method is insensitive to RTT changes, the standard method, also called Jacobson/Karels algorithm, is introduced later.
There are three steps.
Step 1: Calculate SRTT. The formula is as follows:
SRTT = (1 - α) * SRTT + α * RTT
Copy the codeNote that the value of alpha is different from that of the classical method. The recommended value is 1/8, which is 0.125.
Step 2: Calculate the intermediate variable RTTVAR(round-trip time variation).
RTTVAR = (1- beta) * RTTVAR + beta * (| RTT - SRTT |)Copy the codeThe recommended value of β is 0.25. This value is the beauty of the algorithm, that is, it records the difference between the latest RTT and the current SRTT, giving us a grip on subsequent changes in RTT.
Step 3: Calculate the final RTO:
RTO = µ * SRTT + ∂ * RTTVAR
Copy the codeThe recommended value of µ is 1, and the recommended value of ∂ is 4.
This formula adds the latest RTT and its offset on the basis of SRTT, so as to better perceive the change of RTT. Under this algorithm, the difference between RTO and RTT change is more closely related.
009: Can you say something about TCP flow control?
For the sender and receiver, TCP puts the sent data into the send cache and the received data into the receive cache.
What flow control is supposed to do is control the sending side by the size of the receive cache. If the recipient’s receive cache is full, the recipient cannot send any more.
To understand flow control specifically, you first need to understand the concept of sliding Windows.
TCP sliding window
There are two types of TCP sliding Windows: sending window and receiving window.
Send window
The structure of the sliding window at the sending end is as follows:
It contains four major parts:
- Sent and confirmed
- Sent but not confirmed
- Not sent but can be sent
- If you have not sent it, you cannot send it
There are some important concepts that I’ve highlighted here:
The send window is the area in the picture that is framed. SND means send, WND means window, UNA means unacknowledged, NXT means next, indicating the next sending location.
Receiving window
The window structure of the receiving end is as follows:
Rev. indicates receive, NXT indicates the location of the next receive, and WND indicates the size of the receive window.
Flow control process
Here we do not need too complex examples, to a simplest back to simulate the flow control process, convenient for you to understand.
First, the two sides shake hands three times to initialize their respective window sizes, both of which are 200 bytes.
If the current sender sends 100 bytes to the receiver, then the snD. NXT has to be shifted to the right by 100 bytes for the sender, which means that the current available window is reduced by 100 bytes. This makes sense.
Now these 100 have reached the receiver, and they’re put in the receiver buffer queue. However, due to the heavy load, the receiver can not process this many bytes, can only process 40 bytes, the remaining 60 bytes are left in the buffer queue.
Note that at this point, the receiving side is not enough processing power, you sent me less send points, so at this point, the receiving side of the receive window should be reduced, specifically, 60 bytes, from 200 bytes to 140 bytes, because the buffer queue has 60 bytes not taken away by the application.
Therefore, the receiver will put the reduced sliding window of 140 bytes in the ACK packet header, and the sender will adjust the size of the sending window to 140 bytes accordingly.
At this time, for the sending end, the part that has been sent and confirmed is increased by 40 bytes, that is, snD. UNA is moved to the right by 40 bytes, and the sending window is reduced to 140 bytes.
This is the flow control process. Despite the number of turns, the process and principle of control are the same.
010: Can you talk about TCP congestion control?
The flow control mentioned in the previous section takes place between the sender and the receiver without considering the influence of the entire network environment. If the current network is particularly bad and prone to packet loss, the sender should pay attention to it. This, too, is the problem that congestion control needs to address.
For congestion control, TCP needs to maintain two core states per connection:
- Congestion Window (CWND)
- Slow Start Threshold (SSthresh)
There are several algorithms involved:
- Slow start
- Congestion avoidance
- Fast retransmission and recovery
Next, let’s break down these states and algorithms one by one. First, start with the congestion window.
Congestion window
Congestion Window (CWND) is the amount of data you can still transfer.
Now that we’ve introduced the concept of a receive window, what’s the difference?
- Receive window (RWND) yes
The receiving endTo the limit - Congestion Window (CWND) Yes
The senderThe limits of
Limit who?
The limit is the size of the send window.
With these two Windows, how do you compute the send window?
Send window size = min(RWND, CWND)Copy the codeTake the smaller of both. Congestion control is to control CWND changes.
Slow start
When you first start transferring data, you don’t know whether the network is stable or congested. If you do it too aggressively and send packets too quickly, you will lose packets and cause an avalanche of disaster.
Therefore, congestion control first requires a conservative algorithm to slowly adapt to the whole network, this algorithm is called slow start. The operation process is as follows:
- First, with a three-way handshake, both sides declare their receive window size
- Each side initializes its own congestion window (CWND) size
- During the initial transmission period, the congestion window size increases by 1 for each ACK received by the sender, that is, the CWND doubles for each RTT passed. If the initial window is 10, after the first round of 10 packets are transmitted and the sender receives an ACK, the CWND changes to 20, the second round to 40, the third round to 80, and so on.
Are you just going to double forever? Of course not. Its threshold is called slow start threshold, when CWND reaches this threshold, it is like stepping on the brake, don’t increase so fast, old iron, hold on!
How do you control the size of the CWND after the threshold is reached?
That’s what congestion is trying to avoid.
Congestion avoidance
In the past, CWND increased by 1 for each ACK received, but now it has reached the threshold where CWND can only be added: 1 / CWND. Then you calculate carefully, after a round of RTT, received CWND ACK, the last congestion window size CWND increased by 1.
In other words, when an RTT came down, CWND doubled, now CWND only increased by 1.
Of course, slow start and congestion avoidance work together, all in one.
Fast retransmission and recovery
The fast retransmission
In the process of TCP transmission, if packet loss occurs, that is, when the receiver finds that the data segment does not arrive in order, the receiver processes the ACK before sending repeatedly.
For example, if the fifth packet is lost, even if the sixth and seventh packets arrive at the receiver, the receiver will return an ACK for the fourth packet. When the sender receives three duplicate ACK’s, it realizes that the packet is lost and immediately retransmits the packet without waiting for an RTO to run out.
This is called fast retransmission, and it addresses the question of whether or not you need to retransmit.
Selective retransmission
Then you might ask, if you want to retransmit, should you only retransmit the 5th packet or all the 5th, 6th and 7th packets?
Of course, the 6th and 7th have already arrived. The designer of TCP is not stupid. Simply keep track of which packages have arrived and which have not, and retransmit them accordingly.
After receiving a packet from the sender, the receiver replies with an ACK packet. In this case, the SACK attribute can be added to the optional header of the packet, and the left edge and right edge of the packet can be used to inform the sender of the range of datagram received. So even if the fifth packet is lost, when the sixth and seventh packets are received, the receiver will still tell the sender that these two packets have arrived. If the fifth packet does not arrive, the packet is retransmitted. This process, also called SACK, Selective Acknowledgment, solves the problem of how to retransmit.
Fast recovery
Of course, after receiving the repeated ACK for three times, the sender finds that the packet is lost and thinks that the current network has been somewhat congested, so it will enter the rapid recovery phase.
At this stage, the sender changes as follows:
- The congestion threshold is reduced to half of that of CWND
- The CWND size becomes the congestion threshold
- CWND increases linearly
These are the classic algorithms of TCP congestion control: slow start, congestion avoidance, fast retransmission, and fast recovery.
Can you talk about the Nagle algorithm and delayed validation?
Nagle algorithm
Imagine a scenario in which the sender keeps sending very small packets to the receiver, sending only one byte at a time. It would take 1,000 times to send a kilobyte. This kind of frequent transmission is problematic, not only because of the transmission delay consumption, but also because of the time consumption of sending and confirming. Frequent transmission and receiving bring huge delay.
And to avoid sending small packets too often, that’s what the Nagle algorithm does.
Specifically, the rules of the Nagle algorithm are as follows:
- There is no wait when the data is sent for the first time, even 1byte packets are sent immediately
- If one of the following conditions is met:
- Max Segment Size (MSS)
- All previous ACK packets have been received
Delay to confirm
Imagine a scenario where I receive a packet from the sender and then a second packet within a very short period of time. Should I reply one by one or wait for a moment and reply together by combining the ACK of the two packets?
What a delayed ACK does, which is the latter, is delay a little bit, then merge the ACK, and then finally reply back to the sender. TCP requires this delay to be less than 500ms, and most operating system implementations do not exceed 200ms.
However, the main thing is that there are some scenarios that cannot be confirmed late, so you should reply immediately after receiving them:
- A message larger than one frame is received, and the window size needs to be resized. Procedure
- TCP in Quickack mode (passed
tcp_in_quickack_modeSettings) - Out-of-order packets found
What happens when you use them together?
The former means delayed sending, and the latter means delayed receiving, resulting in greater delay and performance problems.
012. How to understand TCP keep-alive?
Everyone has heard of HTTP keep-alive, but the TCP layer also has a keep-alive mechanism, and it’s not quite the same as the application layer.
Consider a scenario where one party’s connection fails due to a network failure or downtime. Because TCP is not a polling protocol, the peer is unaware of the connection failure until the next packet arrives.
This is where keep-alive occurs, which detects whether the connection to the peer has failed.
In Linux, you can view the configuration like this:
Sudo sysctl -a | grep keepalive / / every 7200 s detection a.net. Ipv4. Tcp_keepalive_time = 7200 / / one of the most multiple 9 packages Net.ipv4. tcp_KeepALIVE_probes = 9 // Interval of each packet retransmission interval 75 s net.ipv4. tcp_KeepALIve_INTvL = 75Copy the codeHowever, most applications do not have TCP keep-alive enabled by default. Why?
From the perspective of application:
- 7200s is a test every two hours, which is too long
- Any shorter time would not reflect what it was designed for, which is to detect long dead connections
So it’s an awkward design.
The last
This article was first published on my blog, if it is helpful to you, I hope you can help me to click a star, thank you very much ~
Next up: HTTP protocol
References:
Detailed Explanation of Web Protocol and Actual Packet Capture — Tao Hui
“Interesting Talk about Network Agreement” — Liu Chao
Understanding TCP: From Principle to Practice
BBR congestion control algorithm