ВСE ЧТО НАДО ЗНАТЬ ПРО СЕТИ transcript

Всем привет. Вы на канале ПростопS. Есть одна тема, которую изучают вскользь. А зря взять даже любое собеседование на Дивопса. Там обязательно будет несколько вопросов по сетям. Ну вот где начинаются сети и где они заканчиваются? Плюс что конкретно надо знать. Сегодня поговорим именно об этом. И начнём со основ. Прочитаю определение. Сеть - это два и более устройств, которые обмениваются данными. Всё достаточно просто. Но тут возникает вопрос: а как именно они обмениваются? Потому что нельзя просто взять и кинуть файл по проводу. Сначала нужно договориться о правилах. В какой момент начинать передачу, как понять, что данные дошли, что делать, если два устройства заговорили одновременно и так далее. Вот эти договорённости - это протоколы. И вся сетевая инженерия - это, по сути, набор протоколов, где каждый следующий решает проблему, которую не решил предыдущий. Но прежде чем лезть в протоколы, давайте поймём общую картину. Что происходит, когда вы открываете сайт? Вот ваш комп, и он подключен к домашнему роутеру. Роутер подключен к провайдеру. Провайдер подключен к магистральному оператору. Это те ребята, которые владеют подводными кабелями между континентами. И эти магистральные операторы обмениваются трафиком между собой на iP точках обмена трафиком. Их в мире всего несколько сотен. А где-то на другом конце этой цепочки стоит сервер в дата-центре, на котором работает сайт, который вы хотите открыть, и ваш запрос проходит через все эти звенья, получает ответ, и ответ идёт обратно. При этом весь путь занимает буквально миллисекунды. Но на каждом этапе работают разные протоколы и разные устройства. И чтобы понять, как они все работают вместе, нам нужна модель. Сеть устроена слоями, где каждый слой решает свою задачу и ничего не знает о том, что происходит выше или ниже. Давайте пройдёмся по ним снизу вверх. В самом низу у нас находится физический уровень. Здесь нет данных, нет адресов. Здесь только физика. Электрические сигналы в медном кабеле, цветовые импульсы в автоволокне, радиоволны в вай-фае. И задача первого уровня - это передать биты, то есть нули и единицы. На этом уровне работают кабели, разъёмы, приёмники и передатчики. Так что если у вас перерезан кабель и из-за этого не проходит сигнал, это проблема на уровне L1. При этом для Divпса L1 обычно не в зоне ответственности. Этим занимаются сетевые инженеры, монтажники и сидмины. Но понимать, что он существует, очень важно, потому что иногда проблема может быть в кривом кабеле или умирающем трансивере, но не в конфигурации. И вот мы умеем передавать биты. Но как понять, кому конкретно они адресованы? Потому что в одном кабеле или Wi-Fi сети могут быть десятки, а то и сотни устройств. Нам нужен адрес. И тут мы переходим на второй уровень, который называется канальным. Тут у нас появляются MA-адреса.

MACдрес состоит из 48 бит, зашитых в сетевую карту на заводе. Выглядит как шесть пар шестнадцатиричных цифр, пример у вас на экране. И абсолютно каждый сетевой интерфейс в мире имеет уникальный Мак. На этом уровне данные упаковываются в кадры. Кадр - это, по сути, как конверт. В нём написано от кого, то есть маcдрес отправителя, кому то есть маcдрес получателя и то, что лежит внутри, сами данные. Плюс на втором уровне работают устройства, которые называются коммутаторы, они же свечи, которые умеют самую главную вещь смотреть на каком порту какой MAC-адрес и перенаправлять карты только туда, куда нужно. Для этого у них есть специальная таблица макодресов. И здесь есть важный момент. Мак-адреса работают только в пределах одной локальной сети. Они не маршрутизируются, поэтому домашний роутер не может отправить кадр с Мак-адресом на сервер Гугла. Для этого существует следующий уровень. И тут уже начинается настоящий интернет. На L3, то есть сетевом уровне, появляются IP-адреса.

