Linux TCP/IP protocol stack tuning __linux

Source: Internet
Author: User
Tags ack rfc

This article is reproduced to: http://colobu.com/2014/09/18/linux-tcpip-tuning

Recently busy with debug and tuning of system performance. Some performance bottlenecks and Linux TCP/IP protocol stack settings, so specifically Google the Linux TCP/IP stack of the parameters of the meaning and configuration, recorded.
If you want to permanently save the settings for the parameters, you can add the parameters to the/etc/sysctl.conf. If you want to temporarily change the configuration of the parameters, you can modify the parameters under/proc/sys/net/ipv4/, the machine reboot after the change is invalid.

Yang 1028 Description of the parameters of the collation:
Reference articles:
Linux kernel tcp correlation parameter explanation
Http://os.chinaunix.net/a2008/0918/985/000000985483.shtml

Linux kernel parameter optimization
http://blog.chinaunix.net/uid-29081804-id-3830203.html Linux kernel parameter annotation

Arrange the table according to the different directory of the parameter file
The following files are located in the directory:/proc/sys/net/ipv4/

Name

Default value

Recommended values

Describe

tcpsyn_retries

5

1

For a new connection, the kernel has to send a few SYN connection requests before deciding to give up. should not be greater than 255, the default value is 5, corresponding to 180 seconds or so. (For a network with a large load and a good physical communication, this value is high and can be modified to 2.) This value is only for external connections, the incoming connection is determined by Tcp_retries1 .

tcp_synack_retries

5

1

For a remote connection request SYN, the kernel sends a SYN + ACK datagram to confirm receipt of the last SYN connection request package. This is the second step of the so-called three-time handshake (threeway handshake) mechanism. This determines the number of Syn+ack the kernel sends out before abandoning the connection. should not be greater than 255, the default value is 5, corresponding to 180 seconds or so.

Tcp_keepalive_time

7200

600

The time interval (in seconds) that TCP sends a KEEPALIVE probe message to confirm that the TCP connection is valid.

An attack that prevents both sides from establishing a connection but not sending data.

Tcp_keepalive_probes

9

3

The time interval (in seconds) that TCP sends a KEEPALIVE probe message to confirm that the TCP connection is valid.

TCP_KEEPALIVE_INTVL

75

15

The time interval (in seconds) that the message is to be sent back when the probe message has not been responded to. The default value is 75 seconds. (For general applications, this value is somewhat large and can be changed as small as needed.) in particular, web-class servers need to change the value, 15 is a more appropriate value.

tcp_retries1

3

3

How many retries are required before the response to a TCP connection request is discarded. The minimum number of RFC requirements is 3

Tcp_retries2

15

5

How many retries are required before discarding a TCP connection that activates (established communication status). The default value is 15, based on the RTO value, which is equivalent to 13-30 minutes (RFC1122 must be greater than 100 seconds). (This value is based on the current network settings, can be appropriately changed to small, my network modified to 5)

tcp_orphan_retries

7

3

How many retries are to be made before the TCP connection is dropped near the end. The default value is 7, equivalent to 50 seconds-16 minutes, depending on the RTO. If your system is a heavily loaded Web server, you may need to lower that value, which can be a sockets of resources. In addition, the test Tcp_max_orphans. (In fact, when NAT, lower this value is also a significant benefit, my own network environment to reduce this value is 3)

Tcp_fin_timeout

60

2

For a socket connection that is disconnected from the end, TCP remains in the Fin-wait-2 state for a time. The other side may disconnect or never end the connection or the unexpected process dies. The default value is 60 seconds.

tcp_max_tw_buckets

180000

36000

The number of maximum timewait sockets that the system processes at the same time. If this number is exceeded, the,time-wait socket is immediately removed and a warning message is displayed. This limit is set to protect against simple DoS attacks, but if the network condition requires more than the default, you can increase it (and perhaps add more memory). (In fact, it is best to add this value when doing NAT)

tcp_tw_recycle

0

1

Turn on fast time-wait sockets recycling. Do not modify this value at will unless you are advised or requested by a technical expert. (When doing NAT, it is recommended to open it)

Tcp_tw_reuse

0

1

