Чи впливає фізична відстань на швидкість завантаження?

22

Я щойно посперечався з моїм колегою і подумав, що просто звернусь до експертів з цього питання. Ось сценарій. Ми використовували веб-сайт, який вимірює швидкість вашого з'єднання. Ми протестували за допомогою далекого від нас сервера (ми знаходимося в Малайзії, а сервер був у США). Це було близько 2 Мбіт / с. Тоді ми спробували з сервером у Сінгапурі, і це було набагато швидше (близько 15 Мбіт / с). Мій колега вважав, що це через фізичну відстань, тоді як я не думаю, що це має значення. Я розумію, що після того, як ви виконали початкове рукостискання і розпочався потік даних, не має значення, де розташований сервер, і результат повинен бути майже однаковим. Я чогось тут пропускаю? Як це насправді працює?

tcp latency bandwidth

— Навід
джерело

2

Ви можете це підтвердити самостійно. Пінг-сервер для отримання затримки. Тоді 2Mbps * Затримка == Window. Ви можете підтвердити фактичний розмір вікна за допомогою проводки. Але припустимо, що у вас немає масштабування вікон, тоді це 64 кБ / 2 Мбіт / с = 256 мс, тому я прогнозую, що ваш сервер знаходиться в 256 мс.

— ytti

2

@ytti опосередковано описує BDP (продукт із затримкою пропускної здатності), який приблизно перекладається на довгі (затримка), жирові (пропускну здатність) мережі, що важче зберігати повноцінне і все, що менше їсть далеко від потенційної пропускної здатності. Дивіться en.wikipedia.org/wiki/Bandwidth-delay_product .

— generalnetworkerror

2

@ytti, Windows Vista та пізніші версії за замовчуванням увімкнено масштабування вікон ... нам потрібно знати, що ОС Navid використовує для тесту

— Майк Пеннінгтон,

Згідно з цією підтримкою.microsoft.com/ kb/ 934430 масштабування (фактор 8) у Windows Vista за замовчуванням, але лише для не HTTP. Я сам не користувач Windows, тому не можу підтвердити.

— ytti

2

@ytti, я не впевнений, що це актуально. Я запускаю Vista, і я дивлюся на нюх мого HTTP-з'єднання до цієї сторінки підтримки, і TCP SYN каже: "Шкала вікна: 2 (множимо на коефіцієнт 4)"

— Майк Пеннінгтон

23

Мій колега вважав, що це через фізичну відстань, тоді як я не думаю, що це має значення. Я розумію, що після того, як ви виконали початкове рукостискання і розпочався потік даних, не має значення, де розташований сервер, і результат повинен бути майже однаковим. Я чогось тут пропускаю? Як це насправді працює?

Ви обидва мали рацію в якийсь момент історії, але ваше розуміння здебільшого правильне ... сьогодні :). Є кілька факторів, які змінилися між старішою відповіддю, яку дав ваш друг, та можливостями, якими ми сьогодні володіємо.

Масштабування вікон TCP
Настройка буфера хосту

На різницю результатів, які ви побачили, може вплинути:

Втрата пакету
Паралельні передачі TCP

Масштабування вікон TCP: ефект затримки пропускної здатності

