Что происходит когда в браузере набираешь адрес и нажимаешь enter

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

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

Пошаговый рассказ о том, что делает браузер, основан на статье «What happens when», опубликованной на Гитхабе. Мы сократили источник, убрав технические сложности, дополнили его примерами из жизни и небольшими схемами, чтобы разобраться смог каждый новичок.

Давайте представим, что вы решили ввести адрес REG.RU в поисковую строку. Что произойдет дальше?

Когда вы нажмете клавишу «R» (первую букву сайта), браузер получит команду и начнет предлагать вам варианты для автоподстановки. Они могут быть разными, например, популярные сайты, начинающиеся с «R» (RUTUBE, Rambler), самые посещаемые вами страницы или сайты из закладок.

Воспользовавшись подсказкой от браузера или напечатав адрес сайта полностью, вы нажимаете на «Enter». А дальше…

Начинается поиск сервера

…немного теории. Чтобы пользователь смог увидеть страницы сайта в любое время дня и ночи из любого уголка света, владелец сайта подключает хостинг. Ведь сайт — это набор файлов, который хранится на сервере.

Как только вы вводите доменное имя, браузер должен узнать, к какому серверу обратиться за данными.

В мире интернета адрес сайта называется IP-адресом. И «айпи» есть абсолютно у каждого сервера. Например, IP-адрес сервера, на котором расположен домен сайта REG.RU, — 194.58.116.31. Узнать его можно, используя специальные сервисы. У нас тоже есть такой. С его помощью можете «вычислить по айпи» любой сайт. В качестве примера мы покажем, какие IP у домена YANDEX.RU. Спойлер — очень красивые.

Эти числа и точки можно сравнить с геолокацией. Но разве вы ходите в гости к другу или отправляете посылку, используя геолокацию? Гораздо удобнее использовать почтовый адрес. Для этого придумали систему DNS — Domain Name Service.

Если коротко, DNS — это огромная таблица с данными о сайтах, которую можно сравнить с телефонной книгой. Хочешь позвонить Ване → нажми на его профиль в телефонной книге, за которым закреплен номер +7 999 999 99 99. Хочешь попасть на сайт Вани → введи в поисковую строку домен, за которым закреплен IP-адрес 99.99.99.99.

С теорией разобрались, можем возвращаться к нашему «Что происходит, когда…». Как только браузер отправил запрос, он должен понять, какой именно IP у сервера, на котором хранится сайт.

Сначала браузер смотрит, посещали вы этот сайт раньше или нет. А дальше есть два сценария.

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

2 вариант. Если же вы не посещали сайт, браузер начнет просматривать IP в конфигурационных файлах вашей операционной системы (ОС).

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

Если нужной информации не окажется и там, браузер перестанет играть в Шерлока Холмса и отправит запрос на DNS-сервер, на котором 100% есть нужная информация. Кстати, большая часть серверов находится в Северной Америке. Но чтобы вам не приходилось минутами или часами сидеть в ожидании, когда же откроется сайт, по миру сделаны копии DNS. В России, например, копии расположены в:

• Москве,
• Санкт-Петербурге,
• Новосибирске,
• Ростове-на-Дону,
• Екатеринбурге.

Итак, браузер (aka грозный школьник из мемов) вычислил сайт по IP. Что же дальше?

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

Дальше браузер отправляет запрос серверу в духе «Привет, я знаю, что на твоем сервере есть файлы сайта REG.RU. Дай, пожалуйста».

Но, даже если сервер знает об IP-адресе сайта, он не спешит передавать ему ценные данные. Чтобы было безопасно и никто не перехватил данные (как сайта, так и пользователя), браузер и сервер договариваются шифровать путь, по которому обмениваются информацией. Возможно это благодаря протоколу HTTPS и SAN или SSL-сертификату. О них подробнее рассказали в этой статье.

Как только все формальности соблюдены, сервер отвечает браузеру «Да, сейчас всё отправлю».

Данные отправляются в браузер

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

На этом шаге отправляется контент для отображения веб-страницы: информация о типе сжатия данных, способах кэширования, файлы cookie, которые нужно записать, и другие данные.