IP-адрес - это логический адрес, который назначается устройству. Но в отличие от Мака, он не привязан к железу. Его можно менять, переназначать и маршрутизировать. IP-адреса есть двух типов. IP V4, то есть 32 [музыка] бита, записанных как четыре числа через точку, и IP6, состоящий из 128 бит. И появился он потому, что в IP4 уже не хватает адресов для текущего объёма интернета, но сегодня мы о нём забудем. Продолжаем разбираться с L3. Данные здесь упаковываются в пакеты. Пакет - это тот же кадр из L2, но в который завернули ещё один конверт, на этот раз уже с IP-адресами от правителя и получателя. И на этом уровне у нас тоже существует сигнатурное устройство. Здесь это маршрутизатор, также известный как роутер. Но он делает принципиально другую вещь, нежели коммутатор. Коммутор, как мы сказали до этого, работает внутри одной сети, а маршрутизатор соединяет разные сети между собой. Вот представьте, у маршрутизатора есть таблица маршрутизации, в которой сказано, чтобы добраться до сети такой-то, надо отправлять пакеты через такой-то интерфейс на такой-то адрес. И когда пакет приходит, маршрутизатор смотрит его IP-адрес назначения, сверяет с таблицей, чтобы понять, в какую сеть его направить, и отправляет этот пакет в нужном направлении. И этот процесс повторяется на каждом маршрутизаторе по пути, пока пакет не дойдёт до конечной сети. И здесь тоже есть важную деталь, которую многие путают. Когда пакет идёт от вашего компа к серверу через 15 маршрутизаторов, IP-адреса отправителя и получателя не меняются на всём пути. Они зафиксированы от А к Б. А вот Мак-адреса меняются на каждом хопе. то есть прыжке с маршрутизатора на маршрутизатор. И на каждом маршрутизаторе пакет перепаковывается в новый кадр L2 с новыми Маc-адресами, потому что IP - это конечный адрес, а Mac - это адрес следующего звена в цепочке. Итак, у нас есть IP-адрес, и мы можем отправить пакет на любой конкретный сервер. Но на сервере работает множество программ: веб-сервера, базы данных, да тот же SSH. И как пакету попасть именно в НКС, а не в какой-нибудь постгрес. Для этого существует четвёртый уровень, он же транспортный. На нём появляются порты. Порт - это число от нуля до 65.535. И связка IP-адрес прт однозначно определяет, какому конкретно процессу предназначены данные. Вот посмотрите на экран. Первый адрес - это не просто сервер Гугла, это веб-сервер на Гугле, принимающий https. А адрес под ним - это SS на том же сервере, другой порт, соответственно, другой процесс. Есть в целом общепринятые порты: восьмидесятый для HTTP, 443 для HTTPS, двадцать второй для SSH, пятьдесят третий для ДНС, 5432 для подгресса и так далее. Но это конвенция, а не закон. Технически можно повесить SSH на 443 порт, и ничего не сломается, но для дебага в будущем это может стать проблемой. А ещё на транспортном уровне [музыка] живут два очень важных протокола. Оба решают одну задачу: доставить данные от процесса к процессу, но при этом делают они это максимально по-разному. Первый протокол, о котором мы поговорим - это TCP. Он же протокол надёжной доставки. То есть перед отправкой данных отправитель получатель устанавливают соединение. Это знаменитое трёхстороннее рукопожатие. Клиент отправляет пакет sin, который означает, что он хочет установить соединение. Сервер отвечает пакетом Sinк, что он услышал клиента и готов общаться. После чего клиент отправляет финальный ак, что он всё принял и готов начинать общение. Только после этого начинается передача данных. И на каждый кусок данных получатель присылает подтверждение, что он получил такой-то набор байт. И если подтверждение не пришло, отправитель шлёт данные повторно. То есть TCP гарантирует, что данные придут полностью в правильном порядке и без дубликатов. Он сам порежет большой файл на сегменты, пронумерует их, соберёт на другом конце и проверит, что ничего не потерялось. Цена за это накладные расходы, рукопожатия, подтверждение, повторные отправки. Всё это занимает время и трафик. Но TCP используется там, где целостность данных критична и гораздо важнее скорости.

