Вопросы пинга, варпа, лага и привязка к теории

Вопросы пинга, варпа, лага и привязка к теории

Предисловие, которое вполне может сойти за disclaimer.
Прежде всего давайте договоримся о чем пойдет и о чем НЕ пойдет речь ниже, чтобы избежать неясностей в дальнейшем.

Топик 1. Речь пойдет о том, почему нельзя считать пингование фрихоста (при помощи ICMP PING) с компьютера юзера (вирпила) однозначным доказательством стабильности соединения между компом данного вирпила и фрихостом.

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

Ни о чем более, кроме как о темах, указанных в топиках 1 и 2 речи вести не предполагается (потому просьба не искать в нижеизложенном глобпльной или частичной теории Интернета или теорий сетевых протоколов).
Теперь собственно дисклаймеры.
Прежде всего, слова, обращенные к моим коллегам ? специалистам IT. Все что я буду излагать ниже предназначено в основном для мало посвященных, или не очень хорошо посвященных, или посвященных, но не понявших еще до конца того, что является для нас с вами средством зарабатывания на жизнь. Потому, я прошу вас, уважаемые коллеги, принять во внимание, что излагать теорию ниже мне придется достаточно простым языком, прибегая в большинстве случаев к сокращениям и обобщениям, без которых данный материал (и без того обещающий быть не маленьким) превратится в бесконечный. Я призываю вас понять, что я буду заниматься тут неблагодарным делом популяризаторства (не очень приветствуемого мной, как и вами). Но при этом я с удовольствием (в рамках своего и вашего времени) готов дискутировать с вами на принятом между специалистами уровне и в случае необходимости вносить изменения в данный материал.

Теперь дисклаймер для тех, кому материал собственно предназначен. Большая просьба не воспринимать нижеизложенное как учебный материал или как «истину в последней инстанции, застывшую во времени». Воспринимайте это как разбор частного случая возможных проблем виртуальных соединений между вашими компьютерами и сервером фрихоста. Если вы хотите в полном объеме понять тематику и понять, почему я настаиваю на «частности» разбираемого случая, то советую воспользоваться специализированной литературой. Я особенно настаиваю на том, что материал является актуальным на сегодняшнем уровне развития сетевых технологий и может оказаться совсем никчемным через достаточно небольшой промежуток времени, ибо Интернет, а вместе с ним и сетевые технологии идут вперед довольно быстро.

Общий дисклаймер. При изложении материала мне придется воспользоваться техническими терминами и выдержками из специальной литературы. В меру своего умения я буду объяснять значение терминологии на русском языке. Я буду пользоваться цитатами из литературы на английском языке и прошу понять это не как желание кому-то запудрить мозги, а как мою уверенность в том, что лучше чем сказано авторами, мне сказать не удастся. При этом я готов буду объяснить в случае непонимания о чем идет речь (само-собой в рамках собственного понимания тематики). Каждую цитату я буду снабжать ссылкой с указанием откуда она взята.
Последнее ? являсь человеком, работающем в мире cisco, я буду пользоваться литературой cisco. Специалисты поймут о чем я, но хочется, чтобы данный материал не воспринимался как «повод к битве» между cisco и non-cisco. В конце-концов теория, на которую я буду опираться базово едина.

TOPIC 1. Почему нельзя считать пингование фрихоста (при помощи ICMP PING) с компьютера юзера (вирпила) однозначным доказательством стабильности соединения между компом данного вирпила и фрихостом.

Наверное, не будет большой ошибкой сказать, что среди пользователей Интернет общепринятым методом проверки доступности удаленного хоста является пинг. Пинг с том виде, в каком он реализован в рамках операционной системы MS Windows является программой, использующей механизм протокола ICMP, являющегося протоколом Network layer (по классификации модели OSI).



Коротко и очень популярно о том, для чего служит протокол ICMP ? для контролирования и менеджирования (проверки работоспособности) протокола IP.

Более профессиональная формулировка ? ICMP, described in RFC 792, specifies a variety of messages whose common purpose is to manage internetwork. ICMP messages may be classified as either error messages or query and responses. (Chapter 2, p.73. Routing TCP/IP vol.1. CCIE Professional Deployment. Jeff Doyle)

