| |
TCP three stages .1, TCP three-way handshake. 2, TCP data transmission. 3, TCP Four waving.
SYN :( synchronous serial numbers, Synchronize Sequence Numbers) This flag is only valid when the three-way handshake to establish. It represents a new TCP connection requests.
ACK :( confirmation number, Acknowledgement Number) is a confirmation mark on TCP requests, colleagues prompted the peer system has been successfully connected to all data.
FIN (end flag, Finish) to the end of a TCP session, but the corresponding port is still open, ready to accept new data.
What were the state to resolve TCP Server terminal 11 stages and Client end.
1), LISTEN: First, the server needs to open a socket for listening, the state is LISTEN / * The socket is listening for incoming connections listens for a connection request from the remote TCP port * /.
2), SYN_SENT:.. After the client calls connect conducted active open through the application and the client tcp send a SYN to request the establishment of a connection state to SYN_SENT / * The socket isactively attempting toestablish a connection after sending the connection request. wait matching connection request * /
3), SYN_RECV:. After the server should send an ACK client SYN, at the same time send yourself a SYN to the client state to SYN_RECV / * A connection request has been received fromthenetwork after receipt and sends a connection request to wait for the right. confirm connection requests * / (this process is very short, with the netstat difficult to see in this state)
4), ESTABLISHED: represents an open connection, the two sides can be or have been in the data exchange. / * The socket has anestablishedconnection. Represents an open connection, data can be transmitted to the user * /
5), FIN_WAIT1: active close (active close) client application calls close, then issued its TCP FIN request to take the initiative to close the connection, and then enter FIN_WAIT1 state ./* The socket is closed, andtheconnection is shutting down waiting for the remote TCP connectivity. request or prior connection interrupt request confirmation * / (FIN_WAIT1 active only in closing that end, the real meaning FIN_WAIT_1 and FIN_WAIT_2 state are represented wait for a FIN packet and the difference between these two states is: FIN_WAIT_1 when SOCKET status is actually at the ESTABLISHED state, it wants to take the initiative to close the connection to the other party to send a FIN packet, then that is the SOCKET into FIN_WAIT_1 state and when the other party to respond to ACK packet, it enters the state FIN_WAIT_2 of course in the actual normal circumstances, no matter what the other circumstances, it should respond immediately ACK packets, so FIN_WAIT_1 state is generally more difficult to see, but when there FIN_WAIT_2 state often use netstat to see.)
6), CLOSE_WAIT: Close passive (passive close) after receiving end TCP FIN, ACK is issued in response to the FIN request (which also acts as the reception end of file is passed to the upper application), and enter CLOSE_WAIT / * The remote end. hasshut down, waitingfor the socket to close. wait from local users sent disconnection request * /
7), FIN_WAIT2: after active close end to the ACK, entered the FIN-WAIT-2 ./* Connection is closed, and the socket is waiting forashutdown from the remote end waiting for a connection request from the remote TCP interrupt * /.
8), LAST_ACK: passive closed end after a period of time, receiving the end of file application to call CLOSE will close the connection. This led to its TCP also sends a FIN, waiting for the other side of the ACK. Entered the LAST-ACK. / * The remote end has shut down, andthe socket is closed. Waiting foracknowledgement. Wait originally sent to the remote TCP connection interrupt request confirm*/
9), TIME_WAIT: after active close receives FIN, TCP sends ACK packet, and enter the TIME-WAIT state. / * The socket iswaiting after close tohandle packets still in the network. Wait for sufficient time to ensure that the remote TCP received to confirm the connection interrupt request * / (mainline in an active closed end, he acknowledged receipt of the other side of the FIN packets, and sends out the ACK packet, and so 2MSL to return to a usable state CLOSED.)
10), CLOSING: relatively rare ./* Both sockets areshut down but westill don'thave all our data sent Request remote TCP connection interrupts * /.
11), CLOSED: passive closed end Upon receipt of ACK packet enters the closed state. End connection ./* The socket is notbeing used. There is no connection state * /
TIME_WAIT state formation occurs only in the active party to close the connection.
After active close party after receiving a FIN request passive shutdown Party, has been sent successfully give each other a ACK, set your status by the FIN_WAIT2 modified to TIME_WAIT, but must wait twice the MSL (Maximum Segment Lifetime, MSL is a datagram after internetwork can exist for a time) to the time the two sides have to cLOSED state to close the connection. Currently RHEL in TIME_WAIT state holding time is 60 seconds.
TCP three-way handshake state changes:
1. Client: SYN -> Server
Client sends a SYN to Server, then the client status becomes SYN_SENT.
2. Server: SYN + ACK -> Client
Server receives a SYN packet, and sends an ACK to Client, Server at this end state LISTEN-> SYN_RECV
3. Client: ACK -> Server
Client receives the SYN and ACK Server, this time Server side state: LISTEN -> SYN_RECV -> ESTABLISHED
Client-side state SYN_SENT -> ESTABLISHED
The first handshake process involved in the kernel parameters:
net.ipv4.tcp_syn_retries = 5
- (The maximum number oftimes initial SYNs for an active TCP connection attempt will beretransmitted. This value should not be higherthan 255. The defaultvalue is 5, which corresponds to approximately180seconds.)
Second handshake parameters involved:
First, in the process, there is a core for receiving the SYN and SYN client sent queue queuing parameters, if the queue is full, do not accept the new request, send ack wait for the final time to allow the number of wait, provided there is sufficient memory. This parameter is:
net.ipv4.tcp_max_syn_backlog
- (The maximum number of queued connectionrequests which have still not received an acknowledgement fromthe connecting client. If this number is exceeded, thekernel will begin dropping requests. The default value of 256 is increased to 1024 when the memory present in the system is adequate or greater (> = 128Mb), and reduced to 128 for thosesystems with very low memory (<= 32Mb). It isrecommended that if this needs to be increased above 1024, TCP_SYNQ_HSIZE in include / net / tcp.h be modified to keepTCP_SYNQ_HSIZE * 16 <= tcp_max_syn_backlog, and the kernel berecompiled.)
The default is 1024, the memory is large enough, highly concurrent server recommendations to improve net.ipv4.tcp_max_syn_backlog = 16384.
Second, followed by the SYN-ACK retransmissions when the Server sends the Client SYN + ACK not been given, Server retransmission control parameters of this process is
tcp_synack_retries
- (The maximum number of times a SYN / ACK segment for apassive TCP connection will be retransmitted. Thisnumber should not be higher than 255.)
The default value is 5, the corresponding time is 180 seconds for the proposed changes
tcp_synack_retries = 1
Three, SYN Cookies is a server-side TCP three-way handshake protocol to make some changes, specifically as a means to prevent SYN Flood attacks. Its principle is received in TCP server TCP SYN packet and return when TCPSYN + ACK packet is not assigned a specific data area, but according to the SYN packet to calculate the value of a cookie. Upon receipt TCPACK packets, TCP server based on the cookie value in the TCP ACK packet to check the legality. If legitimate, redistribution specialized data processing area next TCP connection. The corresponding kernel parameters are:
net.ipv4.tcp_syncookies = {0 | 1}
- (Enable TCP syncookies. The kernel must be compiled with CONFIG_SYN_COOKIES. Send out syncookies when the syn backlog queue of a socket overflows. The syncookies featureattempts to protect a socket from a SYN flood attack. This should be used as a last resort, if at all. This is a violation of the TCP protocol, andconflicts with other areas of TCP such as TCP extensions. It can cause problems for clients and relays. It is not recommended as a tuning mechanism for heavilyloaded servers to help with overloaded or misconfigured conditions . For recommended alternatives see tcp_max_syn_backlog, tcp_synack_retries, andtcp_abort_on_overflow.)
- tcp_syncookies used in conjunction with tcp_max_syn_backlog prevent SYN Flood attacks.
Intermediate transmission of data involved in the process of kernel parameters:
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_time = 120
These three parameters if the Server-side and Client-side has been no data transmission over 120 seconds after the first detection, after an interval of 15 seconds for a second probe, probe three times until it drops the connection.
Four waving state changes:
Client (initiates closed):
1.Client: FIN (M) -> Server
Client sends a FIN to Server, requested to close, Client by the ESTABLISHED -> FIN_WAIT1
2.Server: ACK -> Client
Server sends an ACK after receiving FIN, Server has ESTABLISHED -> CLOSE_WAIT
Client Server receives the ACK, the FIN_WAIT1-> FIN_WAIT2 continue to wait Server to send data
3.Server: FIN (N) -> Client
Server-side state becomes ESTABLISHED -> CLOSE_WAIT -> LAST_ACK
4.Client: ACK (N + 1) -> Server
Client receives FIN, the state ESTABLISHED-> FIN_WAIT1-> FIN_WAIT2-> TIME_WAIT [2MSL timeout] -> closed
Server-side becomes ESTABLISHED -> CLOSE_WAIT -> LAST_ACK-> CLOSED.
The above relates to a noun, 2MSL (Maximum Segment Lifetime)
- The TIME_WAIT state isalso called the 2MSL wait state.
- Every implementation mustchoose a value for the maximum segment lifetime (MSL). It is the maximum amount of time any segment can exist in the network before being discarded.
- RFC793 specifies the MSLas 2 minutes. Common implementation values, however, are 30seconds, 1 minute, or 2 minutes. Recall that the limit on lifetime of the IP datagram is based on the number of hops, not a timer.
- Given an MSL for animplementation, the rule is: when TCP performs an active close, and sends the final ACK, that connection must stay in the TIME_WAIT state for twice the MSL.
- This lets TCP resend thefinal ACK in case this ACK is lost (in which case the other endwill time out and retransmit its final FIN).
- An effect of this 2MSLwait is that while the TCP connection is in the 2MSL wait, thesocket pair defining that connection can not be reused.
- Any delayed segments thatarrive for a connection while it is in the 2MSL wait are discarded. Since the connection defined by the socket pair in the 2MSL wait can not be reused, when we do establish a valid connection we know that delayed segments from an earlier incarnation of thisconnection can not be misinterpreted as being part of the newconnection.
- The client, who performsthe active close, enters the 2MSL wait. The server does not. Thismeans if we terminate a client, and restart the client immediately, the new client can not reuse the same local port number.
- Servers, however, usewell-known ports. If we terminate a server that has a connectionestablished, and immediately try to restart the server, the server can not assign its well-known port number to its end point.
Simple point to understand is that the final end of the initiative to send FIN ack sent confirmation to the server inevitable after a time. Objective TIME_WAIT (also 2MSL) state is to prevent the loss of the last ack client issue, so in LAST_ACK server timeout retransmission FIN. Configuring 2MSL duration of server parameters, what we need is to connect Time_wait can be reused, and can be quickly closed.
Rapid recovery and reuse of the control parameters are:
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
Note that if the server is LVS-NAT is not recommended to open the above parameters.
If the server has a lot of TIME_WAIT connections can reduce tcp_fin_timeout parameter (default 60), if you have this problem, is generally accompanied by local port is occupied is completed, we need to expand the range of ports:
net.ipv4.tcp_fin_timeout = 20
- How many seconds towait fora final FIN packet before the socket is forcibly closed. This is strictly a violation of the TCP specification, but required to prevent denial-of-service (DoS) attacks. The default value in2.4 kernels is 60, down from 180 in2.2.
net.ipv4.ip_local_port_range = 1024 65534
And TIME_WAIT Maximum:
net.ipv4.tcp_max_tw_buckets = 20000
- The maximum number ofsockets in TIME_WAIT state allowed in the system. This limit exists only to prevent simple denial-of-service attacks. The default value of NR_FILE * 2 is adjusted depending on the memory in the system. If this number isexceeded, the socket is closed and a warning is printed.
Exceeding this value time_wait is closed off.
TCP buffer parameter
net.ipv4.tcp_mem = '873800 8388608 8388608'
Define the TCP protocol stack uses memory space; respectively the minimum, maximum and default values;
- Low: When TCP uses the number of pages of memory below this value, TCP will not consider releasing memory. That is lower than this value has no memory pressure. (Ideally, this value should be assigned to the tcp_wmem first two values match - the first two values indicate that the maximum page size multiplied by the maximum number of concurrent requests divided by the page size (300 * 131072/4096).)
- Pressure: When TCP uses memory more than the number of pages of the value, TCP tries to stabilize its memory usage, enter the pressure mode, when memory consumption is lower than the value of the low pressure exit status. (This value should ideally be the maximum total buffer size TCP can be used (204800 * 300/4096).)
- High: Allow all tcpsockets page amount of buffered data packets for queuing. (If this is exceeded, TCP connection will be denied, which is why not make it too conservative (512000 * 300/4096) why. Great value in this case, provided that it can handle a lot of connections, is 2.5 times expected; or make existing links can carry 2.5 times the data).
* These values are generally at system startup based on the amount of memory the system calculated.
net.ipv4.tcp_rmem = '4096 87380 8388608'
Define the TCP protocol stack for receiving the buffer memory space;
The first value is the minimum, even if the current host memory space is tight, they have to ensure that at least tcp stack space of this size is available;
The second value is the default value, it overrides net.core.rmem_default for all protocols defined by the size of the receive buffer;
The third is the maximum value that can be used to the maximum tcp receive buffer memory;
net.ipv4.tcp_wmem = '4096 65536 8388608'
Define the TCP protocol stack for transmitting buffer memory space;
Some other parameters
net.ipv4.tcp_max_orphans = 262144
- The maximum number oforphaned (not attached to any user file handle) TCP sockets allowed in the system. When this number is exceeded, theorphaned connection is reset and a warning is printed. This limitexists only to prevent simple denial-of-service attacks. Lowering this limit is not recommended. Network conditionsmight require you to increase the number of orphans allowed, butnote that each orphan can eat up to ~ 64K of unswappablememory. The default initial value is set equal to thekernel parameter NR_FILE. This initial default is adjusted depending on the memory in the system.
TCPsockets system can handle the maximum number does not belong to any process. If this number is exceeded, then the process does not belong to any of the connection will be reset immediately, and at the same time display a warning message. The reason for setting this limit, purely in order to resist those simple DoS attacks, do not rely on this or artificially reduce this limit. If the large memory should increase this value.
The system maximum number of TCP sockets not be associated to any user file handle; if more than this figure, an orphan connection will be reset immediately and print a warning message;
This restriction only to prevent simple DoS attacks, you can not rely on it too much or artificially reduce this value if you need to modify, to ensure that there is enough memory available under the premise, this value should be increased;
# This value the bigger the better, the greater the stronger the anti-attack capability
Before the company met once incident, involving arguments ad server backend server, network packet loss was encountered, the situation tcp table is filled, the corresponding parameter adjustment (default is 65536):
net.ipv4.ip_conntrack_max = 196608
net.ipv4.netfilter.ip_conntrack_max = 196608
Parameters listed here is old boy teacher used in the production parameters:
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_retries2 = 5
net.ipv4.tcp_fin_timeout = 2
net.ipv4.tcp_max_tw_buckets = 36000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_orphans = 32768
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_wmem = 8192 131072 16777216
net.ipv4.tcp_rmem = 32768 131072 16777216
net.ipv4.tcp_mem = 786432 1048576 1572864
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.ip_conntrack_max = 65536
net.ipv4.netfilter.ip_conntrack_max = 65536
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180
net.core.somaxconn = 16384
net.core.netdev_max_backlog = 16384
Optimize the kernel parameters will depend on the particular business application scenarios and hardware parameters for dynamic adjustments listed here, just common optimization parameters, defined according to various parameters, after understanding, then according to their production environment. |
|
|
|