Apakah jarak fisik memengaruhi kecepatan unduhan?

22

Saya baru saja berdebat dengan seorang kolega saya dan berpikir saya hanya akan menjangkau para ahli dalam hal ini. Inilah skenarionya. Kami menggunakan situs web yang mengukur kecepatan koneksi Anda. Kami diuji menggunakan server yang jauh dari kami (Kami berada di Malaysia dan server berada di AS). Itu sekitar 2 Mbps. Kemudian kami mencoba dengan server di Singapura dan itu jauh lebih cepat (sekitar 15 Mbps). Rekan saya percaya itu karena jarak fisik sementara saya pikir itu tidak penting. Pemahaman saya adalah sekali Anda telah melakukan jabat tangan awal dan aliran data telah dimulai, tidak masalah di mana server berada dan hasilnya harus hampir sama. Apakah saya melewatkan sesuatu di sini? Bagaimana cara kerjanya?

tcp latency bandwidth

— Navid
sumber

2

Anda dapat mengonfirmasi ini sendiri sepele. Ping server untuk mendapatkan latensi. Kemudian 2Mbps * Latency == Jendela. Anda dapat mengonfirmasi ukuran jendela aktual dengan wireshark. Tapi mari kita asumsikan Anda tidak memiliki skala jendela pada, maka itu 64kB / 2Mbps = 256ms, jadi saya memperkirakan server Anda akan berjarak 256ms.

— ytti

2

@ytti secara tidak langsung menggambarkan BDP (produk penundaan-bandwidth) yang secara kasar diterjemahkan menjadi jaringan panjang (penundaan), lemak (bandwidth) menjadi lebih sulit untuk tetap penuh dan apa pun yang kurang makan dari potensi throughput Anda. Lihat en.wikipedia.org/wiki/Bandwidth-delay_product .

— generalnetworkerror

2

@ytti, Windows Vista dan yang lebih baru memiliki penskalaan jendela secara default ... kita perlu tahu apa yang digunakan oleh OS Navid untuk pengujian

— Mike Pennington

Menurut ini, scaling support.microsoft.com/kb/934430 (faktor 8) adalah default di Vista, tetapi hanya untuk non-HTTP. Saya bukan pengguna Window sendiri jadi tidak bisa memverifikasi.

— ytti

2

@ytti, saya tidak yakin itu relevan. Saya menjalankan Vista, dan saya melihat hirupan koneksi HTTP saya ke halaman dukungan itu, dan TCP SYN mengatakan: "Skala Jendela: 2 (Kalikan dengan faktor 4)"

— Mike Pennington

23

Rekan saya percaya itu karena jarak fisik sementara saya pikir itu tidak penting. Pemahaman saya adalah sekali Anda telah melakukan jabat tangan awal dan aliran data telah dimulai, tidak masalah di mana server berada dan hasilnya harus hampir sama. Apakah saya melewatkan sesuatu di sini? Bagaimana cara kerjanya?

Anda berdua benar pada beberapa titik dalam sejarah, tetapi pemahaman Anda sebagian besar benar ... hari ini :). Ada beberapa faktor yang berubah antara jawaban yang diberikan teman Anda sebelumnya, dan kemampuan yang kami miliki saat ini.

Penskalaan Jendela TCP
Penyetelan penyangga host

Perbedaan dalam hasil yang Anda lihat dapat dipengaruhi oleh:

Paket hilang
Transfer TCP paralel

TCP Window Scaling: Efek bandwidth-delay

Seperti yang teman Anda sebutkan, implementasi TCP yang lebih lama menderita dari batasan yang diberlakukan oleh 16-bit asli yang menerima ukuran jendela di header TCP (ref RFC 793: Bagian 3.1 ); RWIN mengontrol berapa banyak data yang tidak diakui dapat menunggu dalam satu soket TCP. RWIN 16-bit menghargai jalur internet terbatas dengan produk penundaan bandwidth tinggi (dan banyak koneksi internet bandwidth tinggi saat ini akan dibatasi oleh nilai 16-bit).

