1.2 Как можно помочь выпуску новых уроков и будет ли продолжение курса?
Привет, посетитель сайта ZametkiNaPolyah.ru! В этой записи мы еще не начинаем изучать компьютерные сети всё,…
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей, напомню, что эти записи основаны на программе Cisco ICND1 и помогут вам подготовиться к экзаменам CCENT/CCNA. В этой записи мы проследим логику появления моделей сетевого взаимодействия, так как OSI 7 и TCP/IP, попробовав разбить такую сложную задачу, как сетевое взаимодействие, на несколько маленьких. Сам же процесс разбиения одной большой задачи на несколько маленьких называется декомпозицией задачи.
В процессе решения этой задачи мы коснемся такой важной штуки как архитектура компьютерной сети, разберемся с тем, что такое протоколы и межсетевые интерфейсы (или сетевые службы), поймем чем протокол отличается от сетевой службы и наконец нам станет ясно, почему при построение компьютерной сети мы можем выбирать железо и софт от разных производителей, то есть почему архитектура современных сетей довольно гибкая и что на нее влияет.
Перед началом я хотел бы вам напомнить, что ознакомиться с опубликованными материалами первой части нашего курса можно по ссылке: «Основы взаимодействия в компьютерных сетях».
Содержание статьи:
Когда мы собирали простую схему из двух компьютеров, то я уже упоминал о такой штуке, как декомпозиция задачи сетевого взаимодействия, и к чему этот процесс привел. А во всех предыдущих записях я постоянно упоминал эталонную модель сетевого взаимодействия и пару раз упоминал про модель стека протоколов TCP/IP. Коротко напомню, что декомпозиция – это процесс разделения одной сложной и большой задачи на несколько более простых и понятных задач, которые легче выполнить.
В мире компьютерных сетей этот процесс привел к тому, что у нас появились удобные стандарты и протоколы, а также к появлению двух моделей сетевого взаимодействия, которые схематично описывают то, что происходит с данными, когда Иван Иваныч пишет романтишный e-mail Клавдии Петровне, на всех этапах передачи этих данных.
И для того чтобы лучше понимать принципы работы моделей OSI 7 и стека протоколов TCP/IP, нам нужно немного окунуться в прошлое и посмотреть, как мог происходит процесс декомпозиции такой сложной задачи как передача данных по сети.
Естественно, мы не будем его рассматривать с исторической точки зрения, мы посмотрим на логику его развития, чтобы в дальнейшем лучше понимать принципы и архитектуру современных компьютерных сетей.
Но для начала давайте на простом примере из жизни разберемся с тем, что такое декомпозиция задачи. Для тех кому все понятно, можете смело пропускать этот раздел, кто еще не разобрался, прошу к прочтению. Допустим, у нас есть такая задача: купить молоко, и нам нужно сделать декомпозицию этой задачи, то есть разбить ее на несколько более простых. Примерно так можно это сделать:
Примерно так можно было бы выполнить декомпозицию такой простой задачи, как купить молоко. При этом стоит обратить внимание на то, что мы могли бы сделать ветвление в нашем процессе, задавая различные условия (если мы выбрали такой способ, то нужно дальше делать то-то и то-то), мы могли бы разбить нашу задачу на большее количество шагов или наоборот уменьшит количество этапов. Поэтому выполняя декомпозицию, нужно исходить из здравого смысла и, на самом деле, глупо разбивать простую задачу, описанную выше, на еще более мелкие задачи.
Давайте двинемся дальше и попробуем рассмотреть более сложные примеры, чтобы затем приблизиться к компьютерным сетям и их архитектуре.
Компьютерная сеть – это сложная система, работающая по строгим принципам, которые заданы как на аппаратном, так и на программном уровне. Эти принципы заложены в протоколах и стандартах, на основе которых разрабатываются устройства и пишутся программы. Даже без знания о том, что существует какая-то модель передачи данных (не важно какая модель OSI 7 или модель стека протоколов TCP/IP), для себя можно выделить несколько уровней:
Есть и другие уровни, которые решают другие задачи, но эти задачи не так интересны сетевому инженеру, эти задачи решает системный администратор, программист или нынче модный DevOps-инженер (все эти четыре профессии вообще разные).
Мы сейчас выделили четыре уровня, при этом мы можем даже сказать: какие железки будут работать на каждом из этих уровней:
Область передачи данных довольна строга, консервативна и формализована, в противном случае мы бы имели каналы связи низкого качества, и у нас не было бы возможности подружить оборудование разных производителей. Поэтому декомпозиция задачи сетевого взаимодействия заключается в том, чтобы четко определить функциональность каждого небольшого модуля, а также задать порядок их взаимодействия.
Выше я уже упоминал, что каждый этап при декомпозиции должен быть изолирован, а на последующий этап должны передаваться лишь выходные данные. При таком подходе модулям, расположенным на разных уровнях, нет никакого дела до того, что именно происходит на соседних уровнях, они лишь ждут нужные входные данные, что-то с ними делают и передают дальше выходные данные, таким образом уровни являются независимыми.
Каждый уровень может быть обслужен разными людьми, а разработка и тестирование модулей на разных уровнях упрощается и становится независимой от других уровней. Давайте усложним схему, показанную на Рисунке 1.12.1 и сделаем ветвление.
Обратите внимание: данные из «Модуля 5» могут поступить в «Модуль 6.1», «Модуль 6.2» и «Модуль 6.3», но что изменится, если нам нужно будет убрать «Модуль 6.3»? Собственно, изменится только содержимое «Модуля 5» (на Рисунке 1.12.3 я его выделил другим цветом), а также в схеме не будет «Модуля 6.3», изменений в других модулях не будет. Логичный вопрос: почему «Модуль 5» изменится, а «Модуль 7» меняться не будет?
Дело всё в том, что «Модуль 5» предоставляет выходные данные «Модулям 6.х», следовательно, нам нужно свести вероятность появления выходных данных, которые отправлялись «Модулю 6.3», к нулю, следовательно, нужно что-то исправить в «Модуле 5», чтобы такие данные не появлялись, либо реализовать функционал «Модуля 6.3» в других модулях этого этапа. А что касается Модуля 7, то тут все просто: у него может остаться функционал, который ждет появления входных данных генерируемых Модулем 6.3, просто эти данные никогда не будут сгенерированы и этот функционал не будет задействован, хотя его можно было бы и удалить.
Мы рассмотрели сейчас удаление модуля из схемы, попробуйте и попрактикуйтесь в добавление новых модулей в эту схему, например, сделайте схему, в которой будет два модуля на третьем уровне (3.1 и 3.2) и определите, какие модулю на других уровнях должны измениться, а какие нет.
Декомпозиция задачи – очень эффективный способ облегчить себе жизнь и уменьшить объем работы, но есть еще более эффективный и эффектный способ разбиения больших задач на маленькие, который заключается в том, чтобы разбивать задачу не только на модули, но и на уровни. Для этого задача сперва разбивается на модули, а затем эти модули делятся на уровни, которые образуют иерархическую модель (не путайте с иерархическими базами данных). Пример такого разбиения показан на Рисунке 1.12.4.
Таким образом получается, что нижележащий уровень оказывает услугу своему соседу, находящемуся на одну ступень выше, то есть: первый уровень оказывает услуги второму уровню, второй уровень оказывает услуги третьему уровню и так далее, при этом исключается прямое взаимодействие между, например, первым уровнем и третьим. Также обратите внимание на то, что необязательно каждый модуль нижележащего уровня должен или может взаимодействовать с каждым модулем вышестоящего уровня, это совсем необязательно и более того, часто бывает нежелательно. Таким образом мы уже получаем иерархическую систему, в которой не только есть четко определенные функции у каждого модуля, но и есть четкие обязанности и функционал у каждого уровня, на этом этапе у нас уже должно появиться представление о том, что архитектура компьютерной сети довольно таки гибкая.
Стоит также отметить, что если мы говорим о компьютерных сетях, то это означает следующее: чем ниже уровень, тем ближе он к физической сущности, например, физический уровень модели OSI 7 оперирует битами и определяет то, какими уровнями сигнала будут представлены логические единицы, а какие уровни будут использованы для логических нулей. А на седьмом уровне (то есть на самом верхнем), если мы говорим про протокол HTTP, данные уже будут представлены в виде HTTP сообщений, которые делятся по своему функционалу на два вида: HTTP запросы (это сообщение отправляет клиентский компьютер серверу, чтобы получить веб-страницу) и HTTP ответы (а такие сообщения отправляет сервер клиенту, чтобы тем или иным образом удовлетворить запрос клиента, естественно, такое взаимодействие можно описать схемой клиент-сервер), кстати сказать, если взглянуть на незакодированное или незашифрованное HTTP сообщение, то его содержимое будет понятным для человека, так как это обычный текст, чего нельзя сказать о последовательности бит, которые передаются на первом уровне.
Разбираясь с декомпозицией задачи сетевого взаимодействия, мы плавно подошли к иерархии протоколов в компьютерных сетях. Условно говоря, каждый модуль в той иерархической модели, которую мы создали, является протоколом (но никак не стандартом или технологией, потому что, например, такая технология как Ethernet будет расположена сразу на двух уровнях модели OSI: канальном и физическом).
Мы уже выяснили, что нижележащий уровень предоставляет свои услуги вышестоящему уровню, а также стоит сказать, что в процессе обмена данными по сети участвуют как минимум две стороны, поэтому они должны согласовать друг с другом то, как они будут взаимодействовать, при этом согласованность должна быть на каждом уровне, иначе ничего не получится. Если нарисовать картинку взаимодействия двух сетевых узлов, то она будет выглядеть примерно так, как показано на Рисунке 1.12.5.
Итак, если прочитать все надписи, можно понять, что в компьютерной сети есть межуровневые интерфейсы и протоколы. На самом деле и те, и другие это практически одно и то же: четко описанный набор правил взаимодействия и последовательность применения этих правил. Просто межуровневые интерфейсы осуществляют связь между уровнями внутри узла (очень часто вместо слова межуровневый интерфейс можно встретить слово служба или сетевая служба). А вот протоколы это, собственно то, что позволяет общаться двум узлам друг с другом на одном уровне, эти протоколы одноранговые, а это означает, что они работают на одном уровне.
Стоит учитывать, что протоколы и интерфейсы в нашем неидеальном мире представлены в двух видах:
Поэтому при организации компьютерной сети вам стоит определять протоколы, которые будут максимально соответствовать требованиям, предъявляемым к сети, а также выбирать производителя оборудования и программного обеспечения, более того, производители предлагают различные решения для различных задач, например, домашний роутер будет сильно отличаться от того роутера, который установлен у провайдера для подключения абонентов к своей сети как по своему функционалу, так и по стоимости. В конце концов от выбранного вам оборудования зависят многие характеристики компьютерной сети, например, если в вашей сети появится устройство под названием сетевой концентратор или просто хаб, то участок компьютерной сети, на котором работает этот хаб будет иметь топологию общая шина. А как вы помните, ранее мы говорили, что сети передачи данных с топологией общая шина совершенно непригодны для сетевого взаимодействия типа H2H, то есть по таким сетям нельзя организовать аудио или видео связь в режиме реального времени.
На каждом уровне нашей иерархической модели устройства будут обмениваться сообщения, на каждом уровне это разные сообщения и у них свои названия, мы пока в это не вдаемся, но стоит сейчас отметить, что за исключением физического уровня, где передаются нули и единицы, обычно сообщения состоят из двух частей: заголовка, в котором содержится служебная информация, и поля данных, в котором передается полезная информация, но иногда (чаще всего на канальном уровне) к сообщению добавляется третья часть, так называемый трейлер, в котором содержится контрольная сумма, она позволяет проверить данные на целостность.
Львиная доля функционала протокола заложена в заголовке сообщения и чаще всего действует правило (но не всегда): чем сложнее и больше заголовок, тем сложнее и функциональнее протокол. По содержимому заголовка узлы понимают: какие данные к ним пришли и что с ними нужно дальше делать.
Вообще, этот вопрос очень сложный и объемный, и с ним мы собственно и будем разбираться на протяжении всех этих уроков (немного о самом курсе по основам компьютерных сетей), а наш текущий разговор мы продолжим, когда будем рассматривать модели OSI 7 и TCP/IP. Сейчас же давайте представим схему, при которой два компьютера взаимодействуют друг с другом (подобную схему мы уже реализовывали в Cisco Packet Tracer). Мы уже говорили, что этих два компьютера для взаимодействия должны поддерживать связь друг с другом на каждом уровне, но в реальной жизни все не так.
В реальности данные, которые отправляет первый узел второму, сперва спускаются (если ориентироваться на Рисунок 1.12.5) с четвертого уровня на первый, при этом на каждом из уровней с ними происходят определенные изменения, а как только эти данные достигают первого уровня и превращаются в последовательность бит (логических нулей и единиц), они попадают в физическую среду, по которой и производится обмен данными (все остальное – абстракция удобная для людей, в проводе существуют только физические сигналы).
Как только отправленная последовательность бит поступает узлу получателю, она по тем же самым ступенькам поднимается вверх и на самом верхнем уровне превращается в данные, которые понятны и удобны для человека. Тут стоит добавить, что конкретно реализованный набор уровней и протоколов часто называют архитектурой сети.
При этом с учетом выработанной и изолированной модели, архитектура у современных компьютерных сетей очень гибкая. Во-первых, вы можете выбирать различных производителей аппаратного и программного обеспечения в зависимости от выбранных протоколов. Во-вторых, одно и то же устройство может поддерживать не один протокол, выполняющий те или иные функции, а сразу несколько, например, ваш домашний роутер дает вам возможность подключать конечные устройства как по Wi-Fi, так и по проводам, а в этом уже третья особенность, подчеркивающая гибкость архитектуры современных компьютерных сетей: чаще всего при изменении протоколов или технологий на одном конкретном уровне, на других уровнях ничего не изменяется (но есть исключения, например, есть такой физический интерфейс, как serial-link, который приводит к изменениям на канальном уровне, но уже на сетевом уровне (третий по счету) протокол можно не менять.
Четвертая особенность заключается в том, что интерфейсы и протоколы можно комбинировать, например, у вас есть три маршрутизатора: A, B и C, пусть B на схеме будет в центре и для примера мы можем соединить маршрутизаторы B и C при помощи физического порта serial link, а маршрутизаторы A и B будут связаны друг с другом при помощи технологии Ethernet с соответствующими физическими портами и протоколами канального уровня. При этом можно с уверенностью сказать, что маршрутизатор A сможет взаимодействовать с маршрутизатором C через маршрутизатор B. Схема показана на рисунке 1.12.6.
Если рисунок не совсем понятен, то прочитайте запись про условные обозначения Cisco. В этих уроках мы будем изучать принципы работы самых часто используемых протоколов в небольших локальных сетях, а заодно, как приятный бонус, мы научимся немного работать с оборудованием Cisco.
Давайте подведем итог нашему разговору. Мы разобрались с основными особенностями архитектуры современных компьютерных сетей и выяснили, что она, то есть, архитектура может быть довольно гибкой:
Это всё мы имеем благодаря тому, что на протяжении нескольких десятков лет происходил процесс декомпозиции сетевого взаимодействия, казалось бы, что при текущем рассмотрении все просто и очевидно, но поверьте, современные компьютерные сети имеют такую гибкую архитектуру благодаря тому, что на их развитие и на решение небольших задач было потрачено десятки тысяч трудочасов, поскольку простые и эффективные решения, вернее путь к этим решениям, очень сложен.
Кстати, тут стоит заметить, что чаще всего приживаются и выигрывают самые простые решения, например, Ethernet: на канальном уровне этот протокол прост и незамысловат, если его сравнивать с конкурентами и именно это является его основным преимуществом. Во-первых, чем сложнее вещь, тем больше вероятность, что в ней что-то может сломаться, во-вторых, чем проще сам протокол, тем проще и дешевле его реализовать.
Выберете удобный для себя способ, чтобы оставить комментарий