Насколько расстояние и мс могут повлиять на скорость загрузки?

Рассмотрим A (клиент) и B (сервер), где A выполняет загрузку с B.

Насколько плохая маршрутизация от A до B может повлиять на скорость загрузки?

Трассировка от A к B возвращает путь длиной 10 переходов с задержкой приема-передачи 300 мс. Он также показывает потерю пакетов ~ 10% на четвертом переходе. В нормальных условиях средняя задержка приема-передачи между A и B составляет от 10 мс до 30 мс.
Может ли такое воздействие резко снизить скорость загрузки A или до тех пор, пока обе стороны и маршруты имеют достаточно канала для полной скорости A от B, и наоборот, скорость должна оставаться такой же?
Помимо tracert и ping-анализа от A до B, что еще используется для определения проблемы?

Если вам нужна дополнительная информация, дайте мне знать.

Этот вопрос затрагивает несколько вопросов, относящихся к разным вещам. Я постараюсь ответить на них по порядку, а затем дам более подробное объяснение.

(Слегка перефразируя):

Трассировка от A к B возвращает путь длиной 10 переходов с задержкой приема-передачи 300 мс. Он также показывает потерю пакетов ~ 10% на четвертом переходе. В нормальных условиях средняя задержка приема-передачи между A и B составляет от 10 мс до 30 мс.

Рассматривая эти вопросы по порядку:

Количество переходов в пути практически не влияет на эффективную пропускную способность. Важны сквозная задержка, средняя потеря пакетов и настройки в стеках TCP в A и B, особенно в отношении работы с окнами TCP. (Подробнее см. Ниже.)
Потеря 10% пакетов на четвертом шаге в трассировке вряд ли будет признаком проблем со сквозным соединением. Многие маршрутизаторы реализуют такие функции, как контроль уровня управления или Ограничение скорости ICMP (в частности, создание ICMP-сообщений «Срок действия TTL истек в передаче», на которые опирается traceroute). Единственный надежный способ измерить потерю пакетов - это проверить счетчики в вашем стеке TCP или захватить пакеты из вашего фактического потока данных с помощью tcpdump / Wireshark и изучить захват с помощью анализатора протокола.
Очень редко задержка в оба конца до определенного интернет-адреса меняется с 10-30 мс до 300 мс. Такие изменения, скорее всего, будут результатом катастрофического изменения политики маршрутизации у провайдера и, скорее всего, будут исправлены как можно скорее. Возможно, единственный случай, когда я вижу, что это происходит нормально, - это сайт, который имеет одно физическое (Ethernet, DSL и т. Д.) Соединение со своим интернет-провайдером со спутниковой резервной копией.

Что касается влияния задержки на скорость загрузки, многие реализации TCP настроены на использование размера окна приема 64 Кбайт. Когда у вас есть соединение с высокой задержкой между двумя хостами (точнее, высокая продукт задержки полосы пропускания, этот размер окна часто может ограничивать вашу эффективную пропускную способность, поскольку TCP прекратит передачу буферизованных данных до тех пор, пока не начнет получать ACK для уже отправленных данных с дальнего конца.

РЕДАКТИРОВАТЬ: В зависимости от того, как вы настроили pingplotter, он может не предоставлять вам точное представление о потерях на вашем соединении. Если pingplotter использует ICMP, возможно, что сети будут отбрасывать / понижать приоритет этого трафика во время перегрузки, поскольку он не считается «пользовательским трафиком». Кроме того, любые данные о потерях на промежуточных переходах следует рассматривать как подозрительные по причинам, указанным выше.

Если возможно, было бы интересно запустить захват пакетов на вашем хосте (это можно сделать с помощью Wireshark например), и посмотреть на анализ в Wireshark, относящийся к фактическим TCP-разговорам, которые выполняют ваши приложения.

Да, высокая задержка сетевого соединения, безусловно, может повлиять на скорость загрузки (влияние будет меньше, если окно TCP будет достаточно большим, чтобы источник мог отправить несколько пакетов, не дожидаясь подтверждения каждого из них). И любая значительная потеря пакета будет иметь катастрофическое влияние на производительность, так как каждый раз, когда пакет теряется, загрузка фактически останавливается на время таймаута повторной передачи TCP.