Shulou(Shulou.com)06/01 Report--

How to understand TCP protocols, algorithms and principles, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

First of all, we need to know that the data of our program will first be called into the Segment of TCP, then the Segment of TCP will be called into the Packet of IP, and then to the Frame of Ethernet Ethernet. After it is transmitted to the peer, each layer parses its own protocol, and then sends the data to the higher-level protocol for processing.

TCP header format

Next, let's look at the format of the TCP header:

Here are a few points you need to pay attention to:

TCP packages do not have an IP address, which is a matter on the IP layer. But the active port and the destination port.

A TCP connection requires four tuples to represent the same connection (src_ip, src_port, dst_ip, dst_port), to be exact, a quintuple, and one is a protocol. But because I'm only talking about the TCP protocol here, I'm only talking about quaternions here.

Notice four very important things in the figure above:

Sequence Number is the sequence number of a packet and is used to solve the problem of network packet disorder (reordering).

Acknowledgement Number is used by ACK-- to confirm receipt and to solve the problem of not losing packets.

Window, also known as Advertised-Window, also known as sliding window (Sliding Window), is used to solve flow control.

TCP Flag, that is, the type of package, is mainly used to manipulate the state machine of TCP.

State machine of TCP

In fact, the transmission on the network is not connected, including TCP is the same. TCP's so-called "connection" is actually maintaining a "connection state" between both sides of the communication to make it look as if there is a connection. Therefore, the state transformation of TCP is very important.

The following is the comparison of "TCP protocol state machine" (picture source) and "TCP link building", "TCP disconnection" and "data transfer". I put the two pictures side by side so that it is easy for you to compare them. In addition, the following two pictures are very important, and you must keep them in mind. (spit a hole: when you see such a complex state machine, you can see how complex the agreement is, and there are always a lot of tricks in complicated things, so the TCP agreement is actually pretty lame.)

Many people will ask, why do you need 3 handshakes to build links and 4 waves to break links?

For the 3-way handshake to build a link, the main thing is to initialize the initial value of Sequence Number. Both sides of the communication inform each other of their own initialization Sequence Number (abbreviated as ISN:Inital Sequence Number)-- so it's called SYN, full name Synchronize Sequence Numbers. It's just x and y in the picture above. This number should be used as the sequence number for future data communication to ensure that the data received by the application layer will not be out of order due to transmission problems on the network (TCP will use this serial number to splice the data).

For 4 waves, in fact, if you look carefully, it is 2 times, because TCP is full-duplex, so both the sender and receiver need Fin and Ack. However, one side is passive, so it seems to be the so-called four waves. If both sides are disconnected at the same time, it will enter the CLOSING state, and then reach the TIME_WAIT state. The following is a schematic diagram of both sides being disconnected at the same time (you can also compare it with the TCP state machine):

In addition, there are a few things to pay attention to:

About the SYN timeout while establishing a connection. Just imagine, if the server end receives the SYN sent by client and then returns the SYN-ACK, the client goes offline, and the server side does not receive the ACK returned by client, then the connection is in an intermediate state, that is, it neither succeeds nor fails. Therefore, if the server does not receive the TCP within a certain period of time, it will resend the SYN-ACK. Under Linux, the default number of retries is 5, and the interval between retries is resold every time starting from 1s. The interval between five retries is 1s, 2s, 4s, 8s and 16s, for a total of 31s. You have to wait 32s after the fifth time to know that the fifth time has also timed out. Therefore, it takes 1s + 2s + 4s + 8s + 16s + 32s = 2 ^ 6-1 = 63sTCP to disconnect this connection.

About the SYN Flood attack. Some malicious people create a SYN Flood attack for this-after sending a SYN to the server, the server goes offline, so the server needs to wait 63 seconds by default before it is disconnected, so the attacker can exhaust the queue of syn connections on the server so that normal connection requests cannot be processed. Therefore, a parameter called tcp_syncookies is given under Linux to deal with this-when the SYN queue is full, TCP will create a special Sequence Number to send back (also called cookie) through the source address port, destination address port and timestamp. If it is an attacker, it will not respond, if it is a normal connection, it will send the SYN Cookie back, and then the server can establish a connection through cookie (even if you are not in the SYN queue). Please note that do not use tcp_syncookies to handle normal heavy load connections. Because synccookies is a compromise version of the TCP agreement, it is not rigorous. For a normal request, you should adjust three TCP parameters for you to choose from. The first is: tcp_synack_retries can use it to reduce the number of retries; the second is: tcp_max_syn_backlog, which can increase the number of SYN connections; and the third is that tcp_abort_on_overflow simply rejects the connection if it can't handle it.

