Общая модель сетевого взаимодействия OSI
Общая модель сетевого взаимодействия OSI
При знакомстве с семейством протоколов TCP/IP мы отметили уровневую структуру этих протоколов. Каждый из уровней выполняет строго определенную функцию, изолируя в то же время особенности этой обработки и связанные с ней данные от протоколов верхнего уровня. Четкое определение интерфейсов между протоколами соседних уровней позволяет выполнять разработку и реализацию протоколов независимо, не внося изменений в другие модули системы. Характерным примером является интерфейс между протоколом IP и протоколами транспортного уровня TCP и UDP. Хотя последние выполняют различную обработку, их взаимодействие с IP идентично.
Развитие сетевых технологий и связанных с ними протоколов обмена данными наглядно показало необходимость стандартизации этого процесса. Вместе с тем было очевидно, что единый стандарт на все случаи жизни не может решить подобную задачу. Очевидно также, что коммуникационная архитектура должна иметь модульную структуру, в которой модули обладают стандартными интерфейсами взаимодействия и могут подключаться в соответствии с этими интерфейсами, образуя "конвейер" обработки данных. Все это позволяет считать наиболее жизнеспособным подход, когда в рамках общей модели или архитектуры сетевого взаимодействия стандартизируются интерфейсы и функциональность отдельных модулей.
Такая общая модель была принята в 1983 году Международной организацией по стандартизации (International Organization for Standardization, ISO), и получила название модели взаимодействия открытых систем (Open Systems Interconnection, OSI). Эта модель является основой для объединения разнородных компьютеров в гетерогенную сетевую инфраструктуру. Данная архитектура определяет возможность установления соединения между любыми двумя системами, удовлетворяющими модели и поддерживающими соответствующие стандарты.
В модели OSI, как и в TCP/IP, общая функциональность системы разделена на несколько уровней, каждый из которых выполняет свою часть функций, необходимых для установления соединения с парным ему уровнем удаленной системы. В то же время каждый из уровней выполняет определенную обработку данных, реализуя набор услуг для уровня выше. Описание услуг и формат их предоставления определяются внутренним протоколом взаимодействия соседних уровней и определяют межуровневый интерфейс.
Модель OSI состоит из семи уровней, краткое описание которых приведено в табл. 6.1.
Таблица 6.1. Семь уровней модели OSI
Название уровня Описание Уровень приложений (Application layer) Обеспечивает пользовательский интерфейс доступа к распределенным ресурсам Уровень представления (Presentation layer) Обеспечивает независимость приложений от различий в способах представления данных Уровень сеанса (Session layer) Обеспечивает взаимодействие прикладных программ в сети Транспортный уровень (Transport layer) Обеспечивает прозрачную передачу данных между конечными точками сетевых коммуникаций. Отвечает за восстановление ошибок и контроль за потоком данных Сетевой уровень (Network layer) Обеспечивает независимость верхних уровней от конкретной реализации способа передачи данных по физической среде. Отвечает за установление, поддержку и завершение сетевого соединения Уровень канала данных (Data link layer) Обеспечивает надежную передачу данных по физической сети. Отвечает за передачу пакетов данных — кадров и обеспечивает необходимую синхронизацию, обработку ошибок и управление потоком данных Физический уровень (Physical layer) Отвечает за передачу неструктурированного потока данных по физической среде. Определяет физические характеристики среды передачи данныхРассмотрим процесс передачи данных между удаленными системами в рамках модели OSI. Пусть пользователю А системы C1 необходимо передать данные приложению В системы C2. Обработка прикладных данных начинается на уровне приложения. Уровень приложения передает обработанные данные и управляющую информацию на следующий уровень — уровень представления и т.д., пока данные наконец не достигнут физического уровня и не будут переданы по физической сети. Система C2 принимает эти данные и обрабатывает их в обратном порядке, начиная с физического уровня и заканчивая уровнем приложения, после чего исходные прикладные данные будут получены пользователем В.
Для того чтобы каждый уровень мог правильно обработать полученные данные, последние содержат также управляющую информацию. Эта управляющая информация интерпретируется только тем уровнем, для которого она предназначена, в соответствии с его протоколом, и невидима для других уровней: для верхних, потому что после обработки она удаляется, а для нижних — потому, что представляется им как обычные данные. Благодаря этому каждый уровень по существу общается с расположенным на удаленной системе равным (peer) ему уровнем. Таким образом, взаимодействие между удаленными системами можно представить состоящим из нескольких логических каналов, соответствующих уровням модели, передача данных в каждом из которых определяется протоколом своего уровня.
Так физический уровень и уровень канала данных обеспечивают коммуникационный канал сетевому уровню, который, в свою очередь, предоставляет связность объектам транспортного уровня и т.д.
Нетрудно заметить, что модель TCP/IP отличается от модели OSI. На рис. 6.4 показана схема отображения архитектуры TCP/IP на модель OSI. Видно, что соответствие существует для уровня Internet (сетевой уровень) и транспортного уровня. Уровни сеанса, представления и приложений OSI в TCP/IP представлены одним уровнем приложений. Обсуждение соответствия двух моделей носит весьма теоретический характер, поэтому мы перейдем к более ценному для практики обсуждению прекрасно зарекомендовавших себя протоколов Internet.
Рис. 6.4. Соответствие между моделями TCP/IF и OSI
Более 800 000 книг и аудиокниг! 📚
Получи 2 месяца Литрес Подписки в подарок и наслаждайся неограниченным чтением
ПОЛУЧИТЬ ПОДАРОКДанный текст является ознакомительным фрагментом.
Читайте также
Построение взаимодействия
Построение взаимодействия Мы изучили довольно простой пример, добавляя различные свойства CSS3 к элементам нашей страницы, которые относятся исключительно к взаимодействию. Браузеры, поддерживающие эти свойства, будут показывать анимацию полупрозрачного фона
10.7. Сигналы для межпроцессного взаимодействия
10.7. Сигналы для межпроцессного взаимодействия «ЭТО УЖАСНАЯ МЫСЛЬ! СИГНАЛЫ НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ЭТОГО! Просто скажите НЕТ». - Джефф Колье (Geoff Collyer) - Одним из главных механизмов межпроцессного взаимодействия (IPC) являются каналы, которые описаны в разделе 9.3 «Базовая
Модель сетевого взаимодействия OSI
Модель сетевого взаимодействия OSI В основу работы стека протоколов положена модель OSI (Open System Interconnection — взаимодействие открытых систем). Данная модель предусматривает семь уровней сетевого взаимодействия, на каждом из которых решаются конкретные задачи. Источником
Глава 5 Модель сетевого взаимодействия и основные сетевые протоколы
Глава 5 Модель сетевого взаимодействия и основные сетевые протоколы Если вы были последовательны, то уже успели познакомиться с основными типами и топологиями сетей, а также сетевыми стандартами. Как и любая другая область жизни и работы человека, все действия находятся
1.7.3 RFC и стимулирование сетевого взаимодействия продуктов различных производителей
1.7.3 RFC и стимулирование сетевого взаимодействия продуктов различных производителей То, что пользователи не должны придерживаться только одной компьютерной архитектуры, стало главной причиной одобрения TCP/IP в качестве коммуникационных стандартов правительственными
6.1.2. Уровни взаимодействия OSI
6.1.2. Уровни взаимодействия OSI Физический уровень (Physical Layer)Физический уровень передает биты по физическим каналам связи, например, коаксиальному кабелю или витой паре. На этом уровне определяются характеристики электрических сигналов, которые передают дискретную
26.1. Способы взаимодействия
26.1. Способы взаимодействия Процессы, как и люди, могут «общаться» между собой, то есть обмениваться информацией. В главе 3 мы бегло рассмотрели два средства межпроцессного взаимодействия (IPC, Inter-Process Communication); полудуплексные каналы (конвейеры) и сигналы, но в UNIX-системах
7.1 Общая информационная модель и стандарт WBEM
7.1 Общая информационная модель и стандарт WBEM Протокол SNMP (Simple Network Management Protocol) представляет собой стабильную технологию управления, имеющую свои преимущества и недостатки. Он обеспечивает эффективный мониторинг систем, однако не подходит для моделирования
Общая модель продаж
Общая модель продаж Рассмотрим вкратце общую концепцию похода к продажам, общую модель продаж «Лидген – Lead Conversion – Account Management». Вы должны понимать, что есть три принципиально разных этапа продаж.Первый этап – это лидген, генерация потенциальных клиентов. Потенциальные
5.5. Диаграммы взаимодействия
5.5. Диаграммы взаимодействия Существенное: объекты и их взаимодействия Диаграмма взаимодействии используется, чтобы проследить выполнение сценария в том же контексте, что и диаграмма объектов [Эти диаграммы обобщают диаграммы трассировки событий Румбаха и диаграммы
Понятие удаленного взаимодействия .NET
Понятие удаленного взаимодействия .NET Вы должны помнить из главы 13, что домен приложения [AppDomain] задает логические границы выполнения компоновочного блока .NET в рамках процесса Win32. Понимание этого очень важно для дальнейшего обсуждения распределенных приложений .NET,
Каркас удаленного взаимодействия .NET
Каркас удаленного взаимодействия .NET Когда клиенты и серверы обмениваются информацией через границы приложений, среда CLR вынуждена использовать низкоуровневые примитивы, обеспечивающие настолько "прозрачное" взаимодействие сторон, насколько это возможно. Это значит,
Термины удаленного взаимодействия .NET
Термины удаленного взаимодействия .NET Подобно любой новой парадигме, удаленное взаимодействие .NET предлагает свой собственный набор трехбуквенных акронимов. Поэтому, перед тем как рассмотреть первый пример программного кода, нам с вами придется определить несколько
Файлы конфигурации удаленного взаимодействия
Файлы конфигурации удаленного взаимодействия Итак, вы успешно построили распределённое приложение, используя слой удаленного взаимодействия .NET. В связи c данными примерами следует обратить внимание на то что полученные приложения клиента и сервера содержат большой