Axios Keep-Alive and Latency Impact
HTTP keep-alive connection reuse dramatically reduces network latency in the Axios HTTP client by maintaining persistent TCP and TLS connections across multiple requests to the same origin. Without keep-alive enabled, every individual HTTP request incurs the overhead of opening a new connection, which includes DNS resolution, TCP three-way handshakes, and TLS negotiations. Enabling keep-alive in Axios avoids this repetitive handshake cycle, leading to faster response times, lower CPU overhead, and higher overall throughput for network operations.
The Connection Overhead Problem
When Axios initiates an HTTP request without connection reuse, it creates a new TCP socket for each call. For secure requests (HTTPS), establishing this connection requires multiple sequential round-trips:
- TCP Handshake: 1 Round-Trip Time (RTT) to complete the SYN, SYN-ACK, and ACK exchange.
- TLS Handshake: 1 to 2 RTTs (depending on TLS 1.2 or TLS 1.3) to negotiate cipher suites and exchange cryptographic keys.
In distributed microservices or cloud environments where network
round-trip latency to external APIs ranges from 20ms to over 100ms,
establishing a new connection adds 40ms to 300ms of latency
before the server processes the request payload. Under high
request volumes, this constant teardown and recreation also creates
socket exhaustion by leaving thousands of ports in a
TIME_WAIT state.
How Keep-Alive Reduces Latency
HTTP Keep-Alive allows a single TCP connection to remain open after a response is received, enabling subsequent HTTP requests to reuse the established socket.
By eliminating connection setup phases on subsequent requests, the latency of each request is reduced purely to the transmission time of the HTTP payload and the server processing time. In practice, this often cuts p95 and p99 response times by 50% to 80% for high-frequency or chained API calls. Reusing existing connections also reduces CPU utilization on both the client and server by skipping repeated cryptographic handshakes.
Axios Behavior: Node.js vs. Browser
The impact and configuration of keep-alive in Axios depend heavily on the runtime environment:
- Browser Environment: The browser’s underlying network engine automatically manages connection pooling and keep-alive headers. Developers do not need to manually configure keep-alive in client-side Axios instances.
- Node.js Environment: Axios utilizes Node.js native
httpandhttpsmodules. By default, standard Node.js agents destroy sockets immediately after a request finishes unless explicitly configured with persistent agents.
Configuring Keep-Alive in Node.js Axios
To achieve connection reuse in server-side Node.js environments, you
must provide custom http.Agent and https.Agent
instances with keepAlive set to true:
const axios = require('axios');
const http = require('http');
const https = require('https');
const httpAgent = new http.Agent({
keepAlive: true,
maxSockets: 100,
maxFreeSockets: 10,
timeout: 60000,
});
const httpsAgent = new https.Agent({
keepAlive: true,
maxSockets: 100,
maxFreeSockets: 10,
timeout: 60000,
});
const apiClient = axios.create({
httpAgent,
httpsAgent,
});Best Practices and Considerations
- Idle Socket Timeouts: Set the client-side keep-alive timeout slightly lower than the remote server’s keep-alive timeout. This prevents race conditions where the client attempts to reuse a socket just as the server closes it.
- Socket Limits (
maxSockets): AdjustmaxSocketsbased on workload concurrency. Setting this value too low creates a client-side queue, increasing latency while waiting for an available socket. - Load Balancer Interaction: When routing through Layer 4 (TCP) load balancers, persistent connections can pin traffic to a single backend node. Layer 7 (HTTP/HTTPS) reverse proxies (such as NGINX or AWS ALB) handle keep-alive reuse on the frontend while distributing backend requests evenly.