HTTP, SSH, базы данных, передача файлов - это те вещи, в которых нельзя потерять ничего. Но есть и другой протокол, который называется UDP и, по сути, является полной противоположностью TCP. Здесь нет никакого рукопожатия, никаких подтверждений, никаких повторных отправок. Отправитель просто кидает пакет в скобочках датаграмму и забывает о нём. Дошёл, отлично. Не дошёл и хрен с ним. Пришёл не в том порядке, это проблема клиента, но не от правителя. Звучит на первый взгляд ненадёжно, но у UDP есть козырь. Это его скорость. Нет рукопожатия, равно нет задержки на установление соединения. Нет подтверждений, значит нет задержки на ожидание этих самых подтверждений. Нет повторных отправок, значит нет лишнего трафика. И нужно это в первую очередь там, где идёт потоковое вещание: аудиозвонки, видеозвонки, стриминг, показ видео. Если б пакет с кусочком того же видео потерялся, нет смысла его перезапрашивать, потому что к тому моменту, когда он придёт, этот кадр уже устарел и он не нужен. Лучше показать следующий. Поэтому здесь достаточно простая логика.

TCP про надёжность, а UDP про скорость. И вот, поднимаясь вверх по уровням, мы дошли до туда, откуда уровни и начались. Поговорим про две модели: OSI и TCPIP. Про модель OSI вы, скорее всего, слышали. Семь уровней от физического до прикладного. Её любят спрашивать на собеседованиях, и она есть в каждом учебнике. Ну вот в чём фокус. OSI - это теоретическая модель. Она была придумана как идеал, как эталон. И в реальности интернет работает по другой модели, по модели TCP. И тут уровня всего четыре, а не семь, как в эталоне. Канальный уровень объединяет L1 и L2 из модели оси. Сетевой точно такой же, как L3 [музыка] в модели OSI, то есть IP. Третий уровень транспортный - это четвёртый уровень модели OSI. А четвёртый уровень в модели TCPIP прикладной. Он объединяет пятый, шестой и седьмой уровни из оси. А почему так? Потому что разделение на семь слоёв выглядит очень красиво на бумаге. Но в реальных протоколах границы между уровнями 5, 6 и 7 размыты.

HTTP, ТЛС, ДНС, они все работают на прикладном уровне. Но пытаться впихнуть ТЛС в уровень представления - это натягивать теорию на практику. Модель OSI очень полезно знать для собеседований, а вот для реальной работы достаточно модели TCP. Дальше мы будем использовать нумерацию из модели оси, как делали до этого в ролике, потому что так говорят все, кто работает в индустрии. Но надо помнить, что реальный стек - это TCPIP. А теперь поднимаемся на прикладной уровень. Здесь живут протоколы, с которыми вы сталкиваетесь каждый день. И первый из них - это HTTP.

HTTP - это протокол общения между браузером и веб-сервером. Он текстовый и простой. Вот пример запроса. Он буквально говорит о том, что ему нужно получить файл index.html с сайта example.com. А сервер отвечает: "В HTTP есть специальные статус-коды. Всего их пять семейств: сотые, двухсотые, трёхсотые, четырёхсотые и пятисотые. И каждое семейство нужно для конкретных целей. Коды из семейства 100 обозначают служебную информацию. Двухсотые - это успешные коды, которые сообщают, что всё нормально. Коды из семейства 300 обозначают перенаправления, те самые редиректы. Четырёхсотые, те, с которыми вы сталкиваетесь, когда не можете попасть на сайт. Ошибка на стороне клиента, а пятисотые означают, что сервер сломался. Сам по себе HTTP работает по модели запрос-ответ. Клиент спрашивает, сервер отвечает. И у всех запросов есть специальные методы. Самые популярные - это get, то есть получить данные, пост, отправить данные, пут, обновить, delete, удалить.