RFC 792 дает такое описание назначения ICMP ? Occasionally, a gateway or destination host will communicate with a source host, for example, to report an error in datagram processing. For such purposes this protocol, The Internet Control Message Protocol (ICMP), is used. ICMP uses the basic support of IP as if it were a higher level protocol, however, ICMP is actually an integral part of IP, and must be implemented by every IP module.

Существенно упрощая механизм работы ICMP можно сказать так ? когда на source хосте (компьютере юзера) запущен пинг другого хоста (destination - удаленного компьютера), пакеты, сгенерированные протоколом ICMP инкапсулируются в data link layer (фреймы) на source хосте и отправляются на destination через каналы интернет. Destination хост, получив пакет ICMP отвечает на каждый пакет определенным образом, генерируя пакет ответа, и этот пакет ответа отправляется destination хостом обратно на source хост. Это может быть пакет ECHO, при котором source юзер Windows видит:

Reply from 192.168.0.2: bytes=32 time<1ms TTL=128
Reply from 192.168.0.2: bytes=32 time<1ms TTL=128
Reply from 192.168.0.2: bytes=32 time<1ms TTL=128
Reply from 192.168.0.2: bytes=32 time<1ms TTL=128

Это также может быть пакет Host Unreachable, при этом source юзер Windows видит:
Reply from (router): destination host unreachable
Reply from (router): destination host unreachable
Reply from (router): destination host unreachable
Reply from (router): destination host unreachable

Или это может быть пакет TIME EXCEEDED, с соответствующим изображением у source юзера в Windows:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Я намеренно не углубляюсь в дебри роутинга и не заостряю внимание на том, destination хост ли, роутер ли и какой именно роутер возвращает на source компьютер ответ ICMP. Для понимания сути это не столь важно.

Важно другое. Если понятно для чего служит ICMP - взгляните еще раз на картинку с моделью OSI и запомните на каком Layer находится этот протокол.

Теперь вкратце что означает модель OSI (Open System Interconnection reference model).
Глобальное назначение этой модели ? обеспечить стандарты передачи данных, позволяющие коммуникацию между собой оборудования различных производителей. Модель эта является базовой виртуальной моделью, отображающей систему передачи данных с одного компьютера на другой.

Опять таки, без углубления в дебри, рассмотрим применение модели OSI к нашему случаю.

Вот (при понимании процесса инкапсуляции как, процесса идущего от верхнего лейера к нижнему) как выглядит процесс передачи данных с одного компьютера на другой, согласно OSI:



Отправленные application (например FTP программой) с source компьютера данные разбиваются на сегменты на 4 layer?е, затем на пакеты на 3-м, потом на фреймы на втором и на биты на первом. Этот процесс носит название инкапсуляции. В виде битов информация передается через Интернет на destination компьютер и на нем происходит процесс восстановления данных от первого лейера до седьмого (в нашем примере) ? этот процесс носит название деинкапсуляции.

Теперь рассмотрим что просходит при пинге с source хоста другого (destination) хоста.
Поскольку ICMP существует на Network Layer, то source компьютер отправит на destination компьютер пакеты (принадлежащие network layer). Пакеты будут инкапсулированы в фреймы и биты и отправлены, а затем деинкапсулированы на destination компьютере ДО NETWORK LAYER. Ответ в виде ICMP reply будет отправлен с destination компьютера в обратном направлении тоже с Network Layer и будет получен source компьютером и деинкапсулирован до Network Layer .

Если это понятно, то перейдем к сути вопроса. Почему же ICMP PING в конкретном рассматриваемом случае с фрихостом и юзером не может считаться надежным доказательством стабильности соединения?

Причин две. Основных, разумеется. И в популярном изложении, разумеется.

Первая причина ? протокол связи WB ? это протокол TCP, протокол, принадлежащий Transport Layer. То есть, клиент, установленный на вашем компьютере начинает инкапсуляцию данных обмена с фрихостом с Transport Layer. TCP сегменты инкапсулируются в IP пакеты, далее во фреймы, биты ? и передаются. ICMP же, которым вы привыкли фрихост пинговать, к данному процессу имеет достаточно виртуальное отошение ? он никак не участвует в процессе обмена данными между вашим клиентом и фрихостом. Он просто существует на том же уровне, на каком существует IP.

