OSI и ее протоколы
Наверное, многие из читателей слышали про так называемую сетевую модель OSI. В рамках данной статьи я постараюсь, насколько это возможно, простым языком рассказать про эту самую OSI, а также про особенности протоколов, связанных с данной моделью.
Сетевая модель OSI (от англ. Open Systems Interconnection Reference Model — модель взаимодействия открытых систем) представляет собой абстрактную модель сетевых коммуникаций и взаимодействия сетевых протоколов. Модель состоит из уровней, каждый из которых обслуживает свою зону процесса взаимодействия. Именно благодаря настоящей модели совместная работа сетевого оборудования и программного обеспечения становится гораздо проще и понятнее. Семиуровневая модель OSI является теоретической и содержит ряд недоработок. Реальные сетевые протоколы вынуждены отклоняться от нее, обеспечивая непредусмотренные возможности, поэтому привязка некоторых из них к уровням OSI является чисто условной. Основная недоработка OSI — непродуманный транспортный уровень. На нем OSI позволяет обмен данными между приложениями (вводя понятие порта — идентификатора приложения), однако возможность обмена простыми датаграммами в OSI не предусмотрена — транспортный уровень должен образовывать соединения, обеспечивать доставку, управлять потоком и т.п. Реальные же протоколы реализуют такую возможность. За все время существования модели OSI она так и не была реализована на все 100%, что, по-видимому, обусловлено ее сложностью и громоздкостью. В настоящее время используется лишь некоторая часть модели OSI.
Немного истории
В 1978 году Международный комитет по стандартизации (ISO) разработал стандарт архитектуры ISO 7498 для объединения различных сетей. В разработке участвовало 7 комитетов, каждый из которых разрабатывал свой уровень. В 1980 году IEEE опубликовал спецификацию 802, детально описавшую механизмы взаимодействия физических устройств на канальном и физическом уровнях модели OSI. Уже в 1984 году спецификация модели OSI была пересмотрена и принята в качестве международного стандарта для сетевых коммуникаций. Настоящая модель состоит, как мы уже говорили, из семи уровней, иерархически расположенных друг над другом. Каждый из уровней может взаимодействовать только с ближайшим и выполнять свойственные ему функции:
Итак, начнем по-порядку:
Прикладной уровень (Application layer) представляет собой самый верхний — седьмой — уровень модели, обеспечивающий взаимодействие сети и пользователя. Уровень разрешает (или не разрешает) приложениям пользователя доступ к сетевым службам — таким, как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты и т.д. Данный уровень также отвечает за передачу служебной информации, предоставляет приложениям и пользователю информацию об ошибках и формирует запросы к уровню представления.
Уровень представления (Presentation layer) отвечает за преобразование протоколов и кодирование/декодирование данных. Запросы приложений, полученные с уровня приложений, он преобразует в формат для передачи по сети, а полученные из сети данные — в формат, понятный приложениям. На этом уровне может осуществляться компрессия/декомпрессия или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально.
Сеансовый уровень (Session layer) отвечает за поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием и завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды, когда приложение неактивно. Синхронизация передачи обеспечивается помещением в поток данных так называемых контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия.
Транспортный уровень (Transport layer), он же 4-й уровень модели, предназначен для доставки данных без ошибок, потерь и дублирования в той последовательности, в которой они были переданы. При этом неважно, какие данные передаются, откуда и куда, то есть он предоставляет сам механизм передачи. Блоки данных он разделяет на фрагменты, размер которых зависит от протокола, короткие объединяет в один, длинные разбивает. Протоколы этого уровня предназначены для взаимодействия типа точка-точка.
Сетевой уровень (Network layer) — 3-й уровень сетевой модели OSI — предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имен в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию пакетов, отслеживание неполадок и заторов в сети. На этом уровне работает такое сетевое устройство, как маршрутизатор.
Канальный уровень (Data Link layer) предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля над ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает в кадры данных, проверяет на целостность, если нужно, исправляет ошибки и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием. Спецификация IEEE 802 разделяет этот уровень на 2 подуровня — MAC (Media Access Control) регулирует доступ к разделяемой физической среде, LLC (Logical Link Control) обеспечивает обслуживание сетевого уровня. На этом уровне работают коммутаторы, мосты и сетевые адаптеры. В контексте программирования этот уровень представляет собой драйвер сетевой платы. В операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровня между собой — это не новый уровень, а просто реализация модели для конкретной ОС. Примеры таких интерфейсов: ODI, NDIS.
Физический уровень (Physical layer) — самый нижний уровень модели — предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель и, соответственно, их прием и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Другими словами, осуществляет интерфейс между сетевым носителем и сетевым устройством. На этом уровне работают концентраторы и повторители (ретрансляторы) сигнала.
Теперь давайте рассмотрим каждый уровень и ассоциированные с ним протоколы подробней.
Прикладной уровень (Application layer)
Начнем, пожалуй, с самого известного и всеми нами любимого потокола http, являющегося протоколом прикладного уровня. HTTP (от англ. HyperText Transfer Protocol — "протокол передачи гипертекста") — это сетевой протокол прикладного уровня для передачи файлов. В стеке TCP/IP для HTTP зарезервированы порты 80 транспортных протоколов TCP и UDP (практически используется только TCP). Основной функцией HTTP является передача гипертекстовых страниц, хотя с помощью него с успехом передаются и другие файлы, как связанные с веб-страницами (изображения и приложения), так и не связанные с ними (аналогия с FTP). HTTP предусматривает взаимодействие клиентской программы (веб-браузера) с софтом, находящимся на сервере и обслуживающим соответствующую web-страницу.
Немного истории
HTTP как протокол был предложен в марте 1990 года Тимом Бернерсом-Ли (которого по праву можно назвать отцом современного Интернета), работавшим тогда в CERN, как механизм доступа к документам в сети Интернет и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола — HTTP/0.9 — была впервые опубликована в январе 1992-го. Спецификация протокола привела к созданию четких правил взаимодействия между клиентами и серверами HTTP, а также четкому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения. В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, что послужило основой для реализации большинства компонентов HTTP/1.0. В июне 1999-го была принята последняя версия протокола HTTP/1.1. Новшеством данной версии можно считать режим "постоянного соединения": TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможным более простую организацию виртуального хостинга.
Структура протокола
Подобно FTP или SMTP, HTTP-протокол — это протокол прикладного уровня. Обмен сообщениями осуществляется по схеме "запрос-ответ". Для идентификации ресурсов HTTP использует глобальные URI. Следует отметить, что, в отличие от многих других протоколов, HTTP не сохраняет своего состояния. А это означает отсутствие сохранения промежуточного состояния сеансов "запрос-ответ". Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов.
Каждый запрос/ответ состоит из трех частей:
. стартовая строка;
. заголовки;
. тело сообщения, содержащее различные данные запроса.
Строка запроса имеет такой вид:
‹Метод›* ‹URI› HTTP/‹Версия›
*Вместо "метод" подставляется:
GET — запрашивает содержимое указанного ресурса.
HEAD — аналогичен методу GET за исключением того, что в ответе сервера отсутствует тело. Это полезно для извлечения метаинформации, заданной в заголовках ответа без пересылки всего содержимого.
POST — передает пользовательские данные (например, из формы HTML) заданному ресурсу. Данные включаются в тело запроса.
PUT — загружает указанный ресурс на сервер.
DELETE — удаляет указанный ресурс.
TRACE — возвращает полученный запрос так, что клиент может увидеть, что промежуточные серверы добавляют к запросу или изменяют его. CONNECT — для использования вместе с прокси-серверами, которые могут динамически переключаться в туннельный режим SSL.
В большинстве случаев используются преимущественно GET- и POST-методы. Как вы уже, наверное, догадались, основное различие этих методов в том, что в методе GET данные запроса внедряются в URL-строку ресурса (после вопросительного знака, например:
httр://server/document.html?param=value), а в методе POST они посылаются в теле сообщения.
Строка ответа имеет такой вид:
HTTP/‹Версия› ‹Код статуса›* ‹Описание статуса›
*В качестве кода статуса может быть:
"200 OK" — запрос выполнен успешно;
"404 Not Found" — запрошенный ресурс не найден.
"403 Forbidden" — доступ к запрошенному ресурсу запрещен;
Заголовки HTTP — это строки, каждая из которых состоит из имени параметра, за которым следует двоеточие и его значение. Они несут
информацию для браузера или для серверных программ (таких, как CGI-приложения):
Запрос:
GET /wiki/HTTP HTTP/1.1
Host: ru.wikipedia.org
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Connection: close
Ответ:
HTTP/1.0 200 OK
Server: Apache
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Здесь можно найти текст запрошенной страницы:
…
…
FTP
File Transfer Protocol (букв. "протокол передачи файлов"), или просто FTP сетевой протокол семейства TCP/IP, предназначенный для передачи файлов в компьютерных сетях. Протокол FTP позволяет подключаться к серверам FTP, просматривать содержимое каталогов и загружать файлы с сервера или на сервер, кроме того, возможен режим передачи файлов между серверами. FTP является одним из старейших прикладных протоколов, появившимся задолго до HTTP. Датой его рождения можно считать 1971 год. До начала 90-х годов на долю FTP приходилось около половины трафика в сети Интернет. И по сей день данный протокол не утратил своей популярности и широко используется для закачки файлов.
Команды FTP:
. open имя_сервера (можно просто "о") — открыть соединение — открывает соединение с сервером. Это имя можно указать сразу при вводе команды, загружающей клиента.
. cd имя_директории — осуществляет переход в другой рабочий каталог на FTP-сервере.
. dir [имя_файла] — выдает список файлов в текущей директории. Если вам интересен формат списка каталога, нажмите здесь. Не забывайте, что можно использовать шаблоны групповых операций.
. get имя_файла [имя_локального_файла] — переписывает файл с удаленного компьютера на локальный. Если указано имя локального файла, то записывает его под этим именем, иначе — в каталог по умолчанию.
. mget [имя_файла] — переписать группу файлов — то же самое, что и get, но разрешается использовать шаблоны. Перед копированием каждого файла будет запрашиваться подтверждение. Для отмены подтверждений введите prompt.
. prompt — отменяет подтверждение в командах mget и mput.
. put имя_файла [имя_удаленного_файла] — переписывает файл с локального компьютера на удаленный под именем имя_удаленного_файла. Если оно не указано, то файл записывается в текущий каталог с именем локального файла. Команда запрещена для анонимных пользователей.
. mput [имя_файла] — записать группу файлов. То же самое, что и put, но разрешается использовать шаблоны. Перед записью каждого файла будет запрашиваться подтверждение. Для отмены подтверждений введите prompt.
. ascii — устанавливает ascii-способ передачи файлов. Используется для пересылки файлов-текстов на английском языке. Однако для
надежности лучше использовать binary.
. binary — устанавливает двоичный способ пересылки файлов. При этом файл при передаче не перекодируется и записывается в неизмененном виде. Это наиболее надежный способ передачи файлов.
. close — закрывает соединение с данным сервером и производит возврат в командный режим. Эта команда автоматически выполняется при
выходе из FTP-клиента.
. quit — выход из FTP-клиента.
. user — регистрирует на текущем сервере с новым именем. Используйте эту команду, если первый раз по ошибке неправильно ввели имя
анонимного пользователя и не хотите снова перенабирать команду open.
. lcd [имя_директории] — осуществляет переход на локальном компьютере в указанный каталог.
. pwd — выводит на экран текущий каталог на удаленном компьютере.
. system — выводит на экран тип операционной системы на удаленном компьютере.
. help [FTP-команда] — выдает краткую информацию о командах FTP-клиента или конкретной указанной команде.
Протокол не шифруется, и поэтому при аутентификации логин и пароль передаются по сети в открытом виде. Перехват пароля в данном случае возможен посредством сетевого сниффера. Это обстоятельство необходимо учитывать, особенно если потенциальный злонамеренный пользователь находится в одном сегменте сети с пользователем FTP. Подобные шпионские штучки и "вынюхивание" аутентификационных данных можно предотвратить, например, путем использования протокола SSL.
SNMP
SNMP (англ. Simple Network Management Protocol — простой протокол управления сетью) — представляет собой протокол управления сетями связи на основе архитектуры TCP/IP. Это протокол прикладного уровня для стека TCP/IP (есть реализации для других стеков — IPX/SPX). SNMP широко используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в специальной базе данных — т.н. MIB (Management Information Base). SNMP призван обеспечить управление и контроль устройств и приложений в сети связи путем обмена управляющей информацией между агентами, располагающимися на сетевых устройствах, и менеджерами, расположенными на станциях управления. В настоящее время SNMP является базовым протоколом управления сети Internet. SNMP определяет сеть как совокупность сетевых управляющих станций и элементов сети (главные машины, шлюзы и маршрутизаторы, терминальные серверы), которые совместно обеспечивают административные связи между сетевыми управляющими станциями и сетевыми агентами. SNMP различных версий посвящен целый ряд рекомендаций проблемной группы проектирования Internet (RFC).
SNMP — это протокол типа запрос/ответ: на каждый запрос, поступивший от менеджера, агент должен передать ответ. SNMP включает в себя всего несколько команд:
Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.
Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.
С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.
Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие — отключить порт, приписать порт определенной VLAN и т.п.
Команда Set также используется для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.
Команда Trap используется агентом для сообщения менеджеру о возникновении особой ситуации.
Вышеописанное можно представить лучше, если обратиться к рисунку.
Процедурная характеристика протокола SNMP
Заканчивая разговор об SNMP, резонно упомянуть о том, что протокол имеет существенные недостатки: работа через UDP-протокол приводит к частым потерям аварийных сообщений (trap) от агентов к менеджерам, результатом чего может стать неадекватное управление.
Продолжение следует
Олег Бойцев, Boyscout_zone@mail.ru
Сетевая модель OSI (от англ. Open Systems Interconnection Reference Model — модель взаимодействия открытых систем) представляет собой абстрактную модель сетевых коммуникаций и взаимодействия сетевых протоколов. Модель состоит из уровней, каждый из которых обслуживает свою зону процесса взаимодействия. Именно благодаря настоящей модели совместная работа сетевого оборудования и программного обеспечения становится гораздо проще и понятнее. Семиуровневая модель OSI является теоретической и содержит ряд недоработок. Реальные сетевые протоколы вынуждены отклоняться от нее, обеспечивая непредусмотренные возможности, поэтому привязка некоторых из них к уровням OSI является чисто условной. Основная недоработка OSI — непродуманный транспортный уровень. На нем OSI позволяет обмен данными между приложениями (вводя понятие порта — идентификатора приложения), однако возможность обмена простыми датаграммами в OSI не предусмотрена — транспортный уровень должен образовывать соединения, обеспечивать доставку, управлять потоком и т.п. Реальные же протоколы реализуют такую возможность. За все время существования модели OSI она так и не была реализована на все 100%, что, по-видимому, обусловлено ее сложностью и громоздкостью. В настоящее время используется лишь некоторая часть модели OSI.
Немного истории
Итак, начнем по-порядку:
Прикладной уровень (Application layer) представляет собой самый верхний — седьмой — уровень модели, обеспечивающий взаимодействие сети и пользователя. Уровень разрешает (или не разрешает) приложениям пользователя доступ к сетевым службам — таким, как обработчик запросов к базам данных, доступ к файлам, пересылке электронной почты и т.д. Данный уровень также отвечает за передачу служебной информации, предоставляет приложениям и пользователю информацию об ошибках и формирует запросы к уровню представления.
Уровень представления (Presentation layer) отвечает за преобразование протоколов и кодирование/декодирование данных. Запросы приложений, полученные с уровня приложений, он преобразует в формат для передачи по сети, а полученные из сети данные — в формат, понятный приложениям. На этом уровне может осуществляться компрессия/декомпрессия или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально.
Сеансовый уровень (Session layer) отвечает за поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием и завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды, когда приложение неактивно. Синхронизация передачи обеспечивается помещением в поток данных так называемых контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия.
Транспортный уровень (Transport layer), он же 4-й уровень модели, предназначен для доставки данных без ошибок, потерь и дублирования в той последовательности, в которой они были переданы. При этом неважно, какие данные передаются, откуда и куда, то есть он предоставляет сам механизм передачи. Блоки данных он разделяет на фрагменты, размер которых зависит от протокола, короткие объединяет в один, длинные разбивает. Протоколы этого уровня предназначены для взаимодействия типа точка-точка.
Сетевой уровень (Network layer) — 3-й уровень сетевой модели OSI — предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имен в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию пакетов, отслеживание неполадок и заторов в сети. На этом уровне работает такое сетевое устройство, как маршрутизатор.
Канальный уровень (Data Link layer) предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля над ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает в кадры данных, проверяет на целостность, если нужно, исправляет ошибки и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием. Спецификация IEEE 802 разделяет этот уровень на 2 подуровня — MAC (Media Access Control) регулирует доступ к разделяемой физической среде, LLC (Logical Link Control) обеспечивает обслуживание сетевого уровня. На этом уровне работают коммутаторы, мосты и сетевые адаптеры. В контексте программирования этот уровень представляет собой драйвер сетевой платы. В операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровня между собой — это не новый уровень, а просто реализация модели для конкретной ОС. Примеры таких интерфейсов: ODI, NDIS.
Физический уровень (Physical layer) — самый нижний уровень модели — предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель и, соответственно, их прием и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Другими словами, осуществляет интерфейс между сетевым носителем и сетевым устройством. На этом уровне работают концентраторы и повторители (ретрансляторы) сигнала.
Теперь давайте рассмотрим каждый уровень и ассоциированные с ним протоколы подробней.
Прикладной уровень (Application layer)
Начнем, пожалуй, с самого известного и всеми нами любимого потокола http, являющегося протоколом прикладного уровня. HTTP (от англ. HyperText Transfer Protocol — "протокол передачи гипертекста") — это сетевой протокол прикладного уровня для передачи файлов. В стеке TCP/IP для HTTP зарезервированы порты 80 транспортных протоколов TCP и UDP (практически используется только TCP). Основной функцией HTTP является передача гипертекстовых страниц, хотя с помощью него с успехом передаются и другие файлы, как связанные с веб-страницами (изображения и приложения), так и не связанные с ними (аналогия с FTP). HTTP предусматривает взаимодействие клиентской программы (веб-браузера) с софтом, находящимся на сервере и обслуживающим соответствующую web-страницу.
Немного истории
HTTP как протокол был предложен в марте 1990 года Тимом Бернерсом-Ли (которого по праву можно назвать отцом современного Интернета), работавшим тогда в CERN, как механизм доступа к документам в сети Интернет и облегчения навигации посредством использования гипертекста. Самая ранняя версия протокола — HTTP/0.9 — была впервые опубликована в январе 1992-го. Спецификация протокола привела к созданию четких правил взаимодействия между клиентами и серверами HTTP, а также четкому разделению функций между этими двумя компонентами. Были задокументированы основные синтаксические и семантические положения. В мае 1996 года для практической реализации HTTP был выпущен информационный документ RFC 1945, что послужило основой для реализации большинства компонентов HTTP/1.0. В июне 1999-го была принята последняя версия протокола HTTP/1.1. Новшеством данной версии можно считать режим "постоянного соединения": TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможным более простую организацию виртуального хостинга.
Структура протокола
Подобно FTP или SMTP, HTTP-протокол — это протокол прикладного уровня. Обмен сообщениями осуществляется по схеме "запрос-ответ". Для идентификации ресурсов HTTP использует глобальные URI. Следует отметить, что, в отличие от многих других протоколов, HTTP не сохраняет своего состояния. А это означает отсутствие сохранения промежуточного состояния сеансов "запрос-ответ". Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов.
Каждый запрос/ответ состоит из трех частей:
. стартовая строка;
. заголовки;
. тело сообщения, содержащее различные данные запроса.
Строка запроса имеет такой вид:
‹Метод›* ‹URI› HTTP/‹Версия›
*Вместо "метод" подставляется:
GET — запрашивает содержимое указанного ресурса.
HEAD — аналогичен методу GET за исключением того, что в ответе сервера отсутствует тело. Это полезно для извлечения метаинформации, заданной в заголовках ответа без пересылки всего содержимого.
POST — передает пользовательские данные (например, из формы HTML) заданному ресурсу. Данные включаются в тело запроса.
PUT — загружает указанный ресурс на сервер.
DELETE — удаляет указанный ресурс.
TRACE — возвращает полученный запрос так, что клиент может увидеть, что промежуточные серверы добавляют к запросу или изменяют его. CONNECT — для использования вместе с прокси-серверами, которые могут динамически переключаться в туннельный режим SSL.
В большинстве случаев используются преимущественно GET- и POST-методы. Как вы уже, наверное, догадались, основное различие этих методов в том, что в методе GET данные запроса внедряются в URL-строку ресурса (после вопросительного знака, например:
httр://server/document.html?param=value), а в методе POST они посылаются в теле сообщения.
Строка ответа имеет такой вид:
HTTP/‹Версия› ‹Код статуса›* ‹Описание статуса›
*В качестве кода статуса может быть:
"200 OK" — запрос выполнен успешно;
"404 Not Found" — запрошенный ресурс не найден.
"403 Forbidden" — доступ к запрошенному ресурсу запрещен;
Заголовки HTTP — это строки, каждая из которых состоит из имени параметра, за которым следует двоеточие и его значение. Они несут
информацию для браузера или для серверных программ (таких, как CGI-приложения):
Запрос:
GET /wiki/HTTP HTTP/1.1
Host: ru.wikipedia.org
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Connection: close
Ответ:
HTTP/1.0 200 OK
Server: Apache
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Здесь можно найти текст запрошенной страницы:
…
…
FTP
Команды FTP:
. open имя_сервера (можно просто "о") — открыть соединение — открывает соединение с сервером. Это имя можно указать сразу при вводе команды, загружающей клиента.
. cd имя_директории — осуществляет переход в другой рабочий каталог на FTP-сервере.
. dir [имя_файла] — выдает список файлов в текущей директории. Если вам интересен формат списка каталога, нажмите здесь. Не забывайте, что можно использовать шаблоны групповых операций.
. get имя_файла [имя_локального_файла] — переписывает файл с удаленного компьютера на локальный. Если указано имя локального файла, то записывает его под этим именем, иначе — в каталог по умолчанию.
. mget [имя_файла] — переписать группу файлов — то же самое, что и get, но разрешается использовать шаблоны. Перед копированием каждого файла будет запрашиваться подтверждение. Для отмены подтверждений введите prompt.
. prompt — отменяет подтверждение в командах mget и mput.
. put имя_файла [имя_удаленного_файла] — переписывает файл с локального компьютера на удаленный под именем имя_удаленного_файла. Если оно не указано, то файл записывается в текущий каталог с именем локального файла. Команда запрещена для анонимных пользователей.
. mput [имя_файла] — записать группу файлов. То же самое, что и put, но разрешается использовать шаблоны. Перед записью каждого файла будет запрашиваться подтверждение. Для отмены подтверждений введите prompt.
. ascii — устанавливает ascii-способ передачи файлов. Используется для пересылки файлов-текстов на английском языке. Однако для
надежности лучше использовать binary.
. binary — устанавливает двоичный способ пересылки файлов. При этом файл при передаче не перекодируется и записывается в неизмененном виде. Это наиболее надежный способ передачи файлов.
. close — закрывает соединение с данным сервером и производит возврат в командный режим. Эта команда автоматически выполняется при
выходе из FTP-клиента.
. quit — выход из FTP-клиента.
. user — регистрирует на текущем сервере с новым именем. Используйте эту команду, если первый раз по ошибке неправильно ввели имя
анонимного пользователя и не хотите снова перенабирать команду open.
. lcd [имя_директории] — осуществляет переход на локальном компьютере в указанный каталог.
. pwd — выводит на экран текущий каталог на удаленном компьютере.
. system — выводит на экран тип операционной системы на удаленном компьютере.
. help [FTP-команда] — выдает краткую информацию о командах FTP-клиента или конкретной указанной команде.
Протокол не шифруется, и поэтому при аутентификации логин и пароль передаются по сети в открытом виде. Перехват пароля в данном случае возможен посредством сетевого сниффера. Это обстоятельство необходимо учитывать, особенно если потенциальный злонамеренный пользователь находится в одном сегменте сети с пользователем FTP. Подобные шпионские штучки и "вынюхивание" аутентификационных данных можно предотвратить, например, путем использования протокола SSL.
SNMP
SNMP (англ. Simple Network Management Protocol — простой протокол управления сетью) — представляет собой протокол управления сетями связи на основе архитектуры TCP/IP. Это протокол прикладного уровня для стека TCP/IP (есть реализации для других стеков — IPX/SPX). SNMP широко используется для получения от сетевых устройств информации об их статусе, производительности и других характеристиках, которые хранятся в специальной базе данных — т.н. MIB (Management Information Base). SNMP призван обеспечить управление и контроль устройств и приложений в сети связи путем обмена управляющей информацией между агентами, располагающимися на сетевых устройствах, и менеджерами, расположенными на станциях управления. В настоящее время SNMP является базовым протоколом управления сети Internet. SNMP определяет сеть как совокупность сетевых управляющих станций и элементов сети (главные машины, шлюзы и маршрутизаторы, терминальные серверы), которые совместно обеспечивают административные связи между сетевыми управляющими станциями и сетевыми агентами. SNMP различных версий посвящен целый ряд рекомендаций проблемной группы проектирования Internet (RFC).
SNMP — это протокол типа запрос/ответ: на каждый запрос, поступивший от менеджера, агент должен передать ответ. SNMP включает в себя всего несколько команд:
Команда Get-request используется менеджером для получения от агента значения какого-либо объекта по его имени.
Команда GetNext-request используется менеджером для извлечения значения следующего объекта (без указания его имени) при последовательном просмотре таблицы объектов.
С помощью команды Get-response агент SNMP передает менеджеру ответ на команды Get-request или GetNext-request.
Команда Set используется менеджером для изменения значения какого-либо объекта. С помощью команды Set происходит собственно управление устройством. Агент должен понимать смысл значений объекта, который используется для управления устройством, и на основании этих значений выполнять реальное управляющее воздействие — отключить порт, приписать порт определенной VLAN и т.п.
Команда Set также используется для установки условия, при выполнении которого агент SNMP должен послать менеджеру соответствующее сообщение. Может быть определена реакция на такие события, как инициализация агента, рестарт агента, обрыв связи, восстановление связи, неверная аутентификация и потеря ближайшего маршрутизатора. Если происходит любое из этих событий, то агент инициализирует прерывание.
Вышеописанное можно представить лучше, если обратиться к рисунку.
Процедурная характеристика протокола SNMP
Заканчивая разговор об SNMP, резонно упомянуть о том, что протокол имеет существенные недостатки: работа через UDP-протокол приводит к частым потерям аварийных сообщений (trap) от агентов к менеджерам, результатом чего может стать неадекватное управление.
Продолжение следует
Олег Бойцев, Boyscout_zone@mail.ru
Компьютерная газета. Статья была опубликована в номере 05 за 2007 год в рубрике безопасность