Untuk nilai RTT yang tinggi, sebaiknya memiliki RWIN yang sangat besar. Misalnya, jika jalur Anda RTT dari Malaysia ke AS adalah sekitar 200 ms, TCP RWIN asli akan membatasi Anda hingga 2,6Mbps.

Throughput _maks = Rcv_Win / RTT

* Throughput _maks = 65535 * 8 / 0,200 *

Throughput _maks = 2,6Mbps

RFC 1323 mendefinisikan beberapa "Opsi TCP" untuk mengatasi keterbatasan ini; salah satu dari Opsi TCP adalah "skala jendela". Ini memperkenalkan faktor skala, yang mengalikan nilai RWIN asli, untuk mendapatkan nilai jendela penerimaan penuh; menggunakan opsi penskalaan jendela memungkinkan RWIN maksimum 1073725440 byte. Menerapkan perhitungan yang sama:

Throughput _maks = Rcv_Win / RTT

* Throughput _maks = 1073725440 * 8 / 0,200 *

Throughput _maks = 42,96Gbps

Perlu diingat bahwa TCP meningkatkan RWIN secara bertahap selama durasi transfer, asalkan packet loss tidak menjadi masalah. Untuk melihat kecepatan transfer yang sangat besar pada koneksi penundaan tinggi, Anda harus mentransfer file besar (sehingga TCP punya waktu untuk meningkatkan jendela) dan kehilangan paket tidak bisa menjadi masalah untuk koneksi.

Paket Hilang

Sirkuit internet di Samudra Pasifik terkadang sangat padat. Beberapa keluarga saya tinggal di Taiwan, dan kami secara rutin mengalami masalah ketika kami menggunakan Google Talk dengan mereka. Saya sering melihat paket loss lebih dari 0,5% ketika saya melakukan ping jalur DSL dari AS; jika Anda melihat sesuatu seperti kehilangan 0,5% ke server "lebih lambat", sangat mudah membatasi throughput pada satu soket TCP.

Streaming TCP paralel

FYI, beberapa situs web uji kecepatan menggunakan aliran TCP paralel untuk meningkatkan throughput ; ini mungkin mempengaruhi hasil yang Anda lihat, karena aliran TCP paralel secara dramatis meningkatkan throughput jika Anda memiliki beberapa paket-loss di jalan. Saya telah melihat empat stream TCP paralel sepenuhnya memenuhi modem kabel 5Mbps yang menderita kehilangan paket konstan 1%. Biasanya kehilangan 1% akan menurunkan throughput dari aliran TCP tunggal.

Bahan Bonus: Host Buffer tuning

Banyak implementasi OS yang lebih lama memiliki soket dengan buffer terbatas; dengan OS yang lebih lama (seperti Windows 2000), tidak masalah apakah TCP memungkinkan sejumlah besar data berada dalam penerbangan ... buffer socket mereka tidak disetel untuk mengambil keuntungan dari RWIN yang besar. Ada banyak penelitian yang dilakukan untuk mengaktifkan kinerja tinggi pada transfer TCP . Sistem operasi modern (untuk jawaban ini, kita dapat memanggil Windows Vista dan kemudian "modern") memasukkan mekanisme alokasi buffer yang lebih baik dalam implementasi buffer socket mereka.

— Mike Pennington
sumber

4

Sebagai catatan: ada banyak router gaya lama yang akan muntah pada penskalaan jendela (ada lebih sedikit setiap hari, tetapi masih banyak) dan mengatur ulang ke nol, mengurangi bandwidth Anda secara drastis. Kemungkinan memukul salah satu router yang rusak ini meningkat dengan jumlah hop ke tujuan, meskipun sebagian besar penyedia infrastruktur jaringan seharusnya tidak memiliki masalah ini saat ini.

— Chris Down

