Fiziksel mesafe indirme hızını etkiler mi?

Bir meslektaşımla tartışmıştım ve bu konuda uzmanlara ulaşabileceğimi düşündüm. İşte senaryo. Bağlantınızın hızını ölçen bir web sitesi kullanıyorduk. Bizden uzak bir sunucu kullanarak test ettik (Malezya’dayız ve sunucu ABD’deydi). 2 Mbps civarındaydı. Sonra Singapur'da bir sunucu ile denedik ve çok daha hızlıydı (yaklaşık 15 Mbps). Meslektaşım, önemli olmadığını düşündüğümde fiziksel mesafeden dolayı olduğuna inanıyordu. Anladığım kadarıyla, ilk el sıkışmasını yaptıktan ve veri akışı başladıktan sonra, sunucunun nerede olduğu önemli değil, sonucun neredeyse aynı olması gerektiğidir. Burada bir şey mi eksik? Gerçekten nasıl çalışıyor?

Meslektaşım, önemli olmadığını düşündüğümde fiziksel mesafeden dolayı olduğuna inanıyordu. Anladığım kadarıyla, ilk el sıkışmasını yaptıktan ve veri akışı başladıktan sonra, sunucunun nerede olduğu önemli değil, sonucun neredeyse aynı olması gerektiğidir. Burada bir şey mi eksik? Gerçekten nasıl çalışıyor?

İkiniz de tarihin bir noktasında haklıydınız, ancak anlayışınız çoğunlukla doğru ... bugün :). Arkadaşınızın verdiği eski cevap ile bugün sahip olduğumuz yetenekler arasında değişen birkaç faktör var.

• TCP Pencere Ölçeklemesi
• Ana bilgisayar arabellek ayarı

Gördüğünüz sonuçların arasındaki fark bundan etkilenmiş olabilir:

• Paket kaybı
• Paralel TCP transferleri

TCP Pencere Ölçeklendirme: Bant genişliği gecikme efekti

Arkadaşınızın da belirttiği gibi, daha eski TCP uygulamaları, orijinal 16-bit tarafından belirlenen sınırlardan muzdarip, TCP başlığında pencere büyüklüğünü alır (ref RFC 793: Bölüm 3.1 ); RWIN, tek bir TCP soketinde ne kadar onaylanmamış veri bekleyebileceğini kontrol eder. 16 bitlik RWIN, yüksek bant genişliği gecikmeli ürünlerle sınırlı internet yollarına değer verir (ve günümüzün yüksek bant genişliğine sahip internet bağlantılarının çoğu, 16 bitlik bir değerle sınırlı olacaktır).

Yüksek RTT değerleri için, çok büyük bir RWIN'e sahip olmak faydalıdır. Örneğin, Malezya’dan ABD’ye giden RTT’nizin yolu yaklaşık 200ms ise, orijinal TCP RWIN sizi 2.6Mbps ile sınırlar.

Verim _maks. = Rcv_Win / RTT

* Verim _maks. = 65535 * 8 / 0.200 *

Verim _maks. = 2,6 Mbps

RFC 1323, bu sınırlamaların üstesinden gelmek için bazı "TCP Seçenekleri" tanımlamıştır; bu TCP Seçeneklerinden biri "pencere ölçeklendirme" dir. Tam alma penceresi değerini elde etmek için orijinal RWIN değerini çarpan bir ölçek faktörü sunar; pencere ölçeklendirme seçeneklerini kullanmak, maksimum RWIN 1073725440 bayta izin verir. Aynı hesaplamaları uygulamak:

Verim _maks. = Rcv_Win / RTT

* Verim _maks. = 1073725440 * 8 / 0.200 *

Verim _maks = 42.96Gbps

