В чем заключается преимущество сетевых устройств использующих протоколы открытых стандартов
Обновлено: 27.05.2024
В чем заключается преимущество использования протокола который определяется открытым стандартом
Какое утверждение точно описывает процесс инкапсуляции TCP/IP, если компьютер отправляет данные по сети?
**Сегменты передаются с транспортного уровня на интернет-уровень.
Какова функция уровня 4 модели OSI?
**Описывать упорядоченную и надёжную доставку данных между источником и местом назначения
В чём заключается преимущество сетевых устройств, использующих протоколы открытых стандартов?
**Узел клиента и сервер с разными операционными системами могут успешно обмениваться данными.
Какой адрес предоставляет уникальный адрес узла для обеспечения передачи данных на интернет-уровне?
Какое утверждение описывает функции протокола разрешения адресов (ARP)?
**ARP используется для обнаружения MAC-адреса любого узла в локальной сети.
Какой формат PDU используется в тех случаях, когда биты получены сетевым адаптером узла от сетевой среды?
Откройте интерактивное задание PT. Выполните задания, указанные в инструкциях к упражнению, а затем ответьте на вопрос.
Исходя из данных настроенной сети, какой IP-адрес будет использоваться ПК1 и ПК2 в качестве шлюза по умолчанию?
Компьютер в данной сети взаимодействует с определённой группой компьютеров. Какой это тип коммуникации?
Каким общим термином описывают данные на любом уровне модели сети?
**Блок данных протокола (protocol data unit)
Какой адрес использует сетевая интерфейсная плата (NIC) в процессе определения возможности приёма кадра?
Какой стандарт IEEE позволяет беспроводной сетевой плате подключаться к беспроводной точке доступа, разработанной другим производителем?
Если основной шлюз был неправильно сконфигурирован на узле, каким образом это влияет на связь?
**Узел может обмениваться данными с другими узлами в своей локальной сети, но не может обмениваться данными с узлами в других сетях.
Что такое проприетарные протоколы?
**Протоколы, разработанные организациями, которые полностью контролируют определение и принципы работы этих протоколов
В чем заключается преимущество использования многоуровневой модели для обмена данными в сети?
**Стимулирование конкуренции между разработчиками устройств и программного обеспечения за счёт того, что они будут вынуждены создавать совместимые продукты
**MAC-адрес шлюза по умолчанию
На каком из уровней модели OSI будет инкапсулирован логический адрес?
Веб-клиент отправляет запрос веб-страницы к веб-серверу. С точки зрения клиента какой порядок стека протоколов должен использоваться для подготовки запроса передачи?
Какой метод может использоваться двумя компьютерами для предотвращения потери пакетов из-за слишком быстрой передачи большого количества данных?
Какое утверждение о моделях TCP/IP и OSI является верным?
**Транспортный уровень TCP/IP и 4й уровень OSI обеспечивают аналогичные сервисы и функции.
10 минут на чтение
Оглавление
В вебе используют криптографические протоколы SSL (secure sockets layer) и TLS (transport layer security). Эти протоколы построены на алгоритме асиметричного ключа, который состоит из двух ключей — публичного и частного. Публичные ключи доступны и сайтам и браузерам, частные — хранятся на собственных серверах веб-приложений.
Тема 4. Информационное и программное обеспечение сетей
Оглавление
Цель темы — сформировать представление о принципах работы и реализации в стеке TCP/IP транспортных и служебных протоколов передачи информационных данных через сеть. Реализуются эти протоколы программными средствами операционных систем.
В результате изучения темы студенты должны усвоить:
4.1. Протоколы транспортного уровня UDP и TCP
Основная задача транспортного уровня заключается в передаче данных между парой прикладных процессов, выполняющихся в сети. Протоколы транспортного уровня UDP и TCP функционируют только на конечных узлах сети, выступая посредниками между сетевыми приложениями и самой сетью.
4.1.1. Общие принципы работы протоколов UDP и TCP
После того как пакет средствами протокола IP доставлен в сетевой интерфейс компьютера-получателя, данные из этого пакета необходимо передать конкретному процессу-получателю. В свою очередь процесс или несколько процессов, выполняющихся в компьютере, тоже должны иметь возможность передавать информационные данные протоколу IP для отправки этих данных пакетами по сети к узлам назначения. Транспортные протоколы формируют механизм взаимодействия прикладных сетевых процессов с сетевым интерфейсом компьютера.
Поскольку к одному транспортному протоколу могут обращаться множество прикладных процессов, то вводится условная адресация этих процессов в виде так называемых портов — точек доступа прикладных процессов к транспортному уровню. Номер порта однозначно определяет приложение в пределах одного компьютера, а набор из IP-адреса компьютера и номера порта, который называют сокетом, однозначно определяет приложение в составной сети. В обозначении сокета IP-адрес и номер порта разделяются двоеточием. Пример обозначения сокета: 10.112.0.2:80.
Не следует путать порт транспортного протокола с портом (интерфейсом) компьютера. Порт транспортного уровня — это фактически адрес буфера памяти, через который происходит взаимодействие прикладного процесса с транспортным протоколом. Так как используется 16-битная адресация к этим буферам памяти, то возможные номера адресов (портов) транспортного протокола ограничены числами от 0 до 65 535.
Существует два способа присвоения порта приложению — централизованный и локальный (динамический). Для централизованного способа используются номера портов от 0 до 1023, а для локального — все остальные: 1024—65 535.
Локально номера портов выделяются операционной системой компьютера тем сетевым приложениям, которые не имеют широкого распространения. Операционная система компьютера ведет учет занятых и свободных номеров портов. Так как при локальном (динамическом) распределении номеров портов закрепление портов за приложениями происходит только на время работы этого приложения, то при следующем запуске этого приложения ему может быть выделен другой номер порта из диапазона номеров 1024—65 535.
Следует отметить, что как у протокола UDP, так и у протокола TCP отдельный набор номеров портов от 0 до 65 535, т. е., говоря о номере порта, следует указывать и протокол — TCP или UDP. Следовательно, в компьютере одновременно может использоваться по два номера порта — один для протокола TCP, другой — для протокола UDP.
Протоколы UDP и TCP для каждого номера порта ведут две очереди: очередь сегментов, поступающих в данный порт их сети, и очередь сегментов, отправляемых из данного порта в сеть. Процедура приема сегментов данных из портов различных прикладных процессов называется мультиплексированием. Обратная процедура распределения транспортным протоколом (UDP или TCP) сегментов данных, поступающих от сетевого уровня, между процессами, идентифицированными номерами портов, называется демультиплексированием.
Рис. 4.1 иллюстрирует процедуры мультиплексирования и демультиплексирования данных протоколами TCP и UDP.
Рис. 4.1. Мультиплексирование и демультиплексирование данных на транспортом уровне
Аналогично функционирует и протокол UDP, обслуживая свои процессы через собственные порты.
В заголовках принимаемых IP-пакетов указывается протокол верхнего уровня, поэтому IP-протокол однозначно определяет, какому протоколу следует отдать очередной пакет данных.
4.1.2. Протокол пользовательских дейтаграмм UDP
Заголовок UDP сегмента состоит из 8 байт и имеет структуру, представленную на рис. 4.2.
№ порта источника
(2 байта)
№ порта назначения
(2 байта)
Длина сегмента UDP
(2 байта)
Контрольная сумма
(2 байта)
Рис. 4.2. Структура заголовка сегмента UDP
Поле длины сегмента содержит общее количество байт сегмента вместе с заголовком.
Поле контрольной суммы позволяет проверить точность передачи данных в сегменте. Следует напомнить, что в протоколе IP проверяется на наличие ошибок только заголовок пакета, а поле данных, в котором находится сегмент транспортного протокола, не проверяется. При обнаружении ошибки в сегменте протокол UDP поступает аналогично протоколу IP — отбрасывает принятый сегмент данных.
Поскольку в протоколе UDP отсутствует обратная связь, то в заголовке сегмента UDP допустимо отсутствие номера порта источника. Контрольная сумма тоже является необязательным параметром. В случае отсутствия этих данных вместо них в заголовке передаются последовательности нулей соответствующей длины.
Логическое соединение TCP — это договоренность о параметрах процедуры передачи данных между двумя прикладными процессами сети посредством протокола TCP. Ключевым моментом логического соединения является квитирование (подтверждение) приема переданных данных посредством отправки квитанций.
Модуль TCP в компьютере-отправителе хранит в своем буфере памяти все переданные сегменты потока данных, на байты из которых еще не получены квитанции. Если компьютер-отправитель не получает квитанцию в течение определенного времени, то ее модуль TCP начинает повторную передачу сегментов, на байты данных которых не было подтверждения.
Структура сегмента TCP представлена на рис. 4.3.
Рис. 4.3. Структура сегмента TCP
Сегмент TCP состоит из заголовка и поля данных. Заголовок сегмента имеет размер не менее 20 байт и содержит следующие поля:
4.1.4. Метод скользящего окна
В протоколе TCP в рамках установленного логического соединения правильность передачи данных должна подтверждаться квитанцией получателя. В протоколе TCP используется частный случай квитирования — метод скользящего окна (sliding window).
В этом методе для повышения коэффициента использования линии передачи источнику разрешается передать некоторое количество сегментов данных подряд в непрерывном режиме — в максимально возможном для источника темпе, без получения на эти сегменты положительных квитанций от получателя. Объем данных, которые разрешается передавать таким образом, называется размером окна.
Особенностью этого метода в протоколе TCP является то, что хотя единицей передаваемых данных является сегмент, окно определено на множестве нумерованных байтов неструктурированного потока данных, поступающих от прикладного процесса и буферизуемых протоколом TCP. Рис. 4.4 иллюстрирует работу метода скользящего окна в протоколе TCP.
Рис. 4.4. Скользящее окно в протоколе TCP
В передаваемом потоке на рис. 4.4 получена квитанция с номером N в поле ACK, которая означает, что все предыдущие байты потока безошибочно приняты противоположной стороной и можно передавать следующие байты потока, начиная с номера N. Одновременно получено значение окна W, которое указывает, что передавать можно не один сегмент, а столько, сколько переносят байты с номера N до номера, не превышающего N+W.
Поскольку в протоколе TCP каждая сторона выступает и как отправитель, и как получатель данных, то у каждой стороны есть пара буферов памяти: один — для хранения принятых сегментов, другой — для передаваемых сегментов.
Таким образом, посылая окно приема, обе стороны регулируют поток байтов в свою сторону, исходя из возможностей и загруженности своего буфера приема. Размер окна может меняться в рамках даже одного соединения — его текущее значение указывается в заголовке каждого сегмента TCP.
Переданные сегменты хранятся в буфере передачи до получения квитанции об успешном их приеме. Получатель может послать квитанцию на получение сразу нескольких сегментов, если они образуют непрерывный поток байтов. Подтверждение приема отдельных сегментов, оторванных от потока данных пропусками, не осуществляется до тех пор, пока этот пропуск не будет заполнен.
Каждый переданный сегмент хранится в буфере передачи определенное время, которое определяется в протоколе TCP по достаточно сложному адаптивному алгоритму, учитывающему различные факторы. Если до истечения этого времени квитанция на переданные в сегменте данные не пришла, то модуль протокола TCP повторяет передачу сегмента, считая, что первая копия сегмента была утеряна.
4.1.5. Алгоритм установления логического соединения TCP
Установление соединения TCP выполняется в следующей последовательности:
На рис. 4.5 отображено также, что маршрутизатор между двумя сетями, в которых находятся сетевые процессы, устанавливающие соединение, не принимает в этой процедуре никакого участия.
Сторона-инициатор отправляет первый сегмент данных, предлагает передавать данные в свою сторону (ASК=1) и указывает размер своего окна приема.
4.1.6. Преобразование сетевых адресов: технология NAT
Технология NAT (Network Address Translation — преобразование сетевых адресов) широко используется с целью подмены частных IP-адресов (из таких диапазонов, как 10.х.x.x, 192.168.x.x, 172.16.x.x —172.31.х.х) компьютеров локальных сетей публичным IP-адресом, разрешенным в глобальной сети Интернет.
Основная причина растущей популярности технологии NAT связана со все более обостряющимся дефицитом адресов протокола IPv4. Средство общего доступа к подключению Интернета в операционных системах Windows XP, а также многие шлюзы Интернета активно используют NAT, особенно для подключения к широкополосным сетям, например через DSL или кабельные модемы.
На рис. 4.6 приведен пример использования технологии NAT для выхода в Интернет компьютеров локальной сети 10.0.0.0/24 под одним IP-адресом 157.55.1.10.
Рис. 4.6. Пример использования технологии NAT для локальной сети
NAT устройство — это программа, размещаемая на шлюзе между локальной сетью и сетью Интернет, которая на основе портов транспортного уровня обеспечивает замену IP-адресов в проходящих IP-пакетах.
Процесс, запущенный на компьютере локальной сети и установивший соединение с процессом в сети Интернет, открывает пару сокетов, определяемых IP-адресом источника, портом источника, IP-адресом назначения, портом назначения и сетевым протоколом. Эти параметры идентифицируют обе конечные точки, между которыми происходит соединение.
Когда прикладной процесс передает данные через соединение, частный IP-адрес клиента (IP-адрес источника) и клиентский порт (порт источника) вставляются в пакет в поля параметров источника. Поля параметров пункта назначения будут содержать IP-адрес и порт процесса-назначения. Поскольку пункт назначения пакета находится вне локальной сети, клиент направляет его в основной шлюз. В данном сценарии роль основного шлюза играет устройство NAT.
Устройство NAT перехватывает исходящий пакет и производит сопоставление порта, используя IP-адрес назначения в сети Интернет, порт назначения, внешний IP-адрес устройства NAT, внешний порт, сетевой протокол, а также внутренние IP-адрес и порт клиента локальной сети.
Устройство NAT ведет таблицу сопоставлений портов и сохраняет созданное сопоставление в этой таблице. Внешние IP-адрес и порт — это общие IP-адрес и порт, которые будут использоваться в текущем сеансе передачи данных вместо внутренних IP-адреса и порта клиента.
Преобразованный пакет пересылается по внешней сети и в итоге попадает на узел назначения (Remote host). Пример работы устройства NAT представлен на рис. 4.7.
Рис. 4.7. Пример преобразования исходящего пакета
Внешний удаленный узел сети Интернет будет направлять ответные пакеты на внешние IP-адрес и порт устройства NAT, указывая в полях источника свои собственные IP-адрес и порт.
NAT устройство принимает эти пакеты от удаленного узла сети Интернет и анализирует их содержимое на основе своей таблицы сопоставления портов. Если в таблице будет найдено сопоставление порта, для которого IP-адрес источника, порт источника, порт назначения и сетевой протокол из входящего пакета совпадают с IP-адресом удаленного узла, удаленным портом и сетевым протоколом, указанным в сопоставлении портов, NAT выполнит обратное преобразование. NAT заменяет внешний IP-адрес и внешний порт в полях назначения пакета на частный IP-адрес и внутренний порт клиента локальной сети.
Затем NAT отправляет пакет клиенту по внутренней сети. Однако если NAT не находит подходящего сопоставления портов, входящий пакет отвергается и соединение разрывается.
Благодаря устройству NAT клиент получает возможность передавать данные в глобальной среде Интернета, используя лишь частный IP-адрес; ни от приложения, ни от клиента не требуется никаких дополнительных усилий. В данном случае механизм NAT оказывается прозрачным по отношению к клиенту и к серверному приложению — все работает просто и четко.
Однако не все сетевые приложения пользуются протоколами, способными взаимодействовать с NAT.
4.2.1. Назначение протокола ICMP
Сейчас для нас естественно, то что мы можем подключиться к компьютерным сетям, например к интернету, практически с любого устройства, смартфона, ноутбука, планшета, и другой техники. Независимо от производителя этого оборудования, какая операционная система (ОС) используется, и какие программы мы применяем.
p, blockquote 1,0,0,0,0 -->
p, blockquote 2,0,0,0,0 -->
Но в самом начале развития сетей (1960-1970 годы) устройство одного производителя, например IBM, работало по сети только с устройствами IBM, а устройствами других производителей нет. Основные причины это:
- Несовместимость оборудования между собой;
- Несовместимость ПО;
- Использование разных сетевых протоколов.
Для того, чтобы решить эти задачи, нужны стандарты на оборудование, на ПО и на сетевые протоколы.
p, blockquote 4,0,1,0,0 -->
Типы стандартов
Юридические стандарты (De jure) принимают организации, которые имеют право на это.
p, blockquote 5,0,0,0,0 -->
Фактические стандарты (De facto) — это стандарты, которые установились сами по себе, их никто не принимал. К примеру, появилась новая технология, которая быстро развилась и стала популярной. Как это произошло со стеком протоколов TCP/IP, который сейчас основа сети интернет.
p, blockquote 6,0,0,0,0 -->
Стандарты для сетей
Принимается огромное множество разных стандартов, но есть самые значимые:
- Международная организация по стандартизации (IOS) приняла стандарт на эталонную модель OSI, описывающая, как должны строиться компьютерные сети.
- Институт инженеров по электронике и электротехнике (IEEE) принимающие стандарты на технологи по передачи данных.
- Совет по архитектуре интернета (IAB) принимает стандарты на протоколы интернет.
- Консорциум W3C принимает стандарты в область Web.
Стандарты IEEE
Институт ieee утверждает стандарты не только в компьютерных сетях, но также в других сферах электроники, электротехники. Институт поделен на комитеты. Разработкой стандартов для комп. сетей занимается комитет под № 802.
p, blockquote 8,0,0,0,0 -->
p, blockquote 9,1,0,0,0 -->
Каждый № это семейство стандартов. Например, 802.3 описывает разные варианты технологий Ethernet, такие как, Fast Ethernet, Gigabit Ethernet и 10 Gigabit Ethernet.
p, blockquote 10,0,0,0,0 -->
Совет по архитектуре интернета
Совет поделён две части. Группа исследования интернет (Internet Research Task Force, IRTF) проводит перспективные исследования в области интернет.
p, blockquote 11,0,0,0,0 -->
Часть №2 группа проектирования интернет (Internet Engineering Task Force, IETF) производит стандарты на сетевые протоколы. IETF подготавливает документы RFC (Request for Comments) или запросы на комментарии. Вот эти доки содержат подробное описание протоколов интернет. Если вы будите использовать другие протоколы, то ваше устройство и ПО не сможет работать в сети интернет.
p, blockquote 12,0,0,0,0 -->
Документы RFC
У каждого документа RFC есть индивидуальный номер и он описывает какой-либо протокол интернет.
p, blockquote 13,0,0,0,0 -->
p, blockquote 14,0,0,1,0 -->
Существуют много документов RFC , с которыми вы можете ознакомиться.
p, blockquote 15,0,0,0,0 -->
Консорциум W3C (World Wide Web)
W3C разрабатывает стандарты для Веб. Документы консорциума, также как и RFC формально, они не называются стандартами, а называются рекомендациями. Но если вы не последуете этим рекомендациям, то не сможете поработать с web.
p, blockquote 16,0,0,0,0 -->
Самые важные рекомендации консорциума w3c это:
- Язык разметки html;
- Таблицы стилей css, которые нужны для создания web-страниц;
- Рекомендации на архитектуру Веб-сервисов;
- И язык разметки xml.
Но существуют еще рекомендации, которые в свободном доступе на сайте консорциума .
p, blockquote 18,0,0,0,0 -->
Заключение
Как мы выяснили, рассмотренные стандарты имеют важную роль в работе компьютерных сетей. Все мы хотим выходить в интернет с любого устройства независимо от того, какая там ОС, кто создал это устройство и какое ПО на нем применяется. Для этого и нужны открытые стандарты.
Свидетельство и скидка на обучение каждому участнику
Лабораторное занятие №6
Тема: Установка и настройка протокола TCP / IP в ОС Windows и Linux .
Цель работы: Изучить способы диагностики настроек стека протоколов TCP/ IP; получить сведения о настройке TCP/IP для работы с DHCP сервером.
Оборудование : Компьютер в сборе или испытательный стенд.
1. Ознакомиться с теоретической частью.
2. Выполнить задания.
3. Ответить на контрольные вопросы.
4. Оформить отчет.
Теоретическая часть
На концептуальной модели взаимодействия открытых систем OSI основан стек протоколов TCP/IP(Transmission Control Protocol - протокол управления передачей / Internet Protocol – Интернет-протокол), который предоставляет ряд стандартов для связи компьютеров и сетей.
Стек протоколов TCP/IP – промышленный стандарт, который позволяет организовать сеть масштаба предприятия и связывать компьютеры, работающие под управлением различных операционных систем.
Применение стека протоколов TCP/IP дает следующие преимущества:
· поддерживается почти всеми операционными системами; почти все большие сети основаны на TCP/IP;
· технология позволяет соединить разнородные системы;
· получение доступа к ресурсам сети Интернет.
Каждый узел TCP/IP идентифицирован своим логическим IP-адресом, который идентифицирует положение компьютера в сети почти таким же способом, как номер дома идентифицирует дом на улице.
Реализация TCP/IP позволяет узлу TCP/IP использовать статический IP-адрес или получить IP-адрес автоматически с помощью DHCP-сервера (Dynamic Host Configuration Protocol - протокол динамической конфигурации хоста).
Для простых сетевых конфигураций, основанных на локальных сетях (LAN, Local Area Network), он поддерживает автоматическое назначение IP-адресов.
По умолчанию компьютеры клиентов, работающие под управлением ОС Windows или Linux, получают информацию о настройке протокола TCP/IP автоматически от службы DHCP.
Однако даже в том случае, если в сети доступен DHCP-сервер, необходимо назначить статический IP-адрес для отдельных компьютеров в сети. Например, компьютеры с запущенной службой DHCP не могут быть клиентами DHCP, поэтому они должны иметь статический IP-адрес.
Если служба DHCP недоступна, можно настроить TCP/IP для использования статического IP-адреса.
Для каждой платы сетевого адаптера в компьютере, которая использует TCP/IP, можно установить IP-адрес, маску подсети и шлюз по умолчанию.
Ниже описаны параметры, которые используются при настройке статического адреса TCP/IP.
Логический 32-битный адрес, который идентифицирует TCP/IP узел. Каждой плате сетевого адаптера в компьютере с запущенным протоколом TCP/IP необходим уникальный IP-адрес, такой, как 192.168.0.108. Каждый адрес имеет две части: ID сети, который идентифицирует все узлы в одной физической сети и ID узла, который идентифицирует узел в сети. В этом примере ID сети — 192.168.0, и ID узла — 108.
Подсети делят большую сеть на множество физических сетей, соединенных маршрутизаторами. Маска подсети закрывает часть IP-адреса так, чтобы TCP/IP мог отличать ID сети от ID узла. При соединении узлов TCP/IP, маска подсети определяет, где находится узел получателя: в локальной или удаленной сети. Для связи в локальной сети компьютеры должны иметь одинаковую маску подсети.
Шлюз по умолчанию
Промежуточное устройство в локальной сети, на котором хранятся сетевые идентификаторы других сетей предприятия или Интернета. TCP/IP посылает пакеты в удаленную сеть через шлюз по умолчанию (если никакой другой маршрут не настроен), который затем пересылает пакеты другим шлюзам, пока пакет не достигнет шлюза, связанного с указанным адресатом.
Если сервер с запущенной службой DHCP доступен в сети, он автоматически предоставляет информацию о параметрах TCP/IP клиентам DНСР.
Настройка и диагностика сети в ОС Linux
Для работы с сетевыми протоколами TCP/IP в Linux достаточно наличие только петлевого интерфейса, но если необходимо объединить хосты между собой, естественно, необходимо наличие сетевого интерфейса, каналов передачи данных (например витая пара), возможно, какого-либо сетевого оборудования. Так же, необходимо наличие установленных утилит для настройки сети ( /sbin/ifconfig , /sbin/route и др.), обычно поставляемые в пакете net-tools . Так же необходимо наличие конфигурационных файлов для сети (например /etc/hosts ) и поддержку сети ядром Linux .
Файлы настроек сети в Linux (конфигурационные файлы)
В целом, вся работа Linux основана на процессе init , который рождается при загрузке ОС и плодит своих потомков, которые в свою очередь и выполняют всю необходимую работу. Вся загрузка Linux основана на скриптах bash , в которых прописана вся последовательность запуска мелких утилит с различными параметрами, которые последовательно запускаются/останавливаются при запуске/остановке системы. Аналогично запускается и сетевая подсистема Linux.
Это скрипт, отвечающий за инициализацию сети.
Данный файл хранит перечень IP адресов и соответствующих им (адресам) имен хостов. Исторически, данный файл использовался вместо службы DNS. В настоящее время, файл так же может использоваться вместо службы DNS, но только при условии, что в вашей сети количество машин измеряется в единицах, а не в десятках или сотнях, потому что в таком случае, придется контролировать корректность данного файла на каждой машине.
Данный файл хранит имена и адреса локальной и других сетей. При использовании данного файла, сетями можно управлять по имени. Например добавить маршрут не route add 192.168.1.12 , а route add home-network .
Файл определяет порядок поиска имени хоста/сети.
Данный фал определяет параметры механизма преобразования сетевых имен в IP адреса. Простым языком, определяет настройки DNS.
Настройка сети
Так же, если выполняется команда ifconfig с недостающими параметрами (например только IP адрес), то остальные дополняются автоматически (например бродкаст адрес добавляется по умолчанию с хостовым адресом, оканчивающимся на 255 и маска подсети по умолчанию берется 255.255.255.0).
Диагностика сети Linux
Существует большое количество инструментов диагностики сети в Linux, зачастую, они очень похожи на утилиты от Microsoft.
Работа этой утилиты заключается в отправке т.н. пакетов ICMP удаленному серверу, который будет указан в параметрах команды, сервер возвращает отправленные команды, а ping подсчитывает время требуемое отправленному пакету, чтобы дойти до сервера и вернуться.
Следует отметить, что данная утилита не всегда надежный инструмент для диагностики. Удаленный сервер может блокировать ответы на ICMP запросы.
Простым языком, команда называется трассировка маршрута. Как можно понять из названия - данная утилита покажет по какому маршруту шли пакеты до хоста. Утилита traceroute несколько похожа на ping , но отображает больше интересной информации. Пример :
6 213.33.201.230 (213.33.201.230) 43.322 ms 41.783 ms 41.106 ms
Данная утилита посылает запросы серверам DNS и возвращает информацию о заданном домене.
Консольные команды управления сетевым интерфейсом.
ifconfig [опции] – стандартная команда Unix управления сетевым интерфейсом. В Mandriva Linux управляющие возможности этой команды ограничены.
ifup - консольная команда включения сетевого интерфейса.
ifdown - консольная команда выключения сетевого интерфейса.
ping - команда проверки функционирования сети с использованием icmp пакета. Для выхода из режима проверки сети необходимо нажать CTRL +C.
arp [опции] – Команда печати таблицы памяти МАС адресов компьютера.
Задания на лабораторную работу
Задание 1. Проверьте работоспособность стека протоколов TCP/IP в ОС Windows .
1. Запустите виртуальную машину и загрузите ОС Windows.
2. Запустите консоль (Пуск/Программы/Стандартные/Командная строка).
3. В командной строке введите ipconfig /all.
4. Используя приведенную ниже информацию, создайте в своей папке текстовый документ со следующими данными:
o Имя компьютера;
o Основной DNS-суффикс;
o Описание DNS-суффикса для подключения;
o Физический адрес;
o Автоконфигурация включена;
o IP-адрес автоконфигурации;
o Маска подсети;
o Шлюз по умолчанию.
5. Убедитесь в работоспособности стека TCP/IP, отправив эхо-запросы на IP-адреса. Для этого воспользуйтесь командой ping :
o отправьте эхо-запрос по другому IP-адресу, например 192.168.10.1.
Задание 2. Настройте стек протоколов TCP/IP для использования статического IP-адреса.
1. Откройте окно Сетевые подключения (Пуск/Панель управления/Сетевые подключения).
2. Вызовите свойства подключения по локальной сети. Для этого можно воспользоваться контекстным меню.
3. В появившемся диалоговом окне на вкладке Общие откройте свойства Протокол Интернета TCP/IP.
4. Щелкните переключатель Использовать следующий IP-адрес и введите в соответствующие поля данные:IP_адрес; Маску подсети; Основной шлюз; Предпочитаемый DNS.
5. Примените параметры кнопкой ОК.
6. Закройте окно свойств подключения кнопкой ОК (если потребуется, то согласитесь на перезагрузку компьютера).
7. Проверьте работоспособность стека протоколов TCP/IP.
Задание 3. Настройте TCP/IP для автоматического получения IP-адреса.
1. Откройте окно Сетевые подключения.
2. Вызовите свойства Подключения по локальной сети.
3. Откройте свойства Протокол Интернета TCP/IP.
4. Установите переключатель Получить IP-адрес автоматически.
5. Закройте диалоговое окно Свойства: Протокол Интернета TCP/IP кнопкой ОК.
6. Примените параметры кнопкой ОК.
7. Проверьте настройку стека протоколов TCP/IP.
8. Получите другой адрес для своего компьютера. Для этого:
o запустите консоль (командную строку);
o введите команду для сброса назначенных адресов - ipconfig /release;
o введите команду для получения нового адреса ipconfig /renew;
9. Проверьте работоспособность стека протоколов TCP/IP.
Задание 4 . Настройка и диагностика сети в ОС Linux .
1 Загрузите ОС Linux
2 Изучите файл настройки сетевого интерфейса: /etc/sysconfig/network-scripts/ifcfg-eth0
3 Изучите руководство программы ifconfig .
4 Изучите руководство программы ifcfg .
5 Просмотрите сетевые интерфейсы при помощи команды ifconfig .
6 Выключите интерфейс eth0, применив консольную команду ifdown .
7 Просмотрите изменение параметров настройки сетевого интерфейса eth0 при помощи команды ifconfig .
8 Сделайте копию экрана во время выполнения операции для отчета по лабораторной работе.
9 Включите интерфейс eth0 при помощи команды ifup .
10 Присвойте интерфейсу eth0 IP-адрес из диапазона 192.168.0.190-192.168.0.200 с маской 255.255.255.0 при помощи команды ifconfig .
11 Просмотрите изменение параметров настройки сетевого интерфейса eth0 при помощи команды ifconfig .
12 Выведите кэш МАС адресов при помощи команды arp .
13 Сделайте копию экрана во время выполнения операции для отчета по лабораторной работе.
14 Проверьте функционирование сетевого интерфейса при помощи команды ping : ping .
15 Проверьте функционирование сети при помощи команды ping: ping .
16 Сделайте копию экрана во время выполнения операции для отчета по лабораторной работе.
Содержание отчета
Тема, цель, оборудование, порядок выполнения заданий, ответы на контрольные вопросы, вывод .
Контрольные вопросы
2. Как происходит автоматическое получение IP-адреса.
3. Назначение маски подсети.
4. Как выполнить тестирование протокола TCP/IP.
5. Что такое интерфейс lo? Какой у него адрес?
6. Почему ping до вашей сетевой платы идет быстрее чем до другого компьютера класса?
Если Вы считаете, что материал нарушает авторские права либо по каким-то другим причинам должен быть удален с сайта, Вы можете оставить жалобу на материал.
Открытая сетевая модель OSI (Open Systems Interconnection model) состоит из семи уровней. Что это за уровни, как устроена модель и какова ее роль при построении сетей — в статье.
Принцип устройства сетевой модели
Сетевая модель OSI имеет семь уровней, иерархически расположенных от большего к меньшему. То есть, самым верхним является седьмой (прикладной), а самым нижним — первый (физический). Модель OSI разрабатывалась еще в 1970-х годах, чтобы описать архитектуру и принципы работы сетей передачи данных. Важно помнить, что данные передаются не только по сети интернет, но и в локальных сетях с помощью проводных или беспроводных соединений.
На седьмом уровне информация представляется в виде данных, на первом — в виде бит. Процесс, когда информация отправляется и переходит из данных в биты, называется инкапсуляцией. Обратный процесс, когда информация, полученная в битах на первом уровне, переходит в данные на седьмом, называется декапсуляцией. На каждом из семи уровней информация представляется в виде блоков данных протокола — PDU (Protocol Data Unit).
Рассмотрим на примере: пользователь 1 отправляет картинку, которая обрабатывается на седьмом уровне в виде данных, данные должны пройти все уровни до самого нижнего (первого), где будут представлены как биты. Этот процесс называется инкапсуляцией. Компьютер пользователя 2 принимает биты, которые должны снова стать данными. Этот обратный процесс называется декапсуляция. Что происходит с информацией на каждом из семи уровней, как и где биты переходят в данные мы разберем в этой статье.
Первый, физический уровень (physical layer, L1)
Каждый уровень имеет свои PDU, представляемые в той форме, которая будет понятна на данном уровне и, возможно, на следующем до преобразования. Работа с чистыми данными происходит только на уровнях с пятого по седьмой.
Устройства физического уровня оперируют битами. Они передаются по проводам (например, через оптоволокно) или без проводов (например, через Bluetooth или IRDA, Wi-Fi, GSM, 4G и так далее).
Второй уровень, канальный (data link layer, L2)
Когда два пользователя находятся в одной сети, состоящей только из двух устройств — это идеальный случай. Но что если этих устройств больше?
У канального уровня есть два подуровня — это MAC и LLC. MAC (Media Access Control, контроль доступа к среде) отвечает за присвоение физических MAC-адресов, а LLC (Logical Link Control, контроль логической связи) занимается проверкой и исправлением данных, управляет их передачей.
На втором уровне OSI работают коммутаторы, их задача — передать сформированные кадры от одного устройства к другому, используя в качестве адресов только физические MAC-адреса.
Третий уровень, сетевой (network layer, L3)
На третьем уровне появляется новое понятие — маршрутизация. Для этой задачи были созданы устройства третьего уровня — маршрутизаторы (их еще называют роутерами). Маршрутизаторы получают MAC-адрес от коммутаторов с предыдущего уровня и занимаются построением маршрута от одного устройства к другому с учетом всех потенциальных неполадок в сети.
На сетевом уровне активно используется протокол ARP (Address Resolution Protocol — протокол определения адреса). С помощью него 64-битные MAC-адреса преобразуются в 32-битные IP-адреса и наоборот, тем самым обеспечивается инкапсуляция и декапсуляция данных.
Четвертый уровень, транспортный (transport layer, L4)
Все семь уровней модели OSI можно условно разделить на две группы:
- Media layers (уровни среды),
- Host layers (уровни хоста).
Уровни группы Media Layers (L1, L2, L3) занимаются передачей информации (по кабелю или беспроводной сети), используются сетевыми устройствами, такими как коммутаторы, маршрутизаторы и т.п. Уровни группы Host Layers (L4, L5, L6, L7) используются непосредственно на устройствах, будь то стационарные компьютеры или портативные мобильные устройства.
Четвертый уровень — это посредник между Host Layers и Media Layers, относящийся скорее к первым, чем к последним, его главной задачей является транспортировка пакетов. Естественно, при транспортировке возможны потери, но некоторые типы данных более чувствительны к потерям, чем другие. Например, если в тексте потеряются гласные, то будет сложно понять смысл, а если из видеопотока пропадет пара кадров, то это практически никак не скажется на конечном пользователе. Поэтому, при передаче данных, наиболее чувствительных к потерям на транспортном уровне используется протокол TCP, контролирующий целостность доставленной информации.
Для мультимедийных файлов небольшие потери не так важны, гораздо критичнее будет задержка. Для передачи таких данных, наиболее чувствительных к задержкам, используется протокол UDP, позволяющий организовать связь без установки соединения.
При передаче по протоколу TCP, данные делятся на сегменты. Сегмент — это часть пакета. Когда приходит пакет данных, который превышает пропускную способность сети, пакет делится на сегменты допустимого размера. Сегментация пакетов также требуется в ненадежных сетях, когда существует большая вероятность того, что большой пакет будет потерян или отправлен не тому адресату. При передаче данных по протоколу UDP, пакеты данных делятся уже на датаграммы. Датаграмма (datagram) — это тоже часть пакета, но ее нельзя путать с сегментом.
Первые четыре уровня — специализация сетевых инженеров, но с последними тремя они не так часто сталкиваются, потому что пятым, шестым и седьмым занимаются разработчики.
Пятый уровень, сеансовый (session layer, L5)
Пятый уровень оперирует чистыми данными; помимо пятого, чистые данные используются также на шестом и седьмом уровне. Сеансовый уровень отвечает за поддержку сеанса или сессии связи. Пятый уровень оказывает услугу следующему: управляет взаимодействием между приложениями, открывает возможности синхронизации задач, завершения сеанса, обмена информации.
Службы сеансового уровня зачастую применяются в средах приложений, требующих удаленного вызова процедур, т.е. чтобы запрашивать выполнение действий на удаленных компьютерах или независимых системах на одном устройстве (при наличии нескольких ОС).
Примером работы пятого уровня может служить видеозвонок по сети. Во время видеосвязи необходимо, чтобы два потока данных (аудио и видео) шли синхронно. Когда к разговору двоих человек прибавится третий — получится уже конференция. Задача пятого уровня — сделать так, чтобы собеседники могли понять, кто сейчас говорит.
Шестой уровень, представления данных (presentation layer, L6)
О задачах уровня представления вновь говорит его название. Шестой уровень занимается тем, что представляет данные (которые все еще являются PDU) в понятном человеку и машине виде. Например, когда одно устройство умеет отображать текст только в кодировке ASCII, а другое только в UTF-8, перевод текста из одной кодировки в другую происходит на шестом уровне.
Шестой уровень также занимается представлением картинок (в JPEG, GIF и т.д.), а также видео-аудио (в MPEG, QuickTime). Помимо перечисленного, шестой уровень занимается шифрованием данных, когда при передаче их необходимо защитить.
Седьмой уровень, прикладной (application layer)
Седьмой уровень иногда еще называют уровень приложений, но чтобы не запутаться можно использовать оригинальное название — application layer. Прикладной уровень — это то, с чем взаимодействуют пользователи, своего рода графический интерфейс всей модели OSI, с другими он взаимодействует по минимуму.
Все услуги, получаемые седьмым уровнем от других, используются для доставки данных до пользователя. Протоколам седьмого уровня не требуется обеспечивать маршрутизацию или гарантировать доставку данных, когда об этом уже позаботились предыдущие шесть. Задача седьмого уровня — использовать свои протоколы, чтобы пользователь увидел данные в понятном ему виде.
Критика модели OSI
Семиуровневая модель была принята в качестве стандарта ISO/IEC 7498, действующего по сей день, однако, модель имеет свои недостатки. Среди основных недостатков говорят о неподходящем времени, плохой технологии, поздней имплементации, неудачной политике.
Первый недостаток — это неподходящее время. На разработку модели было потрачено неоправданно большое количество времени, но разработчики не уделили достаточное внимание существующим в то время стандартам. В связи с этим модель обвиняют в том, что она не отражает действительность. В таких утверждениях есть доля истины, ведь уже на момент появления OSI другие компании были больше готовы работать с получившей широкое распространение моделью TCP/IP.
Вторым недостатком называют плохую технологию. Как основной довод в пользу того, что OSI — это плохая технология, приводят распространенность стека TCP/IP. Протоколы OSI часто дублируют другу друга, функции распределены по уровням неравнозначно, а одни и те же задачи могут быть решены на разных уровнях.
Разделение на семь уровней было скорее политическим, чем техническим. При построении сетей в реальности редко используют уровни 5 и 6, а часто можно обойтись только первыми четырьмя. Даже изначальное описание архитектуры в распечатанном виде имеет толщину в один метр.
Кроме того, в отличие от TCP/IP, OSI никогда не ассоциировалась с UNIX. Добиться широкого распространения OSI не получилось потому, что она проектировалась как закрытая модель, продвигаемая Европейскими телекоммуникационными компаниями и правительством США. Стек протоколов TCP/IP изначально был открыт для всех, что позволило ему набрать популярность среди сторонников открытого программного кода.
Даже несмотря на то, что основные проблемы архитектуры OSI были политическими, репутация была запятнана и модель не получила распространения. Тем не менее, в сетевых технологиях, при работе с коммутацией даже сегодня обычно используют модель OSI.
Вывод, роль модели OSI при построении сетей
В статье мы рассмотрели принципы построения сетевой модели OSI. На каждом из семи уровней модели выполняется своя задача. В действительности архитектура OSI сложнее, чем мы описали. Существуют и другие уровни, например, сервисный, который встречается в интеллектуальных или сотовых сетях, или восьмой — так называют самого пользователя.
Как мы упоминали выше, оригинальное описание всех принципов построения сетей в рамках этой модели, если его распечатать, будет иметь толщину в один метр. Но компании активно используют OSI как эталон. Мы перечислили только основную структуру словами, понятными начинающим.
Модель OSI служит инструментом при диагностике сетей. Если в сети что-то не работает, то гораздо проще определить уровень, на котором произошла неполадка, чем пытаться перестроить всю сеть заново.
Зная архитектуру сети, гораздо проще ее строить и диагностировать. Как нельзя построить дом, не зная его архитектуры, так невозможно построить сеть, не зная модели OSI. При проектировании важно учитывать все. Важно учесть взаимодействие каждого уровня с другими, насколько обеспечивается безопасность, шифрование данных внутри сети, какой прирост пользователей выдержит сеть без обрушения, будет ли возможно перенести сеть на другую машину и т.д. Каждый из перечисленных критериев укладывается в функции одного из семи уровней.
Продолжающееся быстрое развитие Internet, протоколов и стандартов, связанных с Сетью, требует систематизации и упорядочения достигнутых результатов. Этой цели служат периодически обновляемые документы, издаваемые Управляющим советом по вопросам архитектуры Internet (IAB ? Internet Architecture Board).
Продолжающееся быстрое развитие Internet, протоколов и стандартов, связанных с Сетью, требует систематизации и упорядочения достигнутых результатов. Этой цели служат периодически обновляемые документы, издаваемые Управляющим советом по вопросам архитектуры Internet (IAB - Internet Architecture Board). Однако, несмотря на многообразие этих документов, ни один из них не дает достаточно полной и ясной картины о статусе выпускаемых документов и стадиях их разработки. Даже в совокупности они дают очень слабое представление о взаимоотношениях между протоколами и стандартами Internet.
- RFC Index (перечень RFC - Request for Comments) - список всех изданных RFC в порядке возрастания номеров, дополняемый по мере их появления.
- Internet official protocol standards (официальный перечень стандартов по протоколам Internet) - периодически обновляемый документ, где излагается общая характеристика процесса стандартизации в Internet, перечни вновь изданных RFC и обобщающие перечни протоколов, группируемые по стадиям стандартизации и иным признакам. Последняя версия этого документа изложена в RFC 2400.
- RFC Summary Numbers (сводный перечень номеров RFC) переиздается, начиная с номера 699, через каждые 100 номеров и содержит перечни с краткими аннотациями каждых 100 предыдущих номеров RFC.
- Assigned Numbers (присвоенные номера) - перечисляются присвоенные значения параметров, используемых в различных протоколах (например, адреса Internet, имена регионов, протокольные коды IP, номера портов TCP, коды опций Telnet, наименования типов терминалов).
| Рис. 1. Динамика разработки документов RFC |
Можно отметить, по меньшей мере, две существенные особенности документов RFC, отличающие их от нормативных документов других организаций. Во-первых, RFC охватывают самый широкий круг технических материалов, начиная от обязательных стандартов, включая предложения по стандартам, информационные сведения и кончая устаревшими документами, имеющими чисто историческую значимость.
Кроме того, RFC никогда не переиздаются и не пересматриваются с тем же номером. Пересмотренный протокол издается под другим номером, а прежние сохраняются в каталогах под прежними номерами.
- информационные (informational);
- экспериментальные (experimental);
- предложения по стандартам (proposed standards);
- проекты стандартов (draft standards);
- стандарты (standards);
- исторические (historic).
- обязательные (required);
- рекомендуемые (recommended);
- избирательного применения (elective);
- ограниченного применения (limited use);
- не рекомендуемые (not recommended).
Протоколы проходят три стадии созревания: предложение по стандарту, проект и стандарт, подвергаясь на каждой стадии тщательному анализу и тестированию. Предложение по стандарту может стать проектом только при наличии минимум двух независимых реализаций и рекомендации Инженерной группы управления Internet (IESG - Internet Engineering Steering Group). Продвижение от проекта к стандарту требует обычно эксплуатационной проверки и демонстрации взаимодействия с двумя или более реализациями и также рекомендации IESG.
От предложения до проекта стандарта минимальная задержка составляет 6 месяцев, от проекта до стандарта - 4 месяца. Фактические же задержки могут достигать нескольких лет.
Протоколы, разработанные другими организациями по стандартизации или поставщиками и представляющие информационный интерес, либо по каким то другим причинам не входящие в предмет рассмотрения IESG, помечаются как информационные. Информационные документы не имеют статуса.
Общее правило присвоения номеров STD состоит в том, что отдельный номер STD присваивается, если спецификация логически отделена от других. Такой логически отдельной опции присваивается отдельный номер, в то время как не опциональные расширения используют один и тот же номер SТD в качестве базовой спецификации. В подобных случаях документы, определяющие конкретный стандарт, должны ссылаться друг на друга.
Помимо этого протоколы (в основном экспериментальные и исторические) могут получить один из следующих статусов:
С 1995 году IAB ввоцедуре принятия предложений по стандартам. Статус этих документов определен в RFC 1818, а документы BCP имеют свою независимую нумерацию. К сегодняшнему дню разработано 25 RFC в статусе BCP, однако при формальном группировании RFC по RFC 2400 документы BCP в отдельный класс не выделяются.
| Рис. 2. Классификация протоколов Internet |
Изложенная классификация протоколов в схематическом виде представлена на рис. 2. К сожалению, фактическая классификация конкретных документов и протоколов Internet как в самом RFC 2400, так и в других перечисленных регламентирующих и обобщающих документах IAB не обладает четкостью этого рисунка и страдает иногда нелогичностью и противоречивостью.
Таблица 1. Количественное распределение протоколов
Internet по стадиям разработки
| Стадия разработки | Действующие | Устарелые | Всего |
| Стандарт | 55 | 2 | 57 |
| Проект стандарта | 65 | 21 | 86 |
| Предложение по стандарту | 374 | 78 | 452 |
| Экспериментальные | 122 | 24 | 146 |
| Лучшая современная технология | 24 | 1 | 25 |
| Информационные | 516 | 61 | 577 |
| Исторические | 49 | 51 | 100 |
| Не известна | 740 | 168 | 908 |
| Пустые номера RFC | — | — | 77 |
| ВСЕГО | 1945 | 406 | 2428 |
Анализ перечисленных документов IAB позволил выявить следующую статистику количественного распределения документов RFC и протоколов Internet по стадиям разработки.
Все документы RFC, как и протоколы Internet, можно подразделить по другому признаку еще на две группы: документы, определяющие внутреннее функционирование Internet, и документы, определяющие взаимодействие Internet с сетями других типов. При этом ко второй группе относится около 277 (из 2331) документов RFC (включая устарелые и исторические). По относительному количеству выпущенных документов попытаемся косвенно оценить заинтересованность Internet во взаимосвязи с другими сетевыми технологиями и сетевыми архитектурами.
Эта статистика не показывает, однако, динамики взаимоотношений. Так, если взаимосвязь Internet с устарелыми (ARPANET) или достаточно зрелыми, но в чем-то устаревающими системами (IPX Novell, AppleTalk), постепенно вытесняемыми самой Internet, стабилизировалась (судя по отсутствию новых RFC) в начале 80-х, то с конца 80-х началась проработка взаимосвязей с развивающимися новыми архитектурами Frame Relay, ATM, а также привлечение и освоение ресурсов, наработанных в ISO, ITU-T, что и отразилось в появлении соответствующих RFC.
C 1990 года IAB ввел новую серию документов под названием FYI (For Your Information), которые носят информационный характер и должны обеспечить пользователей Internet централизованным справочником по наиболее важным темам и обобщающим вопросам (терминология, ответы на часто задаваемые вопросы относительно Internet и т.п.). Документы FYI имеют свою независимую нумерацию, и помещаются отдельным разделом в RFC Index, но не анализируются в RFC 2300. Издано 32 документа FYI, большинство из которых имеют своими дубликатами документы RFC.
Взаимосвязи между протоколами Internet
Уровневая архитектура протоколов Internet во многом соответствует концепции семиуровневой архитектуры протоколов эталонной модели OSI. Основное различие этих двух архитектур состоит в том, что протоколы трех верхних уровней эталонной модели OSI - прикладного, представления данных и сеансового в Internet, как правило, объединяются в один уровень - прикладной. Обобщенный профиль основных прикладных и коммуникационных протоколов Internet приведен на рис. 3.
 |