Router adalah perangkat L3. Penskalaan jendela TCP adalah proses L4. Router baik meneruskan paket atau tidak dan, kecuali penggunaan mekanisme QoS, tidak ada perbedaan antara TCP, UDP atau protokol lainnya. Router tentu memiliki efek pada negosiasi MSS awal (..atau lakukan jika mereka menjatuhkan ICMP yang tidak terjangkau) tetapi algoritma sliding window murni fungsi dari tumpukan pada sistem akhir.

— rnxrx

2

@ rnxrx Saya setuju, sebagian besar tepi FW yang akan marah tentang opsi TCP. Saya belum pernah mendengar tentang opsi pengaturan skala jendela router TCP, tetapi saya tidak akan terkejut jika seseorang datang dengan vendor / model yang telah melakukannya, mengingat bahwa tidak jarang bagi router tepi untuk menguraikan opsi TCP MSS dalam perjalanan , itu bukan lompatan besar untuk membayangkan seseorang mengacaukannya.

— ytti

3

Jawaban singkat: Ya, jarak berpengaruh pada bandwidth stream tunggal.

Internet telah mengembangkan cara untuk membatasi efek itu ... menunda ACK, penskalaan jendela, protokol lain :-) Tetapi fisika tetap menang pada akhirnya. Dalam hal ini, itu jauh lebih mungkin menjadi kemacetan jaringan umum karena begitu banyak hop - hanya dibutuhkan satu paket yang dijatuhkan untuk membunuh aliran TCP.

— Ricky Beam
sumber

1

Meskipun sudah ada jawaban yang sangat baik untuk ini, saya ingin menambahkan: tidak, kecepatan tidak harus dipengaruhi oleh jarak dan ya, sangat sering kecepatan dipengaruhi oleh jarak , keduanya benar.

Mengapa demikian?

Sangat disederhanakan, semakin jauh jaraknya, semakin banyak "hop" terlibat dalam perjalanan melalui Internet. Bandwidth maksimum ditentukan oleh hop paling lambat dan lalu lintas yang disetujui. Dengan meningkatnya jarak dan distribusi kecepatan hop yang agak acak, probabilitas untuk mendapatkan kecepatan keseluruhan yang lebih lambat meningkat. Selain itu, fisika menghalangi dan meningkatkan latensi juga dapat memperlambat tautan.

Tapi ini tidak bisa diterima begitu saja. Teknologi memungkinkan kita membangun koneksi yang mencakup seluruh planet dari hampir semua bandwidth yang diinginkan. Namun, bandwidth dan jarak adalah musuh dan keduanya secara dramatis meningkatkan biaya koneksi, sekali lagi membuatnya lebih kecil kemungkinannya hanya untuk koneksi yang mungkin Anda butuhkan saat ini.

Tentu saja, ini terlalu disederhanakan tetapi pada kenyataannya, situasi ini adalah apa yang sangat sering Anda temukan. Dan lagi-lagi Anda tidak melakukannya ketika ada koneksi yang sangat cepat atau proxy distribusi hanya di tikungan - tetapi ketika semuanya instan kita jarang berpikir tentang kecepatan internet ...

— Zac67
sumber

-1

Menurut Andrew Martin jawabannya adalah ya

— Jonathan
sumber

Tautan hanya jawaban yang tidak disarankan. Berikan detail yang membuat jawaban ini berguna tanpa bergantung pada halaman web yang ditautkan.

— Teun Vink

Kawan, itu bukan jawaban hanya tautan, ini adalah gambar dengan statistik

— Jonathan

Aku bukan temanmu. Juga, gambar ini tidak memiliki makna tanpa penjelasan apa yang ada pada sumbu Y dan bagaimana pengukurannya. Dan bahkan kemudian, Anda harus menjelaskan bagaimana gambar ini merupakan jawaban untuk pertanyaan itu.

— Teun Vink

Saya tidak tahu mengapa itu sulit bagi Anda, tetapi sumbu X dan Y diberi label. "Kecepatan Unduhan Rata-rata dalam Mbps"

— Jonathan