Предыдущая попытка была, прямо скажем, неудачной. Это видно по комментариям читателей. Было кратко, но скомкано. Признаю. Сегодня я попробую объяснить интернет-связь более понятно. И в этот раз начну с другого конца.
Сначала общая концепция передачи данных. Берём данные, предназначенные для передачи. Например, некий текст. В Интернете это чаще всего это гипертекст, то есть текстовый html-исходник, формирующий страницу сайта.
Любой вид текста — это, как мы с вами, наверное, понимаем, набор цифровых кодов, каждый из которых представляет свой символ. То есть, у нас есть некоторая последовательность цифр, порой, весьма длинная, которую надо передать через сеть:
Передавать сразу всю последовательность целиком за один раз, особенно, если она не такая, как на рисунке, а очень длинная, нецелесообразно. Если он по техническим причинам она потеряется по дороге, её придётся отправлять целиком ещё раз. Такой подход даёт большую нагрузку на сеть.
Лучше разбить цифровую последовательность на кусочки, и отправлять её по частям, контролируя прохождение каждого кусочка. В случае потери одного из кусочков повторно придётся отправить только этот потерянный кусочек. Поэтому последовательность разбивается, и каждый кусочек предваряется ещё несколькими цифрами, идентифицирующими его:
Такая конструкция называется сегментом. В заголовке находится также программный порт, на который кусочек должен прийти, а также порт, с которого он был отправлен. Прохождение каждого сегмента контролируется, и в случае его потери он отправляется повторно. При получении дублирующиеся сегменты устраняются, и выстраивается их правильная последовательность,
Однако это ещё не всё. Перед отправкой сегмент предваряется ещё одним заголовком, в котором помимо прочей служебной информации указывается интернет-адрес получателя, так называемый IP-адрес, а также IP-адрес отправителя:
Такая конструкция называется пакетом. Казалось бы, всё, можно отправлять! Но нет. Чтобы пакет мог путешествовать по сети от маршрутизатора к маршрутизатору, он должен знать конкретные адреса физических сетевых устройств, которые должен пройти и физический адрес сетевой карты адресата. Эти физические адреса называются MAC-адресами, и обычно прошиваются в железо самого физического сетевого интерфейса устройства.
Изначально маршрутизаторы знают только IP-адреса следующих маршрутизаторов, куда должен быть перенаправлен пакет при его путешествии по сети. Поэтому они шлют запрос в сеть, чтобы следующий маршрутизатор с нужным IP-адресом сообщил MAC-адрес своего сетевого интерфейса. После этого пакет предваряется уже третьим заголовком, куда и прописываются MAC-адреса получателя и отправителя, а также завершающим окончанием, содержащим контрольную сумму:
Такая конструкция называется кадром. Всё, в таком виде кадр можно передавать непосредственно в сетевой интерфейс для побитовой передачи через физическую среду — медный кабель, оптоволокно или «эфир». На этом этапе биты кодируются в зависимости от физической среды электрическими, оптическими или электромагнитными импульсами (волной).
Самой наглядной иллюстрацией кодирования цифрового сигнала является обычный пищащий и шипящий домашний модем, которым мы пользовались ещё совсем недавно для выхода в Интернет через проводную телефонную сеть. Модем получал цифровой сигнал из компьютера и кодировал его довольно сложным образом, многократно модулируя разными способами несущую частоту, передаваемую им в телефонную линию, пытаясь использовать возможности телефонного канала по-максимуму.
Собственно, так устроена передача информации в сети Интернет. Сначала дробление её на куски, а потом многократная «запаковка» каждого куска как матрёшку — сначала в сегмент, потом в пакет, потом в кадр. На пути движения кадра он распаковывается каждым промежуточным маршрутизатором, чтобы достать IP-адрес назначения, и снова запаковывается с новыми MAC-адресами, нужными для каждого этапа пересылки.
На компьютере получателя кадр распаковывается до сегмента, чтобы узнать программный порт назначения, после чего из сегмента достаются уже сами данные. Также на уровне сегмента работают межсетевые экраны, поскольку они тоже оперируют портами.
Сетевая модель TCP/IP
Всё вышеописанное, вся эта «матрёшка» формализуется так называемой сетевой моделью TCP/IP, в которой каждый уровень матрёшки при передаче данных обрабатывается по своим правилам, определённым соответствующими протоколами.
Таким образом, сетевая модель иначе называется моделью набора сетевых протоколов или же стека сетевых протоколов. Названа модель TCP/IP по названию наиболее заметных центральных протоколов этой модели — TCP и IP.
Вообще, существуют две основные модели — OSI с семью уровнями «матрёшки» и TCP/IP с четырьмя уровнями, в которой объединены три верхних и два нижних уровня иерархии:
Если вспомнить нашу матрёшку, и сопоставить её с приведёнными выше моделями, то за данные передаваемого нами гипертекста отвечает прикладной уровень и его протокол HTTP. Наш браузер, являющийся частью прикладного уровня, посылает запросы нужной интернет-страницы на сервер, где размещён сайт с этой страницей. Запросы направлены тому же прикладному уровню модели, только на сервере. Важно понимать, что при передаче информации взаимодействуют между собой только одноимённые уровни.
В ответ на запрос сервер формирует страницу гипертекста и отправляет её опять же в соответствии с правилами протокола HTTP нам на тот же прикладной уровень в браузер. В итоге страница оказывается у нас и отображается на экране.
Протокол HTTP ничего не знает о сегментах, пакетах и кадрах, и проблемах их передачи. Он просто пользуется уже налаженным ими соединением, отправляя страницы транспортному уровню целиком.
Транспортный уровень руководствуется протоколом TCP (и при необходимости UDP). Протокол TCP формирует сегменты и отвечает за их гарантированную доставку до соответствующего уровня противоположного компьютера. Кадры с пакетами, содержащими сегменты могут проходить по сети разными маршрутами через разные маршрутизаторы, и из-за этого порядок их отправки может не совпадать с порядком их получения. Поэтому протокол TCP отвечает также и за восстановление очередности пришедших данных.
Протокол TCP знает только порт назначения в компьютере адресата, но ничего не знает о самом адресе этого компьютера в сети. Поэтому для отправки сегмента адресату он передаёт его на сетевой уровень.
Сетевой (иначе — сетевого взаимодействия, межсетевой) уровень руководствуется протоколом IP. Он оперирует уже IP-адресами и позволяет строить по ним маршрут доставки. Пришедший с транспортного уровня сегмент запаковывается в пакет с IP-адресами, и отправляет его соответствующему уровню на компьютере адресата.
Но вот беда, сетевой уровень знает только виртуальные IP-адреса маршрута, а чтобы передать пакет на физический сетевой интерфейс следующего маршрутизатора нужно знать его физический адрес, а об этих тонкостях сетевой уровень ничего не знает. Поэтому пакет просто отправляется на канальный уровень.
Где-то тут между сетевым и канальным уровнями срабатывает неприкаянный протокол ARP, который запрашивает MAC-адрес следующего маршрутизатора по имеющемуся IP-адресу, отправляя соответствующий запрос в сеть и получая ответ с запрошенным MAC-адресом от сетевого устройства, чей IP-адрес совпал с отправленным. Найденный по IP-адресу маршрутизатор возвращает MAC-адрес своего сетевого интерфейса, который будет использован на канальном уровне при формировании кадра.
Канальный уровень руководствуется протоколом технологии Ethernet (или Wi-Fi в случае беспроводного канала). На этом уровне IP-пакеты упаковываются в кадры с указанием конкретного MAC-адреса сетевого интерфейса следующего маршрутизатора, добавляет контрольную сумму и отправляет кадр в сеть.
Маршрутизатор-адресат получает кадр, вскрывает пакет, передавая его на сетевой уровень, и определяет IP-адрес следующего маршрутизатора. Затем получает его MAC-адрес (ARP-протокол), и снова запаковывает пакет в кадр, но уже со своим MAC-адресом отправителя и новым MAC-адресом получателя. Так кадр идёт «по рукам» по вычисленному маршрутизаторами IP-маршруту от сетевого интерфейса к сетевому интерфейсу через все промежуточные узлы Интернета.
Но как физически он идёт «по рукам»? Не в абстрактном же логическом цифровом виде продирается сквозь реальный мир. Как я уже упоминал в конце предыдущей главы, для того, чтобы передать цифровой кадр через аналоговую физическую среду (медный кабель, оптоволокно, «эфир») его нужно выстроить в последовательность логических битов, а потом каким-то образом закодировать их свойствами аналоговой среды. Такое кодирование происходит на физическом уровне.
Физический уровень также регламентируется технологией Ethernet (или Wi-Fi в случае беспроводного канала) и кодирует последовательности битов по-разному в зависимости от выбранного метода и фактических свойств аналоговой среды. Например, для передачи по медному кабелю можно, в простейшем случае, присвоить нулевому значению бита отсутствие напряжения или некоторый низкий уровень напряжения, а единице — высокий уровень напряжения, и последовательно передать эту «гребёнку» двух уровней напряжений в кабель.
Физический уровень адресата декодирует гребёнку напряжений обратно в логические сигналы последовательности битов и передаёт их на канальный уровень, где из них формируются кадры. В случае оптоволокна роль напряжения выполняет электромагнитная волна оптического диапазона (свет), а в случае беспроводной передачи — несущая электромагнитная волна радиочастотного диапазона (радиоволна), которую можно промодулировать различными способами..
Сетевая модель слишком академична
На мой взгляд, обе модели, что OSI, что TCP/IP, слишком мелко нашинковывают алгоритм передачи данных. Для реальной реализации я бы несколько упростил этот стек (взаимосвязанный набор) протоколов, оставив всего три уровня — прикладной, транспортный и физический.
Физический уровень — это всё, что относится к физической среде передачи — способы и методы модуляции аналоговых свойств среды для кодирования логического цифрового сигнала и сама физическая передача модулированного сигнала между сетевыми интерфейсами.
Транспортный уровень — всё, что относится к транспортировке логических блоков информации. Это установка соединения, адресация пакетов, подтверждение доставки и т.п., то есть всё, за что отвечает транспортный, сетевой и канальный уровни модели TCP/IP.
Я не вижу необходимости оборачивать сегмент пакетом а пакет кадром, тем более, что технически все три заголовка следуют вплотную друг за другом и выглядят, как один, и один и тот же транспортный алгоритм может напрямую обращаться к любому полю этого большого заголовка.
Другое дело, что программисты при реализации этого алгоритма в коде, могут разбивать его на какие-то этапы, но это уже личное дело программиста, как организовать работу транспортного уровня. Зачем это жёстко регламентировать и выносить на уровень сетевых инженеров — непонятно.
Прикладной уровень — как и сегодня, это всё, что может нагородить программист поверх работающего транспортного соединения. Кстати, в модели TCP/IP этот уровень уже пошёл по правильному пути по отношению к более подробной академической модели OSI — там сеансовый уровень, уровень представления и прикладной уровень были объединены в один уровень — прикладной. И это правильно, поскольку программист сам волен выбирать, как ему в зависимости от задачи использовать имеющееся соединение.
Заключение
Надеюсь, сегодняшнее объяснение работы интернет-связи было более понятным, чем предыдущее. По крайней мере, я старался :-)
Ставьте нравлики, оставляйте отзывы в комментариях и подписывайтесь на мой канал. Пока!