Category
Network Troubleshooting – Blog No 1
Time to Read
5 Minutes
Who should read this blog?
To learn about the commands which make troubleshooting easier.

Preface

We all have been there. Let me elaborate on a scenario

Sev1 is reported, and you rush to join a call where many people already joined. You are a network guy. As soon as you introduce yourself, they state there is a network issue as the production website is not working as expected or is down. The default claim is – it is a network issue before you start troubleshooting and expect the ETA asap. It is a tough life for network engineers out there. But we can rule the world if we know a few commands at our helm. Life becomes a bit easier.

This is significant for other teams as well, rather than waiting for a network engineer, you may your self run a few checks which will save you time and will help you to isolate the issue faster.

---

What happens when a website is browsed

I like Shrek movie a lot and it has a famous dialogue about layers –

Shrek: Donkey, did you know that onions have layers?
Donkey: Layers? Like a cake?
Shrek: No, Donkey, not like a cake. You know how ogres are like onions?
Donkey: They stink?
Shrek: Yes, no! Well, they do, but... no. Ogres have layers. Onions have layers. You get it? We both have layers.

Well, websites have layers too, Just like onions!! and this is how it works-

To start, it is essential to know what happens when you enter the website URL in the browser’s address field. HTTP/HTTPS request is composed of a number of stages –

• The machine will perform the DNS resolution for the website hostname
• If DNS resolution is successful and the destination IP is known, the machine will try to establish a TCP session on either port 80/443.
• If this is an HTTPS website, a TLS negotiation will be performed
• dispatch of HTTP request, followed by content download.

Failure in any above stages will impact the website’s behavior hence it becomes most important to identify at which stage the website is failing.

There are two ways to achieve this –

• Using online tools
• Using curl command

Online Tools

Many online tools are available to see the resources waterfall view of a website. I personally prefer webpagetest The below snapshot shows the waterfall for my website thecloudblogger.com

In the above waterfall we can see –

• the DNS resolution took -0.2 ms
• TCP connect took -0.4 ms
• SSL Negotiation took – 0.4 ms
• http request/response + content download took – 3.6 seconds (4.6-second document complete mark)

So at whichever stage we see higher latency or failure, that stage is the culprit.

Curl

I am sure you might hear this command, this command can be installed and run on Linux, Windows, and macOS.

Curl for Windows

https://curl.se/windows/

Curl for Linux

#apt-get install curl

Curl command for test

curl -w "dns_resolution: %{time_namelookup},tcp_established: %{time_connect},ssl_handshake_done: %{time_appconnect},TTFB: %{time_starttransfer}\n" -o /dev/null -s https://thecloudblogger.com

Below are the result :
dns_resolution: 0.012712,tcp_established: 0.056150,ssl_handshake_done: 0.366969,TTFB: 0.440029

As we can see from the results of the above curl – the output is in seconds. So from the above output DNS resolution took 12 ms, TCP session took -56 ms, SSL handshake took – 366 ms and time_starttransfer took 440 ms.

The time_starttransfer variable represents the time in seconds taken from the start of the request until the first byte of the response data is received. This timing does not include the time spent establishing the connection or any other preliminary steps before the transfer of data begins.

---