Архитектура интернета и веба | Теоретический курс 2026

Приветствую вас в видео, в ходе которого

мы разберём то, как работает интернет и

веб-приложения на уровне сетей,

протоколов и инфраструктуры с точки

зрения разработчика. Мы будем шаг за

шагом разбирать основные принципы и

логику работы, но без углубления,

допустим, в кодирования сигналов или

физику передачи данных. Мы начнём с

основ компьютерных сетей, поймём, как

устройства взаимодействуют между собой,

какую роль играют клиенты сервер и

почему сетевое взаимодействие невозможно

без протоколов. Затем перейдём к

IP-адресации, маршрутизации, разберём,

как пакеты передаются через интернет,

что такое NAT и какие физические

ограничения он накладывает на

приложение. Далее подробно разберём DNS,

как доменные имена превращаются в

IP-адреса и как работает resolving.

После этого перейдём к транспортному

уровню TCP и UDP, установке соединений и

современным протоколам, таким как Quick.

Отдельный блок будет посвящён HTTP, его

устройству, методам, статусам, а также

тому, как поверх него реализуются куки,

сессии и токены. Затем разберём https

ls, принципы шифрования и доверия

сертификатам. Также мы затронем real

time коммуникации, серверную

инфраструктуру, балансировку нагрузки и

CDN. А кроме того, поговорим о DPI и

современных способах анализа и контроля

сетевого трафика. Не забудьте

подписаться на мой Telegram-канал, где

выходят интересные посты про разработку

обновления моих библиотек и спойлеры к

видео. И также, если вам нравится такой

контент, поставьте лайк и подпишитесь на

канал. Это очень поддерживает мою работу

и помогает делать новые видео. Ну и

начнём мы с вами с небольшого пролога.

Он не обязателен к просмотру, но в нём

мы слегка коснёмся физического

устройства интернета. Интернет - это

огромная сеть, состоящая из множества

соединённых между собой сетей.

дата-центры, серверные стойки,

маршрутизаторы и коммутаторы, реальные

устройства, которые круглосуточно

принимают, обрабатывают и передают

данные. Данные перемещаются не целиком,

а в виде маленьких фрагментов, которые

путешествуют независимо друг от друга,

строго по маршрутам, заданным

оборудованием и протоколами. Каждое

открытие сайта - это физический процесс.

Запрос проходит по кабелям, попадает на

сервер, где обрабатывается и

возвращается ответ. Работа серверов

требует энергии, охлаждения и надёжного

подключения. Они постоянно работают, а

системы построены так, чтобы даже при

сбой части оборудования интернет

оставался доступен. Если задуматься,

интернет - это самая большая машина,

когда-либо построенная человечеством.

Она не имеет центра, не принадлежит

одному владельцу и не может быть

выключена одной кнопкой. Всё держится на

стандартах, договорах и строгом

соблюдении правил. Протоколы и

инфраструктура обеспечивают

предсказуемость и надёжность работы этой

системы. И сейчас мы будем разбирать всё

по порядку, начиная с кабелей.

Существует несколько основных типов

кабелей, по которым передают данные.

Медные витые пары, как сильные кабели и

оптоволокно. Они различаются не только

конструкцией, но и физическим принципам

передачи сигналам, дальностью, скоростью

и областью применения. Начнём с медных

кабелей, самой простой и наглядной формы

сетевого соединения. Самый

распространённый тип eernet,

используемый в домашних и офисных сетях.

Внутри такого кабеля находится не один,

а сразу несколько медных проводников.

Обычно восемь, объединённых в четыре

пары. Каждый проводник изолирован, а

сами пары скручены между собой. Скрутка

выполняет сразу несколько задач.

Во-первых, она уменьшает влияние внешних

электромагнитных полей, когда рядом

проходит электрический шум от другого

кабеля. блока питания или

электродвигателя. Он воздействует на оба

проводника пары почти одинаково.

Приёмное устройство сравнивает сигналы

внутри пары и отбрасывает общий шум,

оставляя полезную информацию. Во-вторых,

скрутка снижает влияние соседних пар

друг на другом. Без неё сигнал из одной

пары наводил бы помехи в другой, что

резко снижало бы скорость и надёжность

передачи. Но существует и другой тип

медного кабеля. Как сильный. Он

использовался в телевизионных сетях,

кабельном интернете и ранних

компьютерных сетях. Его конструкция

принципиально отличается. В центре

находится одна сплошная медная жила, по

которой идёт сигнал. Вокруг неё слой

диэлектрика, затем металлическая оплётка

или экран, подключённый к земле, и

внешняя защитная оболочка. Экран

изолирует центральную жилу от внешних

помех и одновременно задаёт стабильную

электрическую среду для распространения

сигнала. Такая конструкция делает как

сил более устойчивым к шумам и позволяет

передавать сигнал дальше без искажений.

Но он менее гибкий, толще и хуже

масштабируется для современных

скоростей. Теперь коротко о том, как

данные проходят по медным кабелям. Я

сейчас не буду углубляться в физику

сигнала и электронику. Здесь мы просто

поймём общую идею. Данные передаются с

помощью электрического сигнала. Цифровая

информация превращается в изменение

напряжения и итога во времени, а также в

форму импульсов. Источником этого

сигнала является активное сетевое

устройство. В компьютере это сетевая

карта. В инфраструктуре в сетевой

инфраструктуре - это порты коммутаторов

и маршрутизаторов.

Сигнал имеет несколько ключевых

характеристик: уровень напряжения,

скорость изменения и длительность

импульсов. Именно их комбинация кодирует

нули и единицы. На принимающей стороне

сетевое оборудование восстанавливает

исходные данные. Тут важно понимать,

сигнал аналоговый, он подвержен

искажением. Основные причины:

сопротивление меди, нагрев проводника,

внешние электромагнитные поля и наводки

от соседних пар. С ростом длины кабеля

помехи накапливаются и данные начинают

теряться. Для компенсации этих потерь

используют повторители и усилители,

которые восстанавливают форму сигнала.

Но даже с ними медные кабели ограничены.

Их скорость и дальность подходят только

для коротких соединений дома, в офисах

или дата-центрах. Для длинных

магистралей и межконтинентальных линий

они непригодны. Для глобального

интернета используется оптволокно. В

отличие от медных линий, здесь передача

данных основана не на электрическом

токе, а на распространении света.

Физической основой оптоволоконного

кабеля является стеклянное волокно. В

самом центре находится сердцевина,

тончайшая нить из сверхчистого стекла

или кварца. Её диаметр сопоставим с

толщиной человеческого волоса. Вокруг

этой сердцевины располагается оболочка

из стекла с другим коэффициентом

преломления. Именно разница этих

коэффициентов заставляет свет

многократно отражаться от границы

материалов и распространяться строго

вдоль волокна, практически не выходя

наружу. А уже снаружием оно окружено

несколькими защитными слоями. Они

включают ароматизирующие покрытия,

силовые элементы и внешнюю изоляцию. Эти

слои никак не участвуют в передаче

данных, но они обеспечивают механическую

прочность кабеля и защищают его от тех

же самых изгибов, там условно влаги,

давления и перепадов температуры. Уже

передача данных начинается в активном

оборудовании. Так называемый трансивер

принимает цифровые данные и превращает

их в последовательность световых

импульсов с помощью лазера или

светодиода. Каждый импульс кодирует

информацию через наличие света,

длительность или фазу. На другом конце

фотодиоды улавливают свет и преобразуют

его обратно в электрический сигнал для

обработки сетевым оборудованием. Главное

отличие оптоволокна от медич не

взаимодействует с внешней средой. Нет

нагрева проводника, нет электромагнитных

наводок, нет влияния внешних полей.

Потери сигнала минимальны, поэтому

усилители и регенераторы ставят на

десятки, а иногда и на сотни километров.

Это позволяет передавать данные на 1.000

км без существенных искажений. Кроме

того, оптоволокно обладает колоссальной

пропускной способностью. Современные

технологии позволяют передавать

несколько независимых потоков данных по

одному и тому же волокну, используя

разные длины волн света. Это делает

оптоволоконные линии основой всей

глобальной сетевой инфраструктуры.

Именно поэтому все современные

магистральные и межконтинентальные

соединения построены на оптоволокне. Для

таких расстояний и объёмов данных

альтернативы ему просто не существует.

После того, как мы разобрали медные и

оптоволоконные кабели, а также их

устройством, роль в инфраструктуре

интернета и, в принципе, их различиям,

давайте перейдём к следующей теме. Как

интернет пересекает океаны и соединяет

целые континенты. Вопреки

распространённому мифу, глобальный

интернет почти не опирается на спутники.

Более 95% мирового трафика проходит по

кабелям. Причина проста: только они дают

необходимую скорость, стабильность и

пропускную способность. Подводные кабели

прокладываются специализированными

кабелеукладочными судами. На борту таких

кораблей находятся гигантские катушки с

кабелем длиной в сотни и тысячи

километров. Маршрут прокладки заранее

рассчитывается с высокой точностью.

Учитывается рельеф дна, сейсмическая

активность, судоходные пути и рыболовные

зоны. Кабель аккуратно укладывают на

дно, а на мелководе его дополнительно

заглубляют в грунт. Кстати, конструкция

подводного кабеля, она значительно

сложнее обычного автоволокна. Внутри,

конечно, всё та же стеклянная

сердцевина, передающая свет, но снаружи

несколько слоёв защиты. Это герметичные

оболочки, армирование остальными жилами,

изоляция от влаги и коррозии. Это

позволяет кабелю годами лежать на

глубине нескольких километров,

выдерживая давление воды, течения и

агрессивную морскую среду. Тем не менее,

риски полностью исключить, конечно же,

невозможно. Подводные кабели иногда

повреждаются якорями судов, рыболовными

тралами или подводными землетрясениями.

Именно поэтому глобальная инфраструктура

строится с расчётом на отказ.

Магистральные маршруты всегда

дублируются, а сетевые протоколы

автоматически перенаправляют трафик по

альтернативным путям. Про это мы будем

говорить в этом видео. Пользователь в

большинстве случаев, в принципе, даже и

не замечает, что где-то на дне океана

произошёл обрыв. Внутри стран

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

национальные телекоммуникационные

операторы. В России эту роль, например,

выполняет в первую очередь Ростлеком и

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

соединяют города, регионы и дата-центры

внутри страны. А межконтинентальные

маршруты - это уже зона ответственности

международных консорциумов и

технологических гигантов. Компании вроде

Google, Amazon и Microsoft инвестируют

миллиарды долларов в строительство

собственных подводных линий. Именно

благодаря этим кабелям интернет стал

по-настоящему глобальным. Без них

современный мир в том виде, к которому

мы привыкли, просто не существовал бы. В

принципе, на этом рассказ про кабели у

нас подходит к концу. Давайте будем

двигаться дальше. Смотрите, сами по себе

кабели, они, конечно же, не делают

интернет интернетом. Это всего лишь

физические дороги. Возникает логичный

вопрос, куда именно приходят все эти

потоки данных и как разные сети

обмениваются трафиком между собой.

Интернет - это огромное количество

независимых сетей, принадлежащих разным

провайдерам. компаниям и организациям.

Чтобы они могли взаимодействовать,

существуют специальные точки соединения.

Они называются Internet Exchange Points

или сокращённо IXP. IXP - это физические

места. Чаще всего они представляют из

себя большие дата-залы, где установлены

мощные коммутаторы и маршрутизаторы.

Сюда напрямую подключаются

интернет-провайдеры, хостинг-компании,

облачные платформы и крупные сервисы.

Через эти узлы проходят терабиты данных

каждую секунду. Когда вы открываете

сайт, ваш запрос может пройти через

несколько таких точек. Он выходит из

сети вашего провайдера, попадает в XP,

оттуда в сеть другого оператора, затем,

возможно, в следующий обменный узел и

только после этого достигает нужного

дата-центра. На этом же уровне начинают

работать CDN, сети доставки контента.

Они размещают копии данных в разных

частях мира и подключаются напрямую к

обменным узлам. Благодаря этому запросы

не всегда идут к исходному серверу, а

обслуживаются в ближайшей точке.

Пользователь просто видит, что сайт

загружается быстрее. Как именно это

устроено и зачем это нужно, мы подробно

разберём позже. То есть, по сути, IXP -