[музыка] Модель очень простая и при этом работает уже 30 лет, но у HTTP есть одна фатальная проблема. Он передаёт всё открытым текстом. И поэтому любой, кто сидит между вами и сервером, там провайдер, оператор и так далее, видит ваш трафик, какие страницы открываются, какие данные отправляются, какие пароли вводятся. И эту проблему решает ТЛС. тоже протокол, только криптографический, который оборачивает HTTP и любой другой протокол в шифрованный туннель. Перед передачей данных клиент и сервер проходят ТЛС рукопожатие. Оно может показаться в каком-то смысле сложным, поэтому в этом ролике мы разберём SSL рукопожатия, которое было до него. Клиент отправляет клиент hello, то есть сообщает, какие алгоритмы шифрования он поддерживает. И в этом же пакете отправляет SNI, то есть имя сервера, к которому пытается подключиться. Этот момент важный, потому что SNI передаётся открытым текстом ещё до установки шифрования. Дальше сервер отвечает сертификатом, то есть присылает свой публичный ключ, подписанный удостоверяющим центром, с помощью которого можно проверить, что этот сервер действительно является тем, за кого себя выдаёт. После этого клиент проверяет сертификат, стороны генерируют общий секретный ключ, и с этого момента всё зашифровано. И здесь провайдер видит, что вы подключаетесь к какому-то серверу из SNI. Он знает, что вы зашли на, допустим, google.com, но что именно вы там делаете? Он не видит ни содержимого страниц, ни поисковых запросов, ни паролей. И именно поэтому SNI - это основная точка атаки для систем фильтрации. Помните видео про ТСПУ? Мы разбирали, что SNI фильтрация - это до 80% работы ТСПУ. Как раз-таки в этом она и заключается. Система смотрит на тлсовский клиент hello, видит там имя домена и решает, пропустить его или заблокировать. Но не будем отвлекаться.

HTTP + TLS образует HTTPS, то есть это не отдельный протокол, это обычный HTTP, завёрнутый в TS. Порт 80 открытый HTTP, порт 443 для httpса. зашифрованного. И когда вы видите замочек в браузере, это означает, что ТЛС рукопожатие прошло успешно, сертификат проверен и трафик шифруется. Следующий очень важный сетевой протокол - это ДНС. Люди запоминают имена, но серверы и компьютеры работают с IP-адресами. ТНС - это система, которая переводит одно в другое. Мы вводим Google.com. Компьютер отправляет запрос, потому что ему нужен IP-адрес. ДНС-сервер отвечает, что к этому домену соответствует вот такой-то айпишник. Компьютер устанавливает соединение с этим айпишником. Но ДНС - это не один сервер. Это очень большая иерархическая распределённая система. И понимание того, как именно происходит поиск нужного IP-адреса к вашему домену, очень важно. Как минимум, потому что это спрашивают на собеседованиях. Но по факту это может быть полезно и в реальной работе, чтобы понять, где конкретна ошибка и почему какой-нибудь сервис не может общаться с другим. Так вот, когда вы впервые запрашиваете домен, ваш компьютер спрашивает локальный resolver, обычный DNS-сервер провайдера или четыре восьмёрки у Гугла. При этом не знает ответ и после этого идёт к корневому серверу. Корневых серверов 13 [музыка] штук. Они обслуживают верхушку иерархии. Корневой сервер говорит, что он не знает, кто такой Google, но за zonu.com отвечают вот эти серверы и отправляет к серверам zony.com. Серверыzony.com уже знают, что за google.com [музыка] отвечают конкретные сервера и отправляют к авторитативным серверам Гугла. А авторитативный сервер Гугла уже знает, что google.com висит на нужном IP-адресе. Готово. И после этоговер ещё запоминает ответ, чтобы в следующий раз, когда у него запросят этот домен, не идти по всей цепочке, а отдать его сразу. А сейчас на экране вы видите основные ДНСзаписи, которые нужно знать, потому что для DevOps DNS - это не просто имя в IP, это инструмент балансировки нагрузки, отказоустойчивости, сервис Discovery в Кубернетисе и много чего ещё. Теперь давайте поговорим про маршрутизацию. Мы знаем, что маршрутизатор [музыка] смотрит в таблицу маршрутизации и решает, куда отправить пакет. Но откуда сама эта таблица берётся? Вообще можно прописать маршруты руками. Это статическая маршрутизация. И для [музыка] домашней сети или маленького офиса вполне нормально. Но интернет состоит из десятков [музыка] тысяч сетей, и прописывать маршруты вручную просто невозможно. нужны протоколы, которые автоматически обмениваются информацией о маршрутах и обеспечивают динамическую [музыка] маршрутизацию. Самый старый и простой протокол динамической маршрутизации - это RIP. Логика у него элементарная. Каждый маршрутизатор каждые 30 секунд рассылает соседям свою полную таблицу маршрутизации и опирается на метрику в количество хов до цели. Максимум 15 штук. Если до сети нужно больше пнадцати маршрутизаторов, то она считается недоступной. И здесь понятны проблемы. Во-первых, это медленная сходимость. То есть, если что-то упало, то нужно подождать, пока все обменяются таблицами. Плюс нет понимания пропускной способности каналов. И поэтому в реальных сетях RIP сейчас уже, конечно, не используется.