Чтобы обмен данными был быстрым, используют небольшие пакеты (в пределах 8 КБ). Каждый из пакетов пронумерован. Благодаря этому можно отследить последовательность и объем полученных данных браузером. Если что-то потерялось, браузер говорит серверу: «У меня потерялись пакеты, отправь их еще раз».

Браузер рендерит страницу

Итак, браузер получил все нужные пакеты. Теперь нужно собрать пазл из разложенного по пакетам контента в единую картинку, чтобы отобразить сайт на экране пользователя. Этот процесс называется рендерингом, рассказываем подробнее.

Когда браузер загружает HTML-код страницы, он строит на основании него объектную модель документа (Document Object Model или сокращенно DOM).

Упрощенно, в процессе рендеринга браузер выполняет два основных шага:

1. анализирует HTML-документ, чтобы определить то, что в конечном итоге нужно отобразить на странице;
2. выполняет отрисовку дополнительных элементов: картинок, таблиц, стилей и так далее.

Из всех этих файлов и строится DOM-модель.

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

Когда кажется, что работа завершена, браузер и сервер продолжают взаимодействовать. Например:

• подгружать страницы, на которые переходят с этого сайта (прием используется для эффекта моментальный загрузки);
• записывать что-то в cookie;
• подгружать видео или музыку;
• анализировать, что пользователь делает на странице, и собирать эти данные.

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

Удивительно, какое большое количество шагов выполняется всего за пару секунд.

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

Что стоит за простой загрузкой веб-странички в браузере

На собеседованиях мы часто просим кандидата рассказать настолько подробно, насколько он может, что происходит, когда вводишь в адресной строке браузера адрес сайта и нажимаешь кнопку “Ввод”. В зависимости от того, кого собеседуем — фронтендщика или бекендщика — мы ожидаем разные ответы. А как бы выглядел идеальный ответ на этот вопрос? Ниже мой вариант ответа.

Итак, пользователь вводит в адресной строке браузера адрес сайта и нажимает кнопку “Ввод”.

Браузер состоит из нескольких компонентов, одним из которых является User Interface. Адресная строка как раз является одной из частей этого компонента.

User Interface после ввода URL в адресной строке передаёт управление компоненту Browser Engine, который отвечает за взаимодействие различных компонентов браузера.

Чтобы сделать запрос по указанному URL, браузеру нужно знать IP сервера. Первым делом он смотрим в свой локальный кэш DNS.Компонент Browser Engine как раз имеет доступ к этому кэшу.

В браузере Chrome локальный кэш DNS . доступен по ссылке chrome://net-internals/#dns

Если там нет соответствующей записи, то браузер передаёт управление операционной системе, которая проверяет свой кэш DNS. Если и там отсутствует соответствующая запись, то ОС смотрит в локальные хосты (файл /etc/hosts в Unix-системах). Если запись о хосте отсутствует, то операционная система обращается к интернет провайдеру, у которого тоже есть свой кэш DNS на своих рекурсивных серверах DNS. В случае отсутствия записи в кэше на серверах DNS провайдера, запрос идёт на корневой DNS. У корневого DNS тоже есть кэш. Если соответствующей записи в кэше корневого DNS нет, запрос идёт дальше по цепочке серверов DNS.

К примеру, если адрес нашего сайта site.com.ua, то запросы к DNS выглядят так: site.com.ua.: . (корневой DNS) -> ua (DNS зоны “ua”) -> com (DNS зоны “com”)-> site.

Если на любом из этапов находится нужная запись, то она сохраняется во всех кэшах и управление возвращается браузеру, который уже знает IP нужного сервера.

Процесс получения IP адреса называется DNS lookup.

Далее Browser Engine смотрит в локальном кэше, нет ли запрашиваемой страницы. Если страницы в кэше нет, то Browser Engine передаёт управление компоненту Rendering Engine, который обращается к компоненту Networking Component, чтобы тот сделал запрос GET на указанный IP на порт 80 по протоколу HTTP или на порт 443 по протоколу HTTPS (в зависимости от указанного протокола в URL) со своими стандартными HTTP заголовками. Среди стандартных заголовков есть заголовок host, в котором передаётся хост запрашиваемого сайта (в нашем примере site.com.ua). Если в браузере хранятся куки к этому домену, то он отправляет их в заголовке cookie. Запрос будет выполнен, если соответствующий порт на пользовательском компьютере открыт.