это перекрёстки интернетом, через

которые проходит огромная часть мирового

трафика. Каждый запрос, каждая загрузка

страницы и каждый поток данных почти

наверняка проходят через один или

несколько таких узлов. Именно они

превращают набор отдельных сетей в то,

что мы называем глобальным интернетом.

Теперь давайте поговорим про

дата-центры. Именно сюда направляются

запросы после прохождения сетевой

инфраструктуры. И именно здесь

выполняется основная работа по обработке

данных. Дата-центр представляет собой

комплекс помещений с серверным

оборудованием. Внутри размещаются ряды

серверных стоек, каждая из которых

содержит десятки физических серверов. В

сумме в одном дата-центре может работать

несколько тысяч таких машин. Они

принимают входящие соединения,

обрабатывают запросы, работают с базами

данных и формируют ответы, которые затем

возвращаются обратно в сеть. Работа

такого объёма оборудования требует

значительных энергетических ресурсов.

Серверы выделяют большое количество

тепла, поэтому в дата-центрах

используется постоянное охлаждение.

Воздушные или жидкостные системы

поддерживают стабильную температуру

оборудования и предотвращают перегрев

при длительной нагрузке. Энергопитание в

дата-центрах организовано с

резервированием. Используется несколько

независимых линий питания, источники

бесперебойного питания и дизельные

генераторы. Это позволяет сохранять

работоспособность оборудования при сбоях

внешней электросети без разрыва

соединений. С точки зрения сетевого

взаимодействия, сервер - это не

конкретное устройство, это процесс,

выполняющийся на оборудовании

дата-центра. Этот процесс слушает

определённый порт, принимает сетевые

соединения и обрабатывает запросы. Он

может быть перезапущен или перенесён на

другое физическое оборудование без

изменения поведения сервиса для

пользователя. Дата-центры подключаются

напрямую к магистральным сетям и точкам

обмена трафиком. Это позволяет запросам,

прошедшим через интернет-инфраструктуру,

попадать в вычислительную среду с

минимальными задержками. Теперь, когда

мы более-менее рассмотрели кабели, точки

обмена трафиком и датацентры, можно

собрать эту инфраструктуру в единую

цепочку и проследить полный физический

путь данных от устройства пользователя

до сервера и обратно. Начинается всё у

вас дома. Когда вы открываете сайт и

нажимаете Enter, браузер формирует

сетевой запрос, набор байтов в памяти

компьютера. Операционная система

передаёт эти данные в сетевой стек, где

они разбиваются на пакеты и отправляются

в сетевую карту. Сетевая карта

преобразует цифровые данные в физический

сигнал. Если подключение проводное - это

электрический сигнал повитой паре. Если

используется оптоволокно, то сигнал

формируется сразу в виде световых

импульсов. А и в случае Wi-Fi данные

сначала передаются по радиоканалу до

роутера, а уже затем уходят дальше по

кабелю. Далее сигнал попадает на

оборудование интернет-провайдером. На

данном участке данные проходят через

коммутаторы и маршрутизаторы провайдера,

которые направляют пакеты дальше по

сети. Внутри города и между городами

почти всегда используется оптоволокно,

поэтому электрический сигнал на входе

преобразуется в оптический и

распространяется по магистральным линиям

связи. Если сервер находится в другой

стране или на другом континенте, данные

выходят на международные магистрали,

соответственно.

На другой стороне магистрали данные

попадают в сеть уже другого оператора и

проходят через точки обмена трафиком.

Это физические узлы, где сети разных

компаний соединяются напрямом, как мы

уже говорили. Здесь маршрутизаторы

принимают решение, в какую сеть передать

пакет дальше, чтобы они дошли до нужного

дата-центра. После этого запрос попадает

в сам дата-центр. Магистральное

оптоволокно подключается к сетевому

оборудованию дата-центром, откуда трафик

распределяется по внутренним сетям.

Пакеты доходят до конкретной серверной

стойки, затем до сетевого порта нужного

сервера. На сервере физический сигнал

преобразуется обратно в цифровые данные.

Операционная система передаёт их

серверному приложению, которое

обрабатывает запрос, читает данные из

памяти или базы данных и уже затем

формирует ответ. А сам ответ проходит

абсолютно тот же путь, просто в обратном

направлении. Он снова превращается в

физический сигнал, выходит из

дата-центра, проходит через

магистральные сети, точки обмена

трафиком и сеть провайдера, после чего

возвращается к вашему устройству. Ответ,

в свою очередь, проходит тот же путь в

обратном направлении. Он снова

превращается в физический сигнал,

выходит из дата-центра, проходит через

магистральные сети, точки обмена

трафиком и сеть провайдера, после чего

возвращается к вашему устройству.

Сетевая карта принимает сигнал,

восстанавливает данные, и браузер

отображает результат. Теперь у нас есть

какая-никакая картина физического уровня

интернета, от устройства пользователя до

дата-центра и обратно. Дальше мы

поднимаемся на следующий уровень. Мы

поговорим о сетях и адресации, о том,

как устройство находят друг другом, как

выбираются маршруты, как работает ДНС и

почему запросы всегда приходят туда,

куда нужно. Ну и начнём мы с самого

базового, с компьютерных сетей.

Компьютерная сеть - это способ, с

помощью которого устройства могут

обмениваться данными. В самом базовом

виде сеть состоит из как минимум двух

устройств и канала связи между ними.

Устройство может отправлять данные,

другое- их принимать. А для сети на этом

уровне больше ничего не требуется. При

этом совершенно неважно, какие именно

это устройства. Это может быть

компьютер, телефон, сервер или любое

другое оборудование, способное

передавать данные. Также не имеет

значения и расстояние между ними.

Устройства могут находиться в одной

комнате или на разных концах мира. А

канал связи - это среда, по которой

передаются данные. Им может быть

физический кабель, Wi-Fi или мобильная

сеть. Для базового понимания сети

разницы между этими вариантами нет.

Данные просто перемещаются от одного

устройства к другому. И тут важно

понимать, что сама сеть не знает ничего

о сайтах, браузерах или приложениях. Она

не понимает, что такое страница, кнопка

или форма на сайте. На этом уровне сеть

занимается только передачей байтов,

последовательности данных без смысла и

контекста. Ну а простая передача байтов

- это ещё неполноценное общение. Как

многие знают, байты - это просто

последовательности нулей и единиц. Один

компьютер их отправляет, другой

получает, но сами по себе эти цифры

ничего не значат. Без правил устройства

не смогут понять, что именно

представляет собой каждый байт, и обмен

просто-напросто будет бессмысленным.

Вот, чтобы данные имели смысл для

получателя, используются протоколы - это

набор строгих правил и соглашений.

Протокол определяет, как данные делятся

на пакеты, как проверяется их

целостность, какой порядок передачи,

какие заголовки использовать и как

устройства реагируют на ошибки. Иными

словами, протокол - это общий язык, на

котором устройства разговаривают. Без

него сеть не сможет работать, независимо

от того, какой канал связи используется

или где находятся сами устройства. И

такие самые популярные протоколы - это

HTTP, TCP и UDP. HTTP позволяет

обмениваться веб-страницами. TCP

обеспечивает надёжную доставку и порядок

пакетов, а UDP быструю, но ненадёжную

передачу, например, для видео игр. Все

эти правила позволяют разным устройствам

обмениваться данными корректно и

предсказуемо. Сами протоколы мы будем

разбирать в течение этого видео. А пока

давайте мы разберёмся, как данные

физически перемещаются по сети, особенно

когда речь идёт о больших расстояниях.

Начнём с масштаба сети. А есть локальная

сеть или Local Area Network. Это сеть в

пределах небольшого пространства,

например, квартира или офис. То есть

компьютеры, телефоны, серверы и другие

устройства, они находятся рядом и

соединены напрямую через минимальное

количество промежуточного оборудования.

В локальной сети данные проходят очень

короткий путь. Обычно между отправителем

и получателем всего один роутер или,

может быть, вообще прямое соединение,

поэтому задержки тут минимальные, а

скорость передачи очень высокая. Ну,

также у нас есть и глобальная сеть или

One, что расшифровывается как White Area

Network. Это уже совсем другой масштаб.

Это сеть, которая по факту объединяет

между собой множество локальных сетей.

Как я уже говорил в прологе, когда вы

открываете сайт, ваше устройство не

общается напрямую с сервером. Между вами

и сервером находятся десятки или даже

сотни промежуточных узлов: кабели,

стойки, маршрутизаторы и дата-центры. И

здесь возникает логичный вопрос: если

данные проходят через такое количество

устройств и каналов связи, как вообще

можно передать информацию надёжно и

эффективно? Ответ: пакеты. В

компьютерных сетях данные никогда не

передаются целиком одним большим блоком.

Любая информация, текст, изображения,

видео, HTTP запрос или ответ сервером

сначала разбивается на небольшие части.

Эти части и называются пакетами.

Предлагаю рассмотреть небольшой пример.

Вы заходите в Telegram и выполняете

какое-то действие. Ну, например, вводите

текст сообщения и нажимаете кнопку

отправки. Ваше устройство формирует

поток байтов. Далее сетевой стек

операционной системы разбивает этот

поток на пакеты фиксированного или

ограниченного размера. И каждый пакет

является самостоятельной единицей

передачи и может обрабатываться сетью

независимо от остальных. Любой сетевой

пакет у нас состоит из двух частей:

заголовка и полезной нагрузки. Смотрите,

заголовок, он содержит служебную

информацию, необходимую для доставки

этого пакета и его обработки. В нём

указываются такие данные, как IP-адрес

отправителя, IP-адрес получателя,

информация о протоколе, порядковый номер

или идентификатор пакета, технические

флаги и служебные поля. Технические

флаги - это управляющие параметры,

которые определяют поведение при

передаче. Они могут указывать, например,

начало или завершение передачи,

необходимость подтверждения получения,

состояние соединения и особенности

обработки пакета. А служебные поля

используются для контроля целостности

данных, управления потоком и корректной

сборки пакетов на принимающей стороне.

Уже сама полезная нагрузка - это

непосредственно часть передаваемых

данных. Каждый пакет содержит лишь

небольшой фрагмент общего потока. Только

что я сказал, что после формирования

пакеты отправляются в сеть по

отдельности, и в глобальной сети для них

отсутствует единый заранее заданный

маршрут. Мы уже знаем, что между

отправителем и получателем достаточно

большой путь. Провайдеры, магистральные

сети и так далее. И вот каждый

промежуточный узел, допустим,

маршрутизатор, принимает решение только

о следующем шаге передачи, не зная

полного пути пакета. В результате пакеты

одного и того же потока могут идти по

разным маршрутам, приходить с разной

задержкой, поступать в неправильном

порядке и временно теряться. Уже на

принимающей стороне пакеты не

интерпретируются сразу как данные

приложения. Сначала анализируются

заголовки, то есть проверяется

целостность, определяется принадлежность

к потоку и восстанавливается правильная

последовательность. При использовании

надёжных протоколов потерянные пакеты

запрашиваются повторно. При

использовании ненадёжных протоколов

пропущенные данные игнорируются. И

только после этого восстановленный поток

байтов передаётся на уровень приложения,

где уже применяется логика конкретного

сервиса. В данном случае это Telegram.

Точно такой же процесс происходит и в

обратную сторону, когда сервер

отправляет данные вашему устройству.

Теперь переходим к следующей части

первой главы, первого модуля. И давайте

чуть подробнее разберём типы сетей. Как

мы разбирали, у нас существуют локальные

сети LAN Local Area Network и One White

Area Network. Но кроме вот этих двух

есть ещё несколько интересных типов

сетей, которые занимают промежуточное

место между локальными и глобальными

системами. Это MAN Metropolitan Area

Network и PEN Personal Area Network.

Начнём с Menли городской сети. Это сеть,

которая охватывает один город или

какой-то крупный кампус. Представьте,

что несколько офисных зданий в одном

районе соединены между собой высокой

пропускной способностью через

оптоволоконные линии. Они могут

обмениваться данными быстрее, чем если

бы это был, например, обычный oneн

Network, потому что расстояние меньше,

инфраструктура оптимизирована, а

маршруты тщательно спроектированы. В

отличие от One, man обычно не соединяет

города между собой, и управление такой

сетью часто, в принципе, централизовано