Як згадував ваш друг, старші реалізації TCP страждали від обмежень, накладених вихідним 16-бітовим розміром вікна прийому в заголовку TCP (див. RFC 793: Розділ 3.1 ); RWIN контролює, скільки непідтверджених даних може чекати в одному TCP-розетці. 16-розрядні RWIN значення обмежених маршрутів до Інтернету з продуктами із затримкою пропускної здатності (і багато хто з сьогоднішніх інтернет-з'єднань з високою пропускною здатністю буде обмежений 16-бітовим значенням).

Для високих значень RTT корисно мати дуже великий RWIN. Наприклад, якщо ваш шлях RTT з Малайзії до США приблизно 200 мс, оригінальний TCP RWIN обмежив би вас на 2,6 Мбіт / с.

_{Максимальна} пропускна здатність = Rcv_Win / RTT

* _Макс. Пропускна здатність = 65535 * 8 / 0.200 *

_{Максимальна} пропускна здатність = 2,6 Мбіт / с

RFC 1323 визначив деякі "параметри TCP" для подолання цих обмежень; Один з цих параметрів TCP - це "масштабування вікон". Він вводить масштабний коефіцієнт, який помножує вихідне значення RWIN, щоб отримати повне значення вікна прийому; використання параметрів масштабування вікон дозволяють отримати максимальний RWIN 1073725440 байт. Застосовуючи ті самі розрахунки:

_{Максимальна} пропускна здатність = Rcv_Win / RTT

* _{Максимальна} пропускна здатність = 1073725440 * 8 / 0.200 *

_{Максимальна} пропускна здатність = 42,96 Гбіт / с

Майте на увазі, що TCP збільшує RWIN поступово протягом тривалості передачі, доки втрата пакету не є проблемою. Щоб побачити дійсно великі швидкості передачі через з'єднання з високою затримкою, вам потрібно перенести великий файл (щоб TCP встиг збільшити вікно), і втрата пакету не може бути проблемою для з'єднання.

Втрата пакетів

Інтернетні мережі в Тихому океані часом сильно перевантажуються. Деяка частина моєї родини живе в Тайвані, і ми регулярно стикаємося з проблемами, коли використовуємо Google Talk з ними. Я часто бачу втрати пакетів понад 0,5%, коли підпилюю їх лінійки DSL з США; якщо ви бачите щось на кшталт 0,5% втрати на "повільнішому" сервері, це дуже легко обмежить пропускну здатність для одного TCP-сокета.

Паралельні потоки TCP

FYI, деякі веб-сайти для тестування швидкості використовують паралельні потоки TCP для збільшення пропускної здатності ; це може вплинути на результати, які ви бачите, оскільки паралельні потоки TCP різко збільшують пропускну здатність у випадку, якщо у вас є певна втрата пакету на шляху. Я бачив чотири паралельних потоки TCP повністю насичують кабельний модем 5 Мбіт / с, який страждав від 1% постійної втрати пакету. Зазвичай втрати на 1% знижують пропускну здатність одного потоку TCP.

Матеріал бонусу: налаштування буфера господаря

Багато старих реалізацій ОС мали сокети з обмеженими буферами; зі старшою ОС (як Windows 2000), неважливо, чи дозволяв TCP велику кількість даних у польоті ... їхні буфери сокетів не були настроєні, щоб скористатися великим RWIN. Було проведено багато досліджень, щоб забезпечити високу ефективність передачі TCP . Сучасні операційні системи (для цієї відповіді ми можемо назвати Windows Vista, а пізніше "сучасні") включають в себе кращі механізми розподілу буферів у своїх реалізаціях буфера сокета.

— Майк Пеннінгтон
джерело

4

Як зауваження: є безліч маршрутизаторів старого стилю, які дозволять зменшити масштаб вікон (їх щодня менше, але їх все ще є) і скинути їх до нуля, різко зменшивши пропускну здатність. Ймовірність потрапити на один із цих зламаних маршрутизаторів зростає із кількістю перескакувань до пункту призначення, хоча сьогодні у більшості постачальників мережевої інфраструктури ця проблема не повинна виникати.

— Кріс Даун

Маршрутизатори - це пристрої L3. Масштабування вікон TCP - це процес L4. Маршрутизатор або пересилає пакет, або його немає, і, якщо не використовувати механізмів QoS, немає диференціації між TCP, UDP або будь-яким іншим протоколом. Маршрутизатори, безумовно, впливають на початкове узгодження MSS (або робити, якщо вони відмовляються від недоступних ICMP), але алгоритм розсувного вікна є суто функцією стеків на кінцевих системах.

— rnxrx

2

@rnxrx Я погоджуюся, це був би здебільшого крайній FW, який би розлютився на варіанти TCP. Я не чув про параметр масштабування маршрутизатора на маршрутизаторі, але я не був би дуже здивований, якби хтось придумав постачальника / модель, яка це зробила, вважаючи, що крайові маршрутизатори не так рідко обробляють TCP MSS опцією під час транзиту. , це не такий великий стрибок, щоб уявити, що хтось зграє це.

— ytti

3

Коротка відповідь: Так, відстань впливає на пропускну здатність одного потоку.

Інтернет розвинувся шляхом обмеження цього ефекту ... затримка ACK, масштабування вікон, інші протоколи :-) Але фізика все-таки перемагає. У цьому випадку набагато більше шансів на загальну мережеву перевантаженість через стільки стрибків - для вбивства потоку TCP потрібен лише один скинутий пакет.

— Рікі Бім
джерело

1

Хоча на це вже є відмінні відповіді, я хотів би додати: ні, на швидкість не обов'язково впливає відстань, і так, дуже часто на швидкість впливає відстань і те, і інше.

Чому так?

Сильно спрощена, чим довша відстань, тим більше «хмелів» задіяно на шляху через Інтернет. Максимальна пропускна здатність визначається найповільнішим стрибком і одночасним трафіком. Зі збільшенням відстані та дещо випадковим розподілом швидкостей стрибків зростає ймовірність отримання повільних загальних швидкостей. Крім того, фізика заважає, а збільшення затримки також може сповільнити зв'язок.

Але це не слід сприймати як належне. Технологія дозволяє нам побудувати з'єднання, що охоплює планету, практично будь-якої потрібної пропускної здатності. Однак пропускна здатність та відстань - вороги, і вони різко збільшують вартість з'єднання, знову роблячи меншою ймовірність існування лише для з'єднання, яке вам може знадобитися зараз.

Звичайно, це надто спрощено, але насправді ця ситуація дуже часто зустрічається. І тоді ви знову не відчуваєте, коли напрочуд швидкий зв’язок або розповсюджувальний проксі просто за рогом, але коли все моментально, ми рідко замислюємось про швидкість Інтернету ...

— Zac67
джерело

-1

За словами Ендрю Мартіна, відповідь - так

— Джонатан
джерело

Лише відповіді на посилання відмовляють. Будь ласка, надайте детальну інформацію, яка робить цю відповідь корисною, не залежно від пов’язаної веб-сторінки.

— Teun Vink

Чувак, це не лише посилання на відповідь, це зображення зі статистикою

— Джонатан

Я не твій чувак. Також це зображення не має сенсу без пояснення того, що знаходиться на осі Y та як воно вимірювалося. І вже тоді ви повинні пояснити, як цей образ є відповіддю на питання.

— Teun Vink

Я не знаю, чому вам важко, але вісь X і Y позначені етикетками. "Середня швидкість завантаження в Мбіт / с"

— Джонатан