Curl – network performance stats


Curl is a tool commonly used with transferring data from or to a client/server. Its portability has allowed it to present in most OS installations by default, and thus making as a standard tool for troubleshooting and debugging network or server connectivity issues.

Here you will see some Curl features to gather network connectivity performance metrics, all exposed with -w flag.

-w, --write-out <format>
Make curl display information on stdout after a completed transfer.

time_namelookup
 The time, in seconds, it took from the start until the name resolving was completed.

time_connect
 The time, in seconds, it took from the start until the TCP connect to the remote host  (or  proxy)  was completed.

time_pretransfer
 The  time, in seconds, it took from the start until the file transfer was just about to begin.

time_starttransfer
  The  time,  in  seconds,  it took from the start until the first byte was just about to be transferred.

time_total
  The total time, in seconds, that the full operation lasted.

With the above 5 options, we can get a decent amount of information on the culprit for network issue. Is it DNS resolution delay? Or delay in TCP 3 way handshake? etc


Examples

On first run –

$ curl -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null https://www.fifa.com

Lookup time:	0.062836
Connect time:	0.078382
PreXfer time:	0.123689
StartXfer time:	0.155934

Total time:	0.182570

Second run –

$ curl -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null https://www.fifa.com

Lookup time:	0.022473
Connect time:	0.036173
PreXfer time:	0.087416
StartXfer time:	0.134248

Total time:	0.171503

On second run, the dns look up time is lower, as it is coming from cache. Let us flush dns cache –

$ sudo systemd-resolve --flush-caches

$ curl -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null https://www.fifa.com

Lookup time:	0.072109
Connect time:	0.086815
PreXfer time:	0.141417
StartXfer time:	0.185936

Total time:	0.227121

As expected the look up time is higher posed dns cache clear.

Additional information

You can get additional information by reading the manual pages for curl or even use curl to get information about curl –

$ curl cheat.sh/curl
 cheat.sheets:curl 
# curl
# Command-line tool for transferring data with URL syntax

# Process a single GET request, and show its output on stdout.
curl http://path.to.the/file

# Download a file and specify a new filename.
curl http://example.com/file.zip -o new_file.zip

# Download multiple files.
curl -O URLOfFirstFile -O URLOfSecondFile

# Download all sequentially-numbered files (1-24).
curl http://example.com/pic[1-24].jpg

# Download a file and follow redirects.
curl -L http://example.com/file
....

The net-tools set of packages had been deprecated years back, although the commands are still being in use. Tools such as netstat and ifconfig are part of the net-tools. The alternatives can be installed from iproute2 package.

Which Ubuntu package provides a file/command

daniel@hidmo:/tmp$ sudo dpkg -S $(which ss)
iproute2: /bin/ss

daniel@hidmo:/tmp$ sudo dpkg -S $(which netstat)
net-tools: /bin/netstat

daniel@hidmo:/tmp$ sudo dpkg -S $(which ifconfig)
net-tools: /sbin/ifconfig

daniel@hidmo:/tmp$ sudo dpkg -S $(which ip)
iproute2: /sbin/ip

Not all features of netstat can be replace with ss, but ss combined with ip can do the job.

There is lots of similarity between netstat and ss flags or options. Let us see how we can use ss to substitute for one of the most common uses of netstat – viewing TCP connections and their state, including the process name and ID associated with the socket.

Below list is for IPv4 only (-4 ) flag –

daniel@hidmo:/tmp$ sudo netstat -plant4
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      675/systemd-resolve
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      230810/cupsd
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      853/redis-server 12
tcp        0      0 192.168.10.44:51328       74.6.143.25:443       ESTABLISHED 39005/chrome --type 
tcp        0      0 192.168.10.44:56610       74.6.143.25:5228      ESTABLISHED 39005/chrome --type 
tcp        0      0 192.168.10.44:57920       64.233.177.138:443      ESTABLISHED 39005/chrome --type


The equivalent ss comand is below –