То есть, пинг с вашего компьютера на компьютер, где установлен фрихост и процесс обмена данными между вашим клиентом и сервером фрихоста ? процессы параллельные и мало пересекающиеся. Надеюсь теперь, исходя из теории TCP/IP и модели OSI понятно, что пинг с вашего компьютера и ответы типа

Reply from 192.168.0.2: bytes=32 time<1ms TTL=128

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

Что касается параметра time и значения возле него в ms (миллисекундах) ? то это, упрощенно говоря, время, за которое на вашем компьютере был получен назад от фрихоста ответ ICMP (ECHO REPLY). Если вы правильно поняли теорию OSI модели и правильно поняли где в этой модели существует ICMP, то вам не составит труда понять, насколько относительно ICMP PING показывает действительное состояние (стабильность) виртуального линка от вашего компьютера до фрихоста. Для того, чтобы убедиться в справедливости этого утверждения, рекомендую проделать такую процедуру:
1. Пропинговать фрихост из ваших Windows и запомнить значение ms
2. Запустить клиента WB и дать команду .pingtest ? и сравнить полученные данные с данными от команды пинг.

Вот что получилось у меня на тестовом модемном соединении:
Из системы:
#badboy>ping 195.208.34.5

Pinging 195.208.34.5 with 32 bytes of data:

Reply from 195.208.34.5: bytes=32 time=234ms TTL=238
Reply from 195.208.34.5: bytes=32 time=206ms TTL=238
Reply from 195.208.34.5: bytes=32 time=193ms TTL=238
Reply from 195.208.34.5: bytes=32 time=216ms TTL=238

Ping statistics for 195.208.34.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 193ms, Maximum = 234ms, Average = 212ms

Из WB клиента:
463 ms TCP Round Trip

Проверяйте у себя

Теперь можно поговорить о второй причине .

Не знаю всем ли понятно, почему ответ от ваших «форточек» (здесь говорим только о OS Windows 95/98/2000/XP) содержит только четыре пинга by default. Именно четыре, а не 10 и не 1. Ответ простой ? потому что это стандарт. И если в «форточках» задать команду ping без дополнительных параметров ? будет получен ответ от четирех посланных пакетов ICMP. Совсем уж грубо говоря, дефолтной командой пинг вы проверите соединение вашего компьютера с фрихостом в течение максимально 4 секунд. Тем, кто еще не понял о чем речь и обладает терпением и любовью к экспериментам я советую задать пинг со сделающими параметрами:

Ping ?t 195.208.34.5 и пойти попить кофе.... минут так на 30. А потом вернуться, остановить все это безобразие CTRL-C и посмотреть значение в графе Lost = 0 (0% loss). Вместо 0 у вас там вполне может оказаться иная цифра, которая вас несомненно позабавит

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

Надеюсь, что вышеприведенное популярное изложение всем понятно... и многое теперь встало на свои места. Если что-то непонятно ? задавайте вопросы. Будем вместе отвечать. Если заинтересовались вопросом глубже и готовы постигнуть все тонкости, о которых за неимением времени тут речь не шла ? читайте документацию по TCP/IP routing, теории TCP/IP и OSI model.

Теперь перейдем к более сложному вопросу ? Topic 2.

 

Вопросы пинга, варпа, лага и привязка к теории (продолжение)

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

Для начала дадим ответ на этот вопрос. НЕЛЬЗЯ быть уверенным, если вы не находитесь в одном локальном сегменте (одном Ethernet) с фрихостом.

Для тех, кто не понял утверждения и спешит задать вопрос ? а если у меня канал 100 Mb на M-9? ? повторяю ? НЕЛЬЗЯ быть уверенным.
Для тех, кто совсем только что из бронепоезда и говорит ? я три часа гонял пинг со всего хоста до фрихоста и получил Lost = 0 (0% loss) ? наверняка я могу быть уверенным ? я отвечу - НЕЛЬЗЯ быть уверенным .

Для того, чтобы получить ответ, почему нельзя быть уверенным, вспомним, что WB работает по протоколу TCP и разберемся cо следующим (насколько позволяет время):
1. что же такое TCP и как он работает
2. базовые принципы коммуникации в Интернете
3. коснемся темы протоколов маршрутизации.