в пределах города или какой-то

определённой организации. Именно поэтому

её нельзя считать в Н, потому что

масштаб у неё меньше, контроль,

соответственно, выше, и сеть не требует

глобальной маршрутизации. Что касается

PEN, Personal Area Network или

персональной сети, это самая маленькая

сеть из всех, которую вы можете

встретить вокруг себя каждый день. Она

объединяет устройство одного человека,

это ноутбук, телефон, планшет, наушники

или там условно какие-нибудь смарт-часы.

В такой сети используются технологии

вроде блюuтуза, USB или иногда Wi-Fi на

коротких расстояниях. Пен очень

ограничена по расстоянию, пропускной

способности и количеству устройств. И её

основная задача - это обеспечить удобную

синхронизацию и обмен данными между

личными устройствами. Это совершенно

другой уровень, чем а потому что ПА он

не объединяет множество пользователей,

он не работает через провайдеров и, в

принципе, не нуждается в глобальной

маршрутизации. Двигаемся дальше и

давайте перейдём к следующей, а, скажем

так, концепции, которая определяет

структуру глобального интернета - это

автономные системы или AS, Autonomous

Systems. Автономная система - это

большая сеть или совокупность сетей,

управляемых одной организацией. Это

может быть интернет-провайдер, какая-то

крупная компания или облачный сервис.

Каждая такая автономная система имеет

уникальный идентификатор. Он называется

ACN autonomous System Number, который

позволяет другим сетям понимать, с кем

они обмениваются трафиком. И внутри

автономной системы данные могут

передаваться по любым внутренним

маршрутам, оптимизированным для

скорости, надёжности и нагрузки. Однако

для обмена трафика между разными

автономными системами используется уже

такой специальный протокол под названием

BGP или если расшифровать, получится

Border Gateway Protocol. Он решает по

каким путям пакеты будут передаваться

между сетями в масштабах, в принципе

всего интернета. И вот благодаря как раз

автономным системам интернет не является

хаотичной мешаниной сетей. Каждая такая

AS управляет своей частью

инфраструктуры, но взаимодействует с

другими по чётко определённым правилам.

Ну вот, например, когда вы открываете

YouTube, трафик сначала проходит через

автономную систему вашего

интернет-провайдера, допустим, МТС или

Ростлеком, затем через одну или

несколько магистральных AS, и только

после этого попадает в автономную

систему Google, где расположены уже

сервера Ютуба. И каждый из этих этапов

контролируется своей автономной

системой, собственными правилами

маршрутизации. Давайте теперь вернёмся к

протоколам. Как мы уже знаем, это

правила, на которых строится общение

устройств сети. И вот теперь давайте мы

рассмотрим, откуда вообще берутся

протоколы и кто их разрабатывает. Это

такое будет небольшое отступление. А

сами транспортные протоколы TCP и UDP мы

разберём позже. Смотрите, каждый

протокол он рождается из конкретной

потребности. Когда появились первые

сети, стало очевидно, что без единых

правил устройства просто не смогут

понять друг друга. И нужно было

определить, как структурировать данные,

делить их на пакеты, проверять ошибки и

восстанавливать порядок. То есть это

реальные задача коммуникации между

устройствами, которые усложняются вместе

с сетью. С ростом интернета стало

понятно, что одно устройство или

программа не могут задавать правила

всему миру. Протоколы должны быть

едиными, открытыми и понятными для всех.

Поэтому существуют специальные

организации, занимающиеся разработкой и

стандартизацией протоколов, чтобы новые

технологии работали вместе с уже

существующими. И вот благодаря

стандартизации ваш браузер может

взаимодействовать с сервером на другом

конце планеты, независимо от

производителя или оборудования. Именно

поэтому мы до сих пор используем TCP, IP

и HTTP. Их принципы остались прежними, а

новые версии лишь адаптируют их под

современные требования. А давайте ещё

кратко разберём про то, кто занимается

их разработкой, разработкой протоколов.

Существует несколько таких, наверное,

самых ключевых организаций. Самое

известное из них - это IETF

или, если расшифровать, это Internetk

Force. Это сообщество инженеров,

разработчиков и экспертов, которые

добровольно этот обсуждают, предлагают и

утверждают новые протоколы и стандарты.

Она как бы, понятное дело, не управляет

интернетом, она как бы создаёт и задаёт

эти правила игры, которые уже все

участники сети соблюдают. Кроме этой

организации есть и другие организации.

Например, ISO - это международная

организация по стандартизации, которая

формирует общие стандарты для сетевых

технологий, включая модель OSI, про

которую мы сейчас поговорим. А кроме неё

есть ещё такая организация, как ITE или,

если расшифровать Institute of

Electronical and Electronics Engineers.

Это институт инженеров электротехники и

электроники, который разрабатывает

стандарты для локальных сетей, таких как

ERNet и Wi-Fi. Все эти организации, они

работают независимо друг от друга. Ну

вот, как мы видим, их усилия, они

дополняют друг друга и создают единый

язык для абсолютно всех устройств. То

есть получается, что протоколы - это

результат работы тысяч инженеров по

всему миру. После такого отступления про

сами протоколы и кто их кто занимается

их разработкой, давайте мы с вами

перейдём к следующей концепции. Это

модель OSI, про которую я сейчас

упомянул. Смотрите, OSI - это

аббревиатура от Open Systems

Interconnection. И на самом деле это не

какая-то конкретная технология или

протокол. Это концептуальная модель,

которая помогает понять, как данные

перемещаются от одного устройства к

другому. Как мы уже знаем, информация в

сети разбивается на пакеты, проходит

через множество устройств и

промежуточных узлов. OSI даёт нам

инструмент, чтобы структурировать этот

процесс и объяснить, что происходит на

каждом этапе передачи данных. Эта модель

разделяет сетевое взаимодействие на семь

логических уровней. Каждый уровень

отвечает за свою часть работы, и при

этом уровни взаимодействуют друг с

другом строго по порядку. То есть, если

какой-то уровень сталкивается с

проблемой, её проще диагностировать или

исправить, потому что мы точно знаем,

какая часть цепочки отвечает за ту или

иную функцию. Давайте мы эти а уровни и

разберём. Первый уровень, он называется

physical, ну, то есть физический. Здесь

мы уже знакомы с этой темой из пролога.

Этот уровень отвечает за физическую

передачу сигналов электрические импульсы

в медных кабелях, световые импульсы в

оптоволокне, радиосигналы в Wi-Fi или

мобильных сетях. Второй уровень Datalink

- это уровень канала передачи данных.

Здесь информация организуется в так

называемые кадры, которые включают

адреса устройств локальной сети,

Мак-адреса. Он обеспечивает корректную

передачу данных между устройствами

внутри одной локальной сети и проверяет

ошибки, которые могут возникнуть на

физическом уровне, например, и из-за

помех в кабеле. Третий уровень

называется network. Это сетевой уровень.

Это то место, где используются IP-адреса

и происходит маршрутизация между сетями.

Помните, мы говорили о ван, ман и

пакетах. Именно сетевой уровень решает,

как пакеты добираются от одного узла до

другого через множество промежуточных

автономных систем. Четвёртый уровень

называется транспорт. Транспортный. На

этом уровне управляется доставка и

порядок пакетов. Именно данный уровень

гарантирует, что пакеты, которые мы

разбивали при отправке сообщения или

видео, приходят в правильной

последовательности и что потерянные

пакеты могут быть повторно отправлены.

Как раз TCP и UDP работают именно на

этом уровне. Пятый уровень называется

session, сеансовый. Он отвечает за

установку, поддержку и завершение

соединений между приложениями на разных

устройствах. Например, когда вы

открываете видео на Ютубе, сеансовый

уровень обеспечивает, что связь с

сервером сохраняется во время просмотра,

точнее на время просмотра, а затем она

корректно закрывается. Следом идёт

шестой уровень presentation

представления. Он занимается форматом

данных, кодировкой и шифрованием. Это

тот уровень, который следит за тем,

чтобы текст изображения или видео,

отправленные одним устройством,

правильно отображались на другом. И,

наконец, седьмой уровень application

прикладной. Это всё то, что мы видим как

конечные пользователям: браузеры,

мессенджеры, электронная почта и

стриминговые сервисы. Этот уровень

взаимодействует с пользователями и

используют все нижние уровни для

передачи данных и получения ответов.

Именно разделение на уровне делает

модель USI такой мощной для понимания

сетей. И хотя на практике интернет не

используют напрямую OSI, и современные

сети строятся по модели TCP и IP, OSI

остаётся невероятно полезной концепцией.

По сути, это своего рода удобная карта

сети, которая показывает, что происходит

на каждом этапе передачи данных от

физического сигнала до прикладного

приложения. Ну и теперь я предлагаю

перейти уже к практическим моделям,

таким как TCP и IP, и сопоставим их с

этой концептуальной схемой. Если OSI,

как мы выяснили, это удобная

теоретическая схема, то TCP и IP - это

набор протоколов и правил, по которым

данные передаются в сети каждый день.

Именно по этой модели работают все

веб-сайты, мессенджеры, стриминговые

сервисы и облачные приложения. А модель

TCP и IP, она более компактная и

практичная, чем OSI. Здесь вместо семи

всего четыре уровня, но, несмотря на

меньшую детализацию, она охватывает всё

то же самое, что мы с вами рассматривали

в OSI. просто, а, она объединяет как бы

некоторые функции и делает их более

прикладными. Давайте мы, собственно, эти

четыре уровня и разберём. Первый уровень

называется Network Interfей или уровень

сетевого доступа. Это физическая и

канальная часть того, что в OSI делится

на Physical и Datalink. На этом уровне

устройство знает, как физически

передавать пакеты через кабели,

оптоволокно, Wi-Fi или мобильную сеть, и

как адресовать их в пределах локальной

сети. Всё то, о чём мы говорили про

кабели, повторители, роутеры и локальные

сети, здесь полностью используются на

практике. Второй уровень интернет. Он

отвечает за доставку пакетов между

сетями, то есть за маршрутизацию. Именно

здесь используется протокол IP, который

позволяет каждому пакету найти путь

через множество автономных систем.

Третий уровень называется транспорт.

Транспортный. Здесь работают TCP и UDP.

Этот уровень напрямую обеспечивает

надёжность, контроль последовательности

и целостность данных, которые мы так

подробно рассматривали

на примере с Телеграмом. И последний,

четвёртый уровень называется

Application. Прикладной уровень. Он

объединяет всё то, что находится на

верхних уровнях OSI: сеансовый,

презентационной и прикладной. Здесь

работают HTTP, HTTPs, FTP, SMTP, DNS и

другие протоколы, которые

взаимодействуют с пользователем и

обеспечивают реальный обмен данными

между приложениями. Ну что же, на этом,

в принципе, мы с вами разобрали четыре

уровня модели MTCP.

Здесь опять-таки хочу отметить, что мы

сейчас не углубляемся в детали каждого

протокола. Мы их разберём чуть позже.

Как бы важно усвоить просто, что

application уровень - это то место, где,

а, цифровые сигналы и пакеты

превращаются в понятные человеку

действия и сервисы. Ну и, в принципе, на

этом давайте подведём главную

особенность как бы TCP IP. Она

заключается в том, что она максимально

приближена к реальному миру и решает

конкретные задачи. Как доставить пакет

от вашего устройства до сервера, как

гарантировать их порядок и целостность,

и как взаимодействовать с сетевыми

приложениями. В принципе, на этом конец.

В принципе, на этом второй, точнее,

первый модуль у нас подходит к концу.

Подведём такие небольшие итоги. Мы с

вами здесь разобрали, что такое сеть и

как она работает. То есть то, что данные

всегда передаются пакетами, а протоколы

обеспечивают их правильную доставку. А

мы также с вами поговорили про типы

сетей, а познакомились с автономными

системами, которые управляют

маршрутизацией.

Ну и, наконец, рассмотрели сами модели

сетей OSI с семью уровнями и

практическую TCP и IP с четырьмя

уровнями. И теперь с этой базой мы можем

дальше углубляться уже в маршрутизацию.

Ну и переходить, соответственно, ко

второму модулю. Ну и для начала давайте

разберём, что такое IP, а также его

версия. IP

расшифровывается как интернет-протокол -

это цифровой адрес в сети. Он позволяет

