Протоколы прикладного уровня
Вид материала | Реферат |
- Мазмұны, 738.95kb.
- Методические рекомендации по оформлению деловой документации дуз «сказка», 16.42kb.
- Впредставленном курсовом проекте рассматривается глобальная сеть Internet самая крупная, 477.68kb.
- Число, 45.85kb.
- Протоколы локальных сетей, 562.81kb.
- Основы истории декоративно-прикладного искусства, 15.6kb.
- Экзамен "1С: Специалист" по внедрению прикладного решения "1С: Зарплата и Управление, 282.07kb.
- Институт клинического и прикладного психоанализа (095)274-02-67; 502-24-95, 23.27kb.
- Президиума Совета Минского городского объединения организаций профсоюзов от 24. 07., 58.86kb.
- Положение о проведении районного конкурса декоративно-прикладного творчества "Творчество:, 50.53kb.
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 (например: le.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).
Типичный адрес принтера указывается так:
1/printers/myprinter
На корневой странице (1/) может находиться веб-интерфейс управления, а также ссылки на область загрузки драйверов.