Влияет ли физическое расстояние на скорость загрузки?

Я только что поспорил с моим коллегой и подумал, что просто пообщаюсь с экспертами по этому поводу. Вот сценарий. Мы использовали веб-сайт, который измеряет скорость вашего соединения. Мы проверили, используя сервер, который находится далеко от нас (мы находимся в Малайзии, а сервер был в США). Это было около 2 Мбит / с. Затем мы попробовали с сервером в Сингапуре, и это было намного быстрее (около 15 Мбит / с). Мой коллега полагал, что это из-за физической дистанции, хотя я не думаю, что это имеет значение. Насколько я понимаю, после того, как вы выполнили начальное рукопожатие и поток данных начался, не имеет значения, где находится сервер, и результат должен быть почти таким же. Я что-то здесь упускаю? Как это действительно работает?

Мой коллега полагал, что это из-за физической дистанции, хотя я не думаю, что это имеет значение. Насколько я понимаю, после того, как вы выполнили начальное рукопожатие и поток данных начался, не имеет значения, где находится сервер, и результат должен быть почти таким же. Я что-то здесь упускаю? Как это действительно работает?

Вы оба были правы в какой-то момент истории, но ваше понимание в основном верно ... сегодня :). Есть несколько факторов, которые изменились между старым ответом вашего друга и возможностями, которые мы имеем сегодня.

• TCP Window Scaling
• Настройка буфера хоста

На разницу в результатах, которые вы видели, могли повлиять:

• Потеря пакета
• Параллельные TCP-передачи

TCP Window Scaling: эффект задержки полосы пропускания

Как упомянул ваш друг, более старые реализации 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

К вашему сведению, некоторые сайты для тестирования скорости используют параллельные потоки TCP для увеличения пропускной способности ; это может повлиять на результаты, которые вы видите, потому что параллельные потоки TCP значительно увеличивают пропускную способность в случае потери пакетов в пути. Я видел, как четыре параллельных потока TCP полностью насыщали кабельный модем 5 Мбит / с, который страдал от постоянной потери пакетов на 1%. Обычно потеря в 1% снижает пропускную способность одного потока TCP.

Бонусный материал: Host Buffer tuning

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

Краткий ответ: Да, расстояние влияет на пропускную способность одного потока.

В интернете появились средства ограничения этого эффекта ... задержка ACK, масштабирование окна, другие протоколы :-) Но физика все равно победит. В этом случае гораздо более вероятна общая перегрузка сети из-за такого большого количества прыжков - для уничтожения потока TCP требуется всего один отброшенный пакет.

Хотя на этот вопрос уже есть отличные ответы, я хотел бы добавить: нет, скорость не обязательно зависит от расстояния, и да, очень часто скорость зависит от расстояния .

Почему это?

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

Но это не должно восприниматься как должное. Технология позволяет нам построить соединение, охватывающее планету, практически любой желаемой полосы пропускания. Тем не менее, пропускная способность и расстояние являются врагами, и оба значительно увеличивают стоимость соединения, снова снижая вероятность его существования только для соединения, которое вам может понадобиться прямо сейчас.

Конечно, это упрощено, но в действительности вы часто обнаруживаете эту ситуацию. И, опять же, вы этого не делаете, когда неожиданно быстрое соединение или прокси-сервер дистрибуции уже совсем близко - но когда все происходит мгновенно, мы редко задумываемся о скорости Интернета ...

По словам Эндрю Мартина, ответ - да