Сами по себе эти три темы представляют достаточно сложный и объемный материал для изучения, на который можно убить тонну времени. Мы же пробежимся по ним «галопом по европам», но, надеюсь, что некоторое впечатление можно будет составить. А вместе с впечатлением, вполне не исключено, что многие будут десять раз думать, прежде чем кричать другому вирпилу на 100-м канале ? you warp ? reconnect.

Итак, TCP (Transmission Control Protocol) ? это протокол четвертого (Network) лейера (слоя) модели OSI. Для тех, кто не совсем понимает что такое протокол ? предлагаю не совсем точный, но доступный для понимания синоним ? механизм. В случае с TCP ? механизм передачи данных.

Для того, кто захочет познакомиться с этим протоколом и его причиндалами поближе, очень рекомендую упоминавшуюся мной уже книжку Routing TCP/IP vol.1. CCIE Professional Deployment. Jeff Doyle и RFC 793 к ней в придачу.

Общие характеристики протокола TCP таковы - provides excellent and flexible ways to create reliable, well-flowing, low-error network communications.

Дополнительная характеристика TCP из Jeff Doyle (p.78-79):

TCP provides applications with a reliable, connection-oriented service. In other words, TCP provides the appearance of a point-to-point connection. Point-to-point connections have two characteristics:
- They have only one path to the destination. A packet entering one end of the connection cannot become lost, because the only place to go is the other end.
- Packets arrive in the same order in which they are sent.

Итак, WB работает по TCP и уж если ваш клиент послал данные хосту, то можно быть уверенным, что эти данные будут доставлены, причем доставлены именно в таком порядке, в котором они посылались. Расшифруем подробно последнюю фразу ? после того, как сегменты были разбиты на пакеты, каждому пакету был присвоем порядковый номер, а затем пакеты посланы на Layer 3 в порядке очередности ? 1-2-3-4-5. Это необходимо для того, чтобы хост получатель знал ? как же полученные пакеты расположить, чтобы получилось именно то, что хост отправитель отправил.

Перейдем на практику (опять упрощенно, разумеется). Ваш самолет переместился по взлетной полосе на некое расстояние. Данные, содержащие координатные точки перемещения упаковываются в серию пакетов с порядковыми номерами и отправляются с вашего клиента на фрихост. Фрихост получит серию битов, деинкапсулирует их до пакетов, поставит пакеты в нужном порядке и получит координаты перемещения. Теперь хост готов послать эти координаты другим клиентам ? вашему соседу по полосе, например, который получив эти данные увидит у себя на экране как ваш самолет перемещается по полосе.

Теперь остановимся на механизме. Обратите внимание на выделенное жирным шрифтом в предыдущем абзаце. У кого-то может возникнуть вопрос ? а зачем это фрихосту заботиться еще о постановке пакетов в нужном порядке, они ведь и так прибывают в том порядке, в котором были отосланы ? это сказано выше в характеристиках TCP.

Вот тут и кроется первый подводный камень. Характеристики TCP ? это одно, а реалии Интернета ? это несколько другое. Совсеменный Интернет (то есть сообщество различных сетей) не может гарантировать, что пакеты отправленные от одного хоста к другому через ряд различных автономных систем (AS), принадлежащих разным провайдерам, будут доставлены по одним каналам и в том порядке, в каком были отправлены.

Давайте рассмотрим на примере:



В указаном примере вирпил подсоединяется к своему провайдеру через модем. Но фрихост находится в сети другого провайдера и из сети провайдера вирпила существует два пути до сети провайдера фрихоста ? через сеть провайдера 1 или через сеть провайдера 2.

Так вот, реалии современного Интернета таковы, что провайдер вирпила в 99.99999% не даст вирпилу никаких обязательств и обещаний, по какому из двух возможных каналов трафик от вирпила пойдет до фрихоста. Кстати, это касается не только тех вирпилов, которые пользуются модемными соединиями, но и тех, кто сидит из офиса по выделенкам. Особо недоверчивые могут попробовать позвонить своему провайдеру и попросить его прогаранитировать всегда одинаковый маршрут от своего хоста до фрихоста и потом рассказать народу, что ответил провайдер
Итак, примем за аксиому, что трафик может пойти как по первому, так и по второму каналу. Причем с большой степенью вероятности он может пойти и по двум каналам сразу. То есть, например, так - пакет номер 1 будет отправле по каналу 1, пакет номер два ? по каналу 2, 3 и 4 по каналу 1, 5-6-7 ? по каналу 2. По какому принципу провайдет определяет какой пакет по какому каналу слать ? мы сейчас рассматривать не будем. Просто поверьте на слово, описанная ситуация ? не исключение, а правило в современном Интернете.