На сервере запрос принимает веб-сервер (например, nginx или apache).

В конфигурационных файлах веб-сервера прописаны обслуживаемые хосты. Веб-сервер достаёт хост из заголовка запроса host и сопоставляет с теми, которые указаны в конфигурации. Если есть совпадение, то веб-сервер находит в конфигурационном файле правила обработки такого запроса и выполняет их. Дальнейшее поведение сервера зависит от технологии и особенностей приложения. Здесь может происходить работа с базами данных, кэшами, запросы к другим серверам и сервисам, выполнение различных скриптов. Для простоты представим, что приложение сгенерировало файл HTML, и веб-сервер отдал его браузеру.

Браузер получил файл HTML с соответствующими HTTP заголовками от сервера, в которых указана длина контента (заголовок Content-Length), тип контента (заголовок Content-Type со значением “text/html; charset=UTF-8” для файлов HTML), заголовки для кэширования. Если присутствуют кэширующие заголовки, то браузер сохраняет файл в локальный кэш.

Заголовки ответа сервера можно увидеть в Chrome DevTools на вкладке Networking, выбрав нужный запрос

Если длина контента больше нуля и тип контента поддерживается браузером, то браузер пытается его обработать. В нашем случае браузер получает файл HTML с соответствующим заголовком Content-Type. Браузер начинает разбор (parsing) этого файла с первой инструкции, которой является инструкция . DOCTYPE указывает на версию HTML, чтобы браузер понимал, каким правилам следовать во время разбора (какие теги как обрабатывать).

Если DOCTYPE отсутствует, то браузер переключится в режим quirks mode и попытается разобрать документ HTML, однако многие элементы будут проигнорированы. Если указан корректный DOCTYPE, то браузер будет работать в standards mode и будет разбирать документ в соответствии с правилами той версии, которая указана в DOCTYPE.

Rendering Engine начинает разбор документа HTML.

Создаётся DOM (Document Object Model). В браузере этот объект доступен по ссылке, которая хранится в переменной document. У документа есть несколько состояний. Первое состояние — loading. Оно означает, что документ только начал формироваться.

Состояние документа хранится в переменной document.readyState.

Также создаётся объект styleSheets, который будет хранить все стили.

Все стили на странице доступны по ссылке, которая хранится в переменной document.styleSheets.

Любой файл — это набор байтов. Браузер берёт полученный набор байтов и преобразует их в символы по таблице символов в соответствии с кодировкой, которая была передана в заголовке Content-Type. В нашем примере это кодировка UTF-8.

Следующий процесс —разбивание текста на смысловые блоки (tokenization). Так браузер распознаёт теги , и проч., а также понимает, какие правила к какому тегу применять (например, поддерживаемые атрибуты).

Далее токены собираются в узлы (nodes). Эти узлы и сохраняются в DOM со всеми взаимными связями.

Во время разбора, если Rendering Engine встречает ссылку на внешний ресурс, то он передаёт команду загрузить этот ресурс компоненту Networking Component. Это может быть ссылка на стили, скрипты, картинки и т.п. Networking Component ставит все ресурсы в очередь на загрузку. Каждому ресурсу Networking Component присваивает приоритет.

Приоритеты ресурсов можно посмотреть в Chrome DevTools на вкладке Networking в колонке Priority.

Так, у HTML, CSS и шрифтов самый высокий приоритет. У изображений приоритет изначально низкий, но если Rendering Engine обнаружит, что изображение попадает в поле видимости (view port) пользователя, то повысит приоритет до среднего. Приоритет скрипта зависит от положения на странице и способа загрузки. У асинхронных скриптов (async/defer) низкий приоритет. У скриптов, которые в документе перед изображениями — высокий, у тех, что после хотя бы одного изображение — средний.

По возможности браузер пытается загружать ресурсы параллельно. Однако, он не может загружать параллельно более 6 ресурсов с одного домена.