About the initialization of ISN. ISN cannot be hard code, otherwise there will be problems-for example, if the connection is built and ISN is always done with 1, if client sends 30 segment, but the network is down, so client is reconnected and 1 is used as ISN, but the packets connected before are arrived, so they are treated as newly connected packages. At this time, the Sequence Number of client may be 3, while the server thinks that the number of client is 30. It's all messed up. According to RFC793, ISN is tied to a fake clock that adds one to ISN every 4 microseconds until it exceeds 2 ^ 32 and starts at 0 again. In this way, the cycle of an ISN is about 4.55 hours. Because we assume that the survival time of our TCP Segment on the network will not exceed that of Maximum Segment Lifetime (abbreviated as MSL-Wikipedia entry), so as long as the value of MSL is less than 4.55 hours, then we will not reuse ISN.

About MSL and TIME_WAIT. Through the description of ISN above, I believe you also know where MSL came from. We notice that in the state diagram of TCP, from the TIME_WAIT state to the CLOSED state, there is a timeout setting, which is 2*MSL (RFC793 defines MSL as 2 minutes, Linux is set to 30s) Why is there TIME_WAIT? Why not just change it to CLOSED state? There are two main reasons: 1) TIME_WAIT ensures that there is enough time for the peer to receive the ACK, and if the party that passively closes does not receive the Ack, it will trigger the passive side to resend the Fin, which is exactly 2 MSL,2.) there is plenty of time so that the connection will not be confused with the subsequent connection (you know, some self-proclaimed routers will cache IP packets, if the connection is reused Then these delayed packets are likely to be mixed with the new connection. You can read this article "TIME_WAIT and its design implications for protocols and scalable client server systems".

There are too many TIME_WAIT. As we can see from the above description, TIME_WAIT is a very important state, but under large concurrent short links, there will be too much TIME_WAIT, which will consume a lot of system resources. As long as you search, you will find that nine times out of ten, the way to deal with is to teach you to set two parameters, one is called tcp_tw_reuse, the other is called tcp_tw_recycle, the default values of these two parameters are turned off, the latter recyle is more radical than the former resue, resue is softer. In addition, if you use tcp_tw_reuse, you must set tcp_timestamps=1, otherwise it will have no effect. Here, it's important to note that turning on these two parameters will have a big hole-- it may cause some weird problems with TCP connections (because, as mentioned above, new connections may not be built without waiting for timeouts to reuse connections. As the official document says, "It should not be changed without advice/request of technical experts").

About tcp_tw_reuse. The official documentation says that tcp_tw_reuse plus tcp_timestamps (also known as PAWS, for Protection Against Wrapped Sequence Numbers) can guarantee protocol security, but you need tcp_timestamps to be opened on both sides (you can read the source code of tcp_twsk_unique). Personally, I guess there are still some scenarios that will be problematic.

About tcp_tw_recycle. If the tcp_tw_recycle is opened, it is assumed that the tcp_timestamps is opened on the peer, and then the timestamp is compared. If the timestamp becomes larger, it can be reused. However, if the peer is a NAT network (for example, one company uses only one IP to access the public network), or if the peer IP is reused by another, it is complicated. The SYN that created the link may just be discarded (you may see an error in connection time out) (if you want to see the kernel code of Linux, see the source tcp_timewait_state_process).

About tcp_max_tw_buckets. This is to control the number of concurrent TIME_WAIT. The default value is 180000. If the limit is exceeded, the system will drop the excess to destory and issue a warning in the log (such as time wait bucket table overflow). The official website documentation says this parameter is used against DDoS attacks. Also said that the default value of 180000 is not small. This still needs to be considered according to the actual situation.

Again, it is very dangerous to use tcp_tw_reuse and tcp_tw_recycle to solve the TIME_WAIT problem, because these two parameters violate the TCP protocol (RFC 1122).

In fact, TIME_WAIT means that you take the initiative to disconnect, so this is the so-called "no death, no death". Just imagine, if the opposite side is disconnected, then this stupid problem is the other side's, hehe. In addition, if your server is a HTTP server, how important it is to set the KeepAlive of a HTTP (the browser will reuse a TCP connection to handle multiple HTTP requests), and then let the client break the link (you have to be careful, browsers may be so greedy that they won't disconnect until they have to).

