ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

7 минут чтени€

ѕочитать лекцию є15 про управление потоком пакетов в сет€х можно тут.

—овокупность проблем и решений, рассмотренных в предыдущих лекци€х, дает некоторое представление о сложности сетевых транспортных систем.  ак системные администраторы могут взаимодействовать с очевидной сложностью таких систем?

ѕервый способ - рассмотреть основные проблемы, которые решают транспортные системы, и пон€ть спектр решений, доступных дл€ каждой из этих проблем. ¬торой - создание моделей, которые помогут пон€ть транспортные протоколы с помощью:

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

ƒалее будет рассмотрен способ, с помощью которого администраторы могут более полно понимать протоколы: модели. ћодели по сути €вл€ютс€ абстрактными представлени€ми проблем и решений. ќни обеспечивают более нагл€дное и ориентированное на модули представление, показывающее, как вещи сочетаютс€ друг с другом. ¬ этой лекции мы рассмотрим этот вопрос:

 ак можно смоделировать транспортные системы таким образом, чтобы администраторы могли быстро и полностью пон€ть проблемы, которые эти системы должны решать, а также то, как можно объединить несколько протоколов дл€ их решени€?

¬ этой серии лекции будут рассмотрены три конкретные модели:

  1. ћодель ћинистерства обороны —Ўј (United States Department of Defense - DoD)
  2. ћодель взаимодействи€ открытых систем (Open Systems Interconnect - OSI)
  3. ћодель рекурсивной интернет-архитектуры (Recursive Internet Architecture - RINA)

ћодель ћинистерства обороны —Ўј (DoD)

¬ 1960-х годах јгентство перспективных исследовательских проектов ћинистерства обороны —Ўј (DARPA) спонсировало разработку сети с коммутацией пакетов дл€ замены телефонной сети в качестве основного средства компьютерной св€зи. ¬опреки мифу, первоначальна€ иде€ состо€ла не в том, чтобы пережить €дерный взрыв, а скорее в том, чтобы создать способ дл€ различных компьютеров, используемых в то врем€ в нескольких университетах, исследовательских институтах и правительственных учреждени€х, чтобы общатьс€ друг с другом. ¬ то врем€ кажда€ компьютерна€ система использовала свою собственную физическую проводку, протоколы и другие системы; не было никакого способа соединить эти устройства, чтобы даже передавать файлы данных, не говор€ уже о создании чего-то вроде "¬семирной паутины" или кросс-исполн€емого программного обеспечени€. Ёти оригинальные модели часто разрабатывались дл€ обеспечени€ св€зи между терминалами и хостами, поэтому вы могли установить удаленный терминал в офис или общественное место, которое затем можно было использовать дл€ доступа к общим ресурсам системы или хоста. Ѕольша€ часть оригинальных текстов, написанных вокруг этих моделей, отражает эту реальность.

ќдной из первых разработок в этой области была модель DoD, показанна€ на рисунке 1.

4-х уровнева€ модель DoD

DoD раздел€ла работу по передаче информации по сети на четыре отдельные функции, кажда€ из которых могла выполн€тьс€ одним из многих протоколов. »де€ наличи€ нескольких протоколов на каждом уровне считалась несколько спорной до конца 1980-х и даже в начале 1990-х гг. Ќа самом деле одним из ключевых различий между DoD и первоначальным воплощением модели OSI €вл€етс€ концепци€ наличи€ нескольких протоколов на каждом уровне.

¬ модели DoD:

  • ‘изический уровень отвечает за получение "0" и "1" модулированных или сериализованных на физическом канале.  аждый тип св€зи имеет свой формат дл€ передачи сигналов 0 или 1; физический уровень отвечает за преобразование 0 и 1 в физические сигналы.
  • »нтернет-уровень отвечает за передачу данных между системами, которые не св€заны между собой ни одной физической св€зью. “аким образом, уровень интернета предоставл€ет сетевые адреса, а не локальные адреса каналов, а также предоставл€ет некоторые средства дл€ обнаружени€ набора устройств и каналов, которые должны быть пересечены, чтобы достичь этих пунктов назначени€.
  • “ранспортный уровень отвечает за построение и поддержание сеансов между коммутирующими устройствами и обеспечивает общий прозрачный механизм передачи данных дл€ потоков или блоков данных. ”правление потоком и надежна€ транспортировка также могут быть реализованы на этом уровне, как и в случае с TCP.
  • ѕрикладной уровень - это интерфейс между ѕользователем и сетевыми ресурсами или конкретными приложени€ми, которые используют и предоставл€ют данные другим устройствам, подключенным к сети.

