The server repeatedly sends SYN ACK and tcp_defer_accept settings

Phenomenon:

The following are available for other websites, as I have encountered.

Is that the server always sends the SYN, ACK repeatedly.

4414.229553 Client-server TCP 62464 > http [SYN] seq=0 win=65535 len=0 mss=1452 ws=3 tsv=116730231 tser=0
4414.229633 server, client TCP http > 62464 [SYN, ACK] seq=0 ack=1 win=5792 len=0 mss=1460 tsv=2406364374 tser=11 6730231 ws=6
4414.263330 Client-server TCP 62464 > http [ACK] seq=1 ack=1 win=524280 len=0 tsv=116730231 tser=2406364374
4418.812859 server, client TCP http > 62464 [SYN, ACK] seq=0 ack=1 win=5792 len=0 mss=1460 tsv=2406365520 tser=11 6730231 ws=6
4418.892176 client-server TCP [TCP Dup ACK 778#1] 62464 > http [ACK] seq=1 ack=1 win=524280 len=0 tsv=116730278 tser=2406365520
4424.812864 server, client TCP http > 62464 [SYN, ACK] seq=0 ack=1 win=5792 len=0 mss=1460 tsv=2406367020 tser=11 6730278 ws=6
4424.891240 client-server TCP [TCP Dup ACK 778#2] 62464 > http [ACK] seq=1 ack=1 win=524280 len=0 tsv=116730337 tser=2406367020

Possible problems: for reference

OK, I don ' t has a full answer, but I ' ve learned a lot since this issue first came up. I ' ll share my insights here.

• Firstly, the problem is triggered by Google Chrome opening a number of sockets (6 in my tests) to any website you open WI Th it. It does the kickstart downloading the various elements of a website in parallel. For simple websites that don ' t has many items, like mine, some of these pre-opened sockets would sit idle. I ' ve read that other modern browsers does this as well.
• First of all, this issue occurs when you open a Web page by using a Chrome browser by creating multiple sockets (my test is 6 sockets), it initiates parallel downloads of various web content, and the simple Web site does not have much content, just the site, the other pre-opened sockets is idle. I looked at the other browsers are the same.
• The client triggering the connection-tracking problem probably has a broken home-router or something, because the idle Soc Kets tend to disappear without no FIN or RST packets being sent to tear them down.
• The client triggers this connection problem, there may be a problem with the home router or other problems, because these idle sockets will inexplicably disappear without sending any fin or RST packets.
• The repeating of the syn+ack packets seems to being normal TCP behaviour, I ' ve been able to witness it on various Third-party Webservers by running a packet dumps and then doing something as and not telnet www.website.com 80 sending any data. It could still is a Linux peculiarity though, as the servers I tested may well all run Linux. This behaviour also happened without no iptables-rules loaded, so it ' s really kernel-related.
• This repetitive syn+ack report may be a normal behavior, and I have verified it by Telnet to other third party websites without sending data (telnet www.website.com ) and grabbing the package. It may be unique to Linux, and I'm testing it on a Linux system and there are no firewall rule settings, so it might be related to the kernel.
• After sending a few syn+ack packets without response, the Linux kernel would tear down its side of the connection. iptablesconnection-tracking doesn ' t seem to share this logic, so there the connection would remain in the state ESTABLISHED until I T times out. The default timeout of this was 5 days (!). I ' m planning to the something more sensible such as a few hours.
• After sending some syn+ack packets, there is no response. The Linux kernel will disconnect its TCP connection on this side. The firewall connection does not take this approach, so its TCP connection remains established state until timeout, the default timeout is 5 days, and I plan to reduce this value to a reasonable value for a few hours.
• Repeating the syn+acks after receiving ACK isn't completely default behaviour, since I didn ' t see it when I opened a list Ening port with and nc -l ### connected to. So it might is a certain TCP option Apache sets on its listening socket. Or It might is something entirely unique to Apache. Most other daemons announce themselves immediately after connection, so they is no valid test cases for this. The connection needs to does a 3-way handshake and then immediately fall idle.
• It is not entirely a default behavior for the server to receive an ACK and send syn+acks again, and I am using nc-l to open a listening port and connect it without the condition. So it may be that some TCP option is set by Apache on the listener socket. or something unique to Apache. Most other daemons will immediately become connection state. Therefore this does not have a valid test case: This connection needs to be done in a TCP three handshake and is immediately idle.

Above for some analysis on the Internet, I combine my own situation. Basic can be sure that my router has a problem. Because after I have configured the port mappings, the extranet can access the router's Remote Web Administration pages, while idle for some time or one night, the next day to discover that the Remote Web Management page of the extranet could not be connected, and the other mapped ports could not be connected. The inner-net grasping packet discovery and described above phenomenon.

===============================================================================

Cough, just finished writing to find the final answer:

The tcp_defer_accept option is used for the listener socket.

————————————————————————————————————————————————————————————————

1. Set Tcp_defer_accept

int val = 10; Time_out

if (setsockopt (Sock_descriptor, Ipproto_tcp, tcp_defer_accept, &val, sizeof (val)) = = =-1)

{

Perror ("setsockopt");

Exit (1);

}

2. Effect of Tcp_defer_accept

Normal TCP Three-time handshake process:

First handshake: When a connection is established, the client sends a SYN packet (SYN=J) to the server and enters the Syn_send state, waits for the server to confirm; second handshake: The server receives the SYN packet, must confirm the customer's SYN (ACK=J+1), and also sends a SYN packet (syn= k), the Syn+ack packet, at which time the server enters the SYN_RECV state; the third handshake: the client receives the server's Syn+ack package, sends the acknowledgement packet ack (ACK=K+1) to the server, the packet is sent, the client and the server enter the established state, Three-time handshake completed

After setting tcp_defer_accept

Third handshake: The client receives the server's Syn+ack packet, sends the acknowledgment packet ack (ACK=K+1) to the server, the packet is sent, the connection does not enter the established state, but the first packet that actually has the data arrives at the established to complete the establishment of the connection.

Timeout for tcp_defer_accept

sysctl-w net.ipv4.tcp_synack_retries=3 to set, if after 3 retransmissions, the client still has no data in wait settings tcp_defer_accept Time after the specified time-out (the time unit is S, but the test does not appear to be accurate), the system will recycle the connection, do not issue rst or fin packets to the client. 

The server repeatedly sends SYN ACK and tcp_defer_accept settings