Кажется очевидным, что более быстрое соединение снижает задержку ... Но мне интересно: я работаю удаленно на хосте на другом конце света - свет может перемещаться только так быстро (1 фут в наносекунду), и у нас обоих есть широкополосные соединения при загрузке свыше 1000 кбит / с и загрузке 10 000 кбит / с:
Будет ли соединение с более высокой пропускной способностью уменьшать время, необходимое для проверки связи? Поскольку данных очень мало, как может помочь более быстрое соединение? В настоящее время пинг занимает 450 мс, есть ли способ его улучшить?
Во-первых, пропускная способность - это не то же самое, что задержка. Более быстрое соединение не обязательно уменьшит вашу задержку. 450 мс действительно кажется немного медленным, но не так уж и далеко, если вы путешествуете по полпути через мир. В качестве основы для пересечения США высокоскоростного канала с низкой задержкой потребуется ~ 70-80 мс. Возможно, вам удастся добиться немного меньшей задержки, сменив провайдера, если у него более оптимальный путь пиринга. но я ничего не могу обещать.
«Более быстрое» соединение (как вы его называете) не снижает задержку. «Более быстрое» соединение позволяет передавать больше данных по сети за определенный период времени.
Пропускная способность - это мера емкости.
Задержка - это мера задержки.
РЕДАКТИРОВАТЬ
Вот пример разницы между пропускной способностью и задержкой: представьте себе 2 интернет-соединения, одно 10 Мбит / с, а другое 1 Мбит / с. Оба имеют задержку 50 мс. Теперь представьте, что я отправляю нажатия клавиш на удаленный терминал на другом конце этих соединений. Для простоты предположим, что каждое нажатие клавиши потребляет 1 Мбит / с полосы пропускания. При соединении 10 Мбит / с я могу отправлять буквы A, B, C, D, E, F, G, H, I, J одновременно, поэтому все они прибывают на удаленный терминал через 50 мсек и отображаются эхом. экран ... заодно. Теперь при подключении со скоростью 1 Мбит / с каждое нажатие клавиши отправляется независимо, поскольку каждое нажатие клавиши потребляет всю доступную полосу пропускания. Итак, буква A отправляется, а затем через 50 мс она принимается удаленным терминалом и отображается эхом на экране, за которой следует буква B, после чего через 50 мс следует буква C ... вплоть до буквы J. Это займет 500 мс для всех десяти букв, которые должны быть получены на удаленном терминале и отображены на экране. Скорость соединения 10 Мбит / с? Нет, это не так. Задержка составляет 50 мс, как и при подключении со скоростью 1 Мбит / с. Он появляется быстрее из-за того, что имеет более высокую пропускную способность (пропускную способность) и больше данных может быть передано по сети за один раз. В этом разница между пропускной способностью (емкостью) и задержкой (задержкой). Строго говоря, «более быстрое» соединение (в том смысле, в котором вы его называете) не уменьшит задержку.
Подключения измеряются двумя основными факторами: задержкой и пропускной способностью. Не существует таких понятий, как «высокая скорость» или «быстрее». Это маркетинговый двусмысленность, бессмысленная в контексте профессионально управляемых связей.
Я хочу сказать здесь о пинге.
Обычно трафик ICMP не имеет высокого приоритета. Таким образом, измерение сетевой задержки / задержки не будет точным с использованием ping или любого другого трафика на основе icmp.
Задержку между двумя точками можно рассчитать по формуле:
Total delay = transmission delay + propagation delay + processing delay
Задержка передачи - это время, когда биты пакета передаются по сети. Задержка распространения связана со средой и является временем достижения пункта назначения. Задержка обработки связана с принимающими и отправляющими машинами / маршрутизаторами.
Часто будет, да. Но это не одно и то же, и они не связаны напрямую. Просто так случается, что обычно соединения с большей пропускной способностью также имеют меньшую задержку из-за используемой технологии.
Но это не всегда так. Рассмотрим быстрый способ передачи больших объемов данных: заполнить 12 жестких дисков емкостью 2 ТБ данными и отправить их курьером. Скорость передачи данных ОЧЕНЬ высокая (более 2000 Мбит / с, учитывая, что вы можете отправить 24 ТБ за 24 часа). Задержка также очень высока (24 часа). У коммутируемого соединения гораздо меньшая задержка, но для отправки 24 ТБ по коммутируемому соединению потребуются годы.
Прямое равенство этих двух вещей - не лучшая идея. Если вам конкретно нужна меньшая задержка, вы должны спросить об этом конкретно, а не делать покупки по пропускной способности.
Единственное реальное решение для уменьшения задержки - это сократить количество переходов между двумя рассматриваемыми хостами.
Если вы являетесь достаточно крупным корпоративным клиентом, вы должны иметь возможность начать диалог со своими поставщиками телекоммуникационных услуг на обоих концах о выборе более короткого (возможно, более дорогостоящего) IP-маршрута между двумя сайтами.
Вы много постулируете, не собирая фактов. Лучше всего попытаться определить источник высокой задержки: с чего она начинается? Тогда можно попробовать ответить на вопрос: как это исправить?
Запустите traceroute или, еще лучше, mtr (mytraceroute). Если у вас Windows, вы можете использовать winmtr. Пингплоттер тоже хороший инструмент для этого.
Найдите, где начинается ваша высокая задержка, а затем работайте над ее устранением. Расширение полосы пропускания для решения вашей проблемы - не решение.
Более высокая пропускная способность не поможет, если объемные данные не заглушают интерактивные данные. Если обе стороны использовали оптоволокно вместо xDSL / Cable / Wireless, это могло бы сократить ваш RTT на 20-80 мс.
Выполните тест ping, используя pingtest.net чтобы определить качество каждой ссылки. Задержка важна, но / jitter / также может иметь огромное значение. Я бы предпочел более медленное (3 Мбит / с) соединение без джиттера, чем более быстрое (например, 15 Мбит / с) соединение с джиттером.
Для TCP-соединений (например, SSH, telnet и т. Д.) Может помочь некоторая настройка TCP.
Вы также можете использовать ускоритель TCP; есть коммерческие, но пепсал уже может иметь значение.
Возможно, проблема в ваших брандмауэрах / маршрутизаторах ...
единственный способ ДЕЙСТВИТЕЛЬНО сказать, где находится неисправность, - это выполнить traceroute, как было сказано выше,
На этот вопрос есть много разных ответов, и правильный ответ (на мой взгляд) - «Это зависит от обстоятельств».
Не имеет значения, есть ли у вас соединение со скоростью 1 Гбит / с, если оно насыщено. TCP (и другие протоколы) полагаются на проверки передачи, которые в 99% случаев не имеют правильного приоритета с помощью QoS или аналогичных технологий.
Симметричные (SDSL, оптоволокно и т. Д.) Линии обычно лучше подходят для операций с малой задержкой, поскольку они не разделяют RX с TX (это означает, что TCP ACK, ответы ICMP и т. Д. Не будут затруднены, если вы загружаете на полную мощность). Он по-прежнему требует QoS, чтобы гарантировать трафик для чувствительных приложений (в частности, VoIP).
Удивительно, но количество совпадений (и качество совпадений) в Google, когда дело доходит до расстановки приоритетов TCP ACK, довольно невелико ... поговорите с любым сетевым экспертом, и он поймет, зачем вам это нужно.
Да, но ненамного.
Более высокая пропускная способность будет означать, что пакету потребуется меньше времени для полной загрузки, прежде чем другой пакет сможет передать данные, и время, необходимое для загрузки всего пакета, также является фактором, но на самом деле это только добавит 10-20 мс в худшем случае. случаи.
Другой возможной причиной задержки является беспроводная передача, почти каждая форма беспроводной связи с множественным доступом будет иметь большое значение для задержки, будь то обычная домашняя беспроводная сеть или мобильная беспроводная связь, поскольку беспроводная карта должна ждать, пока все закончат передачу данных, прежде чем она сможет отправить свои собственные данные. Чем больше пользователей передают в беспроводной системе, тем медленнее скорость И задержка (опять же, не намного, в основном из-за ожидания, пока он не будет очищен для отправки)
Фактором номер один является время, которое пакет данных потратит на сортировку на маршрутизаторах и другой инфраструктуре WAN.
Теоретически минимальное время, необходимое пакету данных для путешествия по всему миру, составляет около 70 мс, это когда пакет перемещается со скоростью света.
Спросите вокруг и узнайте, испытывают ли другие люди с более быстрыми подключениями и другие интернет-провайдеры такую же задержку, вполне возможно, что это вызвано интернет-провайдером или соединением, но это очень маловероятно.
Пропускная способность и задержка разные, но не полностью связаны. Хотя в основном это правда, все не черно-белое. Между ними много оттенков серого.
Это правда, что большая пропускная способность не обязательно означает меньшие задержки и не обязательно означает такие же или более высокие задержки.
Мы должны помнить, что это зависит от инфраструктуры, которая состоит из сетевых устройств и физических носителей на пути от нашего хоста до места назначения.
Один интернет-провайдер может отдавать приоритет соединениям с низкой / высокой пропускной способностью и предоставлять больше аппаратных и программных преимуществ тому или другому, что приведет к разнице в задержке.
И в духе различных примеров, которые были здесь приведены, да - лучше взять грузовик с 20 дисками той же емкости, чем тот же грузовик только с одним из этих 20 дисков. Однако - как насчет веса диска? Больше дисков означает больше топлива и более медленное ускорение. Но что, если я поменяю двигатель грузовика?
Короче говоря, полоса пропускания и задержка разные, но не полностью несвязанные.