Investigating Network and Sockets

Suppose a client reports that an API is “slow to connect.” On the server, CPU usage looks normal, the process is running, and the listening port is open.

That still does not tell us where the delay is happening. The client could be waiting on DNS, routing, TCP connection setup, the application itself, or data transfer.

A useful network investigation breaks the request into stages:

Each stage leaves different evidence. An established TCP connection does not mean the application is responding, and a retransmission counter alone does not reveal which connection or network path was affected.

The goal is to trace a client-visible symptom to a specific socket, network namespace, queue, counter, or packet sequence.

Breaking the request into observable stages turns a vague “network is slow” report into something you can diagnose.

This chapter follows name resolution, routing, connection setup, application exchange, and close, then uses listener ownership, TCP states and queues, per-connection evidence, counters, packet capture, and namespace-aware checks to isolate failures.