Why Multi‑Threaded Downloads Spike Bandwidth and How to Diagnose Them

Network traffic analysis is a vital technique for operations teams to pinpoint hard‑to‑detect issues such as massive traffic bursts, slow application responses, high transaction failure rates, packet loss on dedicated lines, or abnormal port reuse. When a monitoring system flagged congestion on an internet outbound link, a rapid investigation was required.

Statistical analysis of the traffic revealed that a single client repeatedly accessed the bank’s portal, generating a surge of HTTP GET requests for a zip file hosted under the

static.cebbank.com

domain.

Two hypotheses were considered: the client might be compromised (e.g., part of a DDoS botnet) or the behavior could be legitimate but concealed. Deep packet inspection showed that each request contained a

Range

header specifying byte positions “225443840‑225705983”, indicating a partial content request of 262,144 bytes.

The server responded with an

HTTP 206 Partial Content

status, confirming the partial download succeeded, and the total size of the zip file was about 233,395,503 bytes.

This pattern proved the client was using a multi‑threaded download strategy to maximize bandwidth utilization. By opening multiple simultaneous TCP connections, the client could effectively double its share of the available 56 Kbps link, as illustrated by a simple pipe analogy.

The root cause of the bandwidth spike was therefore the client’s multi‑threaded download, which bypassed the usual CDN distribution because a service‑provider node was misconfigured, forcing the request to hit the internal server directly. After coordinating with the provider to correct the node settings, the congestion issue was resolved.

To enable timely detection of similar incidents, the bank built a dedicated network traffic capture and analysis architecture consisting of a capture network and an analysis network. The capture network aggregates and splits traffic at the source, performs packet slicing, filtering (layers 2‑7), and forwards precise flows to analysis devices.

The analysis network is business‑driven, collecting raw data, locating analysis points based on application flows, and deploying appropriate monitoring equipment. This integrated platform provides dashboards, service dependency graphs, service monitors, session analysis, and deep packet inspection.

For example, LDAP services are monitored with metrics such as transaction rate, timeout rate, failure rate, and retransmission rate. Correlating these metrics with traffic volume helps distinguish application‑level latency from network‑level issues, accelerating fault localization.

Automated baselines and alert definitions now trigger SMS notifications to network administrators at the early stages of a fault, allowing rapid visual assessment via the platform’s UI and, if needed, targeted packet decoding.

After years of practice, the team continues to expand traffic‑analysis use cases, aiming for greater automation and intelligence in fault co‑investigation, security compliance checks, performance monitoring, and virtualized network analysis.