точно определить, откуда пришёл пакет и

куда он должен попасть. Его можно

представить, ну, IP можно представить

как своего роду почтовый адрес. Чтобы

отправить письмо, нужен адрес

получателя. Чтобы получить ответ, нужно

указать, соответственно, обратный адрес.

И, как мы уже знаем, в каждом сетевом

пакете IP-адреса от правителя и

получателя, они записаны в заголовке.

Теперь давайте мы с вами, а, разберём

ключевые вещи в IP-адресах. То есть как

они устроены, зачем они нужны, как

генерируются и чем отличаются старые IP

версииче от нового IP версии 6. Начнём с

версии 4, потому что а она была а первым

стандартом и до сих пор, в принципе,

активно используется. Смотрите, IP V4 -

это тридцатидвухбитный числовой

идентификатор. В привычном виде он

записывается через точки. Пример вы

видите у себя на экране, но под этой

записью скрывается последовательность из

32 нулей и единиц. И чтобы такой длинный

набор цифр было проще читать и

использовать, адрес делят на четыре

блока по 8 бит актетом. Каждый такой

актет может принимать значение от нуля

до 255.

Если посмотреть глубже, каждый блок -

это двоичное число. Расшифровку вы

видите у себя на экране, и можно

посмотреть, во что превращается 192,

168, 1 и 10. И вот как раз соединив эти

блоки вместе, мы получаем ровно 32 бита,

полный IP4 адрес. Но IP-адрес - это не

просто набор каких-то рандомных чисел.

Он имеет структуру, которая помогает

сети понимать, куда направлять данные.

Одна часть адреса указывает сеть, а

другая конкретное устройство внутри неё.

Это похоже на почтовый адрес, как я

приводил пример выше. То то есть сначала

письмо доставляют в нужный город, а

затем на улицу и только потом к нужному

дому. И точно также пакет сначала

попадает в нужную сеть, а уже внутри неё

находит конкретное устройство. Ну только

есть как бы одна проблемка. Смотрите,

IP4 он создавался в эпоху, когда

интернет ещё не был настолько глобальной

инфраструктурой, какой мы её знаем

сейчас. 32 бита позволяют создать чуть

более 4 млрд адресов. И когда вот этот

стандарт появился, этого оказалось более

чем достаточно. Однако с ростом числа

компьютеров, смартфонов, серверов и

других устройств стало понятно, что

адресное пространство заканчивается.

Кроме того, часть адресов

зарезервирована для специальных задач.

это внутренние сети, тестирование и так

далее. И как раз всё это ускорило

переход индустрии к новому стандарту IP

V6. IP шестой версии стал эволюционным

продолжением IP4 и решает ключевую

проблему и хватку адресов. Вме главное

отличие тут заключается в длине адреса.

Вместо 32 бит используется 128.

Это число настолько велико, что

позволяет присвоить уникальный адрес

каждому устройству на планете с огромным

запасом на будущее. Адреса IP V6

выглядят иначе. Они записываются в

шестнадцатиричной системе, а делятся на

восемь блоков по 16 бит и разделяются

двоеточиями. Пример вы видите у себя на

экране. И чтобы запись не была настолько

громозкая, последовательности нулей а

ещё можно сокращать. В результате тот же

адрес может выглядеть другим способом.

Вы видите сейчас у себя на экране, как

он может выглядеть. Структура IP шестой

версии также делится на две части.

Первая часть, она определяет сеть,

которой, а, в которой находится

устройство. Вторая - это как бы

уникальный идентификатор интерфейса

внутри этой сети. А главная идея IP V6

заключается в том, что теперь можно

строить сети без оглядки на нехватку

адресов. Каждое устройство может иметь

уникальные публичный IP и быть доступным

напрямую. Это упрощает взаимодействие

между системами, делает сети гибче и

подготавливает интернет к дальнейшему

росту. Однако, чтобы эффективно

управлять адресным пространством и

понимать, какие устройства находятся в

одной сети, одних адресов, конечно же,

недостаточно. Нужен механизм, который

явно показывает границу между сетью и

устройствами внутри неё. И поэтому

сейчас мы с вами поговорим про Sider.

Sider расшифровывается как Class Inter

domain routing. Это способ записи

IP-адресов, который показывает, какая

часть адреса относится к сети, а какая к

устройствам внутри неё. Сегодня этот

подход используется повсюду: от домашних

роутеров до глобальной инфраструктуры

интернета. Ранее IP-адреса

распределялись по жёсткой системе

классов. Давайте мы их разберём. У нас

существовали большие сети, средние и

маленькие. Ну, тут есть проблема. Это

приводило к огромным потерям адресов.

Например, если компании требовалось

около 500 адресов, маленькой сети было

недостаточно, а следующая категория, она

предоставляла десятки тысяч адресов,

большинство из которых оставались

попросту неиспользованными.

И когда интернет начал стремительно

расти, стало очевидно, что такой подход

не масштабируется. И вот тут

потребовалась система, которая позволяет

выделять ролл на столько адресов,

сколько необходимо. Так и появился

сайer. Сейчас вы видите у себя запись на

экране. Это IP-адрес 192168

100/24.

А эта запись показывает, что первые 24

бита адреса используются для обозначения

сети. Поскольку IP4 содержит 32 бита,

остаётся 8 бит для устройств внутри неё.

Именно эта часть определяет, сколько

устройств можно подключить. И,

соответственно, если доступно 8 бит, это

даёт 256 возможных адресов. Однако один

адрес обозначает саму сеть, а последний

используется для широковещательной

рассылки или, как это называется,

broadcast. Это специальный адрес, при

отправке на который пакет получает все

устройства внутри подсети. Ну, короче, в

итоге для устройства остаётся 254

адресом. Это этого более чем достаточно

для квартиры или небольшого офиса. И

получается, что сайдрон позволяет

создавать сети нужного размера,

уменьшает объём маршрутизации и

предотвращает бессмысленную потерю

адресов. Без него IP4 закончился бы

гораздо быстрее, а маршрутизация стала

бы чрезмерно сложной. Хорошо, сайer мы

разобрались. То есть, когда мы видим

запись вида/24,

мы понимаем, какая часть адреса

относится к сети. Но как это определяют

сами устройство? Для этого как раз

используется маска под сети. Это

специальное значение, показывающее, где

заканчивается сеть и начинается хост. В

двоичном виде маска представляет собой

последовательность единиц и нулей.

Единицы, они обозначают сеть, нули,

устройство. А для сети/24 маска выглядит

следующим образом. Вы видите сейчас у

себя её на экране. А в привычном форме

это выглядит следующим образом.

Получается, что всё, что попадает под

единицы, относится к сети, а всё, что

под нулим, к устройствам внутри неё.

Сейчас на экране вы у себя видите разбор

адресом какого-то, допустим, устройства.

То есть мы поняли, что сайд и маска под

сети - это две формы записи одной и той

же идеи. Сайдер, он просто удобен для

людей и маршрутизации, а маски

используются в настройках устройств и

сетевых протоколах. Теперь, когда мы

более-менее разобрались, а как

устройства получают адреса и как сеть

определяет их расположение, логично

перейти к следующему уровню

идентификации.

Если IP-адрес можно сравнить с адресом

дома, то порт, э, про который мы сейчас

и будем говорить - это номер квартиры

или дверь внутри этого дома. Именно порт

определяет, какое приложение на

устройстве должно принять данные. Порт

представляет собой логический номер,

который позволяет нескольким программам

одновременно использовать сеть, не мешая

друг другу. Когда данные приходят на

устройство, операционная система смотрит

не только на IP-адрес, но и на номер

портам, чтобы передать их нужному

приложению. Получается, что полный

сетевой адрес всегда состоит из трёх

элементов. Это транспортный протокол,

IP-адрес и номер порта. IP-адрес

указывает, куда доставить данные, а

порт, какая программа их ожидает. С

технической точки зрения порт - это

число от нуля до 65.535,

передаваемое внутри заголовкой TCP или

UDP. Исторически порты разделены по

назначению. Нижний диапазон закреплён за

стандартными сервисами. Допустим,

веб-серверы используют порт 80,

защищённые соединения HTTPS 443,

а удалённое управление ПСh двадцать

второй порт. Эти номера известны и

стандартизированы, чтобы клиенты могли

подключаться к сервисам без

дополнительной настройки. Выше

располагаются порты, которые

используются приложениями и сервисами, а

ещё выше динамический диапазон, который

применяется клиентскими устройствами для

исходящих соединений. То есть, когда

браузер открывает веб-страницу, он

временно выбирает свободный порт,

использует его для соединения и

освобождает после завершение обмена.

Именно поэтому говорят, что сервер

слушает порт. Это означает, что

программа постоянно ожидает входящие

соединения на определённом номере.

Клиенты подключаются к этому порту, а

сервер обрабатывает запросы и отправляет

ответы. После того, как мы с вами

разобрали IP-адресацию и маршрутизацию,

переходим к Давайте перейдём к теме

маршрутизации. По-моему, я уже говорил в

этом видео, на всякий случай повторюсь,

что каждый пакет, проходящий через

интернет, он не знает весь путь до

получателя заранее. Представьте себе

путешествие по огромному лабиринту, где

каждый перекрёсток решает, куда

отправить вас дальше. В сети эту роль

выполняют маршрутизаторы. Каждый

маршрутизатор смотрит только на

следующую точку назначения и принимает

решение, куда отправить пакет дальше.

Этот принцип называется хоп byхоп. Шаг

за шагом. Пакет движется через сеть от

одного маршрутизатора к другому, и

каждый шаг зависит только от локальной

информации текущего устройства.

Маршрутизаторы используют так называемые

таблицы маршрутизации, которые

напоминают карту дорог. В этих таблицах

прописано, через какие интерфейсы

доступны разные сети. Когда пакет

приходит, маршрутизатор сверяет адрес

получателя с картой и отправляет пакет

туда, где он приблизится к целям. То

есть, если часть сети перегружена или

недоступна, пакеты обходят проблемный

участок. На стороне получателя система

собирает их в правильном порядке,

проверяет целостность и устраняет

потери. Переходим к следующей теме. И

здесь мы давайте с вами поговорим про

одну, скажем так, проблемку. Смотрите,

каждое устройство в сети, оно нуждается

в уникальном адресе для обмена данными.

Однако, понятное дело, что глобальных IP

V4 адресов недостаточно, и подключать

каждое устройство напрямую к интернету

просто невозможно.

И здесь у нас появляется NAT, что

расшифровывается как network Adress

translation. Эта технология позволяет

множеству устройств локальной сети

работать через один публичный IP,

скрывая внутреннюю структуру сети от

внешнего мира. Вот, допустим, у вас есть

роутер, к которому и подключены ваши

компьютеры, смартфоны, планшеты и так

далее. Но снаружи виден только один

адрес. Когда любое устройство отправляет

запрос в интернет, NAT заменяет его

внутренний адрес на внешний и

запоминает, кто отправил запрос. Таким

образом, ответ от внешнего сервера

вернётся именно на то устройство,

которое его ожидало. Для управления

большим числом устройств часто

используют ПАД по Portress Translation.

Пад добавляет каждому соединению

уникальный номер порта, что позволяет

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

тысячи запросов и направлять ответы

корректно. Благодаря этому все

устройства могут использовать один IP.

При этом интернет не путается, кому

какой ответ нужен. Однако над создаёт

проблемы, когда нужно, чтобы внешние

пользователи напрямую подключались к

внутреннему устройству. Если вы хотите

запустить собственный сервер или

онлайн-сервис, стандартный над

недостаточен. Интернет видит только один

адрес, и соединение не может попасть

внутрь вашей локальной сети. Но есть

решение портфовординг или

перенаправление портов. Роутер получает

запрос на определённый порт и пересылает

его конкретному устройству. Современные

провайдеры также часто используют CGN

когда сотни пользователей делят один

публичный IP. Это позволяет экономить

адреса, но усложняет прямое подключение

к устройствам. В таких сетях

портфовординг может не работать, а

запуск собственного сервера превращается

в достаточно сложную задачу. При этом

НАТО остаётся важнейшим инструментом. Он

не только экономит адреса, но и повышает

безопасность сети, скрывая внутреннее

устройство от прямых атак извне.

Получается, что NAT и PAD помогают

создать управляемую сеть, где каждое

