Part 5 · 2 chapters · ~12 min

Network Debugging

Splitting a slow call into DNS, connect, TLS, server time and transfer with curl timings, tcpdump capture filters, reading captures in Wireshark (retransmits, resets, zero windows), DNS debugging with dig, TLS debugging with openssl s_client, and MTU and NAT problems.

curl timings, dig and openssl

code

curl -s -o /dev/null -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n' https://partner.example/api/health
dig +trace partner.example ; dig @1.1.1.1 partner.example +stats     # resolver path and query time
openssl s_client -connect partner.example:443 -servername partner.example -showcerts </dev/null   # cert chain, protocol, cipher

WHERE A SLOW HTTP CALL SPENDS ITS TIME

curl -w timings for one call to a partner API

swipe the figure sideways, or tap expand for full screen

1/5

DNS

A 312 ms lookup is the biggest single cost: no caching, a slow resolver, or (in Node) a saturated threadpool (the lab /dns route measured 316 ms during four hashes).

slow DNS dominateslab: /hash then /dns

tcpdump and Wireshark

code

tcpdump -i any -nn -s 0 -w /tmp/pg.pcap 'host 10.0.4.7 and port 5432'      # capture; open in Wireshark
tcpdump -i any -nn 'tcp[tcpflags] & (tcp-rst) != 0'                          # watch for resets live

Wireshark sees	likely meaning
many retransmissions	packet loss or congestion on the path
RST right after connect	nothing listening, or a firewall rejecting
RST on an idle keep-alive connection	a load balancer or NAT dropped the idle mapping: align idle timeouts
zero window	the receiver is not reading fast enough (an overloaded consumer)
large packets lost, small ones fine	an MTU problem on a tunnel or VPN