Реферат: Протоколы прикладного уровня
Министерство образования Российской Федерации
Санкт-Петербургский государственный электротехнический университет
Кафедра МО ЭВМ
Протоколы прикладного уровня
Выполнили: Рогозина О. Н., 4351
Строкина Н.В., 4305
Факультет КТИ
Преподаватель: Яновский В.В.
Санкт-Петербург
Содержание.
1. Введение………………………………………………………………………………………….2
2. Общие принципы организации и функционирования прикладного уровня (OSI)………….2
3. Протоколы прикладного уровня OSI………………………………………………………...…4
4. Протоколы прикладного уровня NetWare……………………………………………………...5
5. Прикладной уровень TCP/IP…………………………………………………………………….7
6. Протоколы прикладного уровня TCP/IP………………………………………………………..8
6.1. Протоколы управления терминалами (TELNET, SSH)……………………………..8
6.2. Протоколы управления файлами (HTTP, IPP, FTP)………………………………..10
6.3. Протоколы управления сетью (SNMP, DNS)……………………………………….14
6.4. Протоколы организации электронной почты
(SMTP, POP3, IMAP4)…………...18
6.5. Протоколы организации обмена сообщениями (NNTP, IRC)…………………..….23
7. Заключение ………………………………………………………………………………………24
8. Список литературы ……………………………………………………………………………..25
1. Введение
Для человека, пользующегося Интернетом каждый день, просмотр веб-страниц или чтение почты не требуют огромных усилий или специального образования. Можно и не подозревать, что каждый щелчок мыши или нажатие кнопки порождает множество разнообразных процессов, связанных друг с другом, иногда конфликтующих и борющихся за ресурсы. От глаз пользователя все это хитрое взаимодействие скрыто, доступен лишь конечный результат. Чтобы понять, как на самом деле происходит то, что предстает перед нами в виде цепочки тривиальных действий, рассмотрим организацию прикладного уровня и его протоколов.
^ 2. Общие принципы организации и функционирования прикладного уровня (OSI)
Прикладной уровень является наивысшим уровнем в эталонной модели OSI RM и единственным средством доступа прикладных процессов к функциональной среде OSIE. На рисунке 1 изображено взаимодействие прикладных процессов
^ Рис.1 Взаимодействие прикладных процессов.
Прикладная сущность (application-entity - AE): совокупность функций прикладного процесса, непосредственно связанных с обеспечением его взаимодействия с другими прикладными процессами.
^ Активация прикладной сущности или AE-активация (AE-invocation): конкретное использование некоторой части функциональных возможностей некоторой прикладной сущности, осуществляющей поддержку функций взаимосвязи, реализуемых некоторой активацией прикладного процесса.
Совокупность средств, с помощью которых выполняются все элементы взаимодействия процессов, называется прикладной ассоциацией (Application Association).
Примерами таких элементов взаимодействия являются:
- идентификация и аутентификация прикладных процессов,
- согласование и установления прикладного контекста взаимосвязи,
- обмен прикладными блоками данных,
- управление режимами взаимосвязи,
- прекращение взаимосвязи ...
Взаимодействие прикладных процессов (рис. 2) осуществляется посредством обмена прикладными протокольными блоками данных (Application Protocol Data Unit - APDU).
Протокольные блоки данных
Протокольные блоки данных
Протокольные блоки данных
^ Рис.2 Взаимодействие прикладных процессов.
Прикладной сервисный элемент (application-service-element - ASE): набор прикладных функций, обеспечивающих узкоспециализированную форму сетевого взаимодействия активаций прикладных сущностей; прикладной сервисный элемент является компонентой прикладных сервисный объектов и сущностей (функциональным модулем), реализующей конкретный протокол прикладного уровня.
Различаются две категории прикладных сервисных элементов:
- общие;
- специальные.
^ Общие прикладные сервисные элементы (Common Application Service Elements - CASE) обеспечивают услуги общесистемного характера, которые обычно используются большинством прикладных процессов.
^ Специальные элементы прикладных услуг (Special Application Service Elements - SASE) ориентированы на удовлетворение требований узкоспециализированных применений.
Общие прикладные сервисные элементы
Сервисный элемент управления ассоциацией (Association control service element – ACSE) [X.217, X.227].
-Сервисный элемент надежной передачи (Reliable transfer service element – RTSE)
[X.218, X.228].
-Сервисный элемент удаленной операции (Remote operations service element – ROSE)
[X.219, X.229, X.881, X.882].
-Сервисный элемент фиксации, параллельности и восстановления
(Commitment, Concurrency and Recovery service element - CCRSE) [X.852].
^ Специальные элементы прикладных услуг
-Сервисный элемент передачи и управления файлами
(File Transfer, Access and Management – FTAM) [ISO/IEC 8571:1989].
-Сервисный элемент передачи и управления заданиями
(Job Transfer and Management – JTM) [ISO/IEC 8831].
-Сервисный элемент виртуального терминала
(Virtual Terminal Service, Basic Class) [ISO/IEC 9040].
-Сервисный элемент удаленного доступа к базам данных
(Remote Database Access - RDA) [ISO/IEC 9579-1, ISO/IEC 9579-2].
-Сервисный элемент распределенной обработки
(Distributed Transaction Processing - TP) [X.861].
-Сервисный элемент сетевого управления
(Common management information service) [X.710].
Для иллюстрации организации работы прикладного уровня рассмотрим простой пример, в котором для программы (program) пользователя (user) реализуется возможность доступа к сервису простой электронной почты, т.е. через свою программу пользователь может готовить и пересылать сообщения другому удаленному пользователю, используя специальный прикладной сервисный элемент системы обработки сообщений MHS (Message Handling System).
Организация вычислительного процесса для данного приложения показана на рис. 3.
Прикладной процесс (Application Process) программы пользователя в данном примере состоит из прикладной сущности (Application Entity), ответственной за реализацию функций взаимосвязи с другими пользователями, и из компоненты, реализующей взаимосвязь прикладного сервисного элемента с локальными ресурсами реальной открытой системы и называемой часто прикладным агентом (Application Agent).
После того, как программа пользователя сформирует сообщение, включающее собственно текст сообщения и адрес получателя, оно передается прикладным процессом посредством локального пользовательского интерфейса своему агенту. Далее через внутренний интерфейс сообщение передается от агента прикладному сервисному элементу почтовой службы, который в нашем случае состоит из единственного специального сервисного элемента MHS, реализующего одноименный протокол.
Далее сообщение, используя стек протоколов модели OSI с первого по шестой уровень (этот стек представлен на рисунке поставщиком представительного сервиса (presentation service provider)), передается в виде прикладного протокольного блока данных (APDU) конечной системе-адресату. При получении сообщения конечной системой оно через сервисный элемент MHS будет передано локальному агенту, который после анализа этого сообщения запишет его в локальную файловую систему (file storage), точнее в почтовый ящик (mail folder), и проинформирует программу пользователя-получателя о поступлении сообщения.
Рис. 3. Пример организации прикладного уровня для программы пользователя, использующей сервис электронной почты
^ 3. Протоколы прикладного уровня OSI
В настоящее время эталонная модель OSI является самой выдающейся в мире моделью архитектуры объединенных сетей. Она также является самым популярным средством приобретения знаний о сетях. Следует различать стек протоколов OSI и модель OSI. В то время как модель OSI концептуально определяет процедуру взаимодействия открытых систем, декомпозируя задачу на 7 уровней, стандартизирует назначение каждого уровня и вводит стандартные названия уровней, стек OSI - это набор вполне конкретных спецификаций протоколов, образующих согласованный стек протоколов. На Рис. 4 представлены некоторые протоколы стека OSI и их связь с эталонной моделью OSI.
Рис. 4. Протоколы стека OSI и их связь с эталонной моделью OSI
Наибольшего внимания заслуживают следующие пять протоколов прикладного уровня OSI:
File Transfer, Access and Management (FTAM) - протокол доступа к файлам; стандарт соединения открытых систем:
- для передачи файлов (целиком);
- для удаленного доступа к записям в файле; и
- для создания, удаления и переименования файлов.
Common Management Information Protocol (CMIP) - протокол общей управляющей информации – протокол, определяющий стандартный способ управления сетями, разработанными различными производителями.
Virtual Terminal Protocol (VTP) - протокол виртуальных терминалов, обеспечивает эмуляцию терминалов, он позволяет компьютерной системе для отдаленного пользователя казаться непосредственно подключенным терминалом. С помощью VTP пользователь может, например, выполнять дистанционные работы на универсальных вычислительных машинах.
Massage Handling Systems (MHS) - системы обработки сообщений - обеспечивает механизм, лежащий в основе транспортировки данных для прикладных задач передачи сообщений по электронной почте и других задач, требующих услуг по хранению и продвижению данных.
Directory Services (DS) - услуги каталогов. Разработанная на основе спецификации Х.500 CITT, эта услуга предоставляет возможности распределенной базы данных, которые полезны для идентификации и адресации узлов высших уровней.
^ 4. Протоколы прикладного уровня NetWare
NetWare является операционной системой сети (network operating system - NOS) и связанной с ней средой обеспечения услуг, разработанной Novell, Inc. и представленной на рынок в начале 1980 гг. В качестве среды NOS, NetWare определяет пять высших уровней эталонной модели OSI. Она обеспечивает совместное пользование файлами и принтером, поддержку различных прикладных задач, таких как передача электронной почты и доступ к базе данных, и другие услуги. Так же, как и другие NOS, базируется на архитектуре клиент-сервер (slient-server architecture). В таких архитектурах клиенты (иногда называемые рабочими станциями) запрашивают у серверов определенные услуги, такие как доступ к файлам и принтеру. Основная характеристика системы клиент-сервер заключается в том, что доступ к отдаленной сети является прозрачным для пользователя. Это достигается с помощью удаленного вызовова процедур (remote procedure calls) - такого процесса, когда программа местного компьютера, работающая на оборудовании клиента, отправляет вызов в удаленный сервер. Этот сервер выполняет указанную процедуру и возвращает запрошенную информацию клиенту местного компьютера.
Рис. 5 иллюстрирует в упрощенном виде известные протоколы NetWare и их связь с эталонной моделью OSI. При наличии соответствующих драйверов, NetWare может работать с любым протоколом доступа к носителю. На рисунке перечислены те протоколы доступа к носителю, которые в настоящее время обеспечиваются драйверами NetWare.
Рис. 5. Протоколы стека NetWare и их связь с эталонной моделью OSI
^ Протоколы высших уровней
NetWare поддерживает большое разнообразие протоколов высших уровней:
Netware Core Protocol (NCP) (Основной протокол NetWare) представляет собой ряд программ для сервера, предназначенных для удовлетворения запросов прикладных задач, приходящих, например, из NetWare shell. Услуги, предоставляемые NCP, включают доступ к файлам, доступ к принтеру, управление именами, учет использования ресурсов, защиту данных и синхронизацию файлов.
NetBIOS - программа эмуляции NetBIOS, обеспечиваемая NetWare, позволяет программам, написанным для промышленного стандартного интерфейса сеансового уровня Network Basic I/O System (NetBIOS) компаний IBM и Microsoft NetBIOS, работать в пределах системы NetWare.
Услуги прикладного уровня NetWare включают:
- ^ NetWare Message Handling Service (NetWare MHS) - Услуги по обработке сообщений,
- Btrieve - реализация механизма доступа к базе данных двоичного дерева (btree) Novell,
- NetWare Loadable Modules (NLM) - Загружаемые модули NetWare
^ 5. Прикладной уровень стека TCP/IP.
Прикладной уровень стека TCP/IP соответствует трем верхним уровням модели OSI: прикладному, представительному и сеансовому. Он объединяет службы, предоставляемые системой пользовательским приложениям. За долгие годы использования в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и служб прикладного уровня. Протоколы прикладного уровня устанавливаются на хостах. Прикладной уровень реализуется программными системами, построенными в архитектуре клиент-сервер. В отличие от протоколов остальных трех уровней, протоколы прикладного уровня отрабатывают логику приложений и «не интересуются» способами передачи данных по сети, они обращаются к протоколам нижних уровней как к некоторому набору инструментов. Так, клиентская часть протокола прикладного уровня для обмена сообщениями со своей серверной частью, установленной на отдаленном узле составной сети, должна обратиться с запросом к нижележащему транспортному уровню…
На Рис. 6. представлены наиболее известные протоколы каждого из уровней стека TCP/IP и взаимосвязь между ними.
Рис.6. Протоколы стека TCP/IP
Функции прикладного уровня:
Функции прикладного уровня обычно включают идентификацию партнеров по связи, определение наличия ресурса и синхронизацию связи. При идентификации партнеров по связи прикладной уровень определяет подлинность и наличие партнеров по связи для прикладной программы, имеющей данные, готовые к передаче. При определении наличия ресурса прикладной уровень должен принять решение, существует ли достаточное количество сетевых ресурсов для запрошенной связи. При синхронизации связи весь обмен данными между прикладными программами требует взаимодействия, которое управлялось бы прикладным уровнем.
Идентификация и установление наличия предполагаемых партнеров связи
Синхронизация совместно работающих программ
Установление соотношения по процедурам устранения ошибок
Управление целостностью информации
Протоколы прикладного уровня определяют, имеется ли в наличии достаточно ресурсов для предполагаемой связи
Отвечает за то, чтобы информация, посылаемая из прикладного уровня одной системы, была читаема на прикладном уровне другой системы
При необходимости осуществляет трансляцию между множеством форматов представления информации путем использования общего формата и структур данных, а также согласует синтаксис передачи данных для прикладного уровня
Устанавливает и завершает сеансы взаимодействия между прикладными задачами, управляет этими сеансами, синхронизирует диалог между объектами и управляет обменом информации между ними
Предоставляет средства для отправки информации и уведомления об исключительных ситуациях передачи данных.
Почему существуют два транспортных протокола TCP и UDP, а не один из них? Дело в том, что они предоставляют разные услуги прикладным процессам. Большинство прикладных программ пользуются только одним из них. Вы, как программист, выбираете тот протокол, который наилучшим образом соответствует вашим потребностям. Если вам нужна надежная доставка, то лучшим может быть TCP. Если вам нужна доставка датаграмм, то лучше может быть UDP. Если вам нужна эффективная доставка по длинному и ненадежному каналу передачи данных, то лучше может подойти протокол TCP. Если нужна эффективность на быстрых сетях с короткими соединениями, то лучшим может быть протокол UDP. Если ваши потребности не попадают ни в одну из этих категорий, то выбор транспортного протокола не ясен. Однако прикладные программы могут устранять недостатки выбранного протокола. Например, если вы выбрали UDP, а вам необходима надежность, то прикладная программа должна обеспечить надежность. Если вы выбрали TCP, а вам нужно передавать записи, то прикладная программа должна вставлять маркеры в поток байтов так, чтобы можно было различить записи.
^ 6.1. Протоколы управления терминалами
6.1.1 Протокол Telnet
Telnet (англ. Teletype Network) — сетевой протокол для реализации текстового интерфейса по сети (в современной форме — при помощи транспорта TCP). Название «telnet» имеют также некоторые утилиты, реализующие клиентскую часть протокола.
Устройство
Хотя в сессии Telnet выделяют клиентскую и серверную сторону, протокол на самом деле полностью симметричен. После установления транспортного соединения (как правило, TCP) оба его конца играют роль «сетевых виртуальных терминалов» (англ. Network Virtual Terminal, NVT), обменивающимися двумя типами данных:
Прикладными данными (т.е. данными, которые идут от пользователя к текстовому приложению на стороне сервера и обратно);
Опциями протокола Telnet, служащими для уяснения возможностей и предпочтений сторон.
Прикладные данные проходят через протокол без изменений, т.е. на выходе второго виртуального терминала мы видим именно то, что было введено на вход первого. С точки зрения протокола данные представляют просто последовательность байтов (октетов), по умолчанию принадлежащих набору ASCII, но при включенной опции Binary — любых. Хотя были предложены расширения для идентификации набора символов, но на практике ими не пользуются.
Безопасность
В протоколе не предусмотрено использование ни шифрования, ни проверки подлинности данных. Поэтому он уязвим для любого вида атак, к которым уязвим его транспорт, т.е. протокол TCP. Для функциональности удалённого доступа к системе в настоящее время применяется сетевой протокол SSH (особенно его версия 2), при создании которого упор делался именно на вопросы безопасности. Так что следует иметь в виду, что сессия Telnet весьма беззащитна, если только не осуществляется в полностью контролируемой сети или с применением защиты на сетевом уровне (различные реализации виртуальных частных сетей). По причине ненадёжности от Telnet как средства управления операционными системами давно отказались.
^ Telnet и другие протоколы
В среде специалистов по технологиям internet распространено мнение, что клиент Telnet пригоден для осуществления ручного доступа (например, в целях отладки) к таким протоколам прикладного уровня как HTTP, IRC, SMTP, POP3 и прочим текст-ориентированным протоколам на основе транспорта TCP. Однако, использование клиента telnet в качестве клиента TCP вызывает следующие нежелательные эффекты:
Клиент может передать данные, которые Вы не вводили (опции Telnet);
Клиент не будет принимать октет \377;
Клиент будет искажать октет \377 при передаче;
Клиент вообще может отказаться передавать октеты со старшим битом 1.
Такие программы как netcat действительно обеспечивают чистый доступ к TCP, однако использование чистого доступа к TCP вызывает иную проблему. Перевод строки, вводимый из Unix-системы, будет передан одним символом LF, в то время как названные протоколы требуют CR LF как разделитель строки — впрочем, большинство серверов удовлетворяются и одним LF, хотя по стандарту делать это не обязаны. Обычный клиент Telnet по умолчанию передаёт любой перевод строки именно как CR LF. Наиболее корректным решением для отладочного доступа к прикладным протоколам (кроме FTP и, собственно, Telnet) является использование клиента PuTTY в режиме «Raw» (чистый доступ к TCP) — PuTTY преобразует переводы строки отдельно от поддержки протокола Telnet.
^ 6.1.2 Протокол SSH
SSH (Secure Shell) — сетевой протокол, позволяющий производить удалённое управление компьютером и передачу файлов. Сходен по функциональности с протоколом Telnet и rlogin, однако использует алгоритмы шифрования передаваемой информации.
Криптографическая защита протокола SSH не фиксирована, возможен выбор различных алгоритмов шифрования. Клиенты и серверы, поддерживающие этот протокол, доступны для различных платформ. Кроме того, протокол позволяет не только использовать безопасный удалённый shell на машине, но и туннелировать графический интерфейс — X Tunnelling (только для Unix-подобных ОС или приложений, использующих графический интерфейс X Window System). SSH также способен передавать через безопасный канал (Port Forwarding) любой другой сетевой протокол, обеспечивая (при надлежащем конфигурировании) возможность безопасной пересылки не только X-интерфейса, но и, например, звука.
Поддержка SSH реализована во всех UNIX системах, и на большинстве из них в числе стандартных утилит присутствуют клиент и сервер ssh. Существует множество реализаций SSH-клиентов и для не-UNIX ОС. Большую популярность протокол получил после широкого развития sniffer’ов, как альтернативное небезопасному телнету решение для управления важными узлами.
На данный момент известно две ветки версий — 1 и 2. Однако ветка 1 остановлена, так как в конце 90-x в ней было найдено много уязвимостей, некоторые из которых до сих пор накладывают серьёзные ограничения на её использование, поэтому перспективной, развивающейся и наиболее безопасной является версия 2.
^ 6.2. Протоколы управления файлами
6.2.1. Протокол FTP
File Transfer Protocol (FTP) - сетевой протокол, предназначенный для передачи файлов в компьютерных сетях. Протокол FTP позволяет подключаться к серверам FTP, просматривать содержимое каталогов и загружать файлы с сервера или на сервер, кроме того, возможен режим передачи файлов между серверами.
Функции протокола FTP
решение задач разделения доступа к файлам на удаленных хостах
прямое или косвенное использование ресурсов удаленных компьютеров
обеспечение независимости клиента от файловых систем удаленных хостов
эффективная и надежная передачи данных.
Схема работы FTP.
Простейшая схема работы протокола FTP представлена на рисунке 7. В FTP соединение инициируется интерпретатором протокола пользователя. Управление обменом осуществляется по каналу управления в стандарте протокола TELNET. Команды FTP генерируются интерпретатором протокола пользователя и передаются на сервер. Ответы сервера отправляются пользователю также по каналу управления. В общем случае пользователь имеет возможность установить контакт с интерпретатором протокола сервера и отличными от интерпретатора протокола пользователя средствами.
^ Рис.7. Простейшая схема работы протокола FTP
Команды FTP определяют параметры канала передачи данных и самого процесса передачи. Они также определяют и характер работы с удаленной и локальной файловыми системами.
Сессия управления инициализирует канал передачи данных. При организации канала передачи данных последовательность действий другая, отличная от организации канала управления. В этом случае сервер инициирует обмен данными в соответствии с согласованными в сессии управления параметрами.
Канал данных устанавливается для того же хоста, что и канал управления, через который ведется настройка канала данных. Канал данных может быть использован как для приема, так и для передачи данных.
^ Алгоритм работы протокола FTP:
Сервер FTP использует в качестве управляющего соединение на TCP порт 21, который всегда находится в состоянии ожидания соединения со стороны пользователя FTP.
После того как устанавливается управляющее соединение модуля “Интерпретатор протокола пользователя” с модулем сервера — “Интерпретатор протокола сервера”, пользователь (клиент) может отправлять на сервер команды. FTP-команды определяют параметры соединения передачи данных: роль участников соединения (активный или пассивный), порт соединения (как для модуля “Программа передачи данных пользователя”, так и для модуля “Программа передачи данных сервера”), тип передачи, тип передаваемых данных, структуру данных и управляющие директивы, обозначающие действия, которые пользователь хочет совершить (например, сохранить, считать, добавить или удалить данные или файл и другие).
После того как согласованы все параметры канала передачи данных, один из участников соединения, который является пассивным (например, “Программа передачи данных пользователя”), становится в режим ожидания открытия соединения на заданный для передачи данных порт. После этого активный модуль (например, “Программа передачи данных сервера”) открывает соединение и начинает передачу данных.
После окончания передачи данных, соединение между “Программой передачи данных сервера” и “Программой передачи данных пользователя” закрывается, но управляющее соединение “Интерпретатора протокола сервера” и “Интерпретатора протокола пользователя” остается открытым. Пользователь, не закрывая сессии FTP, может еще раз открыть канал передачи данных.
Основу передачи данных FTP составляет механизм установления соединения между соответствующими портами и выбора параметров передачи. Каждый участник FTP-соединения должен поддерживать порт передачи данных по умолчанию. По умолчанию “Программа передачи данных пользователя” использует тот же порт, что и для передачи команд (обозначим его “U”), а “Программа передачи данных сервера” использует порт L-1, где “L”- управляющий порт. Однако, участниками соединения используются порты передачи данных, выбранные для них “Интерпретатором протокола пользователя”, поскольку из управляющих процессов участвующих в соединении, только “Интерпретатор протокола пользователя” может изменить порты передачи данных как у “Программы передачи данных пользователя”, так и у “Программы передачи данных сервера”.
Пассивная сторона соединения должна до того, как будет подана команда “начать передачу”, “слушать” свой порт передачи данных. Активная сторона, подающая команду к началу передачи данных, определяет направление перемещения данных.
После того как соединение установлено, между “Программой передачи данных сервера” и “Программой передачи данных пользователя” начинается передача. Одновременно по каналу “Интерпретатор протокола сервера” — “Интерпретатор протокола пользователя” передаются уведомления о получении данных. Протокол FTP требует, чтобы управляющее соединение было открыто, пока по каналу обмена данными идет передача. Сессия FTP считается закрытой только после закрытия управляющего соединения.
Как правило, сервер FTP ответственен за открытие и закрытие канала передачи данных. Сервер FTP должен самостоятельно закрыть канал передачи данных в следующих случаях:
Сервер закончил передачу данных в формате, который требует закрытия соединения.
Сервер получил от пользователя команду “прервать соединение”.
Пользователь изменил параметры порта передачи данных.
Было закрыто управляющее соединение.
Возникли ошибки, при которых невозможно возобновить передачу данных.
^ 6.2.2. Протокол HTTP
HTTP — сетевой протокол прикладного уровня для передачи файлов. В стеке TCP/IP для HTTP зарезервированы порты 80 и 8080 транспортных протоколов TCP и UDP. Основным назначением протокола HTTP является передача веб-страниц (текстовых файлов с разметкой HTML), хотя с помощью него с успехом передаются и другие файлы, как связанные с веб-страницами (изображения и приложения), так и не связанные с ними.
^ Структура протокола
HTTP — протокол прикладного уровня, аналогичными ему явлются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.
Каждый запрос/ответ состоит из трёх частей:
стартовая строка;
заголовки;
тело сообщения, содержащее данные запроса, запрашиваемый ресурс или описание проблемы, если запрос не был выполнен.
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
‹Метод› ‹URI› HTTP/‹Версия›
где ‹Метод› может быть:
OPTIONS
Возвращает методы HTTP, которые поддерживаются сервером. Этот метод может служить для определения возможностей веб-сервера.
GET
Запрашивает содержимое указанного ресурса. Запрашиваемый ресурс может принимать параметры (например, поисковая система может принимать в качестве параметра искомую строку). Они передаются в строке URI (например: http://www.example.net/resource?param1=value1¶m2=value2). Согласно стандарту HTTP, запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
HEAD
Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Это полезно для извлечения метаинформации, заданной в заголовках ответа, без пересылки всего содержимого.
POST
Передаёт пользовательские данные (например, из HTML-формы) заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария).
PUT
Загружает указанный ресурс на сервер.
DELETE
Удаляет указанный ресурс.
TRACE
Возвращает полученный запрос так, что клиент может увидеть, что промежуточные сервера добавляют или изменяют в запросе.
CONNECT
Для использования вместе с прокси-серверами, которые могут динамически переключаться в туннельный режим SSL.
В основном используются методы GET и POST.
Первая строка ответа выглядит так:
HTTP/‹Версия› ‹Код статуса› ‹Описание статуса›
Наиболее типичные статусы:
200 OK — запрос выполнен успешно;
403 Forbidden — доступ к запрошенному ресурсу запрещён;
404 Not Found — запрошенный ресурс не найден.
Заголовки HTTP — это строки, каждая из которых состоит из имени параметра, за которым следует двоеточие и его значение. Они несут информацию для браузера или для серверных программ (таких, как CGI-приложения). Между заголовками и телом обязательно должна быть пустая строка.
Примеры HTTP
Запрос:
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
(далее следует текст запрошенной страницы)
6.2.3. Протокол IPP
IPP (от англ. Internet Printing Protocol — «протокол межсетевой печати», «протокол печати через Интернет») — сетевой протокол прикладного уровня для передачи документов на печать. Является перегруженной версией HTTP, то есть придаёт всем известному протоколу передачи гипертекста новое значение. Помимо расширенных функций управления печатью, поддерживает контроль доступа, аутентификацию и шифрование (SSL).
Типичный адрес принтера указывается так:
http://server:631/printers/myprinter
На корневой странице (http://server:631/) может находиться веб-интерфейс управления, а также ссылки на область загрузки драйверов.
Вместо стандартного IPP-порта 631/tcp часто используется 80/tcp (стандартный для HTTP). Для шифрованного трафика применяется либо 443/tcp (стандартный для HTTP over SSL), либо тот же 631. ^ 6.3. Протоколы управления сетью
Протокол SNMP
SNMP (англ.Simple Network Management Protocol — простой протокол управления сетью) — это протокол управления сетями связи на основе архитектуры TCP/IP.
Протокол SNMP работает на базе транспортных возможностей UDP (возможны реализации и на основе ТСР) и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB - management information base, RFC-1213, -1212).
Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица команд (pdu - protocol data unit) SNMP (Таблица1) и схема запросов-отликов SNMP (Рис. 8):
Таблица1
Команда SNMP
Тип PDU
Назначение
GET-request
0
Получить значение указанной переменной или информацию о состоянии сетевого элемента;
GET_next_request
1
Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);
SET-request
2
Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено;
GET response
3
Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные);
TRAP
4
Отклик сетевого объекта на событие или на изменение состояния.
GetBulkRequest
5
Запрос пересылки больших объемов данных, например, таблиц.
InformRequest
6
Менеджер обращает внимание партнера на определенную информацию в MIB.
SNMPv3-Trap
7
Отклик на событие (расширение по отношению v1 и v2).
Report
8
Отчет (функция пока не задана).
Рис. 8. Схема запросов/откликов SNMP
Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид (Рис. 9):
Рис. 9. Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы
Поле версия содержит значение, равное номеру версии SNMP минус один. Поле пароль (community - определяет группу доступа) содержит последовательность символов, которая является пропуском при взаимодействии менеджера и объекта управления. Обычно это поле содержит 6-байтовую строку public, что означает общедоступность. Для запросов GET, GET-next и SET значение идентификатора запроса устанавливается менеджером и возвращается объектом управления в отклике GET, что позволяет связывать в пары запросы и отклики. Поле фирма (enterprise) = sysobjectid объекта. Поле статус ошибки характеризуется целым числом, присланным объектом управления
^ Управляющая база данных MIB
Вся управляющая информация для контроля ЭВМ и маршрутизаторами Интернет концентрируется в базе данных MIB (Management Information Base, RFC-1213 или STD0017). Именно эти данные используются протоколом SNMP. Система SNMP состоит из трех частей: менеджера SNMP, агента SNMP и базы данных MIB. Агент SNMP должен находиться резидентно в памяти объекта управления. SNMP-менеджер может быть частью системы управления сетью NMS (Network Management System), что реализуется, например, в маршрутизаторах компании CISCO (CiscoWorks).
MIB определяет, например, что IP программное обеспечение должно хранить число всех октетов, которые приняты любым из сетевых интерфейсов, управляющие программы могут только читать эту информацию.
Согласно нормативам MIB управляющая информация делится