daniel@hidmo:/tmp$ sudo ss -pant4
State          Recv-Q         Send-Q                 Local Address:Port                    Peer Address:Port         Process
LISTEN         0              4096                   127.0.0.53%lo:53                           0.0.0.0:*             users:(("systemd-resolve",pid=675,fd=13))
LISTEN         0              5                          127.0.0.1:631                          0.0.0.0:*             users:(("cupsd",pid=230810,fd=7))
LISTEN         0              511                        127.0.0.1:6379                         0.0.0.0:*             users:(("redis-server",pid=853,fd=6))
ESTAB          0              0                        192.168.10.44:51328                  74.6.143.25:443         users:(("chrome",pid=39005,fd=35))
ESTAB          0              0                        192.168.10.44:56610                  74.6.143.25:5228        users:(("chrome",pid=39005,fd=37))
ESTAB          0              0                        192.168.10.44:57920                 64.233.177.138:443         users:(("chrome",pid=39005,fd=32))

ss has very helpful filtering features, for instance we can filter by source or destination IP address or port and tcp states. In below example, we are looking for TCP connections in TIMEWAIT state to a an http or https port and destined to specific IP CIDR block –

daniel@hidmo:/tmp$ sudo ss -o state time-wait '( dport = :http or dport = :https )' dst 162.247.78.0/24
Netid             Recv-Q             Send-Q                           Local Address:Port                            Peer Address:Port              Process                               
tcp               0                  0                                  192.168.10.44:59318                           162.247.78.1:https              timer:(timewait,58sec,0)             
tcp               0                  0                                  192.168.10.44:59312                           162.247.78.1:https              timer:(timewait,58sec,0)             
tcp               0                  0                                  192.168.10.44:59322                           162.247.78.1:https              timer:(timewait,58sec,0)             
tcp               0                  0                                  192.168.10.44:59328                           162.247.78.1:https              timer:(timewait,59sec,0)             
tcp               0                  0                                  192.168.10.44:59304                           162.247.78.1:https              timer:(timewait,58sec,0)             
tcp               0                  0                                  192.168.10.44:59326                           162.247.78.1:https              timer:(timewait,59sec,0)             
tcp               0                  0                                  192.168.10.44:59320                           162.247.78.1:https              timer:(timewait,58sec,0)             
tcp               0                  0                                  192.168.10.44:59306                           162.247.78.1:https              timer:(timewait,58sec,0)             
tcp               0                  0                                  192.168.10.44:59334                           162.247.78.1:https              timer:(timewait,59sec,0)             
tcp               0                  0                                  192.168.10.44:59314                           162.247.78.1:https              timer:(timewait,58sec,0)             
tcp               0                  0                                  192.168.10.44:59308                           162.247.78.1:https              timer:(timewait,58sec,0)    


References –

https://www.redhat.com/sysadmin/ss-command

https://man7.org/linux/man-pages/man8/ss.8.html

https://linux.die.net/man/8/netstat


How to generate a sequence of numbers in Bash scripting

  • Use Bash 4’s brace expansion
$ echo {1..10}
1 2 3 4 5 6 7 8 9 10

$ echo {1..10..2}
1 3 5 7 9
  • Use “seq” command
$ seq 1 10
1
2
3
4
5
6
7
8
9
10

$ seq 1 2 10
1
3
5
7
9

$ echo $(seq 1 10)
1 2 3 4 5 6 7 8 9 10


Show the changelog of package with apt-get


In Ubuntu, the command “dpkg” is a tool to install, build, remove and manage Debian packages. And aptitude(“apt”) is commonly used a frontend for dpkg. For instance, to install a package most users would use “apt-get install package”.

The “changelog” sub-command for apt-get can be used to download and display the changelog for the given package.

$ apt-get changelog dnsutils