[музыка] После него появился OSPF, который вместо того, чтобы тупо считать хопы, строил полную карту сети. То есть каждый маршрутизатор знает всю топологию, какие маршрутизаторы есть, как они связаны и какова пропускная способность каждого канала. На основе этой карты УPF рассчитывает кратчайший путь алгоритмам Дейкстры. Причём кратчайший - это не меньшее количество прыжков, а меньшая стоимость. А стоимость привязана к пропускной способности, потому что понятно, что канал в 1 Гби куда быстрее, чем канал в 100 Мбит. И у SPF поэтому выберет путь через три быстрых маршрутизатора вместо одного медленного. К тому же ОPF моментально реагирует на изменения. Если упал канал, все маршрутизаторы узнают об этом за секунды и перестраивают маршруты.

[музыка] И это основной протокол внутренней маршрутизации в корпоративных сетях и у провайдеров. Но нас куда больше интересует BGP. Это протокол, на котором работает весь интернет. RIP и OSPF работают внутри одной сети, а BGP работает между сетями. И поэтому каждый провайдер, каждый крупный дата-центр, каждая корпорация - это автономная система со своим номером. А BGP - это протокол, по которому все эти автономные системы рассказывают друг другу, какие IP-адреса у них живут и через кого до них можно добраться. При этом BGP бывает двух видов: EBGP и IBGP. Буква в начале показывает разницу.

E означает external, то есть между разными автономными системами. Например, стыки между провайдерами или точки обмена трафиком, те самые IXP, про которые говорили в начале ролика. А ещё есть Internal BGP, то есть внутри одной автономной системы. Когда маршрутизаторы внутри сети передают друг другу BGP маршруты, полученные от внешних партнёров, это как раз-таки IBGP. И принципиальное отличие BGP от OSPF в том, что BGP - это не технический протокол, а политический. УF, а BGP выбирает путь на основе политик. Через этого провайдера пускаем, через того нет. Этому клиенту маршруты отдаём, а этому только часть.

BGP маршрутизация - это инструмент бизнес-отношений между провайдерами. И именно поэтому всякие BGP утечки - это очень серьёзные инциденты. Если кто-то случайно или намеренно объявит чужие IP-адреса через свою автономную систему, трафик пойдёт не туда. Такое, например, произошло в 2008 году. Тогда Пакистан случайно забрал себе трафик Ютуба, объявив его под сети через BGP. И 2 часа абсолютно весь трафик шёл туда. Но на самом деле сети - эта тема очень обширная. В этом ролике мы не упомянули фаерволлы, разные тонкости протоколов, правила, по которым назначаются IP-адреса и многое другое. Но если бы мы это сделали, то ролик пришлось бы делать часа на два, а то и больше. Но у себя в Телеграме мы выложили логическое продолжение ролика, в котором разбираем всё то, что не вошло, плюс чуть более подробно ныряем в те вещи, о которых говорили в ролике. Ссылка на Telegram есть в описании, а также можно перейти по QR-коду на экране. Ставьте лайки. Подписывайтесь на канал. Всем пока-пока.