Кроме того, когда Rendering Engine отдаёт команду компоненту Networking Component на синхронную загрузку стиля или скрипта, он останавливает разбор документа.

С загрузкой стилей происходит подобный процесс преобразования из байтов в Object Model (CSSOM): байты -> символы -> токены -> узлы -> CSSOM.

Немного иначе происходит загрузка скрипта. Вместо того, чтобы вернуть управление Rendering Engine’у, Networking Component . передаёт управление JavaScript Interpreter, который преобразует байты в исполняемый код: байты -> символы -> токены -> Abstract Syntax Tree (evaluating). Далее в работу вступает компилятор, который оптимизирует AST, кэширует некоторые участки кода, компилирует его на лету (JIT compilation) в исполняемый код и исполняет (executing). Однако исполняется скрипт только, когда готова CSSOM. До тех пор скрипт стоит в очереди на исполнение.

Во многих современных браузерах во время исполнения JavaScript в отдельном потоке продолжается сканирование документа на наличие ссылок на другие ресурсы и постановка ресурсов в очередь на скачивание (Speculative parsing).

Каждый этап разбора HTML, CSS и JS можно увидеть в Chrome DevTools во вкладке Performance

Если при загрузке скрипта Rendering Engine видит у скрипта атрибут async, то он не останавливает разбор документа во время загрузки скрипта. Скрипт также станет в очередь на исполнение, дожидаясь, когда CSSOM будет готова.

Если при загрузке скрипта Rendering Engine видит у скрипта атрибут defer, то он не останавливает разбор документа во время загрузки скрипта, но когда скрипт загрузится, он станет в очередь на исполнение, которая заработает при возникновении события DOMContentLoaded. К этому моменту CSSOM будет уже готова.

Когда Rendering Engine заканчивает разбор документа, он вызывает событие DOMContentLoaded, и состояние документа меняется на interactive. При этом ресурсы (например, картинки) могут продолжать загружаться.

Когда все ресурсы загрузились, вызывается событие load, а состояние документа меняется на complete.

После того, как документ полностью разобран и сформированы DOM и CSSOM, Rendering Engine начинает построение Render Tree. В него попадут все элементы, которые нужно отрисовать. Некоторые элементы изначально могут быть невидимыми — их не нужно рисовать. Для каждого элемента, который “выпадает” из потока (например, используется position: absolute), будет создаваться отдельная ветка в Render Tree.

Во время Rendering Tree происходит сопоставление узлов из DOM и узлов CSSOM.

Свойства узла можно получить с помощью функции window.getComputedStyles(узел).

Когда Rendering Tree готов, Rendering Engine запускает процесс layout. Он заключается в вычислении размеров и позиций каждого элемента на странице.

Следующий этап — paint. Rendering Engine вычисляет цвет каждого пикселя.

И, наконец, последний этап — composite. Компонент UI Backend слой за слоем отрисовывает элементы на странице. При этом, если требуется отрисовать изображение, которое ещё не загрузилось, во время процесса layout, Rendering Engine зарезервирует место для изображения, если у него указаны ширина и высота. Rendering Engine вынесет на отдельный слой те элементы, стили которых содержат правила opacity, transform или will-change. Более того, эти слои Rendering Engine передаст для обработки GPU.

Если требуется отобразить текст, для которого используется нестандартный шрифт, то современные браузеры скроют текст до момента загрузки шрифта (flash of invisible text).

В современных браузерах скачивание документа, его разбор и отрисовка происходят по кускам, частями.

В документе HTML могут присутствовать некоторые мета-теги, которые могут менять порядок загрузки ресурсов, а также их приоритет.

К примеру, мета-тег dns-prefetch вынуждает Rendering Engine обратиться к Networking Component и получить IP нужного домена ещё до того, как Rendering Engine встретить его в документе.

Мета-тег prefetch вынудит Networking Component поставить указанный ресурс в очередь на загрузку с низким приоритетом.

Мета-тег preload вынудит Networking Component поставить указанный ресурс в очередь на загрузку с высоким приоритетом.

