Если вас направляют по медленной ссылке в общедоступном Интернете, ваши единственные возможности - принудительно направить вас вокруг нее. Простейший способ сделать это - попытаться передать файл между двумя конечными точками, одна из которых является "точкой A" (источником данных) и промежуточным сайтом, который географически не расположен совместно с пунктом назначения, "точкой B". ,
Как только вы найдете "точку C", то есть сервер, который не маршрутизируется через медленный интернет-маршрутизатор, с которым вы сталкиваетесь, вы можете настроить VPN между точкой A и точкой C, чтобы трафик "маршрутизировался" вокруг медленный узел.
Если у вас высокая деловая ценность ($$$$$$) или влияние на интернет-провайдера, вы также можете решить эту проблему непосредственно на уровне 3. Тем не менее, L3 - это Интернет-провайдер 1-го уровня, и он не может быть особенно восприимчив к жалобам на качество обслуживания или насыщение сети, поскольку они очень мало могут с этим поделать, если не могут, не хотят или не могут расширить свой пиринг соглашения с нижестоящими или другими провайдерами уровня 1, которые создают конфликт на своем узле.
Так как вы сказали, что соединение «офис-сервер» быстрее, вы можете попробовать настроить VPN на "офисном" сайте с умеренно мощным компьютером (хорошо подойдет двухъядерная система серверного уровня).
О, тоже! Если задержка (от конца к концу) между "точкой A" и "точкой B" очень высока (более 100 мс высока в мире серверов), вам следует убедиться, что вы не используете болтливый сетевой протокол. Samba (также известный как SMB или Windows File Sharing) чрезвычайно болтлив; другие протоколы синхронизации также могут быть болтливыми.
Болтливые протоколы - это протоколы, которые требуют много синхронных «туда-обратно» поездок туда и обратно для передачи данных. Если ваш протокол слишком болтлив, то только задержка может стать препятствием для вашей передачи, независимо от того, насколько быстро способна ссылка.
Чтобы определить, действительно ли болтливость действительно влияет на вашу пропускную способность, вы можете использовать известный тестовый протокол, такой как HTTP, для тестовой передачи. Итак, попробуйте обычный старый HTTP из "точки A" в "точку B" через "медленный" маршрутизатор Level3, и если задержка высока, но пропускная способность все еще хорошая, то вы знаете, что причина, по которой ваша передача медленная, заключается в том, что ваш Протокол слишком болтливый, поэтому вам нужно изменить протокол.
Итак, позвольте мне завершить обсуждение, кратко определив и объяснив три нарушения сети и почему любой из них может быть ответственным за эту проблему:
Задержка - как долго дейтаграмма проходит от вашего конца до другого конца. Вы не можете напрямую улучшить задержку в большинстве случаев, если только один из ваших компьютеров не перегружен настолько, что его сетевой стек, ядро или приложения генерируют значительную дополнительную задержку. Наибольшая задержка в общедоступном Интернете исходит от интернет-маршрутизаторов, а не от вашего компьютера или конечной точки.
Пропускная способность. Пропускная способность - это максимальная пропускная способность самого медленного канала между вашим компьютером и конечной точкой. В большинстве современных сетей пропускная способность не является реальным ограничением, потому что другие сетевые нарушения устанавливаются и замедляют работу сети задолго до того, как пропускная способность станет реальной проблемой.
Потеря пакета - Потеря пакета может увеличить воспринимаемую задержку для надежных дейтаграмм (таких как TCP) и часто является результатом сильно насыщенных каналов, вынужденных отбрасывать ваш пакет из буфера передачи или приема TCP из-за того, что буфер уже переполнен. Кроме того, потеря пакетов может происходить с «чувствительными ко времени» пакетами, как это имеет место почти со всеми пакетами TCP, потому что, если пакет прибывает после крайнего срока, то он отбрасывается. Это происходит, если более крупный пакет TCP фрагментирован на несколько дейтаграмм IP, и протокол TCP на принимающей стороне может только ждать фиксированное время для прибытия всех фрагментов, прежде чем принять решение об отмене приема пакета. Таким образом, потеря пакетов косвенно связана с проблемами насыщения (что является проблемой пропускной способности), а также с проблемами оборудования или сбоями.
Происходящие из фундаментальных сетевых нарушений, это меры, которые вы можете предпринять, чтобы повысить надежность своих программ без изменения фундаментальных нарушений, потому что в большинстве случаев вы почти ничего не можете сделать, чтобы контролировать их:
Первый способ - сделать ваш протокол менее разговорчивым (или, с точки зрения системной интеграции, использовать существующий протокол, который менее болтлив, чем ваше текущее решение). Чем меньше "циклов" требуется для синхронизации данных между конечными точками, тем лучше будет период. Некоторые протоколы могут быть спроектированы так, чтобы требовать переменной частоты синхронизации - если это так, вам следует динамически максимально снизить частоту синхронизации, если вы обнаружите высокую задержку или потерю пакетов. Уменьшение болтливости помогает уменьшить задержку и потерю пакетов, но не проблемы с потолком пропускной способности.
Второе решение состоит в том, чтобы настроить все ваши переходы (те, которые вы непосредственно контролируете на административном / аппаратном уровне) для использования наилучшего доступного алгоритма активного управления очередью (AQM), который в настоящее время является AQM с управляемой задержкой с честной очередью. Это доступно в ядре Linux 3.5 или новее в качестве реализации qdisc fq_codel , и оно динамически уменьшает размер буферов приема и передачи, чтобы уменьшить задержку, которую эти буферы неизменно создают. Это может уменьшить потерю пакетов и помочь справиться с задержкой, используя протокол TCP, потому что ваши фрагментированные пакеты с меньшей вероятностью истекают, если вы минимизируете количество ожидания, которое пакет должен пройти, прежде чем он будет отправлен по каналу связи. Обратите внимание, что это уменьшение имеет значение только в том случае, если узел "насыщен" (т. Е. Если буфер TCP пуст, это не имеет никакого эффекта). Узел насыщается всякий раз, когда скорость записи данных в сетевой сокет превышает скорость передачи восходящей линии связи. Типичный ответ стека TCP на эту ситуацию - увеличение буфера, что на самом деле имеет отрицательный эффект, поскольку увеличивает задержку и вызывает всевозможные проблемы, поэтому fq_codel помогает уменьшить это.
Обе эти меры по смягчению помогают справиться со всеми тремя основными нарушениями работы сети, не обходя неисправный узел и не меняя аппаратное обеспечение и не связываясь с провайдером.
