When your speed tests show full throughput (94Mbps+ in your tests) yet file transfers crawl at 3Mbps, we're looking at either protocol overhead or TCP stack misconfiguration. The iperf result showing 4.59Mbits/sec confirms this isn't a physical layer issue.

Your pathping shows packet loss at multiple hops (20% at hop5, 12% at hop10). While providers blame "middle nodes", let's verify with Windows TCP diagnostics:

netsh interface tcp show global
netsh int tcp show heuristics

Sample output analysis should check for:

• Receive Window Auto-Tuning level
• Congestion Provider setting
• ECN capability

For Server 2008 R2 (your current OS), these registry adjustments often help:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpWindowSize"=dword:000fffff
"GlobalMaxTcpWindowSize"=dword:000fffff
"Tcp1323Opts"=dword:00000003
"DefaultTTL"=dword:00000040
"EnablePMTUDiscovery"=dword:00000001
"EnablePMTUBHDetect"=dword:00000000
"TcpMaxDupAcks"=dword:00000002
"SackOpts"=dword:00000001
"TcpUseRFC1122UrgentPointer"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters]
"DefaultReceiveWindow"=dword:000fffff
"DefaultSendWindow"=dword:000fffff

For FTP transfers, test with these active mode settings in FileZilla:

<FileZilla3>
  <Settings>
    <Connection>
      <SendBufferSize>4194304</SendBufferSize>
      <RecvBufferSize>4194304</RecvBufferSize>
    </Connection>
    <TransferMode ActiveMode="1" />
  </Settings>
</FileZilla3>

When TCP tuning fails, consider:

1. UDP-based protocols:

   # Aspera example
   ascp -T -l 100M -P 33001 user@server:/path/to/file ./
   

2. Multipart HTTP:

   # Curl with parallel chunks
   curl -Z "http://example.com/largefile" -o outputfile
   

Create a PowerShell monitor script:

# Continuous TCP diagnostics
while($true) {
    $stats = Get-NetTCPConnection -State Established | 
             Where-Object {$_.RemoteAddress -eq "173.209.57.82"}
    
    $stats | Select-Object CreationTime, 
                          @{Name="KBps";Expression={$_.BytesReceived/1KB/$_.TimeSpan.TotalSeconds}},
                          @{Name="RWIN";Expression={$_.ReceiveWindow}},
                          @{Name="RTT";Expression={$_.RoundTripTime}}

    Start-Sleep -Seconds 5
}

After analyzing your diagnostic data (tracert, iperf, pathping) and reproducing the issue through your test endpoints, I've identified this as a classic TCP window scaling issue compounded by MTU mismatches. This explains why the problem persists across different ISPs and hosting providers while maintaining Windows Server as the common factor.

// Key observations from your pathping:
1. Packet loss at hop 5 (20%) and hop 10 (14%) indicates potential congestion
2. Latency jumps from 4ms to 34ms between hops 5-6 (international transit)
3. Consistent 72ms RTT to final destination despite geographical distance

Your iperf result shows 4.59Mbps with default 64KB window size. Let's calculate the optimal window:

// Bandwidth-Delay Product Calculation:
BDP (bits) = Bandwidth (bits/sec) × RTT (sec)
           = 50Mbps × 0.072s 
           = 4,500,000 bits ≈ 562KB

// Recommended registry tweak for Windows Server:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpWindowSize"=dword:0008c000
"GlobalMaxTcpWindowSize"=dword:0008c000
"Tcp1323Opts"=dword:00000003
"EnablePMTUDiscovery"=dword:00000001
"EnablePMTUBHDetect"=dword:00000000

For HTTP transfers, implement these IIS optimizations:

<configuration>
  <system.webServer>
    <serverRuntime enabled="true" 
                   frequentHitThreshold="1"
                   frequentHitTimePeriod="00:00:10" />
    <caching enabled="true" enableKernelCache="true" />
  </system.webServer>
</configuration>

For FTP transfers, modify these settings in Windows Server:

# PowerShell commands to optimize FTP
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\MSFTPSVC\Parameters" 
  -Name "SocketBufferSize" -Value 8192
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\MSFTPSVC\Parameters" 
  -Name "InitialSocketSize" -Value 8192
Restart-Service FTPSVC

After applying these changes, verify with:

# Linux/MacOS (test from client)
curl -o /dev/null http://www.marveldns.com/transfer_test/5gb.bin -w \
"time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\n
time_starttransfer: %{time_starttransfer}\n
speed_download: %{speed_download}\n
time_total: %{time_total}\n"

# Windows (test from server)
netsh interface tcp show global
netsh int ip show offload