Paralel yükleme teknikleri: aktarım bant genişliğini artırma

Paralel yüklemeler bir dosyayı parçalara böler (genellikle 5 MB ila 100 MB) ve bunları birden fazla eş zamanlı TCP bağlantısı üzerinden iletir; böylece tek akışın yüksek gecikmeli bağlantılarda ulaştığı verim tavanı aşılır. Amazon S3 çok parçalı yükleme, Google Cloud Storage devam ettirilebilir yüklemeler ve tus.io bunu uygular. Hedef sunucuya 80 ms gecikme olan 1 Gbps hatta tek bir HTTP PUT genellikle 150 Mbps'de doygunluğa ulaşırken 8 paralel akış 900 Mbps'in ötesine geçer. Kazanım gerçek ve öngörülebilirdir — nedenini anladığınızda.

Tek akış neden yeterli değil

TCP'nin tıkışma denetimi, ne kadar onaylanmamış verinin aktarımda olacağına karar vermek için kayan bir pencere kullanır. Büyük ve yüksek gecikmeli bir boru hattında varsayılan pencere boyutu (Linux 5.x'te yaklaşık 16 MB, eski çekirdeklerde daha az) ACK'lar dönmeden önce dolar ve gönderici bekleyerek boşta kalır. Bu "bant genişliği-gecikme çarpımı" sorunudur; tek bir FTP aktarımının gigabit hat üzerinde bile Paris'ten Singapur'daki bir sunucuya yaklaşık 30 Mbps'de takılıp kalmasının nedeni budur.

Birden fazla paralel bağlantı çalıştırmak, her bağlantının kendi penceresini alması sayesinde bu sorunu ortadan kaldırır. 30 Mbps'lik sekiz akım 240 Mbps toplar; bu da farklı bağlantıları çoğunlukla farklı giriş noktaları üzerinden yönlendiren CDN kenar seçimini henüz hesaba katmadan.

Parçalama: boyut ve sayı

Tatlı nokta gecikmeye ve paket kaybına bağlıdır. 50 ms'nin altında RTT'ye sahip aynı kıta içi aktarımlarda 4 paralel çalışanla 10 MB parçalar çoğu tüketici hattını doyurur. 100 ms'nin üzerinde RTT veya yüzde 0,5'ten fazla paket kaybına sahip kıtalar arası ya da kayıplı mobil bağlantılarda 8-16 çalışanla 5 MB parçalara düşün.

S3'ün çok parçalı API'si parça başına minimum 5 MB (sonuncusu hariç), parça başına maksimum 5 GB ve yükleme başına 10.000 parça sınırı getirir. Bu, nesne başına teorik tavanı yaklaşık 48,8 TB'a taşır. Google Cloud Storage bileşik başına 32 parçaya izin verir ve bir haftaya kadar kalıcı devam ettirilebilir oturum URI'larını destekler. Azure Blob blok blobları, her biri 4.000 MiB olan 50.000 bloğa kadar kabul eder.

Tarayıcı tabanlı aktarımlar için 100 MB'ın üzerindeki parçalar zaten yüklü sekmelerde belleği zorlamaya başlar; bu yüzden web arayüzlerinin büyük çoğunluğu 5 MB ile 20 MB arasında kalır.

Modern aktarım hizmetleri bunu gerçekte nasıl yapar

WeTransfer'ın web yükleyicisi dosyaları 6 MB parçalara böler ve 3-5 paralel XHR isteği çalıştırır. Smash daha agresif parçalar; 4 MB parçaları 8 çalışana kadar dağıtır. SwissTransfer 4 paralel akımla 50 MB parçalar kullanır; bu Swiss fiber hatlarda verimi kayırmakla birlikte kararsız bağlantılarda daha kötü performans gösterir, zira tek başarısız parça 50 MB yeniden iletim anlamına gelir. Dropbox Transfer, 8 MB parçalı yükleme API'sine dayanır.

Farklar gerçek dünya testlerinde ortaya çıkar: 500 Mbps yüklemede 5 GB dosya WeTransfer'da yaklaşık 95 saniyede tamamlanırken SwissTransfer'ın benzer verimde yaklaşık 105 saniye sürdüğü görülür; bunun nedeni ara sıra yaşanan parça yeniden deneme ek yüküdür.

Devam ettirilebilir yüklemeler: sessiz üstünlük

Parçalı yüklemeler devam ettirmeyi mümkün kılar. Wi-Fi'niz 120'nin 47. parçasında kesilirse sıfırdan başlamazsınız; 48. parçadan devam edersiniz. tus.io protokolü (artık 2.0 sürümünde olan açık bir standart), yükleme ofsetini sorgulamak için HEAD isteklerini ve Upload-Offset ile Upload-Length başlıklarını kullanarak eklemek için PATCH isteklerini resmîleştirir.

