How to measure network latency in Go apps via terminal

Why network latency hides secrets in your application

When a Go application slows down, the common reaction is to blame the database or excessive memory consumption. In practice, the truth is usually much more subtle, hiding within invisible network wires, socket response times, and connection setups. A socket is the communication endpoint that allows two programs to exchange data over a network. If this channel suffers delays, the entire processing chain collapses, creating unwanted queues and timeouts. Understanding how to measure these delays directly from the terminal is an essential skill for any engineer who wants to keep systems fast and predictable.

In modern distributed environments, every HTTP request passes through network address translation layers, routers, and cryptographic certificates. To diagnose where time is being wasted, we must isolate each stage of the communication process. This includes everything from domain name resolution (DNS) to the moment the remote server actually begins sending the first bytes of the response. Before changing a single line of code, the ideal approach is to audit external behavior using native command-line utilities to establish a reliable baseline. Just as we explained when discussing how to diagnose CPU and temperature bottlenecks on Linux via SSH, having visibility over underlying resources is the first step toward successful optimization.

Tracking sockets and connections using curl in the terminal

The terminal hides extremely powerful tools that eliminate the need to install complex monitoring software. The curl command, present in almost every Unix-based operating system, has an incredible capability to detail the time spent in each phase of an HTTP request. When we make a simple web call, the system executes a sequence of invisible events: it translates the textual address into an IP, opens a TCP connection, negotiates security via TLS, and only then transfers the data. Measuring these steps individually eliminates guesswork and points to the true villain of slowness.

To extract detailed timing metrics directly in the terminal, we can create a simple formatting file that displays the exact time of each connection phase. The following command executes a call to a service and returns a complete x-ray of the consumed time:

curl -w 'Lookup: %{time_namelookup}s
Connect: %{time_connect}s
AppConnect: %{time_appconnect}s
PreTransfer: %{time_pretransfer}s
StartTransfer: %{time_starttransfer}s
Total: %{time_total}s
' -o /dev/null -s https://api.example.com

In this block, each variable represents a critical fraction of the data packet journey. The time_connect parameter shows the exact time to establish the raw TCP connection, while time_appconnect reveals the cost of the secure handshake, which is the negotiation of cryptographic certificates. If the handshake value is disproportionately high, we immediately know the problem lies in the TLS configuration or the geographic distance of the certificate provider, saving hours of blind debugging in application code.

Instrumenting Go code to measure HTTP handshakes

While terminal tools help diagnose external problems, we often need the Go application itself to collect network metrics at runtime for auditing and logging purposes. The Go language has an extremely robust standard library called net/http, which allows intercepting the lifecycle of a request through trace hooks. These hooks notify the code whenever a network event occurs, such as DNS resolution, TCP socket creation, or the start of data reception.

Implementing this lightweight instrumentation in Go is surprisingly simple and adds no heavy external dependencies to the project. The code snippet below demonstrates how to configure a custom HTTP client to record the time spent on each stage of a network call:

package main

import (
	"fmt"
	"net/http"
	"net/http/httptrace"
	"time"
)

func main() {
	req, _ := http.NewRequest("GET", "https://api.example.com", nil)
	
	var start, connect, dns time.Time
	
trace := &httptrace.ClientTrace{
		DNSStart: func(info httptrace.DNSStartInfo) {
			dns = time.Now()
		},
		DNSDone: func(info httptrace.DNSDoneInfo) {
			fmt.Printf("DNS Took: %v
", time.Since(dns))
		},
		ConnectStart: func(net, addr string) {
			connect = time.Now()
		},
		ConnectDone: func(net, addr string, err error) {
			fmt.Printf("TCP Connect Took: %v
", time.Since(connect))
		},
	}
	
	req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
	client := &http.Client{}
	resp, err := client.Do(req)
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close()
}

With this structure running inside your microservice, your application gains the ability to log structured data containing the exact network latency of each consumed external dependency. This is essential in microservices architectures, where a single user click can trigger dozens of cascading HTTP calls. Knowing the behavior of these sockets in production prevents unpleasant surprises when traffic spikes suddenly and connection limits start getting hit.

When analyzing data collected by terminal tools and Go tracers, certain problem patterns tend to appear quite frequently. Ephemeral port exhaustion is one of the most classic bottlenecks in applications that open and close HTTP connections recklessly without reusing them. The operating system allocates a local port for each outbound socket, and if the application fails to keep connections alive via the Keep-Alive mechanism, these ports run out rapidly, generating mysterious connection refused errors.

Another recurring issue is the delay generated by TCP packet retransmissions caused by network packet loss or improper buffer tuning. Just as we perform preventive operating system maintenance, as detailed in our guide on how to clear system cache on Ubuntu via terminal safely, keeping the network subsystem clean and optimized is vital. Tuning HTTP client timeouts in Go prevents goroutines from getting blocked indefinitely waiting for a response that will never arrive due to a silent socket drop. To explore these architectural concepts further in production, see our related technical analysis on How to test SMD voltage regulators with a multimeter on bench.

Final considerations on network monitoring in Go

Measuring network latency and tracking socket bottlenecks in Go applications does not have to be a complex task relying on heavy, expensive APM tools. By combining native terminal utilities like curl for point-in-time analysis and lightweight instrumentation provided by the httptrace library in Go code, we achieve total visibility into the actual behavior of the infrastructure. This practical approach empowers developers to understand the complete lifecycle of a request, ensuring more resilient, fast, and easy-to-debug systems in any production environment.