устройство имеет доступ в интернет, но

при этом скрыты внутренние детали. И

если НАТ заботится о том, как устройства

видят интернет, то внутри локальной сети

важно управлять адресами так, чтобы всё

работало автоматически и без и без

конфликтов. Именно здесь появляется

DHCP.

DHCP расшифровывается как Dynamic Host

Configuration Protocol. Это протокол,

который выдаёт IP-адреса и всю

необходимую информацию для подключения.

Маску под сети, адрес шлюза, DNS. Когда

устройство подключается к сети, оно

посылает запрос: "Мне нужен адрес". В

свою очередь DHCP сервер отвечает,

назначая свободное IP на определённое

время. Это называется лизинг. И по

истечении срока лизинга устройство может

получить тот же адрес или какой-то

новый. А лизинг здесь играет ключевую

роль. Он предотвращает конфликты, когда

два устройства случайно получают один

адрес и одновременно позволяет повторно

использовать IP, если устройство

отключилось. Это делает сеть динамичной

и устойчивой даже при постоянном

подключении и отключении большого числа

устройств. DHCP особенно удобен для

пользователей. Подключение к сети

происходит мгновенно, без ручной

настройки, а сеть остаётся

упорядоченной. Но для серверов

динамическая выдача адресов непрактична.

Серверы должны быть доступны по

постоянному адресу, иначе клиенты их

попросту не найдут. Ну что же, в

принципе, на этом модуль 2 у нас

подходит к концом. Ну и мы переходим к

третьему модулю, в котором мы с вами

поговорим про DNS. Каждый день мы

открываем браузер и вводим адреса сайтов

в google.com, youtube.com или

github.com. Мы легко запоминаем эти

имена, делимся имим и сохраняем

закладки. Но компьютеры эти слова не

понимают. Чтобы открыть сайт, устройству

нужен IP-адрес сервера, на котором он

расположен. Возникает вопрос: как

интернет узнаёт, какой числовой адрес

скрывается за привычным доменным именем?

Как раз эту задачу решает DNS, что

расшифровывается как domain name system.

DNS переводит понятные человеку доменные

имена в IP-адреса понятные сети. DNS

переводит понятную DNS переводит

понятные человеку доменные имена в

IP-адреса. Можно представить его как

телефонную книгу интернета. Вы вводите

имя, а система превращает его в нужный

номер. Но DNS - это не какой-то там

единый реестр или сервером. Это система,

построеная по иерархическому принципу,

благодаря которому интернет остаётся

масштабируемым и устойчивым. На самом

верхнем уровне находятся корневые

DNS-сервера. Это Root Servers. Они не

знают адрес каждого сайта, но знают, где

искать информацию дальше. Если

представить DNS в виде дерева, корневые

серверы - это его основа. Следующий

уровень следующий уровень. Домены

верхнего уровня или

toplevelin.com.org.net.ru

и многие другие. Эти серверы отвечают за

информацию о доменах внутри своей зоны и

указывают, какие серверы знают

окончательный ответ. И на последнем

уровне находятся авторитетные ДНС-узлы,

которые содержат окончательные данные о

доме: IP-адрес сайта, почтовые серверы и

служебные параметры. Когда запрос

доходит до них, поиск завершается и

клиент получает точный ответ.

Получается, что запрос движется по

иерархии сверху вниз, пока не будет

найден источник достоверной информации.

Но доменное имя может возвращать не

только IP-адрес. Днс способен передавать

разные типы данных, которые описывают

инфраструктуру домена и правила работы

сервисов. Когда DNS-сервер отвечает на

запрос, он возвращает запись

определённого типа. Тип записи

указывает, какую именно информацию нужно

получить. И давайте мы сейчас разберём

все эти типы. Начнём с самой базовой

записи - это запись типа А. А запись

связывает доменное имя с IP адресом.

Когда браузер открывает сайт, чаще всего

он получает именно азапись, в которой

указан IP-сервером. Пример вы видите

сейчас у себя на экране. Это означает,

чтобы открыть сайт, нужно подключиться к

серверу с этим адресом. А запись

остаётся основной основой работы веба,

потому что IPv4 по-прежнему широко

используется. Двигаемся дальше.

Следующий тип записи - это 4А запись.

Она делает то же самое, но только для IP

V6. Пример вы опять-таки видите у себя

на экране. Современные системы часто

запрашивают и А, и 4А записи

одновременно. Если IP V6 доступен, то

соединение может быть установлено через

него. Это повышает эффективность

маршрутизации. То есть получается, что а

и 4А записи - это фундаментальные

записи, которые позволяют клиенту найти

сервер. Но DNOS у сумеет работать не

только с ними. А давайте мы поэтому

разберём следующий тип под названием

Came. Это псевдонимы доменов. Came, что

расшифровывается как canonical name,

позволяет одному доменному имени

указывать на другое. Пример вы видите у

себя на экране. Это означает, что 3W -

это лишь псевдоним основного домена.

Когда клиент запрашивает

wwweexample.com,

то DNS перенаправляет его к example.com,

после чего возвращается уже а или 4А

запись. Came используют для подключения

CDN, облачных сервисов и внешних

платформ. Существует также такой тип,

как MX. MX записи определяет, какие

серверы принимают электронную почту для

домена. Ну, допустим, вы отправляете

письмо на адрес supportexample.com.

Почтовая система запрашивает MX записи

domin example.com, чтобы понять, куда

доставить сообщение. Пример ответа может

выглядеть следующим образом. Видите

сейчас у себя на экране. Число

приоритета указывает порядок

использования. То есть сервер с меньшим

значением имеет более высокий приоритет.

И если основной сервер недоступен, то

почта будет отправлена на резервный. Это

делает почтовую систему более устойчивой

Иксбоем. Также существуют TXT записи.

Это служебные проверочные записи. Они

позволяют хранить произвольный текст,

который используется различными

сервисами. Хотя изначально они

создавались для комментариев. Сегодня

TXT играет, в принципе, важную роль в

безопасности и верификации. Через TXT

реализуется, например, подтверждение

владения доменом, ну, например, для

облачных сервисов или SPF, разрешённые

почтовые сервера. Ну, то есть, в

принципе, различные проверки сервисов.

Пример

SPF записи может выглядеть следующим

образом. Видите у себя сейчас этот

пример на экране? А что она делает? Она

сообщает принимающим серверам, какие

источники имеют право отправлять почту

от имени домена. Двигаемся дальше. Далее

давайте разберём по-быстрому тип записи

NS. NS записи указывают, какие

DNS-серверы являются авторитетными для

доменом. То есть, когда домен

делегируется хостинг-провайдеру или

ДНС-платформе, NS записи сообщают миру,

где искать официальную информацию.

Пример вы видите сейчас у себя на

экране. Это означает, что именно эти

серверы содержат достоверные DNS-данные

домена. Безс-записей DNS просто не знал

бы, где хранится информация о домене. Ну

и последний тип записи, который мы

разберём - это запись, это тип под

названием SRV. SRV записи используются

для указания конкретных сервисов. Внутри

домина SRV применяется в Voiceover

IP-системах, в корпоративных системах, в

игровых сервисах и так далее. Пример CRV

записи может указать, где расположен

сервер, допустим, голосовой связи и на

каком порту он работает. Это что даёт?

Это позволяет клиентским приложениям

автоматически находить нужные сервисы

без какой-то, а, ручной настройки. В

принципе, на этом мы более-менее, э,

кратко разобрали ДНС, ну, типы DNS

записей. Я думаю, в принципе, это

достаточно для, а, понимания. Поэтому

давайте будем переходить дальше и

разберём уже resolving доном. Смотрите,

предположим, вы вводите адрес сайта, ну,

условно, cloudfayer.com.

Браузер не может сразу отправить запрос

на сервер. Сначала ему нужно узнать

IP-адрес, связанный с этим именем, как

мы уже поняли. И как раз вот этот

процесс называется резолвингом домена,

преобразованием доменного имени в

сетевой адрес. На первый взгляд всё

выглядит доменно, но за доли секунды тут

происходит целая цепочка проверок. Что

именно происходит? Если говорить кратко,

то система всегда пытается получить

ответ самым быстрым способом, не

обращаясь к внешним серверам без

необходимости. Давайте мы разберём

поподробней. Сначала браузер проверяет

собственный кэш. Если вы уже открывали

этот сайт недавно, то адрес может

храниться прямо в памяти браузера и

повторный запрос не требуется. Если

записи нет, запрос передаётся

операционной системе. Операционная

система также ведёт собственный DNS-эш,

где могут храниться недавно

использованные домены. Если и там ответа

нет, то система обращается к локальному

резолверу. Обычно это DNS-сервер вашего

роутера или провайдера. Именно он

выполняет полноценный поиск, проходя по

ДНС иерархии, от корневых серверов к

серверам доменной зоны и далее к

авторитетному серверу Домина. Как только

ответ найден, он возвращается обратно по

цепочке Resolver, OS и браузер. После

этого браузер уже знает IP-адрес и может

установить соединение с сервером. Однако

кэш не хранится вечно. Каждая DNS-запись

имеет параметр TTL, Time to Leave, время

жизни. Он указывает, сколько секунд

запись может храниться в кэше до

повторной проверки у авторитетного

сервера. Малый TTL позволяет быстрее

обновлять данные, а большой уменьшает

нагрузку на инфраструктуру и ускоряет

работу пользователей. И именно

кэширование и время жизни записей

подводит нас к следующему важному

эффекту, с которым сталкиваются

разработчики и администраторы при

изменении настроек домена. Смотрите,

когда вы изменяете DNS-записи, например,

переносите сайт на новый сервер или

меняете IP-адрес, а обновление не

становится, видимо, мгновенным. Это

явление называют DNS propagation или

распространением DNS изменений. Причина

кроется в кэшировании. Поскольку записи

хранятся на разных уровнях в браузерах

пользователей, операционных системах,

DNS-резалверах, провайдеров и

промежуточных серверах, старая

информация может продолжать

использоваться до истечения TTL. Это

означает, что часть пользователей будет

попадать на новый сервер, а часть на

старый. Такое состояние может

сохраняться от нескольких минут до 24

или даже 48 часов в зависимости от

установленного времени жизни записи и

политики кэширования у провайдеров. В

продакшене это приводит к типичным

ситуациям, которые часто вызывают

путаницу. После обновления ДНС сайт

может открываться у одних пользователей

и не открываться у других. Почта может

временно доставляться на старый сервер

или там, допустим, сертификации,

сертификаты HTTPS могут казаться

недействительными, если пользователь всё

ещё попадает на прежний хост. Поэтому

изменения DNS требуют аккуратного

планирования. Перед переносом

инфраструктуры TTL часто уменьшают,

чтобы ускорить обновление кэшей. После

завершения миграции TTL можно вернуть к

более высоким значениям для повышения

стабильности и производительности.

Теперь, когда мы понимаем, как доменные

имена преобразуются в адреса, как

работает кэширование, как оно ускоряет

работу там и почему изменения

распространяются немгновенно, мы можем

завершить третий модуль, в котором как

раз мы и разобрали DNS, и можем, а,

плавно переходить уже к следующему

модулю, к четвёртому модулю. В четвёртом

модуле мы подробнее поговорим про TCP и

UDP. Я уже несколько раз их упоминал,

когда мы разбирали то, как устроены

пакеты и кто разрабатывает эти

протоколы. Но до этого момента мы особо

не останавливали внимания на этих

протоколах детально. В этом модуле мы

полностью посвятим себя транспортным

протоколам. И начнём мы с TCP

Transmission Control Protocol, одного из

ключевых строительных блоков интернета.

TCP - это протокол с установлением

соединения, то есть связанный протокол.

Связанность здесь означает, что прежде

чем отправлять данные, два устройства

договариваются о том, что они готовы

обмениваться информацией и

устанавливается своего рода контракт

передачи, который гарантирует, что все

байты будут получены и получены они

будут в правильном порядке. Основу

установления соединения здесь составляет

знаменитый трёхэтапный хдшейк или

Freewayх headшеake. Этот процесс

начинается с того, что клиент посылает

серверу специальный пакет с флагом Sign,

сокращённый от Synchronize, сигнализируя

о желании установить соединение. Сервер

в ответ отвечает своим сайпакетом,

подтверждая готовность принять

