Time stamp caused by web site access is not a problem

Problem phenomenon:

Access to our new access to the business interface, can Ping their site, the first telnet to the end interface, the second, the third time ... It doesn't make sense to do it all the time, but when the connection is timed out, the server has no response, and the problem is the three-time handshake in HTTP.

Phenomenon:

The case of grasping the bag:

From the packet capture data found, the problem of the server side of the packet to see that there are issued Tcpsyn packets sometimes respond, sometimes do not respond. When not responding, the TCP connection between the client and the server does not establish properly, causing the page to not open. From the client grab package diagram can be seen, sent to SYN did not receive syn/ack, stating that the service side is not sent an ACK, the server is the end of the packet, they did not receive syn/ack in the network entrance, after the contrast time stamp on the difference, issued Tcpsyn packet with time stamp, Therefore suspect that the timestamp problem is caused by a fault

Solve the problem

Since the suspicion is caused by a timestamp, let's proceed to analyze if the time stamp is removed from the server side and the client on any side to resolve the problem. For the time-stamped TCP SYN packet does not respond to the problem, read the relevant data that the cause of the problem is that the issue of the registry in the system tcp1323opts this option, will cause it in the package time stamp, after the NAT, if the previous same port is used, And the timestamp is greater than the time stamp in the SYN sent by this link, the server will ignore this SYN, do not return to the Syn-ack message, the performance of the user can not complete the TCP3 handshake, resulting in a link cannot be established, link timeout. In the business hours, if the user Nat port is not used, it can open normally, when the business is busy, the NAT port is reused frequently, it is difficult to divide the unused port, which causes this problem.

There are two ways to solve the problem:

1, optimize the kernel parameters net.ipv4.tcp_timestamps, first we look at the default value of our server net.ipv4.tcp_timestamps, if the value of 0 is not caused by the problem, if it is 1 we need to set the value to 0.

To view the method:

Cat /proc/sys/net/ipv4/tcp_timestamps

Workaround:

Echo " net.ipv4.tcp_timestamps = 0 " >>/etc/sysctl.conf  && sysctl-  p

0 means: Disable timestamp

1 means: Disable timestamp

TCP Timestamp Description:

The TCP timestamp option adds 12 bytes to the TCP header, enabling the calculation of the RTT in a more precise manner than a specific weighting.

Role:

1. TCP timestamp is in TCP option, Kind=8;lenth=10;data consists of timestamp and timestamp echo two values, each 4 bytes length.
2, the TCP timestamp theory function has 3: The serial number wraps around, the disorderly order time judgment basis, avoids confirms two semantics, as well as calculates the RTT.

Working principle:

1, the two sides each maintain their own time stamp, the value of time-stamp increases monotonically with time (stipulation is 1ms-1s/times, the common value is 1ms, 10ms).
2, this side sends Timesstamp value, the other party receives after the subsequent ACK timestamp echo responds to the value of the local side, and sends its own timestamp in the timestamp.
3, the TCP record sends the timestamp and receives the response time, thus obtains the RTT.

2. Modify the client registry Tcp1323Opts setting to 0.

Description: This parameter controls the RFC 1323 Timestamp and window scaling options. By default, timestamps are enabled with

The window is scaled, but can be controlled using the flag bit. 0-bit Control window scaling, 1-bit control timestamp.

Value of 0 (option to disable RFC 1323)

A value of 1 (window scaling is enabled only)

A value of 2 (timestamp only)

A value of 3 (two options are enabled)

What happens when this problem occurs:

Only when the client and the server are on the time stamp, it will be able to ping can not establish a TCP three handshake, so as a service provider to provide services to the company, it is impossible to ensure that all users are closed timestamp, this function, so we must turn off the timestamp, in order to provide the user with normal service.

Through this error analysis to share a few good blog:

Http://www.udpwork.com/item/6909.html

Http://www.cnblogs.com/tolimit/p/5065761.html

Http://www.cnblogs.com/lulu/p/4149312.html

Time stamp caused by web site access is not a problem