| Рис. 3. Основополагающие протоколы Internet и взаимосвязи между ними |
Основными изначальными прикладными службами Internet были и остаются службы передачи файлов, электронной почты и обмена новостями, виртуальных терминалов и справочная служба. В каждой из таких областей шло постоянное развитие исходных и создание новых более эффективных протоколов, основные из которых, используемые сегодня перечислены на рисунке. Кроме того изначально применялись протоколы, выполняющие ряд вспомогательных, но повышающих эффективность работы функций - протоколы информирования о времени (TIME, NTP), получения собственных идентификаторов (BOOTP), получения информации об окружающей системе (Finger), диагностические протоколы (Echo) и др.
На прикладном уровне Internet используются также разработанные в рамках архитектуры OSI прикладные протоколы электронной почты Х.400 и справочной службы Х.500.
На уровне звена данных (канальном уровне) изначально использовался протокол SLIP, который сегодня фактически вытеснен протоколом двухпунктовых соединений PPP, поддерживающим как асинхронные (байт-ориентированные стартстопные), так и синхронные (бит-ориентированные) двунаправленные кабельные или модемные соединения. В последнее время дополнительно разработаны и успешно используются специальные стандарты для передачи IP-трафика по сетям различных архитектур, которые более полно учитывают особенности этих сетей. Кроме того на этом уровне часто используются (с применением инкапсуляции) протоколы других архитектур (Frame Relay, HDLC (в подсетях X.25), SDLC (в подсетях SNA), DDCMP (в подсетях DECNet), протоколы LAN и др.
На физическом уровне в сети Internet могут быть использованы практически все широко известные протоколы и интерфейсы физического уровня, стандартизованные ITU-T (CCITT), EIA, ISO, Frame Relay Forum, ATM Forum, протоколы и интерфейсы LAN, SDH (SONET) и др. Единственным ограничением, налагаемым протоколом РРР на физический уровень, является наличие дуплексного канала, выделенного или коммутируемого, работающего в асинхронном или синхронном последовательном режиме, прозрачном для пакетов уровня PPP. На скорости передачи данных и тип интерфейса никаких ограничений не налагается.
Стандартизация протоколов защиты информации на всех уровнях Internet пока недостаточно зрелая - сегодня по этим вопросам нет ни одного принятого стандарта. Однако проработка вопросов защиты информации ведется достаточно активно - в стадии рассмотрения находится 14 предложений по стандартам и еще большее число документов находятся в экспериментальной и информационной стадиях.
Взаимосвязь с другими сетями и архитектурами
Большие информационные и коммуникационные возможности Internet, с одной стороны, наличие современных высокоскоростных сетевых технологий, а также прикладных программ других сетевых архитектур с более широкими и гибкими возможностями, с другой стороны, приводят к общей практической заинтересованности во взаимном обогащении прикладных и коммуникационных ресурсов различных сетей.
Как уже отмечалось, вопросам взаимодействия Internet с другими сетями посвящено 290 документов RFC, отражающих используемые на практике конфигурации взаимодействия. Основные из таких конфигураций отражены на рис. 4, где указаны также соответствующие документы RFC, определяющие взаимодействие протоколов Internet с другими протоколами.
Можно выделить два основных подхода к взаимодействию Internet с другими сетевыми архитектурами и сетевыми технологиями.
- Использование на нижних уровнях Internet современных высокоскоростных протоколов типа типа FDDI, Fast Ethernet, Frame Relay, ATM и др., повышающее эффективность работы прикладных протоколов Internet.
- Использование более эффективных прикладных программ других сетевых архитектур (типа OSI, SNA) для работы по практически апробированным, достаточно зрелым и широко распространенным коммуникационным протоколам Internet.
Метод инкапсуляции протоколов определен в рекомендациях ITU-T I.363, I.365, Q.2119, стандартах ANSI T1.617a, Frame Relay Forum FRF.3.1 и в RFC 1490. На рис. 4 взаимодействие различных протоколов методом инкапсуляции изображено стрелками.
Метод преобразования услуг использован в показанном на рис. 4 взаимодействии протоколов Internet с прикладными протоколами OSI. В RFC 1006 (стандарт STD 35) определен механизм, позволяющий протоколу транспортного уровня ТР 0 (простой класс) по ISO/IEC 8073 (и, следовательно, любым прикладным программам OSI, работающим по ТР 0) функционировать над протоколом TCP Internet при использовании услуг протокола IP. В результате логические объекты всех верхних уровней OSI (прикладного, представления данных и сеансового) могут функционировать нормально, не ощущая того, что все они работают по TCP/IP.
Протокол по RFC 1006/2126 и ISO/IEC 14766 преобразует услуги протокола TCP Internet в стандартные по ISO/IEC 8348 услуги сетевого уровня OSI в режиме с установлением соединения (CONS), которые затем используются протоколом TP 0 или TP 2 по ISO/IEC 8073. Кроме того указанный протокол инкапсулирует протокольные блоки ISO/IEC 8073 в пакеты протокола ТСР. При этом все основные аспекты услуг транспортного уровня по ISO/IEC 8072 сохраняются, за исключением параметра качества услуг.
 |
| Рис. 4. Взаимосвязь протоколов Internet с протоколами других сетевых архитектур и технологий |
Наряду с широко известными сетевыми архитектурами и сетевыми технологиями OSI, X.25, ISDN, Frame Relay, ATM, SDH/SONET, а также стандартными технологиями локальных сетей семейства IEEE 802 (Ethernet, Token Ring, FDDI) на рис. 4 изображены взаимосвязи Internet с другими менее известными технологиями.
Поскольку служба NetBIOS сконструирована на основе различных протоколов и различного оборудования, то для обеспечения взаимодействия NetBIOS в Internet RFC 1001 и 1002 определили стандартный протокол для функционирования прикладных программ NetBIOS над протоколами TCP и UDP. Кроме того, поскольку для выполнения некоторых приложений NetBIOS типа серверов файлов ПК не подходят, то RFC 1001 и 1002 определили возможность построения реализаций на системах любого типа, где имеется комплект протоколов TCP/IP.
С другой стороны, RFC 1088 определил стандартный метод инкапсуляции датаграмм протокола IP в датаграммы NetBIOS с тем, чтобы обеспечить возможность работы в компьютерах сети NetBIOS прикладных программ Internet, работающих над IP. Кроме того определено преобразование 4-байтовых адресов IP в 16-байтовые имена NetBIOS. Использование маршрутизаторов, способных инкапсулировать пакеты IP в обычные протоколы уровня звена данных (типа протоколов локальных сетей), а также в датаграммы NetBIOS, позволяют компьютерам NetBIOS взаимодействовать со всей Internet.
Протокол PPP обеспечивает стандартный метод транспортирования многопротокольных датаграмм по двухпунктовым каналам. PPP определяет расширяемый Link Control Protocol и поддерживает семейство различных протоколов сетевого уровня NCP (Network Control Protocols). RFC 2097 определил один из протоколов NCP, поддерживаемых PPP, для функционирования протокола сетевого уровня NBFCP сети NetBIOS над PPP.
Высокопроизводительный параллельный интерфейс HIPPI, разработанный в конце 80-х - начале 90-х рабочей группой ANSI X3T9.3 HIPPI, представляет собой простой канал данных. Пара таких каналов обеспечивает одновременный прием и передачу данных на скорости 800 Мбит/с и факультативно 1600 Мбит/с.
Документы RFC Index:
Следует учесть, что содержимое RFC Index по всем указанным адресам не идентичное. Если, например, по первому из адресов RFC Index содержит только перечень номеров RFC (без названий документов), форматы RFC (указываемые расширением имени файла) и емкость электронной версии документа в Кбайт, то по последнему из перечисленных адресов содержится наиболее подробный RFC Index с указанием дополнительно наименования документа, фамилий авторов, даты издания, устарелых или обновляемых версий документа и стадии разработки протокола.
Читайте также: