потеря пакетов на ie1.net.belpak.by

Народ! Кто в последнюю неделю начал замечал трудности с доступом на российский сегмент интернета.
По результатам трассировки наблюдаются нефиговые потери пакетов на каком-то республиканском узле с адресом

93.85.80.50 - ie1.net.belpak.by

У кого наблюдается такой "брак" работы белтелеком ака белпака, отпишитесь пожалуйста и назв. провайдера черканите.
Трассировку можно сделать программой PingPlotter к примеру, вывод будет выглядеть так (красным цветом потери)

точно также, на ie1.net.belpak.by красный частокол на http://www.ru. Даже чаще чем у тебя на скрине

ping - протокол icmp - вообще не показатель работы интернета - этот протокол может иметь низкий приоритет на маршрутизаторе и при высокой нагрузке может отбрасываться, при этом TCP протокол будет нормально работать.

есть такая проблема (
в игре пропажа пакетов - и меня выносят в любом бою, разумеется. та же прога выдала тот же узел - 93.85.80.82 ie1.net.belpak.by
ByFly... Их ТП не видят проблему...

budgerigar:

Daimos:

ping - протокол icmp - вообще не показатель работы интернета - этот протокол может иметь низкий приоритет на маршрутизаторе и при высокой нагрузке может отбрасываться, при этом TCP протокол будет нормально работать.

http://help.ea.com/ru/article/online-ports-for-battlefield-4/
http://eu.battle.net/wow/ru/forum/topic/3313064356
https://ru.wargaming.net/support/Knowledgebase/Article/View/385/1 ... t-proxynat

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

Расскажите что будет c VPN каналами поверх UDP, что будет со Skype или его аналогами.

Интересно же послушать системного администратора, будет рассказ из первых рук.

Или про то, можно ли по-человечески настроить маршрутизаторы на выдачу корректной информации по ICMP, UDP конечным пользователям о состоянии узлов? Чтобы информация от них соответствовала положению дел в сети?

Или предоставлять такой сервис белорусским пользователям по цене в три-четыре раза выше чем у соседей, местным системным администраторам слишком сложно?

Специфика UDP - невозможно узнать, получил ли адресат пакет. Невозможно даже узнать, дошёл пакет до него или потерялся по пути.
Понять это можно только по косвенным признакам:
если протокол требует ответ от сервера. Замечу, что посылать случайного содержания пакет может быть бессмысленно, т.к. сервер может проигнорировать пакет, непохожий на его протокол.

Или вот еще:

Что ж, мы можем сделать это, используя UDP. UDP расшифровывается как “user datagram protocol” (протокол пользовательских датаграмм), и он работает поверх IP (как и TCP), но вместо добавления кучи функциональности он представляет собой лишь небольшую надстройку над IP.

Используя UDP, мы можем отослать пакет по определенному IP адресу (к примеру, 112.140.20.10) и порту (к примеру, 52423), и он будет передаваться от компьютера к компьютеру, пока не достигнет цели (или не потеряется по пути).

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

Протокол UDP не гарантирует доставку данных. На практике большинство пакетов, конечно, доходят, но всегда имеются потери около 1-5%, а иногда бывают периоды времени, в которые пакеты вообще не доходят (помните, что между отправителем и получателем могут находиться тысячи компьютеров, на любом из которых что-то может отказать или сломаться).

Также UDP не гарантирует порядок доставки пакетов. Вы можете отправить пять пакетов по порядку — 1, 2, 3, 4, 5 — а прийти они могут совершенно в другом порядке — к примеру, 3, 1, 2, 5, 4. Опять же, на практике, они скорее всего придут в правильном порядке в большинстве случаев, но полагаться на это нельзя!

Наконец, хоть UDP и ничего особо не добавляет к IP, одну вещь он все-таки гарантирует. Если вы пересылаете пакет, то он либо дойдет полностью, либо не дойдет вообще. Так, если вы пересылаете пакет в 256 байт другому компьютеру, то он не может получить только первые 100 байт от пакета — он обязательно должен получить все 256 байт. Это реально единственная вещь, которую гарантирует протокол UDP — все остальное ложится на ваши плечи.

Для надежности придуман TCP, где устанавливается соединение, идет проверка контрольных сумм, проверка в каком порядке пришли пакеты и т.д. Но из-за этого он не пригоден для систем реального времени (онлайн игры, IPTV, интернет радио и т.д.)

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

Насчет UDP - при такой постановке не совсем понятно. Уникаст, мультикаст? Какой UDP? Вероятно тоже будет отбрасываться часть пакетов, потери будут. Что делать, вовремя модернизировать оборудование, а не ждать до последнего

У меня такая же проблема не знаю что делать помогите провайдер белтелеком-"рекорд 20" оптоволокно