Indicates whether a time-wait-state socket is allowed for a new TCP connection (this pair quickly restarts certain services, which is helpful when prompting the port to be used after startup)

Tcp_max_orphans

8192

32768

The maximum number of TCP sockets that the system can handle that is not part of any process. If this number is exceeded, a connection that is not part of any process is reset immediately and a warning message is displayed. The reason to set this limit is simply to defend against those simple DoS attacks, and do not rely on this or artificially lowering the limit. This value should be added if memory is large. (This value is set to 32768 in the Redhat as version, but when many firewalls are modified, it is recommended that the value be modified to 2000)

Tcp_abort_on_overflow

0

0

When the daemon is too busy to accept the new connection, it is like sending a reset message and the default value is False. This means that when the overflow is due to an accidental burst, the connection will revert to state. This option is only turned on when you are sure that the daemon is really unable to complete the connection request, which affects the customer's use. (when it comes to services that are already loaded with Sendmail,apache, this can quickly terminate the connection to the client, giving the service program the opportunity to handle existing connections, so many firewalls recommend opening it)

tcp_syncookies

0

1

Only occurs when Config_syncookies is selected at the kernel compile time. When a SYN wait queue appears overflow, it sends a syncookies like the other. The purpose is to prevent SYN flood attacks.

Tcp_stdurg

0

0

Use the host Request interpretation feature in the TCP Urg pointer field. Most hosts use old BSD explanations, so if you open it on Linux, it may cause you to not communicate with them properly.

Tcp_max_syn_backlog

1024

16384

For connection requests that are still not receiving client confirmation, you need to save the maximum number in the queue. For systems exceeding 128Mb of memory, the default value is 128 for 1024, below 128Mb. If the server is constantly overloaded, try adding this number. Warning! If you set this value to be greater than 1024, it is best to modify the tcp_synq_hsize, in the include/net/tcp.h to keep the tcp_synq_hsize*16 (SYN flood attack using the TCP protocol to spread the handshake defect, Fake source IP address sent a large number of Tcp-syn connected to the target system, resulting in the target system socket queue resources exhausted and unable to accept new connections. In order to cope with this attack, modern UNIX systems commonly use a multiple-connection queue approach to buffer (rather than resolve) this attack, using a basic queue to handle the normal full connection applications (connect () and accept ()), which is to store the Half-open connection separately with another queue. This dual-queue processing and other system kernel measures (such as syn-cookies/caches) can be used effectively to mitigate small-scale syn-flood attacks (proven)

tcp_window_scaling

1

1

This file indicates whether the sliding window size for setting up a TCP/IP session is variable. The parameter value is a Boolean value and is 1 to represent a variable, and 0 to represent the immutable. TCP/IP typically uses a window of up to 65535 bytes, which may be too small for a high-speed network, and if enabled, the TCP/IP sliding window size can be increased by several orders of magnitude, increasing the ability to transfer data (RFC 1323). (for ordinary hundred m networks, closing lowers overhead, so if it's not a high-speed network, consider setting to 0)

Tcp_timestamps

1

1

Timestamps is used in other things to guard against forged sequence numbers. A 1G broadband line may be encountering an old sequence number with a Out-of-line value (if it is due to the last time it was created). Timestamp will let it know it's an ' old bag '. (This file indicates whether the calculation of RTT is enabled in a method that is more precise than a time-out (RFC 1323), and this option should be enabled for better performance.) )

Tcp_sack

1

1

Using selective ack, It can be used to find specific lost datagrams-thus helping to quickly recover state. This file indicates whether a selective response (selective acknowledgment) is enabled, which can improve performance by selectively answering packets received in order to allow the sender to send only the missing message segments. (This option should be enabled for WAN traffic, but this will increase the CPU footprint.) )

Tcp_fack

1

1

Turn on the fack congestion avoidance and fast retransmission feature. (Note that when Tcp_sack is set to 0, this value is not valid even if set to 1) [This is the core function of TCP connectivity]

Tcp_dsack

1

1

Allow TCP to send "two identical" sack.

TCP_ECN

0

0

The direct congestion notification function of TCP.

tcp_reordering

3

6

The maximum number of reorder datagrams in the TCP stream. (generally see the recommendation to adjust this number slightly larger, such as 5)

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.