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), принадлежащих разным провайдерам, будут доставлены
по одним каналам и в том порядке, в каком были отправлены.
Давайте рассмотрим на примере:
http://forum.wbfree.net/images/badboy/1.gif
В указаном примере вирпил подсоединяется к своему провайдеру через модем. Но фрихост находится в сети другого провайдера и из сети провайдера вирпила существует два пути до сети провайдера фрихоста ? через сеть провайдера 1 или через сеть провайдера 2.
Так вот, реалии современного Интернета таковы, что провайдер вирпила в 99.99999% не даст вирпилу никаких обязательств и обещаний, по какому из двух возможных каналов трафик от вирпила пойдет до фрихоста. Кстати, это касается не только тех вирпилов, которые пользуются модемными соединиями, но и тех, кто сидит из офиса по выделенкам. Особо недоверчивые могут попробовать позвонить своему провайдеру и попросить его прогаранитировать всегда одинаковый маршрут от своего хоста до фрихоста и потом рассказать народу, что ответил провайдер :D
Итак, примем за аксиому, что трафик может пойти как по первому, так и по второму каналу. Причем с большой степенью вероятности он может пойти и по двум каналам сразу. То есть, например, так - пакет номер 1 будет отправле по каналу 1, пакет номер два ? по каналу 2, 3 и 4 по каналу 1, 5-6-7 ? по каналу 2. По какому принципу провайдет определяет какой пакет по какому каналу слать ? мы сейчас рассматривать не будем. Просто поверьте на слово, описанная ситуация ? не исключение, а правило в современном Интернете.
Ну и что, скажете вы, пусть они были отправлены по разным каналам. Но ведь отправлены были по порядку! Что им мешает прибыть по порядку? Вот тут и есть загвоздка ? много чего им может помешать. Например, перегруженный роутер у одного провайдера, на котором образовалась очередь из пакетов, ожидающих отправки. Или, еще проще ? представим себе, что вместо сети провайдера 1 мы имеем две последовательно соединные сети ? провайдера 1 и провайдера 3.
http://forum.wbfree.net/images/badboy/2.gif
Если даже принять за основание, что каналы у всех провайдеров одинаковые по пропускной способности, то пакеты, отправленные через провайдера 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. А вариантов этих, поверьте, существует очень много.
Теперь представим, что подобная каша с пакетами произошла в момент вашей стрельбы по самолету противника и в посылаемых пакетах содержаться ваши «пулевые пинги». Включайте серое вещество в голове и представляйте себе что будет. Представили?
А теперь представьте себе, что «в пути» от вашего клиента до сервера задержался не ОДИН пакет, а десяток. Представили? Ну как, понятна первая часть описания того, что такое лаг? Или варп?
Если понятна ? идем дальше. Берем случай, когда нету от вашей выделенки двух каналов до фрихоста. А есть один. Опустим причины, скажем только, что такое тоже может быть ? таковы реалии отношения между независимыми провайдерами в интернете.
Итак:
http://forum.wbfree.net/images/badboy/3.gif
Между Автономными Системами (сетями) провайдеров запущен протокол BGP ? Border Gateway Protocol, занимающийся маршрутизацией трафика от отдной AS до другой. Все бы здорово, все бы прекрасно. Дорожка от вирпила, до фрихоста одна. Пакеты идут в нужном порядке. Сидит себе вирпил и наслаждается стабильным соединением. И тут вдруг... ну скажем к роутеру в сети провайдера 3 получил доступ «великий специалист». И взял, да и перезагрузил этот роутер. Как там будут дела у вирпила со стабильным коннектом до хоста на время, пока роутер поднимается? Правильно.... хреново будут у него дела.
Впрочем, вероятность получения ламером доступа к core роутеру, занимающемуся маршрутизацией BGP ? исчезающе мала. Это я могу заявить с высокой степенью вероятности.
Зато, если вам будет не лень заглянуть в литературу о принципах работы BGP, то вы найдете там то, что, например, от одного до нескольких раз в сутки BGP роутер получает обновление таблиц маршрутизации от своих «соседей» - роутеров других автономных систем. Таблицы маршрутизации помогают роутеру разобраться куда какой трафик отправлять. Сами по себе таблицы никак на коннект вирпила повлять не способны, но вот время, которое роутер, получив обновленные таблицы, потратит на их упорядочивание ? вот это серьезный момент. В зависимости от типа роутера, памяти у этого роутера и величины полученной информации может случиться (и случается весьма часто) то, что называется «перестройкой таблиц маршрутизации». И в момент такой перестройки роутеру может быть совсем не до вашего трафика. Он занят. Он строит. И трафик ваш дропнет попросту. А заботливый TCP попросит ваш хост трафик перезаслать. А роутер занят. И опять дропнет. И так пока он таблице не перестроит. А потом, когда в AS1 перестройка закончилась, началась перестройка таблиц, например в AS3. Так что у нас там с устойчивым коннектом?
Ну и на закуску рассмотрим сложный, но совершенно реальный вариант.
http://forum.wbfree.net/images/badboy/4.gif
В сети каждого провайдера на этой схеме существуют по два протокола. Один ? BGP ? для связи с соседними провайдерами. А другой ? IGP (internal gateway protocol ? так называется группа протоколов, применяемых для маршрутизации внутри одной автономной системы). И вот в нашем варианте у каждого провайдера IGP свой. Каждый провайдер поставил редистрибьюцию из IGP в BGP. Но теперь представим себе, что в сети провайдера 1 произошел сбой. Неважно от чего, просто произошел. RIP ? старый, хотя и до сих пор применяемый протокол. Но отличается он, упрощенно говоря, долгим временем восстановления потерянного маршрута ? до 30 секунд. Что происходит с трафиком, который идет через AS провайдера 1 в этот момент? Правильно ? трафик не идет. У OSPF, в сети провайдера вирпила, время восстановления маршрута не в пример меньше ? доли секунд. Потому единократная потеря маршрута не будет так заметна. Но в результате не очень правильной имплементации OSPF может случиться такая беда ? какой-то из роутеров будет нестабилен. И будет то терять, то ставить маршруты в таблицу, чем окажет влияние на все роутеры AS. Вот это и будет еще одним примером причин варпа или лага.
И самое забавное, что в случаях проблем с маршрутизацие «ширина» канала, по которому вирпил подключен к провайдеру ? ну совершенно ни на что не влияет. Ибо проблемы не в этом канале. Проблемы у провайдера.
Это, пожалуй, все. В процессе дискуссии в материал, думаю, будут вноситься дополнения и уточнения.
Готов выслушать вопросы.