bind9 (1:9.16.1-0ubuntu2.7) focal; urgency=medium

  * Fix a race between deactivating socket handle and processing
    async callbacks, which can lead to sockets not being closed
    properly, exhausting TCP connection limits. (LP: #1909950) 
    - d/p/lp-1909950-fix-race-between-deactivating-handle-async-callback.patch

 -- Matthew Ruffell &lt;matthew.ruffell@canonical.com>  Thu, 18 Feb 2021 16:28:44 +1300

bind9 (1:9.16.1-0ubuntu2.6) focal-security; urgency=medium

  * SECURITY UPDATE: off-by-one bug in ISC SPNEGO implementation
    - debian/patches/CVE-2020-8625.patch: properly calculate length in
      lib/dns/spnego.c.
    - CVE-2020-8625
  * This update does _not_ contain the changes from 1:9.16.1-0ubuntu2.5 in
    focal-proposed.

 -- Marc Deslauriers &lt;marc.deslauriers@ubuntu.com>  Tue, 16 Feb 2021 15:08:33 -0500

....

Note: this will download the changelog for the package to the most recent version of the package, not just the installed version. You can view the installed version and candidate version with below command –

$ apt-cache policy dnsutils
dnsutils:
  Installed: 1:9.16.1-0ubuntu2.3
  Candidate: 1:9.16.1-0ubuntu2.7
  Version table:
     1:9.16.1-0ubuntu2.7 500
        500 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages
        500 http://archive.ubuntu.com/ubuntu focal-updates/universe i386 Packages
     1:9.16.1-0ubuntu2.6 500
        500 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages
        500 http://security.ubuntu.com/ubuntu focal-security/universe i386 Packages
 *** 1:9.16.1-0ubuntu2.3 100
        100 /var/lib/dpkg/status
     1:9.16.1-0ubuntu2 500
        500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages
        500 http://archive.ubuntu.com/ubuntu focal/universe i386 Packages

References


  1. https://linux.die.net/man/8/apt-get
  2. https://linux.die.net/man/1/dpkg

Linux – view dns cache contents

Every visit to a site such as google.com starts with resolving the domain name or FQDN to an IP address. And this resolution is done by a dns service. The domain name to IP address(A record in dns terminology) mapping is cached by both dns servers and client as most domain names do not change IPs that often.

Sometimes though you might know that the A record or IP address of a domain has changed and yet your local cache is holding the old IP. Before clearing the cache, you can view the contents of the dns cache by sending a USR1 signal to systemd-resolved

sudo killall -USR1 systemd-resolved

This will dump the contents of dns cache and name servers to systemd log, which you can view with journalctl command –

sudo journalctl -u systemd-resolved

As the bottom of the log, you should see the CACHE entries –


Oct 30 22:53:04 hidmo systemd-resolved[23811]: CACHE:
Oct 30 22:53:04 hidmo systemd-resolved[23811]:         csi.gstatic.com IN A 209.85.202.120
Oct 30 22:53:04 hidmo systemd-resolved[23811]:         csi.gstatic.com IN A 209.85.202.94
Oct 30 22:53:04 hidmo systemd-resolved[23811]:         connectivity-check.ubuntu.com IN A 35.222.85.5
Oct 30 22:53:04 hidmo systemd-resolved[23811]:         connectivity-check.ubuntu.com IN A 35.224.99.156

....

Linux – flush dns with systemd

TLTR; systemd-resolve –flush-caches

systemd-resolve is a CLI tool for resolving domain names, IPv4 and IPv6 addresses, DNS records and services.

It also provides dns resolution statistics, settings and ability to flush cache. Before flushing cache, check the cache size and hit/miss statistics. Additional information such as transactions count is also reported.

$ sudo systemd-resolve --statistics
DNSSEC supported by current servers: no

Transactions                
Current Transactions: 0     
  Total Transactions: 105240
                            
Cache                       
  Current Cache Size: 15     
          Cache Hits: 50425 
        Cache Misses: 66235 
                            
DNSSEC Verdicts             
              Secure: 0     
            Insecure: 0     
               Bogus: 0     
       Indeterminate: 0     

As you can see above, the cache size is 15. In order to clear or flush the dns cache, run below command –

systemd-resolve --flush-caches

Running systemd-resolve --statistics should show a current cache size of 0.