Sequence Number in data Transmission

The picture below is that I took a picture of data transmission when I visited coolshell.cn from Wireshark to show you how SeqNum has changed. (use Statistics-> Flow Graph from the Wireshark menu. )

As you can see, the increase in SeqNum is related to the number of bytes transferred. In the image above, after the three-way handshake, there are two Len:1440 packets, and the SeqNum of the second package is 1441. Then the first ACK returns 1441, indicating that the first 1440 has been received.

Note: if you use the Wireshark package grab program to watch 3 handshakes, you will find that SeqNum is always 0, which is not the case. Wireshark uses a relative serial number of Relative SeqNum-- in order to be more friendly, as long as you cancel it in protocol preference in the right-click menu, you can see "Absolute SeqNum".

TCP retransmission mechanism

TCP needs to ensure that all packets are reachable, so there must be a retransmission mechanism.

Note that the Ack acknowledgement from the receiver to the sender will only confirm the last continuous packet. For example, the sender sends a total of five copies of data, and the receiver receives 1d2, then returns ack 3, and then receives 4 (note that 3 does not receive it at this time). What will the TCP do at this time? We need to know that, as mentioned earlier, SeqNum and Ack are in bytes, so when ack, you can't skip acknowledgment, you can only confirm the largest packet received in succession, otherwise, the sender will assume that the previous packet has been received.

Timeout retransmission mechanism

One is not to return ack, death and so on 3. When the sender finds that the ack with less than 3 has timed out, it will retransmit 3. Once the receiver receives 3, it will ack back to 4 Murray-meaning both 3 and 4 have been received.

However, there will be a more serious problem with this approach, that is, waiting for 3 will lead to 4 and 5, even if it has been received, and the sender has no idea what happened, because the sender has not received the Ack, so the sender may pessimistically think that it has been lost, so it may also lead to retransmission of 4 and 5.

There are two options for this:

One is a packet that retransmits only timeout. That's the third piece of data.

The other is to retransmit all the data after timeout, that is, 3, 4, 5, these three data.