Ну и что, скажете вы, пусть они были отправлены по разным каналам. Но ведь отправлены были по порядку! Что им мешает прибыть по порядку? Вот тут и есть загвоздка ? много чего им может помешать. Например, перегруженный роутер у одного провайдера, на котором образовалась очередь из пакетов, ожидающих отправки. Или, еще проще ? представим себе, что вместо сети провайдера 1 мы имеем две последовательно соединные сети ? провайдера 1 и провайдера 3.



Если даже принять за основание, что каналы у всех провайдеров одинаковые по пропускной способности, то пакеты, отправленные через провайдера 2 доберутся до фрихоста с высокой степенью вероятности раньше чем пакеты, отправленные через провайдеров 1 и 3.

А теперь представляем себе картину: комп вирпила отправляет пакеты как 1-2-3-4-5-6-7, провайдер вирпила отправляет пакеты 1 через провайдера 2, 2 через провайдера 1, 3-4, через провайдера 1, 5-6 через провайдера 2, 7 через провайдера 1. Что в результате, вполне возможно, получит фрихост? 1-3-4-2-5-6-7.

Теперь возвратимся к теории TCP, который на фрихосте должен расставить получаемые от вирпила пакеты в том порядке, в каком они были отправлены. TCP получит пакет 1 и следом за ним сразу 3 и 4. Хороший вопрос, что сделает TCP?

Ответ (в сильно упрощенном виде) элементаный. Он будет ждать. Ждать, пока к нему приедет пакет 2.

Ответ более приближенный к реальности - в зависимости от реализации TCP для каждой конкретной программы - TCP может и не ждать. А может, например, увидев, что пакет 2 не получен попросту задержит все полученные не по порядку пакеты и запросит хост вирпила о получении пакета 2. Хост вирпила остановит передачу, вернется к пакету 2, пошлет его, дождется от фрихоста подтверждения получения пакета 2 и только после этого продолжит передачу пакетов.... Теперь представим себе, что картина повторилась и часть пакетов пошла через провайдера 1, а часть через провайдера 2... а теперь представим, что в пересылаемых пакетах содержалась информация о перемещении вашего самолета по полосе. Теперь попытайтесь додумать сами, как в глазах вашего соседа по полосе будет выглядеть перемещение вашего самолета.

Наглядно, не правда ли? А теперь самое вкусное ? мы рассмотрели всего ОДИН из возможных проблемных вариантов передачи пакетов по TCP. А вариантов этих, поверьте, существует очень много.

Теперь представим, что подобная каша с пакетами произошла в момент вашей стрельбы по самолету противника и в посылаемых пакетах содержаться ваши «пулевые пинги». Включайте серое вещество в голове и представляйте себе что будет. Представили?

А теперь представьте себе, что «в пути» от вашего клиента до сервера задержался не ОДИН пакет, а десяток. Представили? Ну как, понятна первая часть описания того, что такое лаг? Или варп?

Если понятна ? идем дальше. Берем случай, когда нету от вашей выделенки двух каналов до фрихоста. А есть один. Опустим причины, скажем только, что такое тоже может быть ? таковы реалии отношения между независимыми провайдерами в интернете.

Итак:



Между Автономными Системами (сетями) провайдеров запущен протокол BGP ? Border Gateway Protocol, занимающийся маршрутизацией трафика от отдной AS до другой. Все бы здорово, все бы прекрасно. Дорожка от вирпила, до фрихоста одна. Пакеты идут в нужном порядке. Сидит себе вирпил и наслаждается стабильным соединением. И тут вдруг... ну скажем к роутеру в сети провайдера 3 получил доступ «великий специалист». И взял, да и перезагрузил этот роутер. Как там будут дела у вирпила со стабильным коннектом до хоста на время, пока роутер поднимается? Правильно.... хреново будут у него дела.

