- Тема: Модель OSI/ISO, DOD. Обзор сетевых протоколов. Сетевая файловая система.
- План занятия
- Основные понятия
- Протоколы передачи данных
- Протоколы передачи данных
- Firewall
- HTTP/HTTPS
- SMTP / POP3 / IMAP
- Сетевая модель
- Инкапсуляция
- Примеры сетевых моделей
- Примеры сетевых моделей – OSI
- Модель OSI: канальный уровень
- Модель OSI: Домен коллизий
- Модель OSI: Протоколы канального уровня
- Модель OSI: Широковещательный домен
- Формат кадра Ethernet
- Типы передачи трафика
- Пример:
- Модель OSI: сетевой уровень
- Примеры сетевых моделей – OSI
- Модель OSI: транспортный уровень
- Модель OSI: сеансовый уровень
- Модель OSI: уровень представления
- Модель OSI: прикладной уровень
- Сетевая модель DOD
- Модель DOD
- Модель TCP/IP
- TCP/IP: сетевая модель
Тема: Модель OSI/ISO, DOD. Обзор сетевых протоколов. Сетевая файловая система.
План занятия
- Основные понятия
- Сетевая модель
- Модель OSI
- Модель TCP/IP (DOD)
- Сетевые устройства
По итогу занятия вы получите представление об особенностях взаимодействия сетевой подсистемы ОС и ее взаимодействие с другими устройствами. Будете знать особенности функционирования сетевых моделей и протоколов, ознакомитесь с популярными сетевыми утилитами.
Основные понятия
- Компьютерная сеть
- Протоколы передачи данных
- NAT (Network Address Translations)
- VPN (Virtual Private Network)
- Firewall
- DNS (Domain Name System)
- DHCP (Dynamic Host Configuration Protocol)
- HTTP/HTTPS
- SMTP/POP3/IMAP
Протоколы передачи данных
Протокол – это набор соглашений (правил), который определяет обмен данными между различными устройствами. Протокол определяет установку соединения (приветствие), характеристики передачи данных (скорость обмена, сколько времени ждать ответа, и т.п.), формат данных (сколько данных передаем за один раз, в каком виде), обработку ошибок (что делать, если произошла ошибка) и закрытие соединения (прощание).
Протоколы передачи данных
На каждый протокол разработана спецификация (описание правил). Ключевые спецификации протоколов описываются в стандартах:
- IEEE (Institute of Electrical and Electronics Engineers)
- IETF (Internet Engineering Task Force)
Например, протоколы сети Интернет описываются в документах, которые называются RFC, выпускаемые IETF Request for Comments.
Firewall
Firewall (межсетевой экран) – программный или программно-аппаратный элемент компьютерной сети, осуществляющий контроль и фильтрацию проходящего через него трафика. Firewall пропускает легитимный трафик и блокирует нелегитимный.
HTTP/HTTPS
HTTP/HTTPS (HyperText Transfer Protocol) – протокол передачи гипертекста (документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам). Основой HTTP является технология клиент-сервер.
Источник изображения
SMTP / POP3 / IMAP
SMTP (Simple Mail Transfer Protocol) — простой протокол передачи почты. Широко используемый сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.
POP3 (Post Office Protocol Version 3) — протокол почтового отделения, версия 3. Стандартный интернет-протокол, используемый клиентами электронной почты для получения почты с удалённого сервера по TCP соединению.
IMAP (Internet Message Access Protocol) — протокол доступа к электронной почте. Задача аналогична POP3, реализация другая. IMAP работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками.
Сетевая модель
Сетевая модель — теоретическое описание принципов работы набора сетевых протоколов, взаимодействующих друг с другом. Модель обычно делится на уровни, так, чтобы протоколы вышестоящего уровня использовали бы протоколы нижестоящего уровня.
Модели бывают как практические (использующиеся в сетях, иногда запутанные и/или не полные, но решающие поставленные задачи), так и теоретические (показывающие принципы реализации сетевых моделей, приносящие в жертву наглядности производительность/возможности).
Инкапсуляция
Инкапсуляция – это процесс передачи данных с верхнего уровня приложений вниз (по стеку протоколов) к физическому уровню, чтобы быть переданными по сетевой физической среде. Причём на каждом уровне различные протоколы добавляют к передающимся данным свою информацию.
Подробнее о инкапсуляции
Примеры сетевых моделей
- Модель OSI (Open Systems Interconnection, взаимосвязь открытых систем) — теоретическая сетевая модель, описанная в различных стандартах и используемая как пример для обучения;
- Модель DOD (англ. Department of Defense — Министерство обороны США, модель TCP/IP) — сетевая модель передачи данных, представленных в цифровом виде.
Модель OSI:
- Физический уровень (physical layer) — определяет способы передачи бит информации через физические среды линий связи (оптический кабель, витая пара).
Пример оборудования:
- витая пара UTP Cat.5 (5e);
- хаб (сетевой концентратор);
- медиаконвертер (преобразователи оптика – медь, Ethernet – RS-485).
Примеры сетевых моделей – OSI
Модель OSI: канальный уровень
Канальный уровень (Data Link layer) — определяет способы передачи данных между устройствами, находящимися в одном сегменте сети. Основные решаемые проблемы: обнаружение ошибок физического уровня, одновременная передача данных разными устройствам (доступ к среде), аппаратная адресация. Единица данных: кадр, фрейм (frame).
Пример оборудования / протокол:
- коммутатор (Ethernet)
- сетевая карта
Модель OSI: Домен коллизий
Домен коллизий — часть сети Ethernet, все узлы которой конкурируют за общую разделяемую среду передачи и, следовательно, каждый узел которой может создать коллизию с любым другим узлом этой части сети. Чем больше узлов в таком сегменте — тем выше вероятность коллизий. Для разделения коммутаторы. домена коллизий применяются
Модель OSI: Протоколы канального уровня
Протоколы канального уровня отвечают доставку данных внутри одного сегмента сети. Стандарт для сетей Ethernet имеет название IEEE 802.3 и детальное описание приведено в документе. Сегмент сети, согласно IEEE 802.3, – это электрически соединенные устройства, использующие общую среду. Сегменты соединяются в сеть при помощи повторителей или коммутаторов.
Модель OSI: Широковещательный домен
Все узлы внутри одного сегмента имеют доступ друг к другу при помощи аппаратных адресов и образуют широковещательный домен. Для IEEE 802.3 такой адрес называется MAC-адресом. MAC-адрес зашивается в сетевые карты (но может быть изменён). Широковещательный домен – метод доставки сообщений, при котором сообщение получают сразу все участники обмена (связи). Нужное сообщение фильтруется самим узлом по MAC-адресу.
Формат кадра Ethernet
- MACs – адрес приемника и отправителя
- Ether Type – тип Ethernet либо размер Payload
- Payload – данные
- CRC – контрольная сумма
Типы передачи трафика
- Broadcast трафик – процесс отправки пакета от одного хоста ко всем хостам в сети; Пример: служебный трафик
- Unicast трафик – процесс отправки пакета от одного хоста к другому хосту; Пример: общение 2-х компьютеров
- Multicast трафик – процесс отправки пакета от одного хоста к некоторой ограниченной группе хостов. Пример: видео по подписке (IPTV)
Пример:
Представим, что у нас есть жилой дом на несколько подъездов и у этого дома есть доска объявлений, на которой управляющая компания информирует жильцов своего дома. Если в объявление будет написано всем жильцам дома, то это будет похоже на broadcast. Если написано жильцам третьего этажа или жильцам второго подъезда, то это будет похоже на multicast. Письмо в почтовый ящик – похоже на unicast.
Модель OSI: сетевой уровень
Сетевой уровень (Network layer) — определяет способы передачи данных между устройствами, находящимися в разных сетях (сегментах сети). Основные решаемые проблемы: логическая адресация, построение маршрутов между сетями, диагностика сети. Единица данных: пакет (packet).
Пример оборудование / протокол:
- маршрутизатор (IPv4, IPv6, ICMP)
Примеры сетевых моделей – OSI
Модель OSI: транспортный уровень
Транспортный уровень (Transport layer) определяет способы доставки данных, т.е. механизм передачи данных. Тип взаимодействия: точка – точка. Основные решаемые проблемы: мультиплексирование, надежная передача данных, регулирование количества передаваемых данных, контроль доставки данных. Единица данных: сегмент (segment), дейтаграмма (datagram). Пример протокола:
- TCP
- UDP
Модель OSI: сеансовый уровень
Сеансовый уровень (Session layer) определяет способы установления и поддержания сеансов связи. Основные решаемые проблемы: создание/завершение сеанса, синхронизация/восстановление сеанса, определение прав на передачу данных, поддержание сеанса в периоды неактивности приложений. Единица данных: поток данных. Пример протокола:
- H.245
- NetBIOS
Модель OSI: уровень представления
Уровень представления (Presentation layer) определяет способы преобразования протоколов и кодирование/декодирование данных. Основные решаемые проблемы: сжатие и распаковка, кодирование и декодирование данных, перенаправление запросов другому сетевому ресурсу. Единица данных: поток данных. Пример протокола:
- ASCII
- EBCDIC
Модель OSI: прикладной уровень
Прикладной уровень (Application layer) определяет способы взаимодействия сети и пользователя. Основные решаемые проблемы: доступ к сетевым службам, передача служебной информации, предоставление информации об ошибках. Единица данных: поток данных. Пример протоколов:
- HTTP
- DNS
- SSH
- Telnet
Сетевая модель DOD
Модель DOD
Модель DOD (Department of Defense, министерство обороны США) – модель сетевого взаимодействия, разработанная Министерством Обороны США/ ARPANET. ARPANET – компьютерная сеть, созданная Агентством Министерства Обороны США по перспективным исследованиям (DARPA) в 1969 году. Прототип сети Интернет.
Модель TCP/IP
Модель TCP/IP – сетевая модель передачи данных, описывающая способы передачи данных от источника информации к получателю. В модели выделено четыре сетевых уровня, каждый из которых описывается соответствующими протоколами передачи данных. Название TCP/IP происходит из двух важных протоколов — Transmission Control Protocol (TCP) и Internet Protocol (IP).
TCP/IP: сетевая модель
Стек протоколов TCP/IP включает в себя четыре уровня:
- Прикладной уровень (Application Layer)
- Транспортный уровень (Transport Layer)
- Межсетевой уровень (Internet Layer)
- Канальный уровень (Network Access Layer)
Сетевые устройства Сетевая плата (в англоязычной среде NIC — англ. network interface controller), также известная как сетевая карта, сетевой адаптер (в терминологии компании Intel), Ethernet-адаптер — по названию технологии — дополнительное устройство, позволяющее компьютеру взаимодействовать с другими устройствами сети. В настоящее время в персональных компьютерах и ноутбуках контроллер и компоненты, выполняющие функции сетевой платы, довольно часто интегрированы в материнские платы для удобства, в том числе унификации драйвера и удешевления всего компьютера в целом.
Сетевые устройства Концентраторы (хаб) Термин «концентратор» иногда используется для обозначения любого сетевого устройства, которое служит для объединения ПК сети, но на самом деле концентратор — это многопортовый повторитель. Устройства подобного типа просто передают (повторяют) всю информацию, которую они получают — то есть все устройства, подключенные к портам концентратора, получают одну и ту же информацию. Концентраторы используются для расширения сети. Однако чрезмерное увлечение концентраторами может привести к большому количеству ненужного трафика (коллизиям), который поступает на сетевые устройства.
Сетевые устройства Сетевой коммутатор (свитч) — устройство, предназначенное для соединения нескольких узлов компьютерной сети в пределах одного или нескольких сегментов сети. Коммутатор работает на канальном уровне сетевой модели OSI. В отличие от хаба, более «умный» свитч запоминает MACадреса компьютеров в специальной таблице и пересылает пакеты только в тот порт, который соответствует адресу получателя. Кроме того, пакеты буферизуются, что исключает коллизии. За счёт этого посылки данных идут только по нужным портам — нет проблем с безопасностью и с чрезмерной нагрузкой не нуждающихся в соответствующих пакетах проводов и компьютеров.
Сетевые устройства Маршрутиза́тор, ро́утер – специализированное устройство, которое пересылает пакеты между различными сегментами сети на основе правил и таблиц маршрутизации. Маршрутизатор может связывать разнородные сети различных архитектур. Для принятия решений о пересылке пакетов используется информация о топологии сети и определённые правила, заданные администратором. Маршрутизаторы работают на «сетевом» (третьем) уровне сетевой модели OSI, в отличие от коммутаторов (свитчей) L2 уровня OSI и концентраторов (хабов), которые работают соответственно на втором и первом уровнях модели OSI.
Итоги На лекции мы рассмотрели и узнали следующее: ● базовые понятия сетей; ● что такое сетевая модель; ● 2 основные сетевых модели: ○ модель OSI ○ модель TCP/IP. ● распространённые сетевые устройства на нашей практике
ГОСТ Р ИСО/МЭК 12207. ОСНОВНЫЕ ПРОЦЕССЫ И ВЗАИМОСВЯЗЬ МЕЖДУ ДОКУМЕНТАМИ В ИНФОРМАЦИОННОЙ СИСТЕМЕ СОГЛАСНО СТАНДАРТАМ.
Область применения его, как следует из названия, относительно узка: процессы, выполняющиеся в ходе жизненного цикла программной системы (речь не идет о жизненном цикле технических средств, таких как вычислительные мощности, сети передачи данных и т. п.). Эти процессы представлены во взаимосвязи с другими процессами организации. Модель жизненного цикла стандарт определяет как "структуру, состоящую из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающую жизнь системы от установления требований к ней до прекращения ее использования".
Цель стандарта – определить полную совокупность процессов, которые могут выполняться в ходе проекта по созданию программной системы. Но поскольку проекты могут сильно различаться, например по масштабам, сложности, рискам и т. п., допускается для каждого проекта локально видоизменять использующиеся в нем процессы, исключая или добавляя отдельные работы и задачи. Такая деятельность называется в стандарте адаптацией.
Методологическая основа ГОСТ Р ИСО/МЭК 12207 разбиение процессов на группы, которых в стандарте вводится три. Основные. Это процессы, непосредственно относящиеся к жизненному циклу информационной системы. Можно считать, что это производственные процессы организации. Вспомогательные. Это процессы, предназначенные для поддержки основных процессов. Сами по себе эти процессы организации не нужны только в связи с основными процессами, которые они обслуживают. Несколько процессов из этой группы связано с управлением качеством. Организационные. Это общекорпоративные процессы, такие как "Обучение" или "Управление". Эти процессы существуют в организации независимо от того, как организовано производство и как устроены вспомогательные процессы.
Таблица 1. Структура процессов жизненного цикла программных систем по ГОСТ Р ИСО/МЭК 12207
Процесс заказа Процесс заказа состоит из работ и задач, выполняемых заказчиком. Процесс начинается с определения потребностей заказчика в системе, программном продукте или программной услуге. Далее следуют подготовка и выпуск заявки на подряд, выбор поставщика и управление процессом заказа вплоть до завершения приемки системы, программного продукта или программной услуги. Конкретная организация, имеющая соответствующую потребность, может быть названа собственником. Собственник может заключить договор на выполнение части или всех работ по заказу с посредником, который будет поочередно проводить данные работы в соответствии с процессом заказа. В данном подразделе под заказчиком понимается собственник или посредник. Заказчик управляет процессом заказа на проектном уровне в соответствии с процессом управления (7.1), который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры (7.2); адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации и управляет процессом заказа на организационном уровне в соответствии с процессами усовершенствования (7.3) и обучения (7.4).
Список работ. Данный процесс состоит из следующих работ: 1. подготовка; 2. подготовка заявки на подряд; 3. подготовка и корректировка договора; 4. надзор за поставщиком; 5. приемка и закрытие договора.
5.1.1. Подготовка – Заказчик начинает процесс заказа, описывая концепцию или потребность в заказе, разработке или модернизации системы, программного продукта или программной услуги. – Заказчик должен определить и проанализировать требования к системе. Требования к системе должны охватывать функциональные, коммерческие, организационные, потребительские аспекты системы, а также требования к безопасности, защите и другие критические требования наряду с требованиями к проектированию, тестированию и соответствующим стандартам и процедурам. – Если заказчик поручает поставщику выполнение анализа требований к системе, то заказчик должен согласовать требования, сформулированные в результате анализа. – Заказчик может выполнить определение и анализ требований к программным средствам сам или поручить решение этой задачи поставщику. Заказчик должен рассмотреть варианты реализации заказа начиная с анализа соответствующих критериев, включая рискованность и стоимость проекта и выгоды от каждого варианта. Анализируются следующие варианты: a) покупка готового программного продукта, удовлетворяющего определенным требованиям; b) разработка программного продукта или получение программной услуги собственными силами; c) разработка программного продукта или получение программной услуги на договорной основе; d) комбинации по перечислениям a), b), c); e) модернизация существующего программного продукта или услуги.
• – При приобретении готового программного продукта заказчик должен получить гарантии того, что удовлетворены следующие условия: • a) программный продукт соответствует установленным требованиям; • b) имеется в наличии соответствующая документация; • c) соблюдены права собственности, использования, лицензирования и гарантии; • d) предусмотрена последующая поддержка программного продукта. • – Заказчик должен подготовить, документально оформить и выполнить план заказа. План должен содержать: • a) требования к системе; • b) планируемую загрузку системы; • c) тип реализуемого договора; • d) обязанности организаций, участвующих в договоре; • e) обеспечение подходов к реализации договора; • f) анализ возможных рискованных ситуаций, а также методы управления такими ситуациями. • – Заказчик должен определить и документально оформить принятые правила и условия (критерии) реализации договора.
Подготовка заявки на подряд Данная работа состоит из следующих задач. – Заказчик должен документально оформить требования к заказу (например, в виде заявки на подряд), состав которых зависит от вариантов реализации заказа Соответствующая документация по заказу должна содержать: a) требования к системе; b) описание области применения системы; c) указания для участников торгов; d) список программных продуктов; e) сроки и условия реализации заказа; f) правила контроля над субподрядчиками; g) технические ограничения (например, по условиям эксплуатации). – Заказчик должен определить, какие из процессов, работ и задач, описанных в настоящем стандарте, применимы к условиям проекта, и соответствующим образом их адаптировать. – В документации по заказу должны быть также определены контрольные пункты договора, при выполнении которых анализируется и проверяется деятельность поставщика – Требования к заказу должны быть представлены организации, выбранной для выполнения работ в процессе заказа
Подготовка и корректировка договора – Заказчик должен определить процедуру для выбора поставщика, включая критерии оценки поступающих предложений по реализации заказа и их соответствие установленным требованиям. – Заказчик должен выбрать поставщика исходя из оценки предложений, поступивших от потенциальных поставщиков, их возможностей и других рассматриваемых факторов. – Заказчик может до заключения договора привлекать другие стороны, включая потенциальных поставщиков, для адаптации настоящего стандарта к условиям проекта. Однако окончательное решение по адаптации должен принимать заказчик. Заказчик должен включить в текст договора или сослаться в нем на адаптированный настоящий стандарт. – Заказчик должен подготовить и обсудить условия договора с поставщиком, который согласился с требованиями к заказу (включая стоимость и календарный план) на поставку программного продукта или услуги. В договоре должны быть оговорены права собственности, использования, лицензирования и гарантии, связанные с используемыми в заказе готовыми программными продуктами. – В ходе реализации договора заказчик должен контролировать изменения, вносимые в договор, обсуждая их с поставщиком. Изменения, вносимые в договор, должны быть изучены с точки зрения их влияния на договорные планы и цены, эффективность и качество.
Надзор за поставщиком Данная работа состоит из следующих задач. – Заказчик должен осуществлять надзор за работами поставщика в соответствии с процессами совместного анализа и аудита. При необходимости заказчик должен дополнять текущий надзор процессами верификации и аттестации. – Заказчик должен взаимодействовать с поставщиком по вопросам своевременного взаимообмена всей необходимой информацией и решения всех возникающих проблем.
Приемка и закрытие договора – Заказчик должен подготовиться к приемке на основе установленных правил и критериев проведения приемки. При этом должны быть подготовлены контрольные примеры, контрольные данные, процедуры тестирования и условия проведения испытаний. Заказчик должен определить степень участия поставщика при проведении приемки. – Заказчик должен проверить готовность поставщика к проведению приемки и провести приемочные испытания поставляемого продукта или услуги, а затем принять их от поставщика при выполнении всех условий приемки. – После приемки заказчик должен принять на себя ответственность за управление конфигурацией поставленного программного продукта –