These two ways are both good and bad. The first will save bandwidth, but slow, and the second will be faster, but it will waste bandwidth, and it may be useless. But on the whole, it's not good. Because we're all waiting for timeout,timeout to be very long (I'll talk about how TCP dynamically calculates timeout in the next article).

Fast retransmission mechanism

Therefore, TCP introduces an algorithm called Fast Retransmit, which is not time-driven, but data-driven retransmission. That is, if the packet does not arrive continuously, ack the last packet that may have been lost, and if the sender receives the same ack three times in a row, it is retransmitted. The advantage of Fast Retransmit is that you don't have to wait for timeout to retransmit.

For example, if the sender sends out five pieces of data, and the first one arrives first, then ack replies 2. As a result, 2 does not receive it for some reason, and 3 arrives, so it is still ack back 2, followed by 4 and 5, but still ack back 2, because 2 still does not receive, so the sender receives three ack=2 acknowledgements, knowing that 2 has not yet arrived, so it immediately redirects 2. Then, the receiver received 2, and at this time, because 3Jing 4pm 5 all received it, ack replied 6.

Fast Retransmit has solved only one problem, and that is, the problem of timeout, it still faces a difficult choice, that is, whether to retransmit the one before retransmission or all the problems before retransmission. For the above example, is it a retransmission of # 2 or a retransmission of # 2, "3" and "4" 5? Because the sender does not know who sent back the three consecutive ack (2)? Maybe the sender sent 20 pieces of data, which was sent from # 6 "10 ~ (1)" 20. In this way, it is likely that the sender will have to retransmit this pile of data from 2 to 20 (this is the actual implementation of some TCP). We can see that this is a double-edged sword.

SACK method

Another better way is called Selective Acknowledgment (SACK) (see RFC 2018), which requires adding a SACK to the TCP header, while ACK or Fast Retransmit's ACK,SACK reports the received data fragments. See the following figure:

In this way, the sender can know which data has arrived and which has not arrived according to the SACK returned. So the algorithm of Fast Retransmit is optimized. Of course, this agreement needs to be supported by both sides. Under Linux, you can turn on this feature through the tcp_sack parameter (after Linux 2.4, it is enabled by default).

There is another problem to pay attention to here-the receiver Reneging, which means that the receiver has the right to lose the data that has been reported to the sender SACK. This is not encouraged because it complicates the problem, but it may be extreme for the receiver to do so, such as giving memory to something more important. Therefore, the sender can not rely entirely on SACK, but still has to rely on ACK and maintain Time-Out. If the subsequent ACK does not grow, it is still necessary to retransmit the SACK. In addition, the receiver can never mark the SACK packet as Ack.

Note: SACK consumes the sender's resources. Imagine that if an attacker sends a bunch of SACK to the data sender, this will cause the sender to retransmit or even traverse the data that has been sent, which will consume a lot of sender resources. For details, see "performance tradeoffs for TCP SACK".

Duplicate SACK-problem with repeated receipt of data

Duplicate SACK, also known as D-SACK, mainly uses SACK to tell the sender which data has been repeatedly received. There are detailed descriptions and examples in RFC-2883. Here are a few examples (from RFC-2883)

D-SACK uses the first segment of SACK to mark it.

If the range of the first segment of SACK is covered by ACK, then it is D-SACK

If the range of the first segment of SACK is covered by the second segment of SACK, then it is D-SACK

Example 1: ACK packet loss

In the following example, two ACK are lost, so the sender retransmits the first packet (3000-3499), so the receiver finds that it has been received repeatedly, so it returns a SACK=3000-3500, because an ACK of 4000 means receiving all the data before 4000, so this SACK is Dmursakmuri-designed to tell the sender that I received duplicate data, and our sender also knows that the packet is not lost, it is the ACK packet that is lost.

Transmitted Received ACK Sent

Segment Segment (Including SACK Blocks)

3000-3499 3000-3499 3500 (ACK dropped)

3500-3999 3500-3999 4000 (ACK dropped)

3000-3499 3000-3499 4000, SACK=3000-3500

-

Example 2, network delay

In the following example, the network packet (1000-1499) is delayed by the network, resulting in that the sender does not receive the ACK, and the next three packets arrive trigger the "Fast Retransmit algorithm", so retransmit, but when retransmitted, the delayed packet arrives again, so a SACK=1000-1500 is returned, because the ACK has reached 3000, so this SACK is a SACK that indicates that a duplicate packet has been received.

In this case, the sender knows that the retransmission triggered by the "Fast Retransmit algorithm" is not because the outgoing packet is lost, nor is it because the response ACK packet is lost, but because of the network delay.

Transmitted Received ACK Sent

Segment Segment (Including SACK Blocks)

5-999 1000

1000-1499 (delayed)

1500-1999 1500-1999 1000, SACK=1500-2000

2000-2499 2000-2499 1000, SACK=1500-2500

2500-2999 2500-2999 1000, SACK=1500-3000

1000-1499 1000-1499 3000

1000-1499 3000, SACK=1000-1500

-

It can be seen that the introduction of D-SACK has several benefits:

1) you can let the sender know whether the outgoing packet or the returned ACK packet has been lost.

2) whether your timeout is too small, resulting in a retransmission.

3) the first-sent packets arrive later on the network (also known as reordering)

4) whether my packet has been copied on the network.

Knowing these things can help TCP understand the situation of the network, so that it can better do the flow control on the network.

The tcp_dsack parameter under Linux is used to enable this feature (it is enabled by default after Linux 2.4).

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.