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

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

The Open Systems Interconnection model (OSI)

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

Комментарии (21)


  1. Akuma
    27.09.2021 16:19
    +7

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

    И внезапно статья про OSI, хотя явно ожидаешь объяснение работы HTTP и браузера.


    1. nicebmw9
      27.09.2021 16:31

      Хм. У меня таких ожиданий не было. Не знаете как браузер отрисовывает html и css ?


      1. Akuma
        27.09.2021 16:32

        Ну так то я и про OSI знаю.

        Просто "интернет" ассоциируется как раз с http, а не с сетевой моделью.


        1. nicebmw9
          27.09.2021 16:33

          А я вот знал ровно наоборот :D


        1. slava-a Автор
          27.09.2021 16:36
          +1

          возможно эта ассоциация зависит от вашей специальности)
          мне, как backend-разработчику, работа интернета представляется как раз как стек описанных протоколов


          1. Akuma
            27.09.2021 16:38

            Интересно, каких протоколов?

            Пусть бекенд. Какие протоколы вы используете при связи через интернет, кроме http/s?


            1. slava-a Автор
              27.09.2021 16:50
              +2

              imap, ssh, в свое время использовал ftp

              думаю, что всегда нужно интересоваться как все устроено внутри — от этого приходит лучшее понимание верхнеуровневых процессов
              поэтому мне и интересно что находится ниже — ip, udp, tcp и.т.д.


              1. ehots
                28.09.2021 12:10

                Искал как раз подобную статью, хорошо получилось. Предыдущий комментатор скорей всего имел ввиду что после заголовка "Что происходит, когда вводишь url, или как работает интернет" ожидал больше про работу браузера и наверное работу протоколов http\s, т.к. ввести запрос в строчку браузера и нажать Enter, самый популярный сценарий у пользователей.
                Про работу браузера подробнее было бы интересно почитать, если будут еще статьи на это тему =)


    1. g0gan
      28.09.2021 11:45

      Вы забыли указать как возникает мысль сходить на google.com, как мозг координирует работу глаз, пальцев, тактильных ощущений


      1. Akuma
        28.09.2021 11:46
        +1

        Нет. А вот статья как раз про это


  1. astra77
    27.09.2021 16:41
    +4

    Я что-то не понял, вы что - просто перепечатали сюда главу из древней книги Олифера??


    1. slava-a Автор
      27.09.2021 16:42
      +1

      да, а еще 2 главы из Таненбаума)

      а если серьезно, то нет — прочитал множество информации, также имею образование в этой области
      а насчет древности вопрос спорный, во-первых книге всего около 10 лет, во-вторых ничего то и не поменялось с тех пор


      1. f000
        27.09.2021 19:02

        Книге Олиферов более 20 лет, в начале 2000-х уже была, по ней и учился.


      1. yellowmew
        28.09.2021 10:17
        +2

        в общем да, база не поменялась, но серьезные изменения в том "что происходит когда вводишь url в браузер" уже есть(схемы работы есть по ссылкам, если интересно)

        1. http/2 - в принципе просто оптимизация http/1 но уже работает несколько иначе

        2. http/3 - работает уже не через TCP

        и поправки для DNS:

        1. он может работать и через TCP в некоторых случаях

        2. При вводе адреса в адресную строку браузер может делать DNS запросы не только для выяснения пункта назначения но и к разным DNS записям в DNS зоне пункта назначения, чтобы прочитать параметры безопасности

        3. схема "браузер кеш"->"хостс"->"днс-сервер" и так-то работала не для всех ОС одинаково (в Windows например есть служба DNS client, которая так же кеширует данные DNS) а с появлением массового DOH в браузерах так и вообще работает совсем не так.

        p.s. тонны редактирований коммента, а можно ведь сделать черновик для комментариев? %D


  1. mc2
    27.09.2021 17:12
    +3

    Имхо предыдущая статья была более всеобьемлюща:

    https://habr.com/ru/company/htmlacademy/blog/254825/


  1. Gengenid
    27.09.2021 18:27
    +9

    Я думал, статья начнется с того, что когда вводишь url он передается:

    1. разработчику браузера

    2. партнерам разработчика браузера

    3. трем правительственным агентствам

    4. разработчикам шести дополнений

    5. на какой-то сервер, никто не помнит зачем, но при попытке убрать ломается TLS 1.2

    И другие причуды современного веб. А тут про OSI


  1. agmt
    27.09.2021 21:05

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

    Интересно, что нового в книгах 2018/2020г, чего нет в ГОСТ 24402-88? И для кого там писали, что уровень звена данных недопустимо называть канальным уровнем (вероятно, это была пасхалка, чтобы на этот гост сослались спустя 33 года). docs.cntd.ru/document/1200015767


  1. ildar_vildanovich
    27.09.2021 22:42

    Вы пишите, что единицей данных для транспортного уровня является пакет. Вы ошибаетесь, на транспортном уровне оперируют понятиями datagram для udp и segment для tcp соответственно


    1. slava-a Автор
      27.09.2021 22:44
      +1

      вопрос довольно дискуссионный

      Таненбаум называет сегментом единицу данных и TCP, и UDP. У Олиферов TCP это пакет, а UDP - дейтаграмма. На просторах интернета можно встретить еще варианты обозначений


  1. Old_Pepper
    28.09.2021 11:46
    +1

    Мне кажется, логичнее описывать первым шагом при вводе URL работу DNS, поскольку общение клиента и сервера начинается с выяснения адреса (IP) сервера.


  1. Comraddm
    11.10.2021 18:13

    Имхо в статье есть неточность:

    с полученной информацией делает запрос в центр сертификации (адреса центров сертификации уже есть в вашем браузере по умолчанию)

    Браузер не делает запросов ни по каким адресам центров сертификации.

    Он сверяется с доступными ему в своей ОС (или в своем хранилище в случае Firefox) корневыми и промежуточными сертификатами и на их основе определят достоверность предоставленного сервером сертификата.

    Периодически корневые сертификаты, установленные в системе, устаревают (как совсем недавно это произошло с IdenTrust DST Root CA X3), и тогда начинаются проблемы с подключением, если списки этих корневых сертификатов в системе вовремя не обновить. В некоторых устройствах это проблематично.