Впрочем, вероятность получения ламером доступа к core роутеру, занимающемуся маршрутизацией BGP ? исчезающе мала. Это я могу заявить с высокой степенью вероятности.

Зато, если вам будет не лень заглянуть в литературу о принципах работы BGP, то вы найдете там то, что, например, от одного до нескольких раз в сутки BGP роутер получает обновление таблиц маршрутизации от своих «соседей» - роутеров других автономных систем. Таблицы маршрутизации помогают роутеру разобраться куда какой трафик отправлять. Сами по себе таблицы никак на коннект вирпила повлять не способны, но вот время, которое роутер, получив обновленные таблицы, потратит на их упорядочивание ? вот это серьезный момент. В зависимости от типа роутера, памяти у этого роутера и величины полученной информации может случиться (и случается весьма часто) то, что называется «перестройкой таблиц маршрутизации». И в момент такой перестройки роутеру может быть совсем не до вашего трафика. Он занят. Он строит. И трафик ваш дропнет попросту. А заботливый TCP попросит ваш хост трафик перезаслать. А роутер занят. И опять дропнет. И так пока он таблице не перестроит. А потом, когда в AS1 перестройка закончилась, началась перестройка таблиц, например в AS3. Так что у нас там с устойчивым коннектом?

Ну и на закуску рассмотрим сложный, но совершенно реальный вариант.



В сети каждого провайдера на этой схеме существуют по два протокола. Один ? BGP ? для связи с соседними провайдерами. А другой ? IGP (internal gateway protocol ? так называется группа протоколов, применяемых для маршрутизации внутри одной автономной системы). И вот в нашем варианте у каждого провайдера IGP свой. Каждый провайдер поставил редистрибьюцию из IGP в BGP. Но теперь представим себе, что в сети провайдера 1 произошел сбой. Неважно от чего, просто произошел. RIP ? старый, хотя и до сих пор применяемый протокол. Но отличается он, упрощенно говоря, долгим временем восстановления потерянного маршрута ? до 30 секунд. Что происходит с трафиком, который идет через AS провайдера 1 в этот момент? Правильно ? трафик не идет. У OSPF, в сети провайдера вирпила, время восстановления маршрута не в пример меньше ? доли секунд. Потому единократная потеря маршрута не будет так заметна. Но в результате не очень правильной имплементации OSPF может случиться такая беда ? какой-то из роутеров будет нестабилен. И будет то терять, то ставить маршруты в таблицу, чем окажет влияние на все роутеры AS. Вот это и будет еще одним примером причин варпа или лага.

И самое забавное, что в случаях проблем с маршрутизацие «ширина» канала, по которому вирпил подключен к провайдеру ? ну совершенно ни на что не влияет. Ибо проблемы не в этом канале. Проблемы у провайдера.

Это, пожалуй, все. В процессе дискуссии в материал, думаю, будут вноситься дополнения и уточнения.

Готов выслушать вопросы.

 

Tnx, внушаить! Особенно понравились глупые роутеры которым таблицы важнее трафика

 

Да какие тут могут быть вопросы... Все на мой взгляд подробно и правильно...
Прикола ради попробовал Ping ?t 195.208.34.5
Средний результат около 30, потерь нет. Но иногда, прыжки до 200-300(примерно раз в минуту) Это если учесть, что я напрямую сижу на канале РОСТЕЛЕКОМА. Так что... Делаем выводы

 

Re: Вопросы пинга, варпа, лага и привязка к теории (продолжение)

А что, ожидается дискуссия?
WTG Badboy.
Вот вроде знаю как работает TCP/IP. Но ведь в голове не держишь постоянно, например, тот факт, что пакетики не всегда по очереди прибегают.. Вот, освежил этот факт в памяти. Сразу стало удивительно (опять - я и раньше всегда удивлялся): а как это мы вообще не варпим всем скопом, и пинги получаем почти сразу, а не когда в следующий раз на арену заходим

 

Кошки, они не глупые... они мягкие и пушистые

Тут не в роутерах дело... дело в алгоритме протокола.
В сети все распределено по приоритетам. Трафик, который управляет маршрутизацией - имеет самый высший приоритет. Потому что если он не обработается - вообще весь трафик может пойти лесом. Потому считается меньшим злом задержать на некоторое время трафик пользователей, но зато соблюсти иерархию и порядок в сети.

