Kernel Tuning of TCP/IP protocol stack

Large concurrency brings a variety of server problems, we need to make good use of the server system core, because its performance than the user-state of the thing

Note: If you want to permanently save the parameters, you can add them to the/etc/sysctl.conf, execute the sysctl-p to make them permanent, and temporarily modify the parameters under/proc/sys/net/ipv4, and then fail after restarting.

[Email protected] ipv4]# more tcp_syn_retries

5

Description: For a new link, the kernel to send a number of SYN link request to decide to discard, should not be greater than 255,default value is 5, corresponding to 180s, (for large loads and the physical channel good communication network, this value is high, can be modified to 2, this value is only for external links, The link to come in is by Tcp_retries1)

With this correspondence time, after grabbing the bag is problematic, let's see

We see that the re-send time is not consistent with the description, and what principle does TCP use to determine the time of the re-send?

The powerful Wireshark has told us that when a TCP fragment is sent, it will start to wait for the ACK of the TCP fragment, and if the receiver receives a sequence of fragments, the receiver will use the ACK fragment to reply to the sender, the sender obtains the ACK, continues to move the window, and sends the next TCP fragment , if the send side still does not receive an ACK reply until the time is completed, then the TCP fragment sent before judgment is lost and therefore re-sent, this time is called Resend timeout (rto,reteransmission timeout)

How long should the sender wait for a re-send, which is the core issue of the re-hair

The above process actually has a round trip of two directions, 1, sending fragments from the sender to the receiver's transmission

2,ack fragments from the receiver to the transmitted transmission.

The entire process actually consumes the round trip time (RTT). If the RTT is fixed, then we can make

RTO equals RTT, but in fact, the RTT floats very large,

, one is a local area network, a public network, we found that its RTO time is not the same, even in the LAN, if a certain time, the network traffic congestion, then the RTT will increase, so if we set the RTO too small, then actually sent before the TCP fragment is not lost, Repeated injection of TCP fragments in the network, thus wasting network transmission resources, on the other hand, if the RTO is too long, then when the previous TCP fragment is lost, the sender can not be re-sent in time, will cause network resources idle.

So the RTO must conform to the current network usage, the better the network, the shorter the RTO should be, the worse the RTO should be longer.

The TCP protocol determines a reasonable RTO by statistical RTT, and the sender can measure the RTT of each TCP transmission (from the point of sending the data fragment to the receiving ACK fragment), so that each measured RTT, called the sampling RTT,

Now let's observe why the RTT in the LAN is 1s

Please allow me once again to thank the Almighty Wireshark, based on the round trip time of the first TCP message, 1s,

We carefully observe that the SYN message from the round trip time can draw the following rules

First RTO = RTT

Second RTO = 1*rtt

Third RTO = 2*rtt

Fourth time RTO = 4*rtt

Fifth time RTO = 8*rtt

At this point, the TCP sends the SYN related to this time to hold a paragraph, limited to the upload limit of the document, can not be described, had to wait for the next time ...

end!

Kernel Tuning of TCP/IP protocol stack