Google Drive'ın devam ettirilebilir yükleme API'si 7 gün boyunca kalıcı olan oturum URI'ları kullanır. Dizüstünüzü çökertebilir, yeniden başlatabilir, sekmeyi açabilir ve kaldığınız yerden devam edebilirsiniz. Bu, kullanılabilir bir 10 GB aktarımı ile yazı-tura'ya bırakılan bir aktarım arasındaki farktır.

İstemci taraflı şifreleme matematiği değiştirir

Uçtan uca şifreli aktarım hizmetleri, her parçayı göndermeden önce istemcide şifrelemek zorundadır. Modern dizüstü CPU'da 500 MB/s hızında AES-256-GCM, darboğaz değildir; ancak sıra önemlidir: parçayı şifrele, yükle, sonraki parçayı şifrele. Çalışan havuzuyla ardışık hattı önemli kılar. Naif uygulamalar şifreleme ve yüklemeyi serileştirir; bu da etkin verimi yarıya indirir. Doğru uygulamalar, 4-8 yükleme çalışanını sınırlı bir kuyruk aracılığıyla beslemek için 2-4 şifreleme çalışanı çalıştırır.

HexaTransfer'ın AES-256-GCM şifrelemesini Web Workers'ta paralel XHR havuzuyla birlikte çalıştırmasının nedeni budur — 10 GB tavan, tarayıcıda kripto nedeniyle takılmadan gerçekten erişilebilirdir.

Geri basınç ve sunucu tarafı sınırları

Daha fazla paralellik her zaman daha hızlı değildir. Alıcı hizmet IP başına hız sınırlandırması uyguluyorsa (CloudFront'ta dağıtım başına saniye başına 25.000 istekte yaygındır) 32 eş zamanlı parça göndermek 503 Yavaşla yanıtlarını tetikleyebilir. HTTP/2, tek bir TCP bağlantısı üzerinde çoklama yaptığından yardımcı olur; ancak pek çok CDN hâlâ uç noktada HTTP/2'yi sonlandırır ve kaynağa HTTP/1.1 olarak yayar; dolayısıyla etkin paralellik kenar yapılandırmasına bağlıdır.

Aşırı paralelize etmeden önce test edin. 8 çalışan neredeyse her zaman güvenlidir; 16, bulut nesne depolarının temiz biçimde kabul edeceği üst sınırdır; 32 ise tasarrufu aşan yeniden denemeler üretmeye başlar.

Bilmeniz gereken tarayıcı sınırları

Chrome ve Firefox, HTTP/1.1 üzerinden kaynak başına eş zamanlı bağlantıları 6 ile sınırlar; HTTP/2 üzerinden ise bu sınır pratikte sınırsızdır. Aktarım hizmeti hâlâ HTTP/1.1 kullanıyorsa (nadir olmakla birlikte bazı eski FTP-HTTP ağ geçidi uygulamaları kullanır) kaç çalışan başlatırsanız başlatın paralellik tavanınız 6'dır. DevTools ile kontrol edin: Ağ panelindeki "Şelale" sütunu sıraya giren isteklerin birikimini gösterir.

iOS 17 ve sonrasındaki Safari, 6 paralel XHR'yi temiz biçimde yönetir; ancak yaklaşık 1,5 GB RAM baskısında arka plan sekmelerini çıkarmaya başlar; bu durum parçalı yükleme arabellekleri için önem taşır.

Paralel yüklemelerin yardımcı olmadığı durumlar

Asimetrik konut bağlantılarında (tipik: 1 Gbps indirme, 40 Mbps yükleme) yükleme darboğazınız sunucunun alım kapasitesi değil sizin bağlantınızdır. 5 MB'lık 8 paralel akışı 40 Mbps'lik bir boru hattından geçirmek, 40 Mbps'de 1 akıştan daha hızlı gitmez. Paralellik, tek akış tavanı boru hattının kapasitesinin altında olduğunda yardımcı olur; bağlantıyı zaten doyuruyorsanız değil.

Hücresel bağlantıda da aynı şey geçerlidir: tek çubuk LTE'deyseniz fazladan çalışanlar büyük ölçüde yeniden iletim üretir.

Hizmet seçerken nelere bakmalı

Sık büyük dosya aktarımı için bir araç seçiyorsanız üç şeyi kontrol edin: devam ettirilebilir parçalı yüklemeyi destekliyor mu, web arayüzü kaç paralel çalışan çalıştırıyor ve kenara HTTP/2 veya HTTP/3 kullanıyor mu. Bu üçünü sağlayan hizmetler, iyi bir bağlantıda 10 GB dosyayı dakikalar içinde taşır.

hexatransfer.com'da deneyin — ücretsiz, hesap gerekmez, 10 GB'a kadar.