Само-собой, что мы говорим о public каналах, где никто ни за что вообще не отвечает. Если надо промаршрутизить time-sensitive трафик (типа VoIP, банковской коммуникации) - применяются другие механизмы, не допускающие остановки трафика клиента. Но это и денег стоит других.

 

Да я в курсе, книжки вумные читаю и все вышеизложенное было более-менее знакомо, только так красиво рассказать у меня бы не получилось.

 

Ну так, как я и говорил - прямой канал еще ничего не означает. Берем последнюю картинку поста. Смотрим на "провайдера фрихоста". Очень легко может статься, что ты сидишь на одном роутере, а фрихост на другом. между роутерами - IGP. Соответственно есть абзац в объяснении. А могут быть (и их много) - другие причины. Например, канальчик где-то узковат. Что толку, если у одного юзера канал в мегабит и пустой, если у destination канал может быть в 128Kb и забитый. Да, потерь не будет на мегабитном канале - они будут в узком. Но эффект будет один - потери пакетов. Или может быть роутер перегружен.

 

Re: Re: Вопросы пинга, варпа, лага и привязка к теории (продолжение)

А деньги нам что, по-твоему, просто так платят?

На иною киску 26-ю без слез не взглянешь, как ей бедной плохо... не всякий core роутер с таким справился. А заглянешь в конфиг - вообще непонятно бывает как оно живет-то еще

Но ведь ходит TCP? Ходит. Непонятно как? Дык никому непонятно... но это разговор второй, но ведь ходит

 

Re: Re: Re: Вопросы пинга, варпа, лага и привязка к теории (продолжение)

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

 

2 badboy

"-пап, а скем это ты сейчас разговаривал ?" (c) анекдот...
Дык фигли... Все вроде ясно... Непонятно только, что за "серое вещество" уважаемый Автор использовал в качестве предмета для читательского напряжения... (Sry, само на язык напросилось )
Столько текста- а помарок (очепяток)- раз два и обчелся. Крепкие нервы и координированные руки Аж приятно читать

Спасибо. Труд неблагодарный, но полезный и оцененный Повешу в рамочку на видное место

Tnx

 

И почто сабджекты такие мелкошрифтовые?

Эт все, канешна, хорошо и красиво, но вот у меня, к примеру, пинги бродят по всей Европе, пока до ФХ добредут.

Я вот тута попинговал ФХ сейчас - расклад еще не самый плохой. Иногда там же Лондоны и Парижи присуйсьвуют.

Первые 4 позиции из лога я выгрыз. Просто так, на всякий случай.
----------------------------------------------------------------
5 62 ms 41 ms 33 ms 36 ms [212.86.227.69]
6 57 ms 39 ms 31 ms 39 ms CORE1-DP.alkar.net [195.248.191.153]
7 52 ms * 78 ms 40 ms SE1-3.FC3-DP.alkar.net [212.86.227.46]
8 852 ms 624 ms 589 ms 571 ms solna-i1-serial5-0.telia.net [193.45.4.153]
9 678 ms 580 ms * * ov-i13-serial0-1.telia.net [193.45.4.177]
10 665 ms 649 ms 575 ms * sto-b1-atm3-0-6.telia.net [194.17.1.113]
11 647 ms 659 ms 603 ms * s-b4-pos3-0.telia.net [213.248.66.58]
12 637 ms 648 ms 648 ms * s-bb2-pos1-0-0.telia.net [213.248.64.145]
13 693 ms 627 ms 722 ms * hbg-bb2-pos0-2-0.telia.net [213.248.64.98]
14 716 ms 636 ms 747 ms * ffm-b1-pos12-0.telia.net [213.248.68.18]
15 709 ms 632 ms 757 ms * [213.248.68.90]
16 751 ms 670 ms 667 ms * gin-fft-cix1.teleglobe.net [80.81.192.250]
17 740 ms 614 ms 661 ms * if-1-0.core1.Frankfurt2.Teleglobe.net [195.219.14.193]
18 752 ms 615 ms 626 ms * ix-5-4.core1.Frankfurt2.Teleglobe.net [195.219.96.94]
19 751 ms 654 ms 684 ms * MSK-M9-RBNet-4.RBNet.ru [195.209.14.245]
20 744 ms 669 ms 677 ms * MSK-M9-RBNet-3.RBNet.ru [195.209.14.214]
21 733 ms 657 ms 665 ms * M9-AT0-58.nc.ras.ru [193.124.249.18]
22 754 ms 674 ms 688 ms * HQ-AT0-128.nc.ras.ru [193.124.249.250]
23 780 ms 673 ms 697 ms * ns.chph.ras.ru [195.208.34.194]
24 769 ms 695 ms 728 ms * cndr.chph.ras.ru [195.208.34.5]

