По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Определение проблемного пространства
Сетевые инженеры часто сталкиваются с проблемой слишком большого трафика для слишком малого канала связи. В частности, почти в каждом пути через сеть одно звено ограничивает весь путь, так же как один перекресток или одна дорога ограничивает поток трафика. Рисунок ниже иллюстрирует это.
На рисунке A обменивается данными с G, а B обменивается данными с E. Если каждая из этих пар устройств использует близкую к доступной полосе пропускания на своих локальных каналах ([A, C], [B, C], [F, G] и D, E]), предполагая, что все каналы имеют одинаковую скорость, канал [C, D] будет перегружен трафиком, превратившись в узкую точку в сети.
Когда канал перегружен, например канал [C, D] на рисунке ниже, по каналу будет отправлено больше трафика, чем пропускная способность канала. Во время перегрузки сетевое устройство, такое как маршрутизатор или коммутатор, должно определять, какой трафик следует перенаправить, какой отбросить и в каком порядке следует пересылать пакеты. Для решения этой проблемы были созданы различные схемы приоритезации.
Управление перегрузкой каналов путем приоритизации одних классов трафика над другими входит в широкий раздел качества обслуживания (QoS). Восприятие QoS среди сетевых инженеров вызывает беспокойство по многим причинам. Например, многие реализации, даже недавние, как правило, не так хорошо продуманы, как могли бы быть, особенно в том, как они настроены и поддерживаются. Кроме того, ранние схемы не всегда работали хорошо, и QoS часто может добавить проблем в сети, а не облегчить их, и, как правило, очень трудно устранить неполадки.
По этим причинам, а также из-за того, что конфигурация, необходимая для реализации схем приоритезации, имеет тенденцию к непостижимости, QoS часто считается темным искусством. Чтобы успешно реализовать стратегию QoS, вы должны классифицировать трафик, определить стратегию организации очередей для различных классов трафика и согласованно установить стратегию на всех сетевых устройствах, которые могут испытывать перегрузку каналов.
Хотя можно погрузиться во множество различных функций и функций схем и реализаций QoS, результат всегда должен быть одним и тем же.
Почему бы просто не сделать линии связи достаточно большими?
После обдумывания ценностного предложения QoS очевидной реакцией будет вопрос, почему сетевые инженеры просто не выбирают достаточно большие линии связи, чтобы избежать перегрузки. В конце концов, если бы линии связи были достаточно большими, перегрузка исчезла бы. Если перегрузка исчезнет, исчезнет необходимость отдавать приоритет одному типу трафика над другим. Весь трафик будет доставлен, и все эти досадные проблемы, связанные с недостаточной пропускной способностью, будут устранены. Действительно, избыточное выделение ресурсов, возможно, является лучшим QoS из всех.
К сожалению, стратегия избыточного обеспечения не всегда является доступным вариантом. Даже если бы это было так, самые большие доступные каналы связи не могут преодолеть определенные модели трафика. Некоторые приложения будут использовать столько пропускной способности, сколько доступно при передаче данных, создавая точку перегрузки для других приложений, совместно использующих линию связи. Другие будут передавать в микроперерывах, подавляющих сетевые ресурсы в течение короткого времени, и некоторые транспортные механизмы-такие как протокол управления передачей (TCP)-будут намеренно собирать путь время от времени, чтобы определить наилучшую скорость передачи данных. В то время как более крупная линия связи может сократить время существования состояния перегрузки, в некоторых сценариях нет такой вещи, как наличие достаточной полосы пропускания для удовлетворения всех требований.
Большинство сетей построены на модели избыточной подписки, когда некоторая совокупная пропускная способность распределяется в определенных узких местах. Например, коммутатор Top of Rack (ToR) в загруженном центре обработки данных может иметь 48 портов 10GbE, обращенных к хостам, но только 4 порта 40GbE, обращенных к остальной части центра обработки данных. Это приводит к коэффициенту переподписки 480:160, который уменьшается до 3:1. Неявно, 160 Гбит/с полосы пропускания центра обработки данных является потенциальным узким местом - точкой перегрузки - для 480 Гбит/с полосы пропускания хоста. И все же соотношение переподписки 3:1 является обычным явлением в схемах коммутации центров обработки данных. Зачем?
Окончательный ответ - часто деньги. Часто можно спроектировать сеть, в которой граничные порты соответствуют доступной пропускной способности. Например, в структуре центра обработки данных, приведенной выше, почти наверняка можно добавить достаточную пропускную способность канала, чтобы обеспечить 480 Гбит / с из ToR в структуру, но стоимость вполне может быть непомерно высокой. Сетевой инженер должен учитывать не только стоимость порта и оптоволокна, но и стоимость дополнительного питания, а также стоимость дополнительного охлаждения, необходимого для управления окружающей средой после добавления необходимых дополнительных устройств, и даже затраты дополнительного места в стойке и веса пола.
Затраты денег на обеспечение более высокой пропускной способности сети также могут быть трудно оправданы, если сеть редко перегружена. Некоторые события перегрузки не являются достаточно частыми, чтобы оправдать дорогостоящее обновление сети. Будет ли город тратить миллионы или миллиарды долларов на улучшение транспортной инфраструктуры, чтобы облегчить движение раз в год, когда политик приезжает с визитом? Нет. Вместо этого для решения проблемы с трафиком вносятся другие корректировки.
Например, компании могут наиболее остро столкнуться с этим ограничением в глобальных сетях, где каналы арендуются у поставщиков услуг (SP). Частично поставщики услуг зарабатывают деньги на объединении разрозненных географических регионов для организаций, которые не могут позволить себе прокладывать и использовать оптоволоконные кабели большой протяженности самостоятельно. Эти линии дальней связи обычно предлагают гораздо более низкую пропускную способность, чем более короткие, местные линии связи в одном кампусе или даже в одном здании. Высокоскоростное соединение в университетском городке или центре обработки данных может легко перегрузить более медленные каналы дальней связи.
Организации будут устанавливать максимально возможные размеры дальних (таких как межсайтовые или даже межконтинентальные) линий связи, но, опять же, важно помнить о деньгах.
В мире избыточной подписки и последующих точек перегруженности, а также временных моделей трафика, которые требуют тщательного управления, схемы приоритизации трафика QoS всегда будут необходимы.
Классификация
Схемы приоритизации QoS действуют на различные классы трафика, но что такое класс трафика и как он определяется?
Классы трафика представляют собой агрегированные группы трафика. Потоки данных из приложений, требующих аналогичной обработки или представляющих аналогичные схемы трафика в сети, помещаются в группы и управляются политикой QoS (или классом обслуживания, CoS). Эта группировка имеет решающее значение, поскольку было бы трудно определить уникальные политики QoS для потенциально бесконечного числа приложений. С практической точки зрения сетевые инженеры обычно группируют трафик в четыре класса. Конечно, возможны и другие классы, и такие схемы существуют в производственных сетях. Однако управление системой классификации и политическими действиями становится все более утомительным по мере того, как число классов превышает четыре.
Каждый пакет может быть отнесен к определенной CoS на основе адреса источника, адреса назначения, порта источника, порта назначения, размера пакета и других факторов. Предполагая, что каждое приложение имеет свой собственный профиль или набор характеристик, каждое приложение может быть помещено в определенный CoS и действовать в соответствии с локальной политикой QoS. Проблема с этим методом классификации трафика заключается в том, что классификация является только локально значимой-действие классификации относится только к устройству, выполняющему классификацию.
Такая классификация пакетов требует много времени, а обработка каждого пакета потребует больших вычислительных ресурсов. Поэтому лучше не повторять эту обработку на каждом устройстве, через которое проходит пакет. Вместо этого лучше один раз классифицировать трафик, пометить пакет в этой единственной точке и действовать в соответствии с этой маркировкой на каждом последующем переходе в сети.
Примечание: Несмотря на то, что пакеты и кадры в сети различны, в этой статье будет использоваться термин пакеты.
Были разработаны и стандартизированы различные схемы маркировки, такие как 8-битное поле типа обслуживания (ToS), включенное в заголовок Интернет-протокола версии 4 (IPv4). Версия 6 того же протокола (IPv6) включает 8-битовое поле класса трафика, служащее аналогичной цели. Кадры Ethernet используют 3-битное поле как часть спецификации 802.1p. На рисунке показано поле ToS IPv4.
В наилучшей сетевой практике классификация трафика должна приводить к одному действию и только к одному действию-маркировке. Когда пакет помечен, присвоенное значение может сохраняться и действовать на протяжении всего пути следования пакета по сетевому пути. Классификация и последующая маркировка должны быть "одноразовым" событием в жизни пакета.
Лучшая практика QoS - рекомендуется маркировать трафик, как близко к источнику, насколько это возможно. В идеале трафик будет помечен в точке входа в сеть. Например, трафик, поступающий в сетевой коммутатор с персонального компьютера, телефона, сервера, устройства Интернета вещей и т. д. будет помечена, и метка будет служить классификатором трафика на пути следования пакета по сети.
Альтернативная схема классификации и маркировки трафика входящим сетевым устройством заключается в том, что приложение само маркирует свой собственный трафик. Другими словами, пакет отправляется с уже заполненным байтом ToS. Это поднимает проблему доверия. Следует ли разрешить приложению ранжировать собственную важность? В худшем случае все приложения эгоистично помечают свои пакеты значениями, указывающими наивысшую возможную важность. Если каждый пакет помечен как очень важный, то на самом деле ни один пакет не является особо важным. Чтобы один пакет был более важным, чем любой другой, должна быть дифференциация. Классы трафика должны иметь разные уровни важности, чтобы схемы приоритезации QoS имели какое-либо значение.
Для сохранения контроля над классификацией трафика все сети, реализующие QoS, имеют границы доверия. Границы доверия позволяют сети избежать ситуации, когда все приложения помечают себя как важные. Представьте, что произошло бы на перегруженной дороге, если бы у каждого автомобиля были мигающие аварийные огни - действительно важные автомобили не выделялись бы.
В сети некоторым приложениям и устройствам доверяют отмечать свой собственный трафик. Например, IP-телефонам обычно доверяют соответствующим образом маркировать свой потоковый голосовой трафик и трафик протокола управления, то есть метки, которые IP-телефоны применяют к своему трафику, принимаются входным сетевым устройством. Другие конечные точки или приложения могут быть ненадежными, что означает, что байт ToS пакета стирается или перезаписывается при входе. По умолчанию большинство сетевых коммутаторов стирают метки, отправленные им, если они не настроены на доверие определенным устройствам. Например, производителям, помещенным в пакет сервером, часто доверяют, а маркировкам, установленным конечным хостом, - нет. На рисунке ниже показана граница доверия.
На рисунке 3 пакеты, передаваемые B, помечены AF41. Поскольку эти пакеты исходят от хоста в домене доверия QoS, маркировка остается, пока они проходят через D. Пакеты, исходящие от A, помечаются EF; однако, поскольку A находится за пределами доверенного домена QoS, эта маркировка удаляется в D. Пакеты в пределах доверенного домена, исходящие из A, рассматриваются как немаркированные с точки зрения QoS. Маркировка протокола физического уровня и верхнего уровня может быть связана, а может и не быть. Например, маркировка верхнего уровня может быть скопирована в маркировку нижнего уровня, или маркировка нижнего уровня может быть перенесена через сеть, или маркировка нижнего уровня может быть удалена. Существует множество различных возможных реализаций, поэтому вы должны быть осторожны, чтобы понять, как маркировка обрабатывается на разных уровнях, а также на каждом переходе.
Хотя операторы сети могут использовать любые значения, которые они выбирают в байте ToS для создания различных классов трафика, часто лучше придерживаться некоторых стандартов, таких как значения, определенные стандартами IETF RFC. Эти стандарты были определены для того, чтобы дать сетевым инженерам логическую схему, позволяющую надлежащим образом различать множество различных классов трафика.
Две из этих схем "Per Hop Behavior" появляются в RFC2597, Assured Forwarding (AF), и RFC3246, Expedited Forwarding (EF), а также в различных других RFC, обновляющих или уточняющих содержание этих основополагающих документов. Оба эти RFC определяют схемы маркировки трафика, включая точные значения битов, которые должны заполнять байт ToS или байт класса трафика IP-заголовка, чтобы указать конкретный тип трафика. Они известны как точки кода дифференцированного обслуживания или значения DSCP.
Например, схема гарантированной пересылки RFC2597 определяет 12 значений в побитовой иерархической схеме для заполнения восьми битов в поле байта ToS. Первые три бита используются для идентификации класса, а вторые три бита определяют приоритет отбрасывания. Последние два бита не используются. Таблица 1 иллюстрирует маркировку кода для нескольких классов AF.
В таблице 1 показано значение бита DSCP для AF11, трафика класса 1 с низким приоритетом отбрасывания, равным 001 010, где "001" обозначает класс 1, а "010" обозначает приоритет отбрасывания. Изучение таблицы более глубоко раскрывает бинарный паттерн, выбранный авторами RFC. Весь трафик класса 1 помечается 001 в первых трех битах, весь класс 2-010 в первых трех битах и т. д. Весь трафик с низким приоритетом отбрасывания помечается 010 во-вторых трех битах, весь трафик со средним приоритетом отбрасывания-100 во-вторых трех битах и т. д.
Схема гарантированной пересылки показана в таблице 2 для примера. Это не исчерпывающий список кодовых точек, используемых при классификации трафика QoS. Например, схема выбора класса, описанная в RFC2474, существует для обратной совместимости со схемой маркировки приоритета IP. Приоритет IP использует только первые три бита байта ToS, всего восемь возможных классов. Селектор классов также использует восемь значений, заполняя первые три бита шестибитового поля DSCP значимыми значениями (соответствующими устаревшей схеме приоритета IP), а последние три бита - нулями. В таблице 2 показаны эти селекторы классов.
RFC3246 определяет требования к задержке, потерям и джиттеру трафика, который должен быть перенаправлен быстро, вместе с единственной новой кодовой точкой - EF, которой присвоено двоичное значение 101 110 (десятичное 46).
Количество и разнообразие формально определенных значений DSCP может показаться ошеломляющим. Комбинированные определения AF, CS и EF сами по себе приводят к формальным определениям для 21 различных классов из возможных 64, использующих шесть битов поля DSCP. Ожидается ли, что сетевые инженеры будут использовать все эти значения в своих схемах приоритезации QoS? Следует ли разбивать трафик с такой высокой степенью детализации для эффективного QoS?
На практике большинство схем QoS ограничиваются от четырех до восьми классов трафика. Различные классы позволяют обрабатывать каждую группу по-своему во время перегрузки. Например, один класс трафика может быть сформирован так, чтобы соответствовать определенному порогу пропускной способности. Другой класс трафика может иметь приоритет над всем остальным трафиком. Еще один может быть определен как критически важный для бизнеса или трафик, который важнее большинства, но менее важен, чем некоторые. Трафик сетевого протокола, критичный для стабильности инфраструктуры, можно рассматривать как очень высокий приоритет. Класс трафика scavenger может находиться в конце списка приоритетов, получая немного больше внимания, чем немаркированный трафик.
Схема, включающая эти значения, вероятно, будет представлять собой сочетание кодовых точек, определенных в различных RFC, и может несколько отличаться от организации к организации. Обычно принятые значения включают EF для критического трафика с требованием своевременности, например VoIP, и CS6 для трафика управления сетью, такого как протоколы маршрутизации и резервирования на первом этапе. Немаркированный трафик (т.е. значение DSCP, равное 0) доставляется по принципу "максимальных усилий", без каких-либо гарантий уровня обслуживания (обычно это считается классом scavenger, как указано выше).
Эти команды помогут вам независимо от того, какую операционную систему вы используете - Linux, Windows или macOS
На сегодняшний день создание виртуальной среды, или виртуализация, является одной из основных компьютерных технологий. С виртуальной машиной вы можете запустить практически любую операционную систему по вашему выбору на своем ПК, не разоряясь на дополнительное оборудование.
Давайте рассмотрим, как использовать терминал командной строки для управления виртуальными машинами VirtualBox независимо от операционной системы, будь то Windows, macOS или Linux. Все установки VirtualBox сопровождаются инструментом командной строки VBoxManage – мощной и гибкой утилитой для управления вашими виртуальными машинами.
Что такое VBoxManage?
VBoxManage – это инструмент интерфейса командной строки, устанавливаемый по умолчанию как часть установки программного обеспечения VirtualBox.
В отличие от управления виртуальными машинами через графический интерфейс, интерфейс командной строки VBoxManage дает больше функциональных возможностей, поскольку он обеспечивает прямой доступ к механизму виртуализации, что позволяет получить доступ к дополнительным функциям, которые недоступны через графический интерфейс. К тому же, большинство серверов Linux не имеют графического интерфейса вовсе, так что виртуальными машинами можно будет управлять даже в автономном режиме.
Все команды VBoxManage начинаются со слова vboxmanage и обычно сопровождаются подкомандой, такой как list, controlvm и т.д. Часто требуется указать имя виртуальной машины, которую вы хотите настроить или которой хотите управлять.
1. Список виртуальных машин
Здесь показано, как вы можете просмотреть список всех виртуальных машин, зарегистрированных на вашем ПК. Каждой виртуальной машине присваивается универсальный уникальный идентификатор, который используется для уникальной идентификации.
vboxmanage list vms
Если вам нужен более подробный список, добавьте флаг –l или –long к команде vboxmanage list vms. На выходе будет отображаться подробная информация, такая как конфигурация каждой виртуальной машины, сведения об аппаратном оборудовании, настройки и т.д.
Чтобы вывести список всех запущенных в данный момент виртуальных машин, используйте подкоманду list с параметром runningvms:
vboxmanage list runningvms
2. Запуск и остановка виртуальных машин
Чтобы запустить виртуальную машину с помощью VBoxManage, воспользуйтесь подкомандой startvm, за которой следует имя виртуальной машины или ее универсальный уникальный идентификатор. Например, вы можете выполнить команду ниже, чтобы запустить виртуальную машину с именем Windows11.
vboxmanage startvm Windows11
Когда дело дойдет до остановки виртуальной машины, то у вас будет несколько вариантов. У вас есть возможность полностью остановить, то есть выключить, виртуальную машину или поставить ее на паузу.
Чтобы остановить виртуальную машину, воспользуйтесь подкомандой controlvm, за которой следует имя виртуальной машины, а затем параметр poweroff.
vboxmanage controlvm Windows11 poweroff
Если вы хотите, чтобы виртуальная машина просто не потребляла системные ресурсы, то не обязательно ее выключать, вы можете приостановить ее работу и возобновить ее позже.
vboxmanage controlvm Windows11 pause
Чтобы восстановить работу приостановленной виртуальной машины, воспользуйтесь следующей командой:
vboxmanage controlvm Windows11 resume
3. Получение сведений о виртуальной машине
Чтобы просмотреть сведения, относящиеся к конкретной виртуальной машине, вместо команды для просмотра списка всех виртуальных машин, воспользуйтесь подкомандой showvminfo. Например, вы можете запустить команду ниже, чтобы получить подробную информацию о виртуальной машине Windows11, включая информацию о ее аппаратном оборудовании и других сведений о конфигурации, состояния сети и т.д.
vboxmanage showvminfo Windows11
4. Создание виртуальной машины
Еще одной важной задачей при управлении виртуальными машинами является создание новых виртуальных машин. Воспользуйтесь подкомандой createavm для создания новой виртуальной машины. Например, чтобы создать виртуальную машину с именем «DebianVM», которая будет работать в операционной системе Debian Linux, вы можете выполнить следующую команду:
vboxmanage createvm --name DebianVM --ostype Debian Debian_64 --register
Если вы не уверены, какое имя операционной системы использовать на вашей виртуальной машине, вы можете проверить, какие операционные системы поддерживает VirtualBox с помощью следующей команды:
vboxmanage list ostypes
5. Изменение виртуальной машины
Если вы хотите изменить только что созданную виртуальную машину, например, изменить размер памяти, имя и другие соответствующие параметры, вы можете воспользоваться подкомандой modifyvm, за которой следует имя виртуальной машины, а затем параметр, который вы хотите изменить, и, наконец, новое значение этого параметра.
Предположим, вы хотите изменить имя только что созданной виртуальной машины выше с DebianVM на Debian9, используя настройку имени.
vboxmanage modifyvm DebianVM --name Debian9
Список настроек, которые вы можете изменить, можно посмотреть, выполнив команду:
vboxmanage modifyvm
6. Резервное копирование
Резервное копирование является важным компонентом поддержания надежности информационной системы. VirtualBox позволяет сохранять состояние вашей виртуальной машины, чтобы у вас была возможность ее сохранить, если вдруг что-то пойдет не так.
Чтобы сделать снимок состояния виртуальной машины, вы можете запустить следующую команду, где «Christmas eve snapshot» - это имя, присвоенное вашему снимку состояния виртуальной машины.
vboxmanage snapshot Windows11 take "Christmas eve snapshot"
Чтобы восстановить упомянутую выше виртуальную машину с помощью только что созданного снимка состояния, для начала остановите виртуальную машину, если она запущена, а затем восстановите снимок состояния с помощью следующей команды:
vboxmanage snapshot Windows11 restore "Christmas eve snapshot"
7. Получение справочной информации
Чтобы вы могли использовать интерфейс командной строки VBoxManage на максимум, вы должны 7-komand-virtualnoj-mashiny-virtualbox-kotorye-nuzhno-znat, как получить справочную информацию или прочитать документацию из терминала командной строки, чтобы не запоминать все команды. Кроме того, есть множество других команд, которые не были рассмотрены нами в этом руководстве. У7-komand-virtualnoj-mashiny-virtualbox-kotorye-nuzhno-znat больше о командах VBoxManage и их параметрах можно, выполнив следующую команду:
vboxmanage
Заключение
В данном руководстве мы изучили некоторые важные команды для управления вашими виртуальными машинами VirtualBox с помощью VBoxManage - мощного и легкого инструмента командной строки для управления вашими виртуальными машинами. Кроме того, вы можете легко создавать сценарии автоматизации на основе VBoxManage, чтобы легко управлять своими виртуальными машинами.
Виртуальные машины дают возможность запускать и экспериментировать с несколькими операционными системами на вашем ПК безопасным и надежным способом.
Почитать лекцию №16 про модель сети Министерства обороны США (DoD) можно тут.
В 1960-х годах, вплоть до 1980-х годов, основной формой связи была коммутируемая схема; отправитель просил сетевой элемент (коммутатор) подключить его к определенному приемнику, коммутатор завершал соединение (если приемник не был занят), и трафик передавался по результирующей схеме. Если это звучит как традиционная телефонная система, то это потому, что на самом деле она основана на традиционной сетевой системе (теперь называемой обычной старой телефонной службой [POTS]). Крупные телефонные и компьютерные компании были глубоко инвестированы в эту модель и получали большой доход от систем, разработанных вокруг методов коммутации цепей. По мере того, как модель DoD (и ее набор сопутствующих протоколов и концепций) начали завоевывать популярность у исследователей, эти сотрудники решили создать новую организацию по стандартизации, которая, в свою очередь, построит альтернативную систему, обеспечивающую "лучшее из обоих миров". Они будут включать в себя лучшие элементы коммутации пакетов, сохраняя при этом лучшие элементы коммутации каналов, создавая новый стандарт, который удовлетворит всех. В 1977 году эта новая организация по стандартизации была предложена и принята в качестве International Organization for Standardizatio (ISO).
Основная цель состояла в том, чтобы обеспечить взаимодействие между крупными системами баз данных, доминировавшими в конце 1970-х гг. Комитет был разделен между инженерами связи и контингентом баз данных, что усложнило стандарты. Разработанные протоколы должны были обеспечить как ориентированное на соединение, так и бесконтактное управление сеансами, а также изобрести весь набор приложений для создания электронной почты, передачи файлов и многих других приложений (помните, что приложения являются частью стека). Например, необходимо было кодифицировать различные виды транспорта для транспортировки широкого спектра услуг. В 1989 году-целых десять лет спустя-спецификации еще не были полностью выполнены. Протокол не получил широкого распространения, хотя многие правительства, крупные производители компьютеров и телекоммуникационные компании поддерживали его через стек и модель протокола DoD.
Но в течение десяти лет стек DoD продолжал развиваться; была сформирована Инженерная рабочая группа по разработке Интернету (Engineering Task Force -IETF) для поддержки стека протоколов TCP/IP, главным образом для исследователей и университетов (Интернет, как тогда было известно, не допускал коммерческого трафика и не будет до 1992 года). С отказом протоколов OSI материализоваться многие коммерческие сети и сетевое оборудование обратились к пакету протоколов TCP/IP для решения реальных проблем "прямо сейчас".
Кроме того, поскольку разработка стека протоколов TCP/IP оплачивалась по грантам правительства США, спецификации были бесплатными. На самом деле существовали реализации TCP/IP, написанные для широкого спектра систем, доступных благодаря работе университетов и аспирантов, которые нуждались в реализации для своих исследовательских усилий. Однако спецификации OSI могли быть приобретены только в бумажном виде у самой ISO и только членами ISO. ISO был разработан, чтобы быть клубом "только для членов", предназначенным для того, чтобы держать должностных лиц под контролем развития технологии коммутации пакетов. Однако принцип "только члены" организации работал против должностных лиц, что в конечном счете сыграло свою роль в их упадке.
Однако модель OSI внесла большой вклад в развитие сетей; например, пристальное внимание, уделяемое качеству обслуживания (QoS) и вопросам маршрутизации, принесло дивиденды в последующие годы. Одним из важных вкладов стала концепция четкой модульности; сложность соединения многих различных систем с множеством различных требований побудила сообщество OSI призвать к четким линиям ответственности и четко определенным интерфейсам между слоями.
Второй - это концепция межмашинного взаимодействия. Средние блоки, называемые затем шлюзами, теперь называемые маршрутизаторами и коммутаторами, явно рассматривались как часть сетевой модели, как показано на рисунке 3.
Гениальность моделирования сети таким образом заключается в том, что она делает взаимодействие между различными частями намного легче для понимания. Каждая пара слоев, перемещаясь вертикально по модели, взаимодействует через сокет или приложение.
Programming Interface (API). Таким образом, чтобы подключиться к определенному физическому порту, часть кода на канальном уровне будет подключаться к сокету для этого порта. Это позволяет абстрагировать и стандартизировать взаимодействие между различными уровнями. Компонент программного обеспечения на сетевом уровне не должен знать, как обращаться с различными видами физических интерфейсов, только как получить данные для программного обеспечения канального уровня в той же системе.
Каждый уровень имеет определенный набор функций для выполнения.
Физический уровень, также называемый уровнем 1, отвечает за модулирование или сериализацию 0 и 1 на физическом канале. Каждый тип связи будет иметь различный формат для передачи сигналов 0 или 1; физический уровень отвечает за преобразование "0" и "1" в эти физические сигналы.
Канальный уровень, также называемый уровнем 2, отвечает за то, чтобы некоторая передаваемая информация фактически отправлялась на нужный компьютер, подключенный к той же линии. Каждое устройство имеет свой адрес канала передачи данных (уровень 2), который можно использовать для отправки трафика на конкретное устройство. Уровень канала передачи данных предполагает, что каждый кадр в потоке информации отделен от всех других кадров в том же потоке, и обеспечивает связь только для устройств, подключенных через один физический канал.
Сетевой уровень, также называемый уровнем 3, отвечает за передачу данных между системами, не связанными через единую физическую линию связи. Сетевой уровень, таким образом, предоставляет сетевые адреса (или Уровень 3), а не локальные адреса линий связи, а также предоставляет некоторые средства для обнаружения набора устройств и линий связи, которые должны быть пересечены, чтобы достичь этих пунктов назначения.
Транспортный уровень, также называемый уровнем 4, отвечает за прозрачную передачу данных между различными устройствами. Протоколы транспортного уровня могут быть либо "надежными", что означает, что транспортный уровень будет повторно передавать данные, потерянные на каком-либо нижнем уровне, либо "ненадежными", что означает, что данные, потерянные на нижних уровнях, должны быть повторно переданы некоторым приложением более высокого уровня.
Сеансовый уровень, также называемый уровнем 5, на самом деле не переносит данные, а скорее управляет соединениями между приложениями, работающими на двух разных компьютерах. Сеансовый уровень гарантирует, что тип данных, форма данных и надежность потока данных все представлены и учтены.
Уровень представления, также называемый уровнем 6, фактически форматирует данные таким образом, чтобы приложение, работающее на двух устройствах, могло понимать и обрабатывать данные. Здесь происходит шифрование, управление потоком и любые другие манипуляции с данными, необходимые для обеспечения интерфейса между приложением и сетью. Приложения взаимодействуют с уровнем представления через сокеты.
Уровень приложений, также называемый уровнем 7, обеспечивает интерфейс между пользователем и приложением, которое, в свою очередь, взаимодействует с сетью через уровень представления.
Не только взаимодействие между слоями может быть точно описано в рамках семислойной модели, но и взаимодействие между параллельными слоями на нескольких компьютерах может быть точно описано. Можно сказать, что физический уровень на первом устройстве взаимодействует с физическим уровнем на втором устройстве, уровень канала передачи данных на первом устройстве с уровнем канала передачи данных на втором устройстве и так далее. Точно так же, как взаимодействие между двумя слоями на устройстве обрабатывается через сокеты, взаимодействие между параллельными слоями на разных устройствах обрабатывается через сетевые протоколы.
Ethernet описывает передачу сигналов "0" и "1" на физический провод, формат для запуска и остановки кадра данных и средство адресации одного устройства среди всех устройств, подключенных к одному проводу. Таким образом, Ethernet попадает как в физический, так и в канальный уровни передачи данных (1 и 2) в модели OSI.
IP описывает форматирование данных в пакеты, а также адресацию и другие средства, необходимые для отправки пакетов по нескольким каналам канального уровня, чтобы достичь устройства за несколько прыжков. Таким образом, IP попадает в сетевой уровень (3) модели OSI.
TCP описывает настройку и обслуживание сеанса, повторную передачу данных и взаимодействие с приложениями. TCP затем попадает в транспортный и сеансовый уровни (4 и 5) модели OSI.
Одним из наиболее запутанных моментов для администраторов, которые когда-либо сталкиваются только со стеком протоколов TCP/IP, является другой способ взаимодействия протоколов, разработанных в/для стека OSI, с устройствами. В TCP/IP адреса относятся к интерфейсам (а в мире сетей с большой степенью виртуализации несколько адресов могут относиться к одному интерфейсу, или к услуге anycast, или к multicast и т. д.). Однако в модели OSI каждое устройство имеет один адрес. Это означает, что протоколы в модели OSI часто называются типами устройств, для которых они предназначены. Например, протокол, несущий информацию о достижимости и топологии (или маршрутизации) через сеть, называется протоколом промежуточной системы (IS-IS), поскольку он работает между промежуточными системами. Существует также протокол, разработанный для того, чтобы промежуточные системы могли обнаруживать конечные системы; это называется протоколом End System to Intermediate System (ES-IS).