¬ частности, прикладной уровень кажетс€ неуместным в модели сетевого транспорта. ѕочему приложение, использующее данные, должно считатьс€ частью транспортной системы? ѕотому что ранние системы считали пользовател€-человека конечным пользователем данных, а приложение - главным образом способом изменить данные, которые будут представлены фактическому пользователю. Ѕольша€ часть обработки от машины к машине, т€жела€ обработка данных перед их представлением пользователю и простое хранение информации в цифровом формате даже не рассматривались как жизнеспособные варианты использовани€. ѕоскольку информаци€ передавалась от одного человека другому, приложение считалось частью транспортной системы.

ƒва других момента могли бы помочь включению прикладного уровн€ сделать его более осмысленным. ¬о-первых, в конструкции этих оригинальных систем было два компонента: терминал и хост. “ерминал тогда был дисплейным устройством, приложение располагалось на хосте. ¬о-вторых, сетевое программное обеспечение не рассматривалось как отдельна€ "вещь" в системе, маршрутизаторы еще не были изобретены, как и любое другое отдельное устройство дл€ обработки и пересылки пакетов. —корее, хост был просто подключен к терминалу или другому хосту; сетевое программное обеспечение было просто еще одним приложением, запущенным на этих устройствах.

—о временем, когда модель OSI стала чаше использоватьс€, модель DoD была изменена, чтобы включить больше уровней. Ќапример, на рисунке 2, на диаграмме, вз€той из статьи 1983 года о модели DoD ("Cerf and Cain, "The DoD Internet Architecture Model"), есть семь слоев (семь почему-то €вл€ютс€ магическим числом).

–асширенна€ модель DoD

Ѕыли добавлены три сло€:

  • ”ровень утилит - это набор протоколов, "живущих" между более общим транспортным уровнем и приложени€ми. ¬ частности, простой протокол передачи почты (SMTP), протокол передачи файлов (FTP) и другие протоколы рассматривались как часть этого уровн€.
  • —етевой уровень из четырехслойной версии был разделен на сетевой уровень и уровень интернета. —етевой уровень представл€ет различные форматы пакетов, используемые на каждом типе канала, такие как радиосети и Ethernet (все еще очень Ќовые в начале 1980-х годов). ”ровень межсетевого взаимодействи€ объедин€ет представление приложений и протоколов утилит, работающих в сети, в единую службу интернет-дейтаграмм.
  •  анальный уровень был вставлен дл€ того, чтобы различать кодирование информации на различные типы каналов и подключение устройства к физическому каналу св€зи. Ќе все аппаратные интерфейсы обеспечивали уровень св€зи.

—о временем эти расширенные модели DoD потер€ли попул€рность; модель с четырьм€ сло€ми €вл€етс€ той, на которую чаще всего ссылаютс€ сегодн€. Ќа это есть несколько причин:

  • ”ровни утилит и приложений в большинстве случаев дублируют друг друга. Ќапример, FTP мультиплексирует контент поверх протокола управлени€ передачей (TCP), а не как отдельный протокол или слой в стеке. TCP и протокол пользовательских дейтаграмм (UDP) со временем превратились в два протокола на транспортном уровне, а все остальное (как правило) работает поверх одного из этих двух протоколов.
  • — изобретением устройств, предназначенных в первую очередь дл€ пересылки пакетов (маршрутизаторы и коммутаторы), разделение между сетевым и межсетевым уровн€ми было преодолено определенными событи€ми. ѕервоначальна€ дифференциаци€ проводилась в основном между низкоскоростными дальнемагистральными (широкозонными) и короткозонными локальными сет€ми; маршрутизаторы обычно брали на себ€ брем€ установки каналов в широкополосные сети вне хоста, поэтому дифференциаци€ стала менее важной.
  • Ќекоторые типы интерфейсов просто не имеют возможности отделить кодирование сигнала от интерфейса хоста, как было предусмотрено в разделении между канальным и физическим уровн€ми. —ледовательно, эти два уровн€ обычно объединены в одну "вещь" в модели DoD.

ћодель DoD исторически важна, потому что

  • Ёто одна из первых попыток систематизировать функциональность сети в модели.
  • Ёто модель, на которой был разработан набор протоколов TCP / IP (на котором работает глобальный »нтернет); јртефакты этой модели важны дл€ понимани€ многих аспектов проектировани€ протокола TCP / IP.
  • ¬ нее была встроена концепци€ множественных протоколов на любом конкретном уровне модели. Ёто подготовило почву дл€ общей концепции сужени€ фокуса любого конкретного протокола, позвол€€ одновременно работать многим различным протоколам в одной и той же сети.