paint-brush
Network Troubleshooting for the Well-Rounded Developerby@memattchung
300 reads
300 reads

Network Troubleshooting for the Well-Rounded Developer

by Matt ChungJune 7th, 2021
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

The ability to troubleshoot the network and systems separates good developers from great developers. Great developers understand the TCP/IP model: great developers understand it: "Tcp-IP" Great developers should gain some proficiency in network troubleshooting. This is especially true if you find yourself gravitating towards systems programming. Regardless of whether you work on the front-end or back-end, I think all developers should learn some basic networking skills. Here are some basic tools you should add to your toolbelt:
featured image - Network Troubleshooting for the Well-Rounded Developer
Matt Chung HackerNoon profile picture

Regardless of whether you work on the front-end or back-end, I think
all developers should gain some proficiency in network troubleshooting. This is especially true if you find yourself gravitating towards systems programming.

The ability to troubleshoot the network and systems separates good developers from great developers. Great developers understand the TCP/IP model:

Source: https://www.guru99.com/tcp-ip-model.html

Some basic network troubleshooting skills

If you are just getting into networking, here are some basic tools you should add to your toolbelt:

  • Perform a DNS query (e.g.,
    dig
    or
    nslookup
    command)
  • Send an ICMP echo request to test end to end IP connectivity (i.e.
    ping X.X.X.X
    )
  • Analyze the various network hops (i.e.
    traceroute X.X.X.X
    )
  • Check whether you can establish a TCP socket connection (e.g.
    telnet X.X.X.X [port]
    )
  • Test application layer (i.e.
    curl -v https://somedomain
    )
  • Perform a packet capture (e.g.
    tcpdump -i any
    ) and what bits are sent on the wire

What IP Address is my browser connecting to?

% dig dev.to

; <<>> DiG 9.10.6 <<>> dev.to
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39029
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dev.to.                IN  A

;; ANSWER SECTION:
dev.to.         268 IN  A   151.101.2.217
dev.to.         268 IN  A   151.101.66.217
dev.to.         268 IN  A   151.101.130.217
dev.to.         268 IN  A   151.101.194.217

Is the webserver listening on the HTTP(s) port?

% telnet 151.101.2.217 443
Trying 151.101.2.217...
Connected to 151.101.2.217.
Escape character is '^]'.

Summary

Learning more about the network stack helps you quickly pinpoint and isolate problems:

  1. Is it my client-side application?
  2. Is it a firewall blocking certain ports?
  3. Is there a transient issue on the network?
  4. Is the server up and running?

Let's chat more about networking engineering and software development

If you are curious about learning how to move from front-end to
back-end development, or from back-end development to low-level systems programming, follow me on Twitter: @memattchung

Previously published here.