You upgraded to a 1Gbps circuit.
You verified bandwidth with testing tools.
Everything looks correct until you transfer a 50GB file over SFTP.
Instead of 1Gbps speeds, you get 8–12 Mbps.
This is not an ISP issue.
It’s not your firewall.
It’s not storage.
It’s TCP physics.
Why Is SFTP So Slow on a 1Gbps Link?
SFTP runs over TCP. And TCP performance is directly limited by something called the Bandwidth-Delay Product (BDP).
Formula:
Bandwidth × Round-Trip Time (RTT)
Example:
- 1 Gbps link
- 150 ms RTT (common transatlantic latency)
1,000,000,000 bits/sec × 0.15 sec = 150,000,000 bits
≈ 18.75 MB of data must be “in flight” to fully utilize the link.
If the TCP window size is smaller than this, the sender pauses and waits for acknowledgments. Throughput collapses.
This is why 1Gbps circuits often deliver only 5–10% utilization for SFTP over long-distance links.
The Real Cause: TCP Window and Latency
TCP sends a window of data and waits for acknowledgment before sending more.
On high-latency links:
- Acknowledgments take longer
- Senders pause more frequently
- Effective throughput drops dramatically
Even with modern hardware, unoptimized TCP connections frequently plateau at:
10–20% utilization on 150–200ms links
This is a protocol limitation — not a bandwidth issue.
Solution Option 1: TCP Tuning (Application-Level Optimization)
Historically, administrators tuned kernel parameters on Unix systems to address this:
- tcp_sendspace
- tcp_recvspace
- window scaling
- buffer limits
Today, modifying OS-level TCP settings is often restricted especially in cloud and container environments.
Modern enterprise MFT platforms like TDXchange solve this differently.
TDXchange supports TCP tuning directly inside the application, allowing administrators to:
- Optimize SFTP client connections
- Optimize SFTP server sessions
- Adjust internal socket buffer behavior
- Improve window utilization without kernel changes
This approach works well when:
- Latency is under 100–120ms
- Packet loss is minimal
- Compliance requires SFTP
- You want to remain TCP-based
In many cases, application-level tuning can improve SFTP performance 3–5x.
However, TCP still has a performance ceiling.
Why TCP Has a Hard Performance Limit
Even perfectly tuned TCP:
- Slows aggressively under minor packet loss
- Remains tied to round-trip latency
- Requires acknowledgment overhead
On long-haul links, TCP efficiency rarely exceeds 20% utilization.
This is not a configuration problem. It is inherent to how TCP works.
Solution Option 2: UDP-Based Acceleration
When large files (10GB+) must move across high-latency networks, UDP-based acceleration becomes the superior solution.
Instead of relying on TCP acknowledgments, bTrade’s Accelerated File Transfer Protocol (AFTP):
- Transmits data over UDP
- Uses custom congestion control
- Performs selective retransmissions
- Decouples throughput from RTT
This removes the wait-for-ACK bottleneck.
On high-latency links, AFTP routinely achieves:
- 90–95% bandwidth utilization
- 10–50x faster transfers than SFTP
Real-World Performance Comparison
1Gbps transatlantic link
80ms latency
Standard SFTP:
- ~45 Mbps
- ~4% utilization
- 150GB transfer ≈ 8 hours
With UDP-based acceleration:
- ~890 Mbps
- ~90% utilization
- 150GB transfer ≈ 28 minutes
Same circuit.
Same distance.
Different protocol behavior.
When to Use TCP Tuning vs UDP Acceleration
Use TCP Tuning when:
- SFTP is mandated for compliance
- Latency is moderate
- Files are smaller
- Standard protocol adherence is required
Use UDP-Based Acceleration when:
- Files exceed 10GB regularly
- Latency exceeds 100ms
- Batch windows are tight
- WAN utilization is below 20%
Many organizations deploy both:
- Tuned SFTP for standard B2B exchanges
- Accelerated transfers for replication, DR, media, and eDiscovery
How to Diagnose Your Bottleneck
- Measure RTT between endpoints
- Calculate Bandwidth-Delay Product
- Check TCP window size
- Compare theoretical vs actual throughput
- Review packet loss
- Measure WAN utilization during transfer
If your utilization is below 20% on a clean link, you are TCP-bound.
Final Takeaway
If your 1Gbps link only delivers 10Mbps for SFTP, the issue is almost certainly TCP window limitations combined with latency.
You have two viable paths:
- Optimize TCP inside the application (TDXchange supports this)
- Bypass TCP limitations entirely using UDP-based acceleration (AFTP)
The physics of TCP haven’t changed.
The tools available to solve it have.
Ignoring the issue means wasted bandwidth, missed SLAs, and longer transfer windows than your
About the Author
Andrei Olin is Chief Technology Officer at bTrade, where he leads product strategy, delivery, and security across the company’s B2B, Managed File Transfer (MFT), and security platforms. He brings over 30 years of experience in enterprise technology, including designing and operating mission-critical MFT and messaging platforms for global financial institutions such as Merrill Lynch and Deutsche Bank. Andrei holds Master’s and Bachelor’s degrees in Information Technology with a focus on Information Security.
Frequently Asked Questions (FAQ)
Why is my SFTP transfer slow on a 1Gbps connection?
Because SFTP runs over TCP, and TCP throughput is limited by the Bandwidth-Delay Product (BDP). On high-latency links (e.g., 100–200ms), the TCP window size often isn’t large enough to keep the pipe full. The sender pauses waiting for acknowledgments, collapsing throughput—even on a fully provisioned 1Gbps circuit.
What is the Bandwidth-Delay Product (BDP)?
BDP is the amount of data that must be “in flight” to fully utilize a network link. It’s calculated as:
Bandwidth × Round-Trip Time (RTT).
If your TCP window is smaller than the BDP, you will never reach full line speed.
How much latency affects SFTP performance?
Even 80–150ms latency can dramatically reduce throughput on long-haul links (e.g., transatlantic routes). On a 1Gbps link with 150ms RTT, nearly 19MB of data must be in flight to saturate the connection. If your TCP window is smaller, utilization drops to 5–20%.
Is slow SFTP caused by my ISP or firewall?
Usually not. If bandwidth tests show expected speeds and packet loss is minimal, the bottleneck is typically TCP behavior under latency—not the circuit itself.
Can TCP tuning improve SFTP performance?
Yes. Application-level TCP tuning can significantly increase throughput by optimizing socket buffers and window behavior.
Platforms like TDXchange allow administrators to tune TCP settings within the application layer—without modifying OS kernel parameters—often improving SFTP speeds by 3–5x.
When is TCP tuning enough?
TCP tuning works well when:
- Latency is below ~100–120ms
- Packet loss is minimal
- Compliance requires SFTP
- Files are moderate in size
However, TCP still has inherent performance limits over long distances.
Why does TCP have a performance ceiling?
TCP requires acknowledgment of transmitted data before sending more. On high-latency links, this acknowledgment delay reduces efficiency. Even perfectly tuned TCP typically struggles to exceed 20% utilization on long-haul networks.
What is UDP-based file transfer acceleration?
UDP-based acceleration bypasses TCP acknowledgment constraints by using custom congestion control and selective retransmission over UDP.
bTrade’s Accelerated File Transfer Protocol (AFTP) removes the wait-for-ACK bottleneck and routinely achieves 90–95% bandwidth utilization on high-latency links.
How much faster is UDP-based acceleration than SFTP?
On high-latency 1Gbps links:
- Standard SFTP may achieve 40–80 Mbps
- UDP acceleration can achieve 800–900 Mbps
This can reduce large transfer windows from hours to minutes.
When should I use UDP acceleration instead of SFTP?
Use UDP-based acceleration when:
- Files regularly exceed 10GB
- Latency exceeds 100ms
- Disaster recovery replication is required
- Batch windows are tight
- WAN utilization is below 20%
Many organizations use both: SFTP for regulated B2B traffic and UDP acceleration for large-scale data movement.
How do I know if I’m TCP-bound?
You are likely TCP-bound if:
- RTT is high (100ms+)
- Packet loss is low
- WAN utilization during transfer is under 20%
- Throughput is far below theoretical bandwidth
Measure RTT, calculate BDP, compare against TCP window size, and review utilization metrics.
Does upgrading bandwidth fix slow SFTP?
No. Increasing bandwidth without addressing TCP window limitations often results in the same low utilization—just on a larger circuit.
What’s the bottom-line fix for slow SFTP on long-distance links?
You have two options:
- Optimize TCP at the application layer (supported in TDXchange)
- Use UDP-based acceleration to bypass TCP limitations entirely
If latency is the bottleneck, protocol choice and not bandwidth is the real solution.