Paket kaybı bir sorun olmadığı sürece TCP'nin transfer süresince RWIN'i kademeli olarak arttırdığını unutmayın . Yüksek gecikmeli bir bağlantı üzerinden gerçekten büyük aktarım hızları görmek için büyük bir dosyayı aktarmanız gerekir (bu nedenle TCP'nin pencereyi arttırmak için zamanı vardır) ve paket kaybı bağlantı için sorun yaratamaz.

Paket kaybı

Pasifik Okyanusu'ndaki internet devreleri zaman zaman oldukça sıkışık oluyor. Ailemin bir kısmı Tayvan'da yaşıyor ve Google Talk’u onlarla birlikte kullanırken düzenli olarak sorunlara rastlıyoruz. DSL hatlarını ABD'den ping yaparken genellikle% 0.5'in üzerinde paket kaybı görüyorum; "yavaş" sunucuya% 0,5'lik bir kayıp görüyorsanız, tek bir TCP soketindeki verimi çok kolay bir şekilde sınırlar.

Paralel TCP akışları

Bilginize, bazı hız testi web siteleri verimi artırmak için paralel TCP akışları kullanır ; bu, gördüğünüz sonuçları etkileyebilir, çünkü paralel TCP akışları, yolda bir paket kaybınız olması durumunda verimi önemli ölçüde artırır. Dört paralel TCP akışının% 1 sabit paket kaybından muzdarip bir 5 Mbps kablo modemi tamamen doyduğunu gördüm. Normalde% 1 kayıp, tek bir TCP akışının verimini düşürür.

Bonus Malzemesi: Host Buffer ayarı

Birçok eski işletim sistemi uygulamasında sınırlı arabellekli soketler vardı; eski işletim sistemlerinde (Windows 2000 gibi), TCP'nin büyük miktarda verinin uçuşta olmasına izin verip vermemesi önemli değildi ... yuva arabellekleri, büyük RWIN'den yararlanmak için ayarlanmamış. TCP transferlerinde yüksek performans sağlamak için çok fazla araştırma yapıldı . Modern işletim sistemleri (bu cevap için Windows Vista'yı arayabiliriz ve daha sonra "modern") soket arabellek uygulamalarında daha iyi arabellek ayırma mekanizmaları içerir.

Kısa cevap: Evet, mesafenin tek akış bant genişliği üzerinde etkisi var.

İnternet bu etkiyi sınırlandırmanın yollarını geliştirdi ... gecikmiş ACK, pencere ölçeklendirmesi, diğer protokoller :-) Ama fizik hala sonuçta kazanıyor. Bu durumda, çok fazla atlamada genel ağ tıkanıklığı olması çok daha muhtemeldir - bir TCP akışını öldürmek için yalnızca tek bir bırakılan paket gerekir.

Buna zaten mükemmel cevaplar varken, şunu eklemek isterim: hayır, hız mutlaka mesafeden etkilenmez ve evet, sık sık mesafeden etkilenir her ikisi de doğrudur.

Neden?

Şiddetle sadeleştirilmiş, mesafe ne kadar uzunsa, İnternet üzerinden yolda daha fazla "atlama" söz konusudur. Maksimum bant genişliği, en yavaş sekme ve yinelenen trafik tarafından belirlenir. Artan mesafe ve atlama hızlarının biraz rasgele dağılmasıyla, toplam hızın yavaşlaması olasılığı artar. Ek olarak, fizik de buna engel oluyor ve gecikmenin artması bağlantıyı da yavaşlatabilir.

Ancak bu kabul edilmesi gereken bir şey değildir. Teknoloji, hemen hemen her istenen bant genişliğine sahip gezegen içeren bir bağlantı kurmamızı sağlıyor. Bununla birlikte, bant genişliği ve mesafe düşmanlardır ve her ikisi de bağlantının maliyetini önemli ölçüde arttırır, bu da tam şimdi ihtiyaç duyabileceğiniz bağlantı için var olma ihtimalini azaltır.

Tabii ki, bu basitleştirilmiştir ancak gerçekte, bu durum çok sık bulduğunuz şeydir. Ve sonra yine köşedeki şaşırtıcı bir şekilde hızlı bir bağlantı ya da bir dağıtım proxy'si olduğunda bunu yapmazsınız - ama her şey anında internetin hızını nadiren düşünüyoruz ...

Andrew Martin'e göre cevap evet