tcp_tw_reuse、tcp_tw_recycle和tcp_timestamps

TCP message format

1. TCP message: composed of TCP header and TCP data

2. TCP header: consists of 20 bytes of fixed length + variable length field (option) + padding

3. MSS (Maximum Segment Size): occupies 4 bytes, which is the maximum length of the data field in each TCP packet, only the data part, not including the TCP header. MSS only appears in the SYN packet, if one party does not accept the other party's MSS value, it is the default 536Byte

4. TCP header length: Determined by the "Data Offset" field in the TCP header. This field occupies 4 bits, when the maximum 1111 is taken, which is 15 decimal, the offset unit of the TCP header is 4 bytes, then the maximum length of the TCP header is 15 * 4 = 60 bytes.

5. The length of options and padding: its maximum value = the maximum length of the TCP header-a fixed length of 20 bytes, that is, a maximum of 40 bytes. The padding is to make the TCP header an integer multiple of 4 bytes.

 

 

 TCP option format

 

 

1 byte option type, 1 byte option length (Option Length) and a variable length option data (Option data)

(1) Option type 0, single-byte option, indicating the end of the option list.
(2) Option type 1, single-byte option, no operation. This option can be used between two options to align the option structure.
(3) Option type 2, maximum segment size (MSS, Maximum Segment Size) option.
(4) Option type 3, window expansion factor option.
(5) Option type 8, time stamp option.

 The timestamp option occupies 10 bytes = kind (1 byte) + length (1 byte) + info (8 bytes), where kind = 8, length = 10, info consists of two values: timestamp and timestamp echo, Each 4 bytes in length.

TCP timestamp options

The sender puts the time value of the current clock into the timestamp field when sending the message segment, and the receiver copies the timestamp field value to the timestamp echo reply field when confirming the message segment.

Therefore, after receiving the confirmation message, the sender can accurately calculate the RTT.

Understand the content stored in the timestamp and timestamp echo fields through examples: Assuming communication between host a and host b, host a sends a segment to host b, then:

1) The content stored in the timestamp field: the host a sends the message s1 to the host b. In the s1 message, the timestamp stores the kernel time ta1 when the host a sends s1.

2) The content stored in the timestamp echo field: the host b receives the s1 message and sends a message s2 containing the ack to the host a. In the s2 message, timestamp is the kernel time tb of the host b, and timestamp echo The field is ta1 parsed from the s1 message.

1) Calculate the round-trip delay RTT:

When host a receives the acknowledgement ack message s2 sent by host b, the kernel of host a is ta2 at this time.

A host can parse out the sending time of the confirmation ack confirmation packet as ta1 from the timestamp echo option of the s2 message.

Then: RTT = time to receive the ack message-time to send the message = ta2-ta1.

Both ta2 and ta1 come from the core of the host a, so there is no need to perform any clock synchronization operations at both ends of the tcp connection.

2) Serial number to prevent rewind

Original link: https://blog.csdn.net/mary19920410/java/article/details/77255967

After the NAT load, the server and client access the website and packet loss occurs

Source function: tcp_v4_conn_request (), which is the processing function (server) of the three-handshake syn package of the tcp layer;
   source code fragment:
       if (tmp_opt.saw_tstamp &&
            tcp_death_row.sysctl_tw_recycle &&
            (dst = inet_csk_route_req (sk, req)) &&
            (peer = rt_get_peer ((struct rtable *) dst))! = NULL &&
            peer-> v4daddr == saddr) {
            if (get_seconds () <peer-> tcp_ts_stamp + TCP_PAWS_MSL &&
                (s32) (peer-> tcp_ts-req -> ts_recent)>
                            TCP_PAWS_WINDOW) {
                NET_INC_STATS_BH (sock_net (sk), LINUX_MIB_PAWSPASSIVEREJECTED);
                goto drop_and_release;
            }
        }
        tmp_opt.saw_tstamp: this socket supports tcp_timestamp
        sysctl_tw_recycle: the local system opens the tcp_tw_recycle option
        TCP_PAWS_MSL: 60s, the condition judgment indicates that the last tcp communication of the source ip occurred within 60s
        TCP_PAWS_WINDOW: 1, the condition judgment indicates that the time tamp of the last tcp communication of the source ip is greater than the current tcp

When both tcp_tw_recycle / tcp_timestamps are enabled, the timestamp in the socket connect request of the same source IP host within 60s must be incremented

Analysis: When the two hosts A and B access the server through the same NAT gateway, since the timestamp time is from the system startup to the current time, the timestamps of A and B are different. Under the condition that tcp_tw_recycle / tcp_timestamps are both turned on, the host with the larger timstamp can Access, small failure.

Parameters: / proc / sys / net / ipv4 / tcp_timestamps-control timestamp option on / off
          / proc / sys / net / ipv4 / tcp_tw_recycle-reduce the timeout time of timewait socket release

 

Parameter optimization to solve TIME_WAIT problem

When mentioning TIME_WAIT, you have to mention MSL: Maximum Segment Lifetime. The maximum packet life time is similar to TTL. TTL is in the IP header. It is an initial value of the setting. The data is every -1 when it passes a network node. The newspaper was discarded.

2MSL is to solve the ack of the last fin that the initiating connection close party replies, to avoid the fin that the other party's ack cannot receive, retransmit, or is still on the intermediate route to kill the new connection.

 

1. tw_reuse and tw_recycle must be used only when the client and server timestamps are enabled (by default)

2. tw_reuse only works on the client, and the client recycles within 1s after opening

3. tw_recycle works for both client and server

 

For the client

1. As a client, there is a problem with port 65535. Too many TIME_OUT directly affects the processing power. Open tw_reuse to solve it. It is not recommended to open tw_recycle at the same time, which is not very helpful.

2. tw_reuse helps the client to complete the connection recovery in 1s. It can basically achieve a 6w / s request for a single machine. If it needs to be higher, increase the number of IPs.

3. If the intranet stress test scenario, and the client does not need to receive the connection, tw_recycle will have a little benefit.

4. Business can also be designed by the server to actively close the connection

 

For the server

1. Open tw_reuse is invalid

2. Online environment tw_recycle should not be opened because the general server and client are behind NAT

 Opening the public network service may cause part of the connection failure. If the internal network is available, it can be opened according to the situation;

   For example, my company's external services are placed behind the load, and the load will clear the timestamp, well, even if you turn it on, it will not work.

3. What to do if the server TIME_WAIT is high

   Unlike the client with port restrictions, handling a large number of TIME_WAIT Linux has been optimized very well, each connection in the TIME_WAIT state consumes very little memory,

And it can also be solved by tcp_max_tw_buckets = 100000 (this value is set according to the number of TIME_WAIT), modern machines generally do not lack this point of memory.

 

Guess you like

Origin www.cnblogs.com/zh-dream/p/12702522.html