Computers won’t lie. If something is abnormal, there must be something fishy going on!

A few days ago, the product guy gave me feedback on a question:

The homepage of one of our online systems occasionally opens with a white screen, but it returns to normal after refreshing.

There must be something wrong when things are abnormal. Such a strange problem must be investigated!

Then I opened it and checked it out, and it was true. A white screen would appear almost every four or five times I refreshed the page.

Computers don't lie, something must be wrong!

Troubleshooting process

Our system is deployed using the architecture of nginx + multiple business servers. Nginx acts as a proxy forwarder and also plays a role in load balancing.

I used the internal address to access each business server behind it individually and refreshed it multiple times, but this problem did not occur.

Once you use the domain name accessed through nginx proxy, it will appear.

My intuition and experience tell me that the problem must be with the forwarding.

After much thought, I decided to start from the front end to troubleshoot.

Then I opened two browser windows, one opened normally and one had a white screen.

I used the F12 method and prepared to compare the differences between the two situations.

Let's take a look at the browser's console window first, and indeed we found something:

Click to view the details and find that the error is the HTML page content of the homepage to be loaded:

The webpage content is compressed. Use the browser's formatting tool to format it into a mode that is easy to read. The error location is further locked in a JS script here:

I requested this JS file separately and there was nothing unusual.

Compare the HTML content of this web page with the HTML content in the window that can be opened normally, and you will find that there is no difference.

How strange!

While I was confused, I found a clue in the network connection information in the console window:

Two browser windows request the same JS file, the normal one is 200, and the white screen one is 302!

Why does 302 appear?

I replaced the domain name with the address of the internal business server, bypassed nginx, and requested the JS file from each server individually.

really!

One of them returned me a 302!

And no matter how I refresh it, it always returns 302, while the other machines can return normally.

Then, I logged into the server and checked the JS file in the corresponding path. There was indeed a file, but the name was different:

Note that the string of hexadecimal numbers in the middle of the file name is not the same as the one requested previously.

I checked several other machines and found no problems. The names were consistent with the requests.

I am not a professional front-end developer. I only know that this name is generated after VUE is packaged, and it will be different every time it is packaged.

It seems that the front-end resource package version used on this problematic server is different from that on the other servers.

The problem can be solved by simply updating the front-end resources of this server.

Why the white screen?

The next step is to explain a question: Why can the page be opened normally when requesting each server separately, but a white screen appears after forwarding by nginx?

To answer this question, we must first understand the basic process of a browser rendering a page.

When a page address is entered, the browser first retrieves the HTML page behind the address.

After receiving it, when parsing the HTML webpage, the browser will find that resource files such as JS, CSS, and pictures are introduced into the webpage, so it will request them again.

Note that there is a problem here:

Should the actions of requesting the HTML web page and requesting these resources be performed in the same TCP connection, or should they be performed through separate TCP connections?

This issue is also an important upgrade of HTTP protocol version 1.1 to version 1.0.

In HTTP 1.0, the default is to establish a separate TCP connection for each resource request.

In HTTP 1.1, a long connection mechanism, keep-alive, was introduced, which can request multiple resources in the same TCP connection.

So what does this have to do with the white screen?

Nginx forwarding is based on connections, and multiple requests in the same connection will be forwarded to the same server.

In this way, HTML and the resources embedded in it are sent to the same server through the same connection, and the name of the JS file introduced in HTML matches the name of the JS file stored on this server.

On the contrary, if the HTML request and the requests for those resources go through different connections, they may be forwarded to different servers by nginx. In this case, the JS file name introduced in the HTML may not match the JS file resources stored on the server to which it is forwarded.

When I bypass nginx and use the internal domain name to request directly, the HTML and resource requests are handled by the same server regardless of whether they are through the same connection. Although the version of the front-end package of this server is different from that of other servers, its HTML and JS are matched, so there will be no mistaking of the two, and there will be no white screen.

Based on this setting, the connection from the browser to nginx is definitely not a long connection, but a short connection!

I captured the packet to verify:

Wow, look how many connections that is.

Click in and take a look:

Wow, nginx actually uses HTTP 1.0!

The truth is now revealed!