И шо теперь? Застрелится всем АБОНом? Кстати, этот провайдер - лучший у нас в городе.

 

Re: И почто сабджекты такие мелкошрифтовые?

Зачем стреляться? Играть. Какой есть пинг, с тем и играть. Будет лучше - все равно играть. И так пока не надоест

 

Re: 2 badboy

Серое вещество... м-м-м... серое вещество... э-э-э...
Короче, это такая фуйня в башке, которая нужна для полного осмысления обсуждавшихся в топиках

Жалко конечно, что напряжение не удалось довести до уровня детектива

Но как ты прав насчет труда неблагодарного
Знаешь, сколько раз я пожалел, пока писал, что дернуло меня каркнуть

 

Re: Re: И почто сабджекты такие мелкошрифтовые?

Кстати, а почему многие игры используют UDP, а не TCP/IP? Ведь в случае tcp/ip не должен теряться не один байтик, просто будут задержки, а в случае UDP вроде возможна потеря информации? И с этой потерей надо будет бороться усложняя алгоритм программы, или полезут глюки, и всеже используют этот UDP. Почему? Объясните на понятном уровне

 

Re: Re: Re: И почто сабджекты такие мелкошрифтовые?

TCP/IP - это стэк протоколов, в который входят в свою очередь и UDP и TCP
(некорректно сравнивать гитару со щипковым инструментом, потому как она сама таковым и является!)

 

Re: Re: 2 badboy

Мнэ... Я тут наверное тоже встряну, как один из тех, кто, собственно, дергал тебя за клюв.

Сапасиба огромное за этот труд. Получил именно то, чего просил. Просветился. Даже не предпологал, что все настолько хреново. Совсем преисполнился чувствами к спецам в области нетворкинга.

ЗЫ Я, как раз, тот агроном по образованию.
ЗЗЫ "Было у отца три сына. Два нормальных, а один - агроном."

 

Re: Re: Re: Re: И почто сабджекты такие мелкошрифтовые?

Имхо вопрос немного о другом. Давай не пинать человека за то, что он не смог его корректно поставить. Ты вопрос понял? Я тоже понял. Арчер понял. Давай отвечать

UDP - в отличие о TCP - протокол non-reliable. То есть он не заботится о том, доставлен ли пакет или помер по дороге. С другой стороны огромный плюс UDP пакетов в отличие от TCP пакетов - гораздо меньший размер. Соответственно (опять очень обобщая) - как будет выглядеть передача если одну и ту же информацию передать по TCP и UDP и если в канале потери:

- TCP будет передавать пакеты большего размера (не всегда)
- TCP доставит каждый пакет и потери связи будут выглядеть как задержки доставки (лаги)

- UDP доставит только те пакеты, которые дойдут. Те, которые потеряны - повторно передаваться не будут.
- Потери пакетов (для WB в нашем случае) будут выглядеть как _скачки_ самолета - тут - и сразу там.
- при этом у UDP пакетов шансы быть доставленными вовремя и без потерь (в зависимости от ситуации в WAN) могут быть выше чем у TCP быть доставленными вовремя.

Каждый разработчик конкретной программы думает - что в его варианте лучше и что более корректно вприсывается в его код (идеологически для целей программы) - потому применение находят и тот и другой протоколы.

 

Re: Re: Re: Re: Re: И почто сабджекты такие мелкошрифтовые?

Вот тогда-то и начнётся вонь на тему: "Я в него всадил 20х37мм, а он в это время в лаге был и пинги потерялись!"
Всё хорошо... но израсходованных боеприпасов уже не вернёшь на место!

PS читеров разведётся-я-я.....