подключение, и одновременно отправляет

АК, подтверждение того, что получил

запрос с клиентом. Наконец клиент

отправляет финальный ак. закрывая цикл

установления связи. Этот

последовательный обмен сигналами

обеспечивает надёжное начало

коммуникации и позволяет обеим сторонам

синхронизировать свои счётчики

последовательностей, которые будут

использоваться для отслеживания

передаваемых данных. После того, как

соединение установлено, TCP обеспечивает

надёжную доставку данных. Надёжность

достигается благодаря нескольким

ключевым механизмам. Протокол следит за

порядком байтов, проверяет корректность

каждого сегмента с помощью контрольной

суммы. И если какой-то пакет теряется

или приходит с ошибкой, то TCP

инициирует повторную передачу только

этого сегмента. И таким образом

получается гарантированно целостный

поток данных. Эта функция особенно важна

для протоколов, где критичен порядок и

целостность. Ну, например, для HTTP,

SMTP, FTP и многих других. Следующий

важный аспект - это потоковый характер

TCP. В отличие от протоколов без

установления соединения, где каждый

пакет независим, TCP представляет данные

как непрерывный поток байтов. Это

значит, что приложения могут отправлять

большие объёмы информации без разделения

их на отдельные сообщения на уровне

транспортного протокола. В TCP сам

разбивает поток на сегменты, оптимально

упаковывает их и обеспечивает их

доставку по сети. Получатель собирает

эти сегменты в исходный поток,

восстанавливая последовательность и

предоставляя приложению данные именно в

том порядке, в котором они были

отправлены. Всё, что я сейчас описал,

порядок байтов, контрольные суммы,

сегментация и повторные передачи, это

делает TCP сложным и мощным инструментом

для сетевого взаимодействия. Он умеет

регулировать скорость передачи в

зависимости от состояния сети, избегает

перегрузки, динамически управляет окнами

приёма и отправки и адаптируется к

потерям и задержкам. После того, как мы

подробно разобрали TCP и поняли, как

протокол устанавливает связь, логично

задать вопрос: а что происходит, когда

связь не требует такой строгой

надёжности, когда критична скорость, а

не абсолютная гарантия доставки? Именно

для таких задач существует UDP, что

расшифровывается как User Datram

протокол. UDP принципиально отличается

от TCP тем, что он без установления

соединения. Здесь нет трёхстороннего

рукопожатия и нет проверки доставки и

нет упорядочивания байтов. Каждый пакет

или датаграмма отправляется как

отдельная сущность, и отправитель не

получает подтверждения, что пакет дошёл

до получателя. Такой подход делает UDP

лёгким и быстрым, потому что протокол

практически не тратит ресурсы на

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

минимизировать задержки и накладные

расходы на передачу данных. Несмотря на

отсутствие гарантии доставки, UDP крайне

востребован, допустим, в стриминге видео

и аудио, где потери нескольких пакетов

не разрушают общий поток, а

воспроизводится как небольшая

пятнистность картинки или

кратковременные шумы в звуке, или

онлайн-игры, где задержка важнее точной

доставки каждого пакета. же игровой

клиент не может ждать подтверждения от

сервера секунду или две, иначе

управление персонажем будет ощущаться

как тормозное. Особенное внимание тут

стоит уделить также IP, ну, voiceover

IP, то есть передача голоса через

интернет. Здесь UDP также незаменим,

потому что голосовые пакеты должны

доходить максимально быстро, и даже если

часть из них теряется, разговор остаётся

понятным. Ну, небольшие пропуски, они

компенсируются человеческим мозгом. TCP

в таких сценариях он бы оказался слишком

медленный из-за постоянной перепередачи

потерянных пакетов и контроля

последовательности, что привело бы к не

каким-нибудь неестественным задержкам и

лагам голосовой связи. Технически

UDP-пакеты содержат минимальный

заголовок, где указаны порты от

правителя и получателям, длина пакета и

контрольная сумма. Данная компактность

сделает протокол лёгким для обработки

сетевыми устройствами, снижает нагрузку

на маршрутизаторы и серверы, ну а также

позволяет масштабировать приложение с

большим числом параллельных подключений.

Однако эта простота означает, что

ответственность за контроль ошибок,

проверку целостности и порядок доставки

полностью перекладывается на приложение.

Поэтому разработчики VIP клиентов,

игровых движков и стриминговых сервисов

создают собственные алгоритмы коррекции

потерь. буферизации и повторной

синхронизации данных, чтобы

компенсировать отсутствие встроенной

надёжности в протоколе. Если подытожить,

то UDP - это инструмент для сценариев,

где скорость важнее гарантии, а

приложения способны самостоятельно

справляться с потерями и корректировать

поток данных. Если подытожить, то UDP -

это инструмент для сценариев, где

скорость важнее гарантии. В отличие от

TCP, который заботится о каждом байте,

UDP доверяет приложениям принимать

решение о том, как использовать

доступный трафик. Теперь, когда мы

разобрали особенности TCP и UDP, можно

задаться вопросом, когда и почему

выбирают один протокол вместо другого.

Начнём с TCP. HTP, протокол, на котором

строится большая часть веба, работает

поверх TCP не случайно. Когда вы

открываете сайт, браузер ожидает, что

каждая часть данных придёт полностью и в

правильном порядке. HTML страница,

скрипты, стили, изображения. Всё должно

быть корректно собрано в конечном

потоке. TCP здесь гарантируют доставку

всех этих элементов, обеспечивая

контроль последовательности, повторную

передачу потерянных пакетов и проверку

целостности. Без TCP браузеры бы

сталкивались с ломающимися страницами,

когда отдельные файлы теряются или

приходят в неправильном порядке, а user

experience был бы крайне неприятным.

Надёжность TCP и его потоковая модель

позволяют HTTP быть стабильным,

предсказуемым и универсальным, даже если

сеть перегружена или нестабильно. Но

если посмотреть с другой стороны,

современные требования к скорости и

минимальным задержкам привели к

появлению протоколов поверх UDP, таких

как Quick. Эта аббревиатура

расшифровывается как Quick UDP Internet

Connections. Про него мы поговорим чуть

подробнее в следующем модуле. Ак

разрабатывался Google, чтобы совмещать

скорость UDP с необходимой надёжностью

TCP, но делать это эффективнее для

современных веб-приложений. Он

использует UDP как транспорт, потому что

UDP не устанавливает соединение и не

ждёт подтверждений. На этом базовом

уровне КВК реализует собственные

механизмы подтверждения и восстановления

потерянных пакетов, упорядочивания

потоков и шифрованием, которое в него

встроено по умолчанию. Это позволяет

уменьшить ручки TCP, такие как медленное

открытие соединений и head ofline

блокиing, когда один потерянный пакет

блокирует всю очередь доставки. То есть

получается, что TCP и UDP - это два

инструмента с разными философиями. Один

ориентирован на абсолютную надёжность и

упорядочистность, а другой на скорость и

эффективность, оставляя контроль

приложения. А теперь мы поднимаемся ещё

на один уровень сетевой модели и

посмотрим на протокол, с которым каждый

разработчик и пользователь сталкивается

ежедневно. Речь пойдёт об HTTP, языке,

на котором браузеры и серверы общаются

друг с другом. HTTP расшифровывается как

гипертексттрансфер протокол, протокол

передачи гипертекста. Несмотря на

название, он используется не только для

передачи HTML-страниц, но и для отправки

изображений, видео, JSON данных, файлов

и любых других ресурсов. HTTP относится

к уровню приложения. Он работает поверх

транспортных протоколов, чаще всего TCP,

используя из них надёжную доставку, но

сам определяет правила общения между

клиентом и сервером. В основе HTTP лежит

простая, но чрезвычайно мощная модель

взаимодействия под названием Request

Response, то есть запрос-ответ. Клиент,

например, браузер, отправляет запрос на

сервер, указывает адрес ресурса, метод

операции, заголовки и иногда тело

запроса. Сервер принимает этот запрос,

обрабатывает его и возвращает ответ,

который содержит статус выполнения,

служебные заголовки и данные. После

этого цикл считается завершённым.

Ключевое понятие в HTTP - это

идомпотентность. Говоря по-простому,

идомпотентный запрос можно отправить

несколько раз подряд, и результат не

изменится. Например, если вы открываете

страницу пользователям, повторное

обновление страницы не создаёт новых

данных и ничего не ломает. Вы просто

снова получаете тот же результат. Это

важно для устойчивости сети. То есть,

если запрос потерялся или был отправлен

повторно из-за сбой соединения, сервер

не должен случайно продублировать

операцию. Поэтому одни HTTP операции

считаются безопасными для повторения, а

другие нет. И это напрямую влияет на

проектирование апи и поведение клиентов.

HTTP также определяет методы, своего

рода глаголы, которые сообщают серверу,

что именно нужно сделать с ресурсом.

Предлагаю разобрать эти методы. Первый -

это Gет. Используется для получения

данных. Он не должен изменять состояние

сервера, считается безопасным и

демпатентным. Браузеры активно кэшируют

такие запросы. Далее идёт пост.

Применяется для создания новых ресурсов

или выполнения действий, которые

изменяют состояние системы. Ну,

допустим, регистрация пользователя,

отправка формы или создание заказа.

Повторный постзапрос может создать

дубликаты, поэтому он не идемпотентен.

Следом идёт пут, означает полную замену

ресурса. Если отправить один и тот же

пут несколько раз, результат останется

одинаковым. Ресурс будет приведён к

переданному состоянию. Патч используется

для частичного обновления ресурса, когда

нужно изменить только отдельные поля.

Повторная отправка может дать тот же

результат, но это зависит от логики

изменений, поэтому патч обычно не

считают строго ипотентным. Далее идёт

delete. Он удаляет ресурс. Он считается

идемпотентным, потому что если ресурс

уже удалён, то повторный запрос не

изменит состояние сервера. А потом идёт

head. Он работает так же, как и getет,

но сервер возвращает только заголовки

ответа без тела. Это позволяет проверить

наличие ресурса, его размер, дату

изменения или кэшметаданные без загрузки

содержимого. Ну и последний - это

Options. Он сообщает клиенту, какие

методы и параметры поддерживает сервер

для конкретного ресурса. Этот метод

используется, например, в механизме CS,

когда браузер заранее опроверяет,

разрешён ли запрос другого домена.

Помимо методов, HTTP также используют

статусы ответов. Это трёхзначные коды,

которые сообщают результат обработки

запроса. Они делятся на категории. Коды,

которые начинаются на 200, они означают

успешное выполнение запроса. Ну,

например, 200. А далее, те, которые у

нас начинаются на 300, они сообщают о

перенаправлениях. А те, которые

начинаются на 400, они указывают на

ошибку со стороны клиента, например,

неверный запрос или отсутствие доступа.

Ну и те, которые начинаются на 500, они

сигнализируют о проблемах на стороне

сервера. Получается, что HTTP - это

универсальный протокол взаимодействия

приложений, определяющий структуру

запросов, операции и КД ответов. HTTPM

благодаря своей простоте и гибкости стал

основой веба, а и современных

интернет-сервисов.

Теперь давайте мы разберём то, что сам

HTP со временем существенно

эволюционировал.

Первые версии, они отлично, в принципе,

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

рост веб-приложений и появление

динамического контента мобильного

интернета и сложных интерфейсов

потребовали повышения скорости, снижения

задерк и более эффективного

использования соединений. Так появились

HTTP 1.1, затем HTTP2 и, наконец, HTTP3.

Каждая версия, она решала конкретные

проблемы производительности предыдущей.

И сейчас давайте мы эти версии и то, что

они решали, разберём. Версия HTTP 1.1

была стандартизирована в 1997

году и стала стандартом веба на долгие

годы. Она ввела ключевое улучшение,

постоянное соединением KBI. В ранних

версиях HTPM для каждого запроса

открывалось новое TCP соединение.

Браузер загружал HTML, закрывал

соединение, затем открывал новое для

CSS, ещё одно для изображений и так

далее. Это приводило к огромным

накладным расходам. Каждый раз

выполнялся TCP хдшейк, увеличивались

задержки и росла нагрузка на сеть. Плать

одно TCP соединение открытым и

отправлять через него несколько запросов

подряд. Это резко снизило задержки и

ускорило загрузку страниц, особенно

содержащих десятки ресурсов. Однако у

этой версии оставалась серьёзная

архитектурная проблема. Head ofline

блокинг на уровне приложения. Это

означает, что браузер мог отправить

несколько запросов подряд, но сервер

обязан был отвечать строго по порядку.

Если первый запрос обрабатывался долго,

все последующие ответы задерживались,

даже если они уже были готовы. В

реальных условиях это приводило к

очередям внутри соединения и замедлению

загрузки страниц. Чтобы обойти это

ограничение, браузеры начали открывать

несколько параллельных TCP соединений к

одному серверу. обычно от шести до

десяти, что частично ускоряло загрузку,

но создавало дополнительную нагрузку на

сеть и серверы. HTP 1.1 стал фундаментом

современного веба, но его текстовый

формат и последовательная модель

обработки запросов со временем начали

ограничивать производительность. Теперь

давайте разберём HTTP2. Он был

стандартизирован в 2015 году на основе

протокола Speedy, разработанного Google.

Он был создан для решения проблем

производительности без изменения

семантики. http. То есть все методы,

статусы и логика остались прежними.

Изменилась именно механика передачи

данных. Главное нововведение здесь - это

мультиплексирование.

Теперь множество запросов и ответов

могут передаваться одновременно внутри

одного AT TCP соединения. То есть данные

разбиваются на небольшие фреймы, которые

могут перемешиваться и собираться

обратно на стороне клиента. Это

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

медленный ресурс больше не задерживает

остальным. Второе важное изменение - это

переход на бинарные фреймы вместо

текстового формата. В HTTP 1.1 данные

передавались в текстовом виде, что

требовало парсинга строк. HTTP2

используют компактные бинарныеструктуры,

которые быстрее обрабатываются и

уменьшают объём передаваемых данных.

Также HTTP2 вводит сжатие заголовков

Hпаack. В реальных запросах заголовки

часто повторяются, там сюзерагент и так

далее, и их сжатие существенно уменьшает

объём трафика. Ещё одна возможность -

это серверпу. То есть сервер может

отправить клиенту ресурсы заранее, не

дожидаясь явного запроса. Например,

вместе с HTML сервер сразу может

отправить CSS и JavaScript. Это

уменьшает задержки, хотя на практике

механизм используется осторожно, чтобы

не отправлять лишние данные. Несмотря на

огромный прирост производительности,

HTTP2 всё ещё работает поверх TCP, а

значит, наследует проблема блокировки на

уровне транспорта. Потеря одного пакета

TCP может временно остановить передачу

остальных данных. И вот здесь мы уже

переходим к HTTP3. HTTP3 - это такой

наиболее радикальный шаг в эволюции

протокола. Он был стандартизирован в

2022 году и уже работает не поверх TCP,

а поверх UDP, используя транспортный

протокол Quick Quick UDP Internet

Connections, который я ранее упоминал.

Квик был разработан Google и

стандартизирован IATF как современный

транспортный протокол, объединяющий

скоростью DP с надёжностью, контролем

потерь и безопасностью. Главное

преимущество HTTP3 - это устранение

задержек, связанных с TCP. То есть

соединение устанавливается быстрее

благодаря объединённому TLS. Потеря

одного пакета больше не блокирует

остальные потоки. Каждый поток данных

независим от других, и повторное

подключение происходит мгновенно

благодаря механизму connection

Migration. Поскольку Quick встроенно

использует TLS 1.3, HTTP3 всегда

работает через шифрование, что повышает

безопасность и ускоряет установление

соединения. Передача "Поверх USDP" здесь

позволяет обходить ограничения TCP, то

есть снижать задержки в мобильных сетях,

улучшать стабильность при потере пакетов

и ускорять загрузку страниц при

нестабильном соединении.

Получается, что эволюция HTTP - это путь

от простого текстового протокола к

высокоэффективной, многопоточной и

устойчивой системе передачи данных. Если

подытожить, то HTTP1.1 сделал соединение

постоянным. HTTP2 устранил блокировки и

оптимизировал передачу, а HTTP3 в целом

переосмыслил сам транспорт, минимизируя

задержки и повышая устойчивость

интернета в условиях современной сети.

Однако скорость и эффективность передачи

данных - это лишь часть картины. Как

только соединение установлено и запросы

начинают выполняться, возникает

следующий важный вопрос: как сервер

узнаёт, кто именно отправляет запрос и

что происходило ранее? HTTP по своей

природе является протоколом без

состояния, то есть каждый запрос

независим и не хранит информации о

предыдущих взаимодействиях. Это делает

протокол простым и масштабируемым, но

создаёт проблему. Без дополнительного

механизма сервер не сможет отличить

одного пользователя от другого или

запомнить, что произошло минуту назад.

Именно для решения этой задачи появились

кукис, сессии и токены, механизмы,

позволяющие сохранять контекст

взаимодействия между клиентом и

сервером. Допустим, когда сервер хочет

сохранить небольшие данные на стороне

клиента, он отправляет заголовок set

cookie. Браузер сохраняет куки и

автоматически прикрепляет её к каждому

последующему запросу к тому же домену.

Таким образом, сервер получает

возможность идентифицировать

пользователя без необходимости хранить

состояние внутри самого HTTP протокола.

Cookies, они представляют собой

небольшие текстовые пары, а, типа ключ

значения, которые могут хранить

идентификатор сессии, там какие-нибудь

настройки интерфейса, язык пользователя

или какие-то технические параметры. Они

автоматически управляются браузером и

передаются незаметно для пользователя.

При работе скис важны параметры

безопасности. Давайте мы разберём

несколько атрибутов в куке. Это атрибут

HTTP only. Он запрещает доступ к куке из

JavaScript. Это защищает её от кражи

через XS атаки. Далее атрибут Secure. Он

указывает браузеру передавать куки

только через https, предотвращая

перехват данных в незашифрованных

соединениях. И дополнительно часто ещё

используют этот атрибут same site сай,

который ограничивает отправку при

межсайтовых запросах и помогает бороться

с CSRF атаками. Но сама по себе куки -

это лишь контейнер. На практике в ней

чаще всего хранится идентификатор

сессии, а основные данные пользователя,

они, понятное дело, остаются на сервере,

то есть там почта, пароль, не знаю, его

имя и так далее. Вот такой подход, он

называется session based

autentification, если говорить именно

про сессии. То есть, когда пользователь

входит в систему, сервер создаёт сессию,

запись в базе данных или хранилище, ну,

например, там Redis, и присваивает ей

уникальный ID. Этот ID отправляется

клиенту в куки, и при каждом последующем

запросе сервер получает ID, находит

соответствующую сессию и восстанавливает

состояние пользователям, авторизацию,

роли и настройки. Мы сейчас не будем

углубляться в авторизацию и

аутентификацию, просто так чисто

пройдёмся поверхностно. У сейсси есть

огромное преимущество- это высокий

уровень контроля и возможность мгновенно

завершить доступ, удалив запись на

сервере. Недостаток - это необходимость

хранить состояние и масштабировать

хранилище сессии при большом числе

пользователей. Альтернативой является

также Token Based Authentification.

Здесь вместо хранения состояния на

сервере система выдаёт клиенту токен,

криптографически подписанный набор

данных, содержащий информацию о

пользователе и правах доступа. Такой

токен, например, GVT, отправляется

клиентам в заголовки Authorization при

каждом запросе. В отличие от сессии,

серверу не нужно хранить состояние. Он

проверяет подпись токена и извлекает

данные прямо из него. Но токены сложнее

отзывать до истечения срока действия,

поэтому часто применяются дополнительные

механизмы. Это короткое время жизни,

рефреш-токены и списки отзыва. Ну, мы

сейчас не будем углубляться в тему

авторизации, потому что она сама по себе

огромная. Мы, поскольку у нас видео

совсем про другое, если вы хотите

разобраться глубже, мы вы можете

посмотреть на канале отдельную

теоретическую лекцию у меня про

авторизацию и аутентификацию, а также

ещё практическое видео, где мы реализуем

как раз авторизацию на сессиях. То есть,

если подвести итоги, то HTTP остаётся

протоколом без состояния. Но благодаря

этим механизмам, это который мы сейчас

разобрали, а поверх него строятся

полноценные системы аутентификации,

персонализации и управления доступом. В

принципе, на этом модуль по HTTP можно

считать завершённым. Мы с вами разобрали

базовую модель запрос-ответ, а разобрали

методы, разобрали статусы, эволюцию. Ну

и теперь у нас есть целостное понимание

того, как веб взаимодействует с

пользователями, передаёт данные и

сохраняет контекст работы в реальном

времени. Но есть один критически важный

момент. Классический HTTP передаёт

данные в открытом виде. Это означает,

что любая информация, отправленная через

HTTP, может быть прочитана теми, кто

способен перехватить трафик. Как мы уже

знаем, а в сети данные передаются

пакетами через множество промежуточных

устройств. И если соединение не

защищено, содержимое этих пакетов

остаётся доступными для анализа.

Допустим, представьте, что пользователь

подключается к общедоступному Wi-Fi, в

кафе или аэропорту. При использовании

обычного HDP злоумышленник в той же сети

может перехватывать трафик с помощью

специальных инструментов анализа пакетов

и видеть передаваемые данные: логины,

пароли, содержимое форм, там куки-файлы,

номера карт или какие-то личные

сообщения. Это называется перехватом

трафика. или снифинг. Обравление

ограничивается чтением данных. Если

трафик не зашифрован, его можно изменить

по путиследования. Поскольку пакеты

проходят через множество узлов,

атакующий способен внедрять вредоносный

код, подменять содержимое страниц или

перенаправлять пользователя на фальшивые

сайты. Такой тип атаки известен как man

in the middle, человек посередине.

Например, при загрузке сайта без

шифрования злоумышленник может подменить

JavaScript файл, встроив вредоносный

код, который будет незаметно

перехватывать данные пользователя.

Пользователь видит страницу, которая

выглядит корректно, но на самом деле

взаимодействует с поддельной логикой.

Кроме атак злоумышленников, отсутствие

шифрования позволяет промежуточным

системам анализировать и модифицировать

трафик. Провайдеры или корпоративные

сети могут вставлять рекламу,

блокировать контент или перенаправлять

запросы. Поскольку данные передаются

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

целостности полученной информации.

Получается, что незашифрованная HTTP не

обеспечивает ни конфиденциальности, ни

целостности данных. Любая информация

может быть прочитана, изменена или

подменена по пути следования. Именно эти

уязвимости стали причиной появления

HTTPS, защищённой версии HTTP, которая

добавляет шифрование и гарантирует, что

данные остаются приватными и

незаметными. И сейчас мы разберём, как

работает TLS. протокол, который делает

это возможным. TLS, что расшифровывается

Transport Layer Security, протокол

безопасности транспортного уровня,

является механизмом, который

обеспечивает конфиденциальность и

целостность передачи. Именно ТС лежит в

основе https и защищает соединения,

через которые передаются пароли,

банковские данные, переписка, в общем,

любая информация. Главная задача ТЛС -

это создать защищённый канал связи

поверх уже установленного TCP

соединения. При этом данные шифруются

таким образом, чтобы их мог прочитать

только получатель, а любые изменения по

пути были обнаружены. Чтобы понять, как

это работает, важно разобраться в двух

типах шифрования: асимметричном и

симметричном. Асимметричное шифрование

используют пару ключей: публичный ключ

public, который можно передавать кому

угодно, и приватный ключ private keim,

который хранится в секрете. Данные,

зашифрованные публичным ключом, можно

расшифровать только соответствующим

приватным ключом. Когда браузер

подключается к серверу по HTTPS, сервер

отправляет свой публичный ключ. Браузер

использует его для безопасной передачи

секретной информации, которую может

прочитать только сервер. Однако

асимметричное шифрование вычислительно

тяжёлое и медленное. Использовать его

для всего потока данных было бы

неэффективно. Поэтому ТЛС применяет его

только на этапе установления защищённого

соединения. То есть перед началом

защищённого обмена данными клиент и

сервер сначала выполняют процесс,

который называется TLS Headshaк.

Рукопожатие ТЛС. Это серия шагов, в ходе

которых стороны согласовывают версию ТЛС

и набор криптографических алгоритмов.

Сервер отправляет свой цифровой

сертификат и публичный ключ. Клиент

проверяет подлинность сертификата и

стороны безопасно договариваются о

секретном симметричном ключе.

Современные версии ТЛС, например, TLS1.3

используют алгоритмы Defy Helman или

ACDE, позволяющие создать общий

секретный ключ даже через небезопасный

канал. При этом ключ не передаётся

напрямую, он вычисляется независимо

обеими сторонами. Это важный момент. То

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

весь обмен во время рукопожатия, он не

сможет восстановить итоговый ключ

шифрования. После завершения рукопожатия

стороны получают уже общий симметричный

ключ. Симметричное шифрование означает,

что один и тот же ключ используется для

шифрования и расшифровки. Алгоритмы

работают значительно быстрее и идеально

подходят для передачи больших объёмов

данных. Для защиты трафика от ЛС

используют современные алгоритмы

симметричного шифрования, таких как IES,

Advanced encryption Standard, а также

механизмы контроля целостности данных,

например, authentificated encryption

with Associated Data. Это обеспечивает

сразу три уровня защиты. Первое - это

конфиденциальность, то есть данные

невозможно прочитать. Второе - это

целостность, то есть любые изменения

будут обнаружены. И третье - это

аутентичность. Клиент уверен, что

общается именно с нужным сервером. Ну и

уже после завершения ТЛС рукопожатия и

установки симметричного ключа весь

дальнейший HTTP трафик передаётся в

зашифрованном виде. Даже если пакеты

будут перехвачены, они будут выглядеть

как случайный набор байтов. Именно

поэтому при подключении к HTTPS сайту

злоумышленник может видеть только факт

соединения, но не содержимое страниц,

формы или передаваемые данные. Теперь

давайте разберём, а какую роль играют

SSL-сертификаты и кто гарантирует, что

сервер, к которому вы подключаетесь,

действительно является тем, за кого себя

выдаёт. Смотрите, когда браузер

устанавливает защищённое соединение по

https, он должен убедиться, что сервер

действительно принадлежит тому домену, к

которому обращается пользователь. Эту

задачу решает SSL-сертификаты.

На самом деле последнее время корректнее

говорить TLS сертификаты, поскольку SSL

Secure Sockets Layer устарел, а

используется TLS. Это Transport Layer

Security. Сертификат - это цифровой

документ, который связывает доменное имя

с публичным криптографическим ключом

сервера и подтверждает эту связь с

помощью цифровой подписи доверенного

центра. Чтобы такой документ имел

юридическую и техническую ценность, его

должен подписать доверенный участник

экосистемы. Именно поэтому сертификаты

выдаются организациями, называемыми

Certificate Authorities или сокращённой

центрами сертификации. Они проверяют,

что заявитель действительно владеет

домином, после чего подписывают

сертификат своей цифровой подписью.

Среди известных центров сертификации

находится DGERT, Global Sign или Lent

Crypt. Когда центр сертификации

подписывает сертификат, он подтверждает,

этот публичный ключ действительно

принадлежит указанному домену. Браузеры

и операционные системы заранее содержат

список доверенных, поэтому их подписи

считаются надёжными. Однако доверие в

интернете строится через многоуровневую

модель, цепочку сертификатов. На вершине

этой цепочки находится корневой

сертификат root certificate встроены в

операционные системы и браузеры. Уже

ниже располагаются промежуточные

сертификаты, подписанные корневым

центром, которые используются для выдачи

сертификатов конкретным сайтом. То есть,

когда сервер отправляет свой сертификат,

он передаёт и промежуточный, чтобы

браузер или OS могли выстроить цепочку:

сертификат сайта, промежуточный и

корневой. Если эта цепочка корректна, то

соединение может считаться безопасным.

Чуть позже мы ещё разберём, почему

браузер доверяет корневому сертификату и

как формируются эти списки доверия. А

пока что давайте будем двигаться дальше.

Смотрите, не все сертификаты, они

подписываются доверенными центрами.

Иногда сертификат, он создаётся и

подписывается самим владельцем сервера.

Это называется Self Science сертификат.

Он обеспечивает шифрование канала, но он

не подтверждает подлинность сервером,

поэтому браузеры показывают

предупреждение о небезопасном

соединении. Такие сертификаты обычно

используются в разработке, тестовых

средах или внутренних корпоративных

системах, где доверие устанавливается

вручную. И теперь давайте ещё разберём

Wiildcard сертификаты. Смотрите, когда

условная инфраструктура начинает расти,

возникает новая задача. Нужно защищать

не один домен, а множество поддоменов. И

как раз для этого используются card

сертификаты. Например, сертификат для

поддоменов domina example.com будет

действовать там условно для

appiexample.com, для shopeexample.com и

любых других поддоменов. Это намного

упрощает администрирование

инфраструктуры и снижает количество

сертификатов, ну а также уменьшает

стоимость обслуживания. И именно на фоне

таких задач автоматизация управления

сертификатами стала особенно

востребований. Смотрите, раньше

получение сертификата было платным и

требовало ручной настройки, что

замедляло внедрение HTTPS. Вся ситуация

изменилась в 2015 году с появлением Leds

and Crypt, бесплатного центра

сертификации, созданного при поддержке

Internet Security Research Group. Что он

сделал? Он автоматизировал выдачу

сертификатов через протокол ACMIM

Automated Certificate Management

Environment. Сервер может самостоятельно

получить и регулярно обновлять

сертификат без участия администратора.

Именно это стало ключевым фактором

массового перехода интернета на https.

Если подытожить, то TLS-сертификат

выполняет сразу две ключевые функции. Он

включает шифрование соединения и

подтверждает подлинность сервером. Без

проверки сертификата злоумышленник мог

бы выдать себя за сайт банка или

онлайн-сервиса и перехватывать данные

пользователя. То есть сертификаты, они

формируют такой фундамент доверия в

интернете. И теперь давайте мы ещё

поговорим про то, почему браузер

доверяет сертификату. Когда мы говорили

о цепочке сертификатов, я упоминал, что

доверие в интернете строится не

напрямую, а через иерархию центров

сертификации. Но тут возникает вопрос,

почему браузер вообще доверяет этой

цепочке и кто решает, каким центром

можно верить. А здесь у нас как раз

ответ скрывается в так называемых

корневых списках доверия. Когда вы

устанавливаете операционную систему или

браузер, вместе с ними поставляется

набор встроенных корневых сертификатов

Root Essa Certificates. Это список

центров сертификации, котором

разработчики платформы решили доверять.

Если сертификат сайта можно связать

через цепочку подписи с одним из этих

корневых центров, соединение считается

безопасным. Например, операционные

системы от Microsof и Apple, а также

большинство дистрибутивов Linux

поддерживают собственные хранилища

доверенных краневых сертификатов. А

браузеры вроде Mazilla Firefox

используют свой независимый список, а

Google Chrome и Microsoft Edge опираются

на хранилище операционной системы. То

есть, когда вы открываете сайт по HTTPS,

браузер получает сертификат сервера и

промежуточные сертификаты, а затем он

пытается выстроить цепочку доверия до

корневого центра. Если такой корневой

сертификат присутствует в списке

доверенных, подписи корректны, срок

действия не истёк, а домен совпадает, то

соединение считается подлинным и

безопасным. Если же хотя бы одно условие

нарушено, например, сертификат

самоподписанный, срок действия стёк или

центр сертификации отсутствует в списке

доверенных, то браузер показывает

предупреждение о небезопасном

соединении. Это сигнал о том, что

личность сервера не может быть

подтверждена. Тут ещё важно понимать,

что вот эти списки доверия - это не

какой-то статичный механизм. Центры

сертификации могут быть исключены из

доверенных, если они нарушают какие-то

правила безопасности или допускают

ошибки при проверке доминов. Такие

случаи на самом-то деле происходили, и

браузеры оперативно обновляли списки

доверия, чтобы защитить пользователей.

Получается, что доверие HTTPS строится

на доверии к ограниченному кругу

проверенных организаций и

криптографической проверки цепочки

подписей. Как раз вот этот механизм, он

позволяет миллиардам устройств по всему

миру безопасно устанавливать защищённые

соединения, не зная друг друга заранее.

Ну что же, на этом мы, в принципе, можем

считать модуль от LS, HTTPS и

безопасности соединений. завершённым.

Теперь, я думаю, вам ясно, как данные

шифруются, проверяются и как браузер

решает, чему доверять. Двигаемся дальше.

HTTP, как мы уже изучили, изначально

создавался как протокол запрос-ответ,

ориентированный на получение документов

и ресурсов. Каждый запрос инициируется

клиентом, сервер отвечает, и соединение

может закрываться после передачи данных.

Для большинства веб-страниц это было

достаточно. Пользователь нажимает

ссылку, получает страницу, всё логично.

Но когда появились приложения, требующие

мгновенной передачи данных, чаты или

онлайн-игры, стандартная модель HTTP

показала свои ограничения. Один из

способов организовать почти живое

обновление данных через HTTP - это

полинг. Клиент периодически отправляет

запросы на сервер, проверяя, появились

ли новые данные. На первый взгляд это

решение простое, но на практике оно

крайне неэффективно. Постоянные запросы

создают лишнюю нагрузку на сервер,

увеличивают трафик и задержку. Между

моментом появления события на сервере и

его получением клиента всегда есть

пауза. Чем чаще отправляются запросы,

тем выше нагрузка, но даже при высокой

частоте невозможно полностью устранить

эту задержку. Попытка сделать соединение

постоянным через HTTP, известное как

Long Poing, немного улучшает ситуацию.

Клиент держит соединение открытым до

появления данных, после чего соединение

закрывается и клиент открывает новое.

Такой подход уменьшает количество

повторных запросов, но он всё ещё

страдает от накладных расходов протокола

HTTP и ограничений на количество

одновременных соединений в браузере.

Более того, серверу всё равно приходится

управлять большим количеством висящих

соединений, что увеличивает сложность

инфраструктуры и требования к

масштабируемости. Эти ограничения

показали, что для Realтай time

коммуникации нужен принципиально другой

подход. Канал, который не требует

постоянного повторного установления

соединения и способен обеспечивать

двухстороннюю мгновенную передачу

данных. Именно эта потребность и стала

стимулом к созданию протоколов вроде

Websocket и Server Send Events, которые

мы сейчас и разберём. Ну и начнём мы с

протокола Websocket. В отличие от

классического HTTP, где клиенты

инициирует каждый запрос, Websocket

создаёт по постоянный двухсторонний

канал связи между клиентом и сервером.

Это означает, что как клиент, так и

сервер могут в любой момент отправлять

данные друг с другу без необходимости

открывать новые соединения для каждого

сообщения. Такая модель идеально

подходит для чатов, игровых серверов или

любых приложений, где важна мгновенная

реакция. Технически websocket строится

поверх TCP, который мы уже

рассматривали. TCP, как мы знаем,

обеспечивает надёжную доставку, порядок

байтов и потоковый характер передачи

данных. Websocket используют эти

свойства, создавая поверх TZP безопасный

и постоянный канал для передачи

сообщений. Клиент и сервер сначала

выполняют так называемое, где HTTP

запрос обновляется до Websocket

протокола. И после успешного рукопожатия

соединение остаётся открытым. И дальше

данные могут свободно течь в обе стороны

без дополнительной нагрузки на у на

установку соединений. Использование

вебсокет особенно полезно там, где нужно

поддерживать множество одновременных

соединений. В чатах это позволяет

мгновенно доставлять новые сообщения

каждому участнику, а в игровых

приложениях синхронизировать состояние

мира и позиции игроков. Протокол также

поддерживает бинарные данные, что важно

для передачи изображений, аудио или

любых других потоковых данных. Кроме

того, Websocket интегрируется с

современными веб-технологиями и легко

работает через стандартные браузеры,

прокси и межсетевые экраны, что делает

его практическим инструментом для

разработчиков. Он полностью решает

проблемы полинг и longполиing, позволяя

создавать настоящее real time приложение

без лишней нагрузки на сервер и сеть. В

целомкеet - это такой первый шаг

полноценной двухсторонней коммуникации в

вебе, который обеспечивает и скорость, и

надёжность, и эффективность, которую в

HTTP в чистом виде обеспечить просто не

может. Продолжая тему Real Time

коммуникации, также стоит рассмотреть

SSE, что расшифровывается как сервер