Я создаю Azure VM с SKU Standard_D1_v21в Southeast Asia. Согласноэтот документожидаемая пропускная способность составляет 750 Мбит/с.
Однако я тестирую пропускную способность соединения с моей локальной машины на VM, результат около 3 Мбит/с. Тестовый инструментiPerf3, с VM как iPerf3 server и моей локальной машиной как iPerf3 clent. Никакой другой тяжелой сетевой нагрузки в VM во время теста. Я провел еще один тест черезНТТТКПпоследовал этот результат.
Я понимаю, что реальная пропускная способность будет меньше ожидаемой по нескольким причинам, таким как:
- Соединение является межрегиональным и имеет множество переходов.
- Виртуальные машины в общей инфраструктуре имеют общее ограничение (связь).
- Виртуальная машина развертывается в регионе с наименьшей задержкой (Тест скорости Azure).
Но реальная пропускная способность (3 Мбит/с) намного меньше ожидаемой (750 Мбит/с). Итак, как:
- устранить основные причины? Неправильная конфигурация в VM; или слишком много переходов в межрегиональном соединении; или дросселирование где-то в инфраструктуре?
- как улучшить пропускную способность между локальной машиной и удаленной виртуальной машиной?
решение1
А что если провести несколько совершенно очевидных тестов — такие, которые заставляют меня задуматься, не лучше ли вам задать вопрос суперпользователю, а не на сайте для профессионалов?
- Проверьте пропускную способность на обеих конечных точках и между ними. Используйте тест, который вы получаете из интернета — многие из них запускаются в браузере. Speedtest.net позволяет вам выбрать контрпункт, так что вы можете начать с локального сервера, затем использовать другую сторону (по крайней мере, близко), а затем повесить себя на протяжении всего пути.
По сути: если у вас или другой стороны нет локальной проблемы (что маловероятно при такой смехотворной скорости, как ваша попытка их прикончить), это проблема маршрутизации, и вы НИЧЕГО не можете сделать, кроме двух вещей:
- Обратитесь в службу поддержки вашего интернет-провайдера
- Смените интернет-провайдера.
Маршрутизация — это их область. Они могли испортить какой-то конкретный маршрут, но если нет, ну, ничего не поделаешь, кроме как поискать другого интернет-провайдера.
Ваш тест (как он есть) совершенно бесполезен, потому что он проверяет только A-B, а не наличие локальной проблемы на любой стороне. С моим подходом вы можете изменить контрапункт и посмотреть, есть ли у вашей локальной машины проблемы в определенных направлениях. Может быть, у вас хорошая локальная пропускная способность, но международные соединения перегружены.
Если это сработает — пора проверить используемую ОС. RSS существует не просто так — он увеличивает количество пакетов «в полете», что может потребоваться для длинных пингов.
Кроме этого, вы ничего не МОЖЕТЕ сделать.
решение2
Добро пожаловать на форум.
Проблема здесь в том, что вы не контролируете точки между ними. Поиск этой детализации — это отчасти наука, отчасти искусство, поскольку нет одного действительно хорошего ответа, скорее отчет о результатах по многим факторам.
Правильное определение узкого места подразумевает возможность проверить все точки между каждой стороной и обратно. У вас никогда не будет доступа ко всем из них, но вы можете сделать некоторые выводы и рассмотреть ситуацию со многих углов, чтобы получить более полную картину.
Вы можете исключить такие вещи, как «У вас есть достаточная пропускная способность на вашей стороне?» Это можно сделать, если у вас есть известный сайт с выделенной полосой пропускания для тестирования и известный хороший маршрут между ними, способный поддерживать вашу пропускную способность. Онлайн-тесты скорости могут быть обманчивыми, потому что у вас может быть адекватное соединение, а у НИХ может быть адекватная полоса пропускания для надежного выполнения тестов. Но никто из вас не контролирует то, что происходит между вами и ими. ЕСЛИ вы постоянно получаете хорошие тесты скорости на нескольких тестовых сайтах, то вы можете относительно безопасно исключить, что проблема на вашей стороне, поскольку вы ее контролируете. С другой стороны, конечно, если этот сбой во всем может быть не у вас, это может быть интернет-провайдер вашего интернет-провайдера, кто-то в основной сети где-то, какой-то маршрут перегружает другой, чтобы оставаться в рабочем состоянии, и т. д. В этом случае, если вы можете попросить своего интернет-провайдера вмешаться, но на потребительской линии они бросят вам «Ускорение до», на выделенной деловой линии у вас есть аргумент, но все еще бремя доказательства.
Хотя это и не невозможно, узкое место вряд ли окажется на лазурной стороне, если только у вас нет ограниченного контрактом BW.
Вы можете делать такие вещи, как использование MTRhttps://en.wikipedia.org/wiki/MTR_(программное обеспечение)чтобы получить небольшой обзор, но имейте в виду, что отброшенный ICMP может быть результатом естественной работы систем, поскольку большая часть сетевого оборудования отбрасывает ICMP под нагрузкой, а некоторые просто настроены не отвечать по умолчанию. Так что, хотя это может дать вам больше информации, это не дымящийся пистолет, вы должны понять, как читать и интерпретировать это.
Вы можете посмотреть такие места, как здесьhttps://www.thousandeyes.com/outages/где крупные сбои регистрируются через сенсорные сети по всему миру. Иногда это может дать вам подсказку, особенно в сети AS (основные узлы интернета, говоря простыми словами), если у кого-то есть проблемы, которые напрямую влияют на ваш маршрут.
Чтобы интерпретировать это и определить, какой маршрут является «вашим», вы можете начать с инструментов BGP компании HE здесьhttps://bgp.he.net/вы увидите эффективногдев интернете вы находитесь в смысле маршрутизации. ЕСЛИ вы нажмете на IP, через который вы проходите, чтобы попасть в интернет (обычно известный как ваш публичный IP), оттуда вы увидите что-то вроде этого...
Это то, кем вы являетесь в Интернете (откуда вы пришли), из какой сети вы заходите (объявлено как) и как это входит в «Интернет» (ваш интернет-провайдер)
Его можно отследить от ASN до ASN (номер автономной системы), чтобы увидеть фактический маршрут, который вы используете (на данный момент времени, поскольку он может меняться без предварительного уведомления, чтобы маршруты оставались открытыми), или даже просмотреть его в графическом виде.
Затем вы можете сравнить данные с диаграммой «Тысяча глаз» или с множеством других онлайн-инструментов для составления отчетов BGP, чтобы увидеть, есть ли на этих маршрутах перегрузка или они нестабильны (то растут, то падают) и т. д.
Как правило, это даст вам достаточно информации, чтобы уведомить вас о том, кто может отвечать за ту или иную систему (имейте в виду, что большинству будет все равно, что делать дальше вашего интернет-провайдера), и хотя это может и не привести вас туда, куда вы хотите, это объяснит, почему вы не там, где хотите быть.
В общем, надо думать так: скорость не везде одинакова, некоторые разделы соединены через невероятно быстрые ссылки, некоторые не очень. И когда один из этих больших выходит из строя, многие более мелкие сильно страдают.
Так что же можно с этим сделать? Иногдавы можете обойти это, если вы делаете одноранговые соединения, но вы не гарантируете, что все ваши клиенты, путешествующие по тем же маршрутам, получат одинаковый опыт. Например, у вас может быть веб-сервер там, и вы можете получить надежное соединение с хорошей пропускной способностью к чему-то вроде провайдера VPN, который выходит ближе к вашему удаленному концу и заставляет его выбирать лучший маршрут. Пользователи, идущие на ваш сервер и не делающие того же самого, не получат того же опыта. Есть некоторые сервисы, которые могут сделать это за плату за все это, фактически заставляя ваш сервер отображаться в другом месте, чем он есть на самом деле, и выбирая премиум-маршрут. Возможно, у Cloudflare есть такие сервисы, я никогда ими не пользовался, поэтому мне придется позволить эксперту по Cloudflair высказаться по этому поводу.
Надеюсь, этого будет достаточно, чтобы вы поняли, насколько все это может быть запутанным, а также осознали, что ваш опыт и опыт человека, живущего в другом штате, могут быть совершенно другими.