Byte One: The website cannot be displayed, how to troubleshoot?

Hello everyone, I am Xiaolin.

A reader was asked this question during his first interview at ByteDance: After entering the URL in the browser and pressing Enter, if the page does not appear, how do you troubleshoot the problem?

My answer:

The most direct way is to capture the packet. The ideas for troubleshooting are as follows:

• First determine whether it is a server-side problem or a client-side problem. First confirm whether the browser can access other websites. If not, it indicates a problem with the client network itself. Then check the client network configuration (whether the wifi connection is normal, whether the network cable is plugged in); if other web pages can be accessed normally, it indicates that the client network can access the Internet normally.
• If the client network is OK, capture the packet to confirm whether the DNS has resolved the IP address. If not, it means that the domain name is written incorrectly. If the IP address is resolved, capture the packet to confirm whether a three-way handshake is established with the server. If the three-way handshake can be successfully established and an HTTP request is sent, but the page is not displayed, you can check the response code returned by the server:

If it is a 404 error code, check whether the entered URL is correct;

If it is 500, it means that there is a problem with the server at this time;

If it is 200, use F12 to see if there is a problem with the front-end code that causes the browser to not render the page.

• If the client network is normal, but the access speed is very slow, it will take a long time to display. At this time, it depends on whether the client network port traffic is too large, causing TCP packet loss and other problems.

In short, it is to check whether the network cable is plugged in layer by layer, whether the network configuration is correct, whether the DNS has resolved the IP address, whether there is a three-way handshake of TCP, and what is the response code returned by HTTP.

Practical teaching

It just so happened that yesterday a friend’s website could not display the web page even after 10 seconds of access. After I helped him check it out, I located the problem. After correcting the problem, the website access speed returned to normal.

So, next, let me tell you about my troubleshooting ideas at the time.

The beginning of things

Early yesterday morning, my friend (programmer Brother Wu) came to me in a hurry and asked me to help check his website. Many people reported that his website was very stuck and the web page could not be displayed even after 10 seconds of access, so many people clicked on his website and left.

He also said that he accessed the page very quickly. I also tried accessing the page myself and found that it was indeed very slow. The webpage took more than 10 seconds to be displayed.

Then he sent me two speed test graphs of the website.

The first one is the website speed test result:

The second picture is the ping test result:

The second one is the website access speed test result:

He asked me: The ping test is red, but the domestic speed test is green. Is there any relationship between the two? Is the problem caused by the ping failure?

Ping detection uses the icmp protocol, and website detection uses the http protocol.

I think the problem of website access card is definitely not caused by ping failure, because the website detection is green, which at least proves that the entire http network link of the website is fine, and the icmp protocol will not be used to access the website.

As for why the ping test is red, it is because the firewall of his server blocks the icmp protocol.

Although ping can help us determine network latency, a ping failure does not necessarily mean that the server is offline or the website is inaccessible, because the icmp protocol may be blocked by the firewall.

So what is the cause? How to continue to investigate?

I first used a packet capture tool to capture the network packets accessing the website.

It was found that TCP three-way handshake, TLS handshake, and HTTP data transmission can be carried out normally, and the delay is also very low. This proves that the website's network is completely fine.

Next, I used the browser's F12 debugging tool to troubleshoot.

As a result, I found a lot of CSS files with access timeouts, and this was the reason. These CSS files were not requested for a long time, causing the website to not display.

Moreover, the request addresses of these CSS files are all jsdelivr cdn, which is no longer available in the country.

As for why Senior Brother Wu can access the site normally, everyone understands.

Previously, all the images on my own website were down due to problems with jsdelivr cdn. This was the image hosting service I used at the beginning, so I purchased my own image hosting service and the problem was solved.

The solution was very simple, just don't use jsdelivr cdn to speed up static files. After he turned off the plugin function of the website, it became normal.

Well, that’s all for the entire actual troubleshooting process. Let’s briefly summarize the useful knowledge:

• A ping failure does not mean that the website is abnormal, because it may be that the server's firewall blocks the ICMP protocol;
• If the website cannot be displayed, first capture the packets to confirm whether the TCP handshake, TLS handshake, and HTTP request are normal; if they are all normal, it proves that there is no problem with the network. Then use the browser's F12 debugging tool to see which file request has a problem. Generally speaking, if CSS, JS and other files cannot be requested, the website will not be displayed.