Nginx access log 400

The error records on the server are similar to the following:

127.0.0.1--[09/Aug/2013: 11: 51: 04 + 0800] "-" 400 0 "-""-""-"

Step:

After analyzing the nginx log file, it is found that the errors are several 400 Errors generated after a normal access, each time there are about 1-6 consecutive errors, in addition, the error 400 does not occur every time the customer accesses the website.

Then observe that the previous access with 400 errors is normal, with 200 status codes, normal files, normal routes, and normal User-Agent... everything is harmonious. is 400 swollen?

After careful observation, we found that all the User-Agent that was accessed before the 400 error was left by Google Chrome, that is, the 400 error was generated by chrome. However, after local packet capture, Chrome does not send abnormal requests or data packets to the server.

During packet capture analysis, it is found that there are more than one connection initiated by Chrome when accessing the server, generally ranging from 5 to 6. If the requested resources do not need so many connections, chrome will close unused connections. This technology is called pre-connection "pre-connection ".

Generally, when we access a website, the first one gets an HTML main file, which links the CSS, JS, images, and other media resource files required by the webpage, generally, resource files and primary HTML files are stored in the same domain. A pre-connection Establishes Many TCP connections before obtaining HTML, instead of waiting until the HTML file is obtained, connect to the server to obtain other files. Because it takes some time to connect to the server, this technology can greatly speed up the rendering of web pages.

If the webpage has few html links or the client has a cache and does not need to be downloaded, the Chrome browser may only need one 5-6 connections, otherwise, you have to disable the connection. In this way, a problem occurs: the connection to the server does not send any request. In this case, nginx is handled as a 400 Error. However, because the connection is closed, the error message is not sent to the client, which leads to errors recorded in the log file, packet Capture analysis does not see anything.

Test:

To verify that the analysis result of logs is very simple, open the command line cmd.exe and enter Telnet serverip 80 in it. After the connection is successful, directly turn off cmd. Then, check the nginx log file and add a 400 Error record.

A comment:

The advantages of pre-connection are clear, but they also have disadvantages. If the webmaster optimizes, the cookie-free technology is used, or the webpage and static resources use different servers, the CSS and JS resources required by the webpage are not in the same domain or IP address as the primary HTML, so pre-connection is not only a weakness, in addition, it will cause unnecessary burden on the master HTML server.