Support downloading packages in parallel, with multiple connections per package (similar to apt-fast)

Relevant area(s)

• WinGet CLI

Description of the new feature / enhancement

Support downloading a single package using multiple concurrent connections/streams (segmented download) to improve throughput — especially on high-latency or intermittently slow links. The concept is similar to apt-fast and other download accelerators.

Note: This issue is scoped to accelerating the download of one package via multiple streams. Downloading the next package while the current one installs (multi-package pipeline) is tracked separately in #4105.

Proposed technical implementation details

• This relies on HTTP Range requests (bytes=) to fetch segments in parallel and reassemble them.
• Current state in WinGet:
  • WinGet tries Delivery Optimization (DO) first for installer downloads, which already performs connection/CDN optimization transparently.
  • The WinINet fallback path downloads sequentially on a single stream (no Range).
  • WinGet already issues HTTP Range requests elsewhere — the random-access HttpStream used for appx reading — so Range-based segmented download is feasible against sources that advertise Accept-Ranges.
• Considerations: sources that don't support ranges must fall back to a single stream; DO may already deliver most of this benefit for installer downloads, so the incremental value should be measured before investing.

Related

• #4105

Updated with GitHub Copilot.

Start by tracing the WinINet fallback download path and reviewing the existing random-access HttpStream implementation that already uses HTTP Range requests. Compare the behavior and measured benefit against Delivery Optimization, then define segmented downloads, single-stream fallback for sources without ranges, and reassembly behavior before implementation.