Вчера, 7 мая, в России и еще некоторых странах праздновался День Радио.
Этот день - профессиональный праздник всех, кто связан с отраслью Связи и Массовых Коммуникаций. Данной статьей я закрываю свой старый гештальт, желание выпустить обзорную статью, доступную для понимания не только моим коллегам, но и простым потребителям наших услуг. Потому что каждый сейчас в той или иной мере наш абонент.
Вчера, к 7 мая, Дню Радио, я наконец-то приступил к написанию статьи, которую очень хотел родить, но откладывал в дальний ящик. Я давно поставил перед собой амбициозную задачу рассказать просто о сложном. Коротко о том, о чем написаны тысячи научных работ, десятки тысяч стандартов, над чем работают миллионы людей по всему миру. То, что настолько вошло в наш ежедневный быт, что считается само собой разумеющимся, незаметным и как будто существовавшим все время. Потому что вчера, 7 мая, мы праздновали наш праздник. Профессиональный праздник всех, кто связал свою жизнь с электросвязью. И я хочу поговорить о ее ведущей частности - всемирной сети передачи данных. Об Интернете, если угодно. Давайте начинать.
Первое, что надо понимать, когда мы говорим об интернете - это то, что он не однороден. Логически интернет разбивается на огромную совокупность IP-сетей.
IP-сеть.
IP-сеть - это определенный "кусок" адресного пространства, в составе которого есть:
1) IP-адрес сети - самый первый адрес диапазона, он обозначает саму сеть, чтобы ее можно было указать в конфигах сетевых устройств, например или в технической документации.
2) IP-адреса хостов - адреса устройств, работающих в этой сети.
3) Широковещательный адрес - последний адрес из диапазона сети. В случае, если пакет "прилетает" на него, то он рассылается всем хостам данной сети. Так работает, например, интернет-телевидение IPTV и прочие широковещательные сервисы (broadсast на англо-сетевом языке).
Неоднородность общей, глобальной сети обуславливает то, что пакет перед тем, как попасть в нужную подсеть (например, в доменную зону того же vk.com), транзитом пробежит несколько других подсетей, путь через которые покажется алгоритмам маршрутизации самым коротким.
Давайте рассмотрим это на примере. Для диагностики сетей в современных ОС есть отличная утилита traceroute (для win-систем tracert), которая с помощью ICMP-запросов формирует трассировку маршрута, по которому "пробежал" пакет. Возьмем стандартный вариант, например, до ya.ru - легковесной версии известного поисковика.
Мы видим, что трассировка строится до адреса 77.88.55.242. По пути происходит 7 хопов до цели.
Первый хоп - это внутренняя сеть, сеть между Вашим компьютером и Вашим же домашним маршрутизатором. Как правило, она принадлежит диапазону адресов 192.168.0.0/16.
Маска IP-сети на примере сети 192.168.0.0/16
/16 или более привычное широкому кругу 255.255.0.0 - маска сети, которая показывает, сколько бит адреса относятся к адресу сети, а сколько - к адресу конкретного хоста в составе сети. В данном случае - за адрес сети отвечают первый и второй октеты (192 и 168 соответственно), за адреса хостов - третий и четвертый, которые могут принимать значения от 0.1 до 255.254, потому что 192.168.255.255 - широковещательный адрес для данной сети, а 192.168.0.0 - адрес самой сети.
Второй хоп - это путешествие внутри сети провайдера. Звездочки обозначают, что мы не получили ответ от устройства, которое выступило в роли шлюза в другую сеть нашего же провайдера. Чаще всего это делается ради безопасности сети, чтобы усложнить злоумышленнику задачу по сканированию сети с помощью таких доступных утилит, как traceroute.
Третий хоп - это шлюз из сети провайдера. Пакет вылетел из сети провайдера и полетел дальше в сторону цели.
Четвертый хоп - это уже интересно. Это пиринговая сеть организации Data-IX, сеть обмена трафиком между разными провайдерами. Задача Data-IX - буквально быть «перекрестком», через который обменивают трафик ключевые игроки рынка телекома РФ и Европы. Вероятнее всего, наш пакет пролетел через оборудование на ММТС 9 в Москве, основную точку обмена трафиком РФ - Европа.
В текущем случае протоколы маршрутизации направили наш пакет внутри сети Data IX (5 и 6 хопы, нет ответа от шлюза, см. хоп 2) в стороны их стыка с сетями Яндекса.
Седьмой хоп - мы пришли в сети Яндекса. 87.250.239.179 встречает наш пакет с распростертыми объятиями и отправляет его в сторону сети 77.88.55.0/24, в которой и находится искомый сервер с нужным нам сайтом. Опять же, видимо, 242 хост не горит желанием отвечать на ICMP-пакет c ttl=1 (и правильно делает, безопасность должна быть безопасной), поэтому, увы, мы не увидим ее финальную точку. Но будьте уверены, она там есть. И восьмой хоп был бы как раз до нее.
Данный пример прекрасно иллюстрирует то, как работает интернет - глобальная паутина вовсе не является монолитной структурой, а включает в себя огромное количество разных по размеру, назначению, принадлежности и географическому расположению сетей, которые пропускают через себя клиентский трафик и обеспечивают связность, буквально, каждого с каждым (если, конечно, кто-то сознательно не отгородится от всех вокруг). Именно в такой ячеистой, распределенной структуре и кроются ключевые фишки и косяки интернета (еще косяки интернета кроются в двачерах, но это уже вне моей компетенции). С одной стороны, в каждую точку мы можем прийти разными маршрутами, отбалансировать нагрузки, с другой стороны, это порождает очень много проблем, связанных с поиском маршрута, ликвидацией и недопущением петель, защитой чувствительных данных от чужого взора, обеспечения качества обслуживания (QoS) и прочего и прочего. Обо всем об этом, но очень-очень кратко - ниже.
Итак, я уже несколько раз употреблял термин “маршрутизация”. Пришло время разобраться, что это такое.
Маршрутизация - это процесс определения оптимального маршрута в сетях связи и отправка по нему пакетов. Когда мы говорим о маршрутизации, неизбежно мы встречаемся с такими понятиями, как маршрут (route) и шлюз (gateway).
Маршрут - это путь от одного хоста, имеющего IP-адрес, к другому. Даже если оба хоста находятся в одной подсети, допустим, сеть 192.168.10.0/30 имеет хосты 192.168.10.1 и 192.168.10.2 соответственно, путь от 10.1 к 10.2 является маршрутом. Это - самый простой случай маршрутизации, когда пакет остается в рамках одного широковещательного домена (внутри одной IP-сети). Случай посложнее - это типа того, что мы рассматривали выше, когда пакет должен "пролететь" через несколько разных сетей. Вот тут в дело и вступает такая вещь, как шлюз.
Когда я учился на MTCNA, наш тренер максимально на пальцах объяснил, как работает маршрутизация и в чем логика ее команд. Итак, представим, что каждая подсеть - это какое-то помещение в жилом доме. Комнаты, коридоры, подсобки, санузлы, не важно. В таком случае шлюзы - это двери, через которые можно попасть из одного помещения в другое. И прописывая статический маршрут, мы просто указываем, в какую сеть мы ходим через какую дверь. В синтаксисе команд CiscoIOS это буквально выглядит так:
ip route 10.12.0.4 255.255.255.252 10.12.0.2
На человеческий язык это можно перевести следующим образом:
Путь в сеть 10.12.0.4/30 лежит через хост с адресом 10.12.0.2. Исходя из адреса хоста-шлюза, мы можем предположить, что мы находимся в сети 10.12.0.0/30. Буквально, «в туалет из спальни мы ходим через правую дверь».
Подобные маршруты наполняют таблицу маршрутизации на каждом роутере, и, получив пакет, в заголовке которого указаны source и destination адреса, он понимает, через какой интерфейс и в какую сторону его надо отправить. Ключевое тут - именно в какую сторону. В данном случае маршрутизатор (роутер = маршрутизатор) не знает, реально ли эта сеть находится сразу за тем шлюзом, или же там еще одно устройство, которое получив этот пакет, прочитав его destination-адрес, точно так же отправит его уже согласно своей таблице маршрутизации в нужный интерфейс, к нужному шлюзу, принадлежащему совсем другой сети. Именно так наш пакет и бежал до сервера Яндекса. В суровом мире маршрутизации нет целей, есть только направления.
Cisco Systems, будучи ведущим поставщиком как сетевого оборудования, так и сетевых инженеров, разделяет два вида маршрутизации - административный и динамический. Если говорить по-русски, административная маршрутизация - это маршрутизация вручную, когда на каждом маршрутизаторе сетевой инженер прописывает маршруты в каждую сеть. Само собой, учитывая огромное количество сетей и маршрутов в интернете, такая маршрутизация ну никак не может быть основной. Нам просто бы не хватило рук и человеко-часов прописать каждый маршрут в каждую сеть на каждой нашей «железке». Поэтому на помощь нам приходят протоколы динамической маршрутизации, которые позволяют выполнять эту работу в автоматическом режиме. Я лишь вкратце пробегусь по основным (на мой субъективный взгляд и опыт) протоколам маршрутизации, подмечу их назначение и основные свойства. Потому что описание каждого протокола тянет на отдельную статью аналогичного этой объема.
RIPv1, RIPv2 - самый первый протокол динамической маршрутизации, прост, легок, из тех времен, когда частоты процессоров были низки, а запасы оперативной памяти очень малы. Этим и ценен до сих пор, поэтому RIPv2 нет-нет, да встречается на сетях, но сильно локально, чтобы проанонсировать буквально пару - тройку сетей и сохранить вычислительный ресурс маршрутизатора под более сложные процессы. Дистанционно-векторный протокол, который периодически проверяет известные ему маршруты за счет отправки т.н. векторов и измерения особых метрик, позволяющих выбирать лучший путь.
IS-IS и OSPF - два брата, оба т.н. Link-State протоколы, отслеживающие состояние линков, и на основе его строящие и перестраивающие маршруты. Выбор наилучшего маршрута выполняется за счет алгоритма Дейкстры. Отличие между ними заключается в том, что OSPF работает только поверх IP-сетей, IS-IS же изначально работал поверх канального уровня, с дейтаграммами данных, а не с пакетами. Впрочем, потом был допилен для работы на IP-сетях.
BGP - батя всего интернета. Сочетает в себе фишки и link-state, и дистанционно-векторных протоколов. На мелочи не разменивается, маршрутизирует трафик не просто между какими-то жалкими маршрутизаторами, а рулит потоками между разными операторами связи, управляя обменом трафика между т.н. автономными системами - AS, номера которых надо получать у регионального регистратора вместе с пулом белых IP-адресов. Работает в основном на стыках между разными провайдерами и крупными участками сети. Изначально предполагалось, что работать будет только через p2p линки (стыки на два IP-адреса между провайдерами), поверх поднятых TCP-сессий по 179 порту, но имеет широченный функционал, позволяющий разруливать неразруливаемое - балансировать трафик между магистральными линками, оперативно перестраивать сетевую топологию в случае их падения.
Если читатель помнит, как гении в шлепанцах порвали кабель связи в Красном Море, и как у многих «мигнул» интернет в этот момент - это заслуга как раз BGP. Заслуга состоит в том, что интернет именно «мигнул» минуты на 3-4, затем поднялся вновь. Но в эти 3-4 минуты на сети кипела работа - таблицы маршрутизации миллионов роутеров по всему миру срочно обновляли и перестраивали маршруты, пока система снова не пришла в устойчивое состояние и связь восстановилась.
Эти протоколы редко когда используются поодиночке, зачастую они работают вместе, и слабые стороны одного перекрываются сильными сторонами другого. Типичная связка - это, например, OSPF внутри сети и BGP на стыках с другими провайдерами и на аплинках. Настройка трансляции анонсов сетей из одного протокола в другой - это отдельный вид искусства для сетевого инженера. Там очень много подводных камней и мест, где можно накосячить. Просто поверьте мне на слово. А нам пора идти дальше.
Дальше мы остановимся на теме, которая косвенно связана с маршрутизацией. Я уже говорил выше, что в сетях связи путь из точки А в точку Б не всегда один, не всегда прямой, не всегда лежит там, где бы нам хотелось. А еще он может случайно, по недосмотру сетевиков, превратиться в петлю. Сразу хочу сказать, что тут мы рассматриваем только петли в разрезе маршрутизации IP-пакетов. Петли еще бывают на канальном уровне, и там они имеют другие последствия, способы борьбы и профилактики.
Проблема петель в том, что пакеты, попавшие в нее, никуда не уходят и никуда не исчезают. Они продолжают ходить по петле, и более того, если ничего не делать - они могут начать копиться, требуя все больше и больше вычислительного ресурса на такой паразитный трафик, который жизненно необходимо как-то отсеять. Именно для этого в заголовке пакета есть поле TTL - time-to-live. Время жизни. Стандартное значение для него - 64. Когда пакет проходит через маршрутизатор, тот не просто направляет его туда, куда надо согласно его таблице маршрутизации, а еще и уменьшает значение TTL на 1. Если к маршрутизатору придет пакет с TTL=0, то тот даже не станет его отрабатывать, а просто сотрет из памяти. Если за 64 хопа пакет не смог дойти до цели, то крайне велика вероятность того, что он «заблудился», и обрабатывать его смысла нет.
Следующая проблема сетей передачи данных - это люди. Вернее, их склонность ругаться, что-то делить и кого-то обижать. Несмотря на святую миссию всея отрасли связи соединить каждого с каждым, чтобы даже самые заклятые враги имели возможность поговорить и помириться, мы, например, не хотим пускать наш трафик через Украину. А США почему-то не хотят, чтобы трафик их гос. сектора так или иначе протекал через Иран. И тут нам на помощь приходит протокол BGP. Так как номера автономных систем вместе с глобальной базой IP-адресов лежат в открытом доступе в базах региональных регистраторов (всего их пять штук на весь мир, Россия работает с RIPE, европейским регистратором), а также доступны сервисы Who is, позволяющие любому посмотреть, кому принадлежит тот или иной IP-адрес, то мы можем настроить BGP так, чтобы наши сети не анонсировались туда, куда не надо. Это, в свою очередь, не даст построить маршруты через AS тех, с кем вы очередной раз что-то ухитрились не поделить.
Итак, маршрутизацию настроили, петель нет, все работает как часы. До поры до времени.
Рано или поздно, но пропускной способности сети все равно начнет не хватать, чтобы передать все быстро и молниеносно. И тут два пути - либо модернизация сети, что долго, больно и с перерывами связи, либо…
Либо оптимизация использования ее ресурса. И перво-наперво, нам надо посмотреть, что вообще мы передаем. Оказывается, трафик через сеть так же не однороден, как и сама сеть. Один и тот же абонент генерирует разное количество трафика в зависимости от времени суток. Ваш покорный слуга в бытность свою инженером дежурной смены ЦОД сам воочию наблюдал эти лавинообразные подъемы трафика к вечеру (которые имеют фрактальную структуру, если строить математическую модель), когда люди приезжают домой и лезут в интернет, падения трафика практически до нуля в районе 3-4 часов ночи и первые робкие подъемы между 5 и 6 часами утра, когда народ начинал просыпаться на работу. Также, многие наверное помнят, в эпоху ADSL-интернета в вечерние часы интернет работал хуже, чем днем. Но вы даже не подозреваете, что эти явления связаны еще более крепко, чем вам кажется. А причина этого - т.н. переподписка.
Переподписка - это способ оптимизировать эксплуатацию каналов связи, когда на один канал подключается немного больше абонентов, чем в этот канал их можно уместить, в расчете на то, что они будут пользоваться каналом в разные временные промежутки. Честные провайдеры об этом сразу предупреждали, обозначая скорости EIR и CIR. CIR - гарантированная полоса пропускания, EIR - максимально доступная скорость, которая не гарантирована.
Не очень честные обещали 10 мбит/сек за три копейки всегда, но вот только зачастую клиенты даже 5 мбит/сек по вечерам получали разве что летом, когда соседи на даче, а маркетологи продали договоров больше, чем могли бы вывезти технари.
Сюда же можно отнести всякие ночные скидки, которые практиковали некоторые провайдеры, обещая более выгодный биллинг для тех, кто будет пользоваться каналом в ночное время, как правило, с часа ночи до 6 утра.
Но с приходом Ethernet и xPON сетей в наши дома переподписка практически пропала.
Ладно, отдохнули, поностальгировали, пора возвращаться к матчасти. Есть еще один способ впихнуть невпихуемое. И именно он получил максимально широкое распространение на современных сетях передачи данных. Все дело в том, что наш трафик тоже можно разделить на разные категории относительно чувствительности к задержкам. Самый расхожий пример тут - торренты и VoIP. Торрент-клиенту абсолютно наплевать, с какой задержкой к нему прилетел очередной пакет с данными, которые пользователь скачивает (на всякий случай, осуждаю пиратство). А вот если пакеты какого-нибудь Discord начнут хотя бы немного тормозить или теряться по пути в то время, когда пользователь потеет с тиммейтами во время очередной катки, и между ними вовсю пашет войсчат - это почувствуют все и сразу. Потерять пакеты сетевой игры терпимо, но тоже неприятно, оно влияет на геймплей. Вырастает пинг и реакция сервера на действия игрока. В то же время видео с YouTube благодаря неплохим алгоритмам предзагрузки может потерпеть потери и высокие задержки на канале. Все это нас подводит к т.н. приоритизации трафика и к такому понятию, как качество обслуживания Quality of Service - QoS. Вообще, QoS - тема очень обширная и сложная (учебник по QoS от Cisco по объему толще, чем учебник по всей маршрутизации от них же), но основная ее идея в том, что в зависимости от типа трафика в специальном поле в заголовке IP-пакета ставится отметка о приоритетности его отработки. Какие-то пакеты могут подождать в буферах маршрутизатора, а какие-то требуют отправки незамедлительно.
Именно поэтому у многих современных провайдеров включенный торрент не мешает работе того же дискорда. На многих домашних маршрутизаторах можно настроить приоритетность того или иного типа трафика (автор видел нечто подобное на Keenetic Viva, например).
Ну и наконец, последнее, о чем я хотел рассказать в данной статье, это про NAT. Трансляция IP адресов. Сколько было сломано копий в молодости, когда я еще не был сетевым инженером, но уже вовсю пытался хостить игровые серверы на своем железе для совместных игр с друзьями…
А история банальна. NAT — это костыль и суровая необходимость. Когда разрабатывался протокол IPv4, никто и подумать не мог, что вокруг нас будет так много устройств с доступом в сеть. И что буквально каждому устройству понадобится свой IP-адрес, которые будут собираться в сети. И когда такая картина стала реальной, то на горизонте замаячил жесткий дефицит адресного пространства. Пока шла разработка протокола IPv6, нужно было какое-то промежуточное решение. И оно нашлось. Сети 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 и некоторые другие изначально предполагались для локальных сетей без выхода в интернет. И их стали использовать по прямому назначению - в локальных сетях квартир (вероятнее всего, ваши компьютер, ноутбук и телефон сейчас имеют адреса из сети 192.168.0.0/16), офисов, предприятий, но для выхода в интернет с устройств, имеющих такие IP-адреса, разработали специальную технологию, которая подменяла в поле source IP-пакетов, исходящих от такого устройства, адреса локальных сетей на единственный белый адрес, который «висит» на порте маршрутизатора, смотрящем в сторону провайдера. Маршрутизатор запоминает номер логического порта, с которого ушел пакет, и при поступлении ответа на этот же порт подменяет destination-адрес пакета серым IP-адресом машины, с которой была инициирована данная сессия.
Обычный пользователь может годами работать из-под NAT и не знать горя, но как только встает задача что-то захостить или расшарить, так приходится доставать сетевой бубен и начинать городить костыли вроде туннелирования, или вообще идти к провайдеру на поклон с звонкой монетой, чтобы купить себе статичный белый IP-адрес, который можно повесить на свою машину и настроить маршрутизацию, чтобы обойтись без NAT.
В конце я хочу сказать, что на свете нет настолько же миролюбивой отрасли, как связь. Я не являюсь пацифистом, но перед тем, как построятся мосты, пройдут переговоры, пожмутся руки и раскроются портфели, между двумя антеннами проскочат электромагнитные волны, зазвонят телефоны, полетят пакеты по оптоволокну. Еще ни одну страну мира не отключали от глобальной сети электросвязи. Даже в самый разгар Битвы под Москвой Сталин мог поднять трубку и позвонить Гитлеру. Связь прошла огромный и очень стремительный путь развития от проволочного телеграфа до современных пакетных систем передачи данных, которым покорились не просто расстояния, но и скорости передачи, недостижимые ни для каких иных сотворенных Человеком вещей. Связь первой полетела в космос. Она вместе с искусственными станциями побывала на Луне, Марсе, Венере, пролетала среди колец Юпитера, улетела за Плутон. Связь проникла везде, куда направил свой взор Человек. Сегодня высокоскоростной канал связи в некоторых системах оценки качества жизни считается чем-то жизненно необходимым. И чем плотнее она заходит в нашу жизнь, тем больше это чудо техники и венец инженерной мысли становится чем то обыденным и само собой разумеющимся. Для меня в прямом смысле награда, когда вахтер-старатель в глубокой дикой Сибири через спутниковый интернет играет в танки и звонит по скайпу домой. Когда по гос. программе УЦН интернет приходит в настолько дикие и отдаленные медвежьи углы, в которых, несмотря ни на что, живут люди - я понимаю, что мы работаем не просто за зарплату. И пусть о нас вспоминают только когда все перестало работать - связь - это то, что держит нас всех вместе.
С праздником, Связисты! С Днем Радио!
P.S: Выражаю огромную благодарность корректорам CatSience, Светлане Андреевой и Александру Грибоедову, за их неоценимый вклад в чистоту Великого и Могучего в этой статье и компетентную помощь в подготовке к ее публикации.
Автор: Степан Иванов.