Мета-тег preconnect вынудит Networking Component заранее подключиться к другом хосту, то есть пройти нужные этапы: DNS lookup, redirects, hand shakes.

Время, которое затрачивается на каждый этап, происходящий во время запроса и разбора документа HTML, хранится в объекте performance.timing.

Полезные ссылки

Что происходит, когда мы открываем сайт в браузере

Эта статья — короткий и простой перевод статьи «What happens when. », опубликованной на Гитхабе. В ней автор подробно рассказывает, что именно происходит внутри компьютера, когда мы вводим в браузере адрес сайта и нажимаем энтер. Мы убрали излишние технические подробности вроде IRQ-прерываний и ARP-запросов и добавили картинки, чтобы было проще понять суть.

Начало

Мы ввели адрес сайта — thecode.media — и нажали энтер. Что происходит дальше?

Поиск сервера в интернете

Каждый сайт в сети физически хранится на каком-то сервере. Как только браузер от нас получил адрес сайта, он должен понять, к какому серверу обратиться за данными. Но то, что мы называем адресом, на самом деле не адрес, а доменное имя.

�� Проще говоря, когда вы садитесь в такси и говорите «Мне в „Мегу“», вы назвали водителю не адрес, а доменное имя. Водитель уже сам должен знать, где в вашем городе «Мега».

Так вот: теперь задача браузера — определить по доменному имени адрес, на который отправлять запрос. В мире интернета этот адрес называется IP-адресом. Он есть у каждого сервера и выглядит, например, так:

По этим числам компьютеры понимают, как связаться друг с другом и отправить нужные данные. Чтобы понять, какой именно IP-адрес у сервера с нашим сайтом, браузер делает так:

1. Сначала смотрит, посещали мы этот сайт раньше или нет. Если посещали — возьмёт IP-адрес из истории. Так же, как водитель, который тысячу раз ездил в «Мегу».
2. Если не посещали — посмотрит в конфигурационных файлах операционной системы. Иногда для ускорения работы некоторые IP-адреса можно прописать в конфигурации компьютера, чтобы он сразу знал, куда обращаться.
3. Если в настройках такого нет, браузер смотрит недавние адреса в роутере, через который компьютер подключается к интернету.
4. Если и там нет, то браузер отправляет запрос на DNS-сервер. Там точно всё есть, но результат получится медленнее, чем в остальных способах.

DNS-сервер — это такая служба в интернете, которая отвечает всем желающим на вопрос «Какой IP у такого-то домена?». Таких серверов в интернете много, и каждый из них знает про свою часть сети. Если у ближайшего сервера нет записей о нашем домене, то он отвечает «Я не знаю, спроси у DNS-сервера покрупнее, вот его адрес». В итоге браузер найдёт DNS-сервер, который знает то, что нам нужно, и получит IP-адрес сервера с сайтом.

Что ещё прочитать на эту тему:

Отправка запроса

Браузер нашёл IP-адрес сервера, на котором располагается наш сайт, и отправляет по этому адресу запрос типа «Я знаю, что у тебя есть вот такой домен. Мне нужна вот такая страница с этого домена с такими-то параметрами. Дай, пожалуйста».

Чтобы всё было безопасно и данные никто не перехватил по пути, браузер и сервер договариваются шифровать все сообщения друг другу. Как только все формальности соблюдены, сервер отвечает «Да, конечно, сейчас всё отправлю». Иногда в адресе бывают ошибки, и сервер не может у себя найти нужную страницу. Тогда он отвечает «А у меня нет нужной страницы, ничем не могу помочь», и браузер показывает ошибку.

Сервер думает

Когда сервер получает запрос от браузера и с адресом всё в порядке, он начинает готовить данные к отправке. Для этого он смотрит, какие серверные программы отвечают за этот домен, и говорит им «Соберите мне вот эту страницу, чтобы я её отправил в браузер». Например, на сервере может стоять Вордпресс или PHP-обработчик, который на лету собирает страницу из разных фрагментов кода.

Отправка данных в браузер

Как только сервер получил от своих внутренних программ всё, что ему нужно, он отправляет результат в браузер.

Для этого он нарезает все данные на мелкие пакеты данных по 8 килобайт, нумерует их и отправляет браузеру. Так делается для того, чтобы одновременно передавать много пакетов — в этом случае загрузка идёт быстрее. Нумерация нужна для того, чтобы браузер потом собрал все пакеты в одно целое и получил исходный документ. Если по пути пакет потерялся, браузер говорит серверу «У меня потерялись такие-то пакеты, отправь их ещё раз». И так до тех пор, пока браузер не соберёт все пакеты.

Браузер думает

Когда все пакеты собраны, браузер разбирает документ на составляющие:

• HTML;
• CSS;
• JavaScript;
• прочий код, который браузер может выполнить.

Это нужно для того, чтобы браузер построил DOM-модель страницы. Такая модель содержит:

• все элементы, которые есть на странице;
• связи между ними;
• как они взаимодействуют между собой;
• что умеют и как реагируют на действия пользователя.

На основе DOM-модели браузер в итоге будет рисовать страницу на экране.

Отрисовка страницы

Последнее, что нужно сделать браузеру, — взять DOM-модель, найти в ней все видимые элементы и нарисовать их на экране. Если есть JavaScript-код, то он выполняется либо до отрисовки, либо после, смотря как работает скрипт.

Иногда во время отрисовки страницы браузер может снова запросить данные у сервера. В этом случае браузер рисует то, что есть, а остальное — когда придут данные. Пока данных нет, на странице могут быть пустые места — например, браузер отрисовал верхнее меню и статью, но ещё не подгрузил видео с ютуба.

Всё готово

Когда страница загрузилась и браузер всё нарисовал, мы видим готовый результат. Но даже сейчас браузер может продолжать работать над страницей:

• выполнять JS-скрипт;
• подгружать в фоне музыку или видео;
• подгружать страницы, на которые переходят с этого сайта чаще всего, чтобы создать эффект моментальной загрузки новых страниц;
• записывать что-то в куки или в локальное хранилище;
• собирать данные о том, что вы делаете на странице;
• и что угодно ещё, что предусмотрели программисты.

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

Об этом спрашивают на собеседованиях. Структурированное понимание этого может помочь вам, даже если вы давно строите сложные архитектурные процессы или кодите 20-ый год подряд. Я — программист уже много лет, последние пару из которых пишу на Go в Каруне. Работа работой, а внутренний исследователь не дремлет. И вот я наконец-то решил привести в порядок информацию, разбросанную по разным закоулкам чертогов разума, по добротным книгам и статьям на тему сетевых технологий.

Хочу представить краткую выжимку о работе протоколов. А если тема окажется интересной, могу продолжить работать с ней более детально. Рассмотрим простейший пример: вы ввели некоторый url в адресную строку. Поехали.

The Open Systems Interconnection model (OSI)

Для начала придётся упомянуть семиуровневую модель OSI, с которой, возможно, каждый из вас знаком не понаслышке. Эталонная модель взаимодействия открытых систем является абстракцией, которая связывает и стандартизирует взаимодействие открытых систем. Она не описывает никакие используемые протоколы, а только определяет, какие функции выполняет каждый из её уровней. В основе любого сетевого взаимодействия лежит данная модель. Для привычного нам интернета схема OSI и соответствующие ей протоколы чаще всего имеют следующий вид:

Некоторые уровни могут отсутствовать и/или объединяться. Рассматривать работу схемы начнём с верхнего уровня — с того самого ввода адреса в адресную строку.

Прикладной уровень, HTTP

Прикладной уровень в модели OSI нужен для взаимодействия пользовательских приложений с сетью. Единица данных, которой оперирует прикладной уровень, называется сообщением. В описываемой системе уровень представлен протоколом HTTP. При вводе адреса google.com ваш браузер формирует HTTP сообщение, которое состоит из строки запроса, тела сообщения и заголовков со служебной информацией — такой как версия протокола, контрольная сумма сообщения, и т.д. Далее задача в том, чтобы передать HTTP-сообщение на следующий уровень — представления, если это HTTPS, или на TCP, если это HTTP.

Уровень представления, SSL (TLS)

Уровень представления отвечает за кодирование/декодирование, а также за шифрование/дешифрование данных. Благодаря этому уровню информация, передаваемая одной системой, всегда понятна другой системе.

Если сервер, к которому вы посылаете запрос, работает на протоколе HTTPS, то в него включён протокол защиты данных — SSL. SSL развивался до версии 3.0. Потом на основе него был создан TLS, который сейчас используется везде и гарантирует безопасность соединения. Принцип работы протокола базируется на ассиметричном шифровании и для создания безопасного канала связи оперирует такими понятиями как публичный ключ, приватный ключ, сеансовый ключ.

Ваш браузер и сервер заново создают защищённое соединение при каждом открытии сайта. Как же это работает? Для начала браузер создаёт запрос на запрашиваемый адрес, чтобы узнать есть ли у него SSL-сертификат. В ответ на запрос он получает информацию и публичный ключ, с полученной информацией делает запрос в центр сертификации (адреса центров сертификации уже есть в вашем браузере по умолчанию). Если информация подтверждается, ваш браузер генерирует сеансовый ключ, зашифровывает его публичным ключом и отправляет на сервер. Сервер расшифровывает сообщение с помощью приватного ключа и сохраняет сеансовый ключ. После этого соединение можно считать установленным — при общении клиента и сервера используется для шифрования сеансовый ключ. И «общение» между клиентом и сервером переходит на симметричное шифрование с помощью сгенерированного сеансового ключа.

Транспортный уровень, TCP

Транспортный уровень по определению обеспечивает передачу данных со степенью надёжности, которая требуется приложениям. В сети Интернет, в рассматриваемом взаимодействии, этот уровень представлен протоколом TCP, задача которого — надёжно доставить HTTP(S)-сообщение в пункт назначения. Единица данных как для TCP уровня, так и для следующего (IP) носит название пакет.

Операционная система, получив HTTP-сообщение от браузера, должна «встроить» его в пакет протокола нижележащего уровня — TCP. Такой процесс встраивания называется инкапсуляцией. Операция эта осуществляется на каждом уровне: пакеты вышележащего уровня инкапсулируются в пакеты нижележащего. И на самом нижнем уровне мы получаем информационную “матрёшку” с вложенными друг в друга пакетами, со служебной информацией в виде заголовков, добавленных на каждом уровне:

Формируются TCP-пакеты чаще всего в ядре операционной системы. Вся прелесть протокола TCP — в надёжности доставки. Использование этого протокола предусматривает установление так называемого логического соединения между двумя конечными узлами сети (перед этим, естественно, такое соединение нужно согласовать). Надёжную доставку пакетов протокол TCP обеспечивает посредством нумерации пакетов, подтверждения их передачи квитанциями, а также контроля правильного порядка пакетов. Схема установления логического соединения, передачи данных и разрыва соединения представлена на рисунке ниже:

Сетевой уровень, IP

Сетевой уровень в общем случае нужен для образования единой транспортной системы, которая объединяет несколько сетей. Сети, кстати, могут иметь разные стеки протоколов. Также на этом уровне определяется маршрут пересылки пакетов от отправителя к получателю.

По ходу перемещения IP-пакета по сети маршрутизаторы передают пакеты от одной сети к другой или же на конечный узел-получатель. Данный протокол не занимается установлением соединения, не контролирует целостность данных, не гарантирует доставку и не отвечает за их достоверность, то есть реализует политику доставки «по возможности». Всё это бремя возложено на вышележащий протокол — TCP. Получив TCP-пакет, ОС инкапсулирует его в IP-пакет, добавляет в него свои параметры и передаёт далее.

DNS

Для того чтобы отправить какие-то данные серверу в IP-пакете, нужно узнать его IP-адрес. Для этого есть специальный протокол DNS, с помощью которого делается отдельный от основного запрос. Запрос этот называется DNS-запросом, и посылается он на специальный DNS сервер — его адрес заведомо известен и прописал в настройках вашей операционной системы. DNS-протокол — это представитель протокола прикладного уровня. Кратко его работу можно описать так:

1. Клиент создает DNS-сообщение, добавляя неизвестный URL в раздел вопроса этого сообщения.
2. Сообщение DNS инкапсулируется в UDP-дейтаграмму протокола UDP транспортного уровня.
3. UDP-дейтаграмма инкапсулируется в IP-пакет данных с IP-адресом назначения DNS-сервера и отправляется на DNS-сервер.
4. DNS-сервер возвращает запись ресурса, в которой указан IP-адрес URL.

Строго говоря, запрос этот выполняется не всегда. Так как вначале браузер проверяет соответствие IP адреса и домена в своем кэше (для chrome это chrome://net-internals/#dns). Затем, если соответствия не найдено, браузер обращается к операционной системе, которая ищет информацию в системном файле hosts. И только в случае, если ничего не найдено в этом файле, посылается запрос DNS. Полученный адрес уже можно указать в формируемом IP-пакете основного запроса.

Физический и канальный уровни, Ethernet

Канальный уровень (также — уровень передачи данных) необходим для передачи сырых данных физического уровня по надежной линии связи. Основная задача на этом уровне — обнаружение и коррекция ошибок. Также он может исправлять ошибки за счёт повторной передачи поврежденных кадров. Канальный уровень тоже должен проверить доступность среды — можно ли выполнять пересылку данных в конкретный момент. Иногда эту функцию выделяют в отдельный подуровень управления доступом к среде (MAC).

Физический уровень отвечает за передачу потока битов по каналам физической связи (коаксиальные кабеля, оптоволокно, витая пара). Со стороны компьютера функции физического уровня выполняет сетевой адаптер или COM-порт. На этом уровне есть только поток битов и ничего более: протокол «не задумывается» об информации, которую он передаёт.

В нашем случае протокол Ethernet объединяет эти два уровня. Ethernet оперирует единицей данных, которая называется кадр. Для физического уровня нет никакого анализа информации, которая передаётся. Для передачи данных между узлами протокол работает по схеме с коммутацией пакетов, то есть сеть ведёт себя менее «ответственно», не создавая для абонентов отдельных каналов связи. Данные могут задерживаться и даже теряться. Поэтому ошибки на этом уровне не исправляются. Это опять же возложено на протокол верхнего уровня — TCP.

Для физического уровня Ethernet описывается стандартом группы IEEE 802.3, который определяет физические характеристики канала связи. Например, какой кабель будет использоваться для передачи данных: витая пара, коаксиальный кабель или оптоволокно. Тут же определяется вид кодирования и модуляции сигнала. Технические характеристики каждого стандарта хорошо описаны в данной статье. Например, спецификация 100Base-T определяет в качестве используемого кабеля витую пару, с максимальной длинной физического сегмента 100 метров и манчестерским кодом для данных в кабеле.

Путь пакета

На следующей схеме представлена схема взаимодействия узлов сети. Наш пакет выходит из конечного узла слева, проходя через концентраторы, коммутаторы (работающие на канальном уровне) и маршрутизаторы, работающие на сетевом уровне:

Как видно из схемы, концентратор работает с данными на физическом уровне, но в настоящее время они вытеснены сетевыми коммутаторами, умеющими работать на канальном и физическом уровнях.

Совершив путь от одного конечного узла до другого, он распаковывается в обратном порядке: из Ethernet-кадра вытаскивается IP-пакет, из него, в свою очередь, TCP-пакет. Получив в конечном счёте HTTP-сообщение и считав с него нужную информацию, сервер формирует и посылает ответное HTTP-сообщение. Оно, в свою очередь, также проходит через каждый уровень и возвращается в виде ответа клиенту, распаковывается каждым уровнем, и мы видим заветную информацию на экране.

Конечно, это краткий обзор того, что происходит в сети Интернет на примере HTTP-запроса. Существует много деталей, которые не вошли в эту статью, дабы не растягивать её до бесконечности, но, надеюсь, войдут в будущие мои обзоры.

Книги, которые помогли мне. Рекомендую и вам:

1. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы — СПб.: Питер, 2018. — 992
2. Таненбаум Э., Уэзеролл Д. Компьютерные сет — СПб.: Питер, 2020. — 960 с.: ил.