Размещено на http://www.allbest.ru/

TALLINNA POLUTEHNIKUM

Arvutid ja Arvutivхrgud

Реферат на тему:

Протоколы прикладного уровня

Учитель: Синельник Татьяна Виниславна

Ученик: Титушко Богдан Ярославович

Таллинн 2016

Содержание

Введение

1. Общие принципы организации и функционирования прикладного уровня (OSI)

2. Протоколы прикладного уровня OSI

3. Прикладной уровень TCP/IP

4. Протоколы прикладного уровня TCP/IP

4.1 Протоколы управления терминалами (TELNET, SSH)

4.2 Протоколы управления файлами (HTTP, IPP, FTP)

4.3 Протоколы управления сетью (SNMP, DNS)

4.4 Протоколы организации электронной почты (SMTP, POP3, IMAP4)

4.5 Протоколы организации обмена сообщениями (NNTP, IRC)

Заключение

Введение

Для человека, пользующегося Интернетом каждый день, просмотр веб-страниц или чтение почты не требуют огромных усилий или специального образования. Можно и не подозревать, что каждый щелчок мыши или нажатие кнопки порождает множество разнообразных процессов, связанных друг с другом, иногда конфликтующих и борющихся за ресурсы. От глаз пользователя все это хитрое взаимодействие скрыто, доступен лишь конечный результат. Чтобы понять, как на самом деле происходит то, что предстает перед нами в виде цепочки тривиальных действий, рассмотрим организацию прикладного уровня и его протоколов.

1. Общие принципы организации и функционирования прикладного уровня (OSI)

Прикладной уровень является наивысшим уровнем в эталонной модели OSI RM и единственным средством доступа прикладных процессов к функциональной среде OSIE. На рисунке 1 изображено взаимодействие прикладных процессов

Размещено на http://www.allbest.ru/

Рис.1 Взаимодействие прикладных процессов.

Прикладная сущность (application-entity - AE): совокупность функций прикладного процесса, непосредственно связанных с обеспечением его взаимодействия с другими прикладными процессами.

Активация прикладной сущности или AE-активация (AE-invocation): конкретное использование некоторой части функциональных возможностей некоторой прикладной сущности, осуществляющей поддержку функций взаимосвязи, реализуемых некоторой активацией прикладного процесса.

Совокупность средств, с помощью которых выполняются все элементы взаимодействия процессов, называется прикладной ассоциацией (Application Association).

Примерами таких элементов взаимодействия являются:

- идентификация и аутентификация прикладных процессов,

- согласование и установления прикладного контекста взаимосвязи,

- обмен прикладными блоками данных,

- управление режимами взаимосвязи,

- прекращение взаимосвязи ...

Взаимодействие прикладных процессов (рис. 2) осуществляется посредством обмена прикладными протокольными блоками данных (Application Protocol Data Unit - APDU).

Размещено на http://www.allbest.ru/

Рис.2 Взаимодействие прикладных процессов.

Прикладной сервисный элемент (application-service-element - ASE): набор прикладных функций, обеспечивающих узкоспециализированную форму сетевого взаимодействия активаций прикладных сущностей; прикладной сервисный элемент является компонентой прикладных сервисный объектов и сущностей (функциональным модулем), реализующей конкретный протокол прикладного уровня.

Различаются две категории прикладных сервисных элементов:

- общие;

- специальные.

Общие прикладные сервисные элементы (Common Application Service Elements - CASE) обеспечивают услуги общесистемного характера, которые обычно используются большинством прикладных процессов.

Специальные элементы прикладных услуг (Special Application Service Elements - SASE) ориентированы на удовлетворение требований узкоспециализированных применений.

возможность доступа к сервису простой электронной почты, т.е. через свою программу пользователь может готовить и пересылать сообщения другому удаленному пользователю

используя специальный прикладной сервисный элемент системы обработки сообщений MHS (Message Handling System).

Организация вычислительного процесса для данного приложения показана на рис. 3.

Прикладной процесс (Application Process) программы пользователя в данном примере состоит из прикладной сущности (Application Entity), ответственной за реализацию функций взаимосвязи с другими пользователями, и из компоненты, реализующей взаимосвязь прикладного сервисного элемента с локальными ресурсами реальной открытой системы и называемой часто прикладным агентом (Application Agent).

После того, как программа пользователя сформирует сообщение, включающее собственно текст сообщения и адрес получателя, оно передается прикладным процессом посредством локального пользовательского интерфейса своему агенту. Далее через внутренний интерфейс сообщение передается от агента прикладному сервисному элементу почтовой службы, который в нашем случае состоит из единственного специального сервисного элемента MHS, реализующего одноименный протокол.

Далее сообщение, используя стек протоколов модели OSI с первого по шестой уровень (этот стек представлен на рисунке поставщиком представительного сервиса (presentation service provider)), передается в виде прикладного протокольного блока данных (APDU) конечной системе-адресату. При получении сообщения конечной системой оно через сервисный элемент MHS будет передано локальному агенту, который после анализа этого сообщения запишет его в локальную файловую систему (file storage), точнее в почтовый ящик (mail folder), и проинформирует программу пользователя-получателя о поступлении сообщения.

2. Протоколы прикладного уровня OSI

В настоящее время эталонная модель OSI является самой выдающейся в мире моделью архитектуры объединенных сетей. Она также является самым популярным средством приобретения знаний о сетях. Следует различать стек протоколов OSI и модель OSI. В то время как модель OSI концептуально определяет процедуру взаимодействия открытых систем, декомпозируя задачу на 7 уровней, стандартизирует назначение каждого уровня и вводит стандартные названия уровней, стек OSI - это набор вполне конкретных спецификаций протоколов, образующих согласованный стек протоколов. На Рис. 4 представлены некоторые протоколы стека OSI и их связь с эталонной моделью OSI.

Размещено на http://www.allbest.ru/

Наибольшего внимания заслуживают следующие пять протоколов прикладного уровня 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, эта услуга предоставляет возможности распределенной базы данных, которые полезны для идентификации и адресации узлов высших уровней.

• 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

3. Прикладной уровень стека TCP/IP

Прикладной уровень стека TCP/IP соответствует трем верхним уровням модели OSI: прикладному, представительному и сеансовому. Он объединяет службы, предоставляемые системой пользовательским приложениям. За долгие годы использования в сетях различных стран и организаций стек TCP/IP накопил большое количество протоколов и служб прикладного уровня. Протоколы прикладного уровня устанавливаются на хостах. Прикладной уровень реализуется программными системами, построенными в архитектуре клиент-сервер. В отличие от протоколов остальных трех уровней, протоколы прикладного уровня отрабатывают логику приложений и «не интересуются» способами передачи данных по сети, они обращаются к протоколам нижних уровней как к некоторому набору инструментов. Так, клиентская часть протокола прикладного уровня для обмена сообщениями со своей серверной частью, установленной на отдаленном узле составной сети, должна обратиться с запросом к нижележащему транспортному уровню…

На Рис. 6. представлены наиболее известные протоколы каждого из уровней стека TCP/IP и взаимосвязь между ними.

Размещено на http://www.allbest.ru/

Функции прикладного уровня:

Функции прикладного уровня обычно включают идентификацию партнеров по связи, определение наличия ресурса и синхронизацию связи. При идентификации партнеров по связи прикладной уровень определяет подлинность и наличие партнеров по связи для прикладной программы, имеющей данные, готовые к передаче. При определении наличия ресурса прикладной уровень должен принять решение, существует ли достаточное количество сетевых ресурсов для запрошенной связи. При синхронизации связи весь обмен данными между прикладными программами требует взаимодействия, которое управлялось бы прикладным уровнем.

1) Идентификация и установление наличия предполагаемых партнеров связи

2) Синхронизация совместно работающих программ

3) Установление соотношения по процедурам устранения ошибок

4) Управление целостностью информации

5) Протоколы прикладного уровня определяют, имеется ли в наличии достаточно ресурсов для предполагаемой связи

6) Отвечает за то, чтобы информация, посылаемая из прикладного уровня одной системы, была читаема на прикладном уровне другой системы

7) При необходимости осуществляет трансляцию между множеством форматов представления информации путем использования общего формата и структур данных, а также согласует синтаксис передачи данных для прикладного уровня

8) Устанавливает и завершает сеансы взаимодействия между прикладными задачами, управляет этими сеансами, синхронизирует диалог между объектами и управляет обменом информации между ними

9) Предоставляет средства для отправки информации и уведомления об исключительных ситуациях передачи данных.

Почему существуют два транспортных протокола TCP и UDP, а не один из них? Дело в том, что они предоставляют разные услуги прикладным процессам. Большинство прикладных программ пользуются только одним из них. Вы, как программист, выбираете тот протокол, который наилучшим образом соответствует вашим потребностям. Если вам нужна надежная доставка, то лучшим может быть TCP. Если вам нужна доставка датаграмм, то лучше может быть UDP. Если вам нужна эффективная доставка по длинному и ненадежному каналу передачи данных, то лучше может подойти протокол TCP. Если нужна эффективность на быстрых сетях с короткими соединениями, то лучшим может быть протокол UDP. Если ваши потребности не попадают ни в одну из этих категорий, то выбор транспортного протокола не ясен. Однако прикладные программы могут устранять недостатки выбранного протокола. Например, если вы выбрали UDP, а вам необходима надежность, то прикладная программа должна обеспечить надежность. Если вы выбрали TCP, а вам нужно передавать записи, то прикладная программа должна вставлять маркеры в поток байтов так, чтобы можно было различить записи.

4. Протоколы прикладного уровня TCP/IP

4.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.

Протокол 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.

4.2 Протоколы управления файлами

Протокол FTP

File Transfer Protocol (FTP) - сетевой протокол, предназначенный для передачи файлов в компьютерных сетях. Протокол FTP позволяет подключаться к серверам FTP, просматривать содержимое каталогов и загружать файлы с сервера или на сервер, кроме того, возможен режим передачи файлов между серверами.

Функции протокола FTP

- решение задач разделения доступа к файлам на удаленных хостах

- прямое или косвенное использование ресурсов удаленных компьютеров

- обеспечение независимости клиента от файловых систем удаленных хостов

- эффективная и надежная передачи данных.

Схема работы FTP.

Простейшая схема работы протокола FTP представлена на рисунке 7. В FTP соединение инициируется интерпретатором протокола пользователя. Управление обменом осуществляется по каналу управления в стандарте протокола TELNET. Команды FTP генерируются интерпретатором протокола пользователя и передаются на сервер. Ответы сервера отправляются пользователю также по каналу управления. В общем случае пользователь имеет возможность установить контакт с интерпретатором протокола сервера и отличными от интерпретатора протокола пользователя средствами.

Размещено на http://www.allbest.ru/

Рис.7. Простейшая схема работы протокола FTP

Команды FTP определяют параметры канала передачи данных и самого процесса передачи. Они также определяют и характер работы с удаленной и локальной файловыми системами.

Сессия управления инициализирует канал передачи данных. При организации канала передачи данных последовательность действий другая, отличная от организации канала управления. В этом случае сервер инициирует обмен данными в соответствии с согласованными в сессии управления параметрами.

Канал данных устанавливается для того же хоста, что и канал управления, через который ведется настройка канала данных. Канал данных может быть использован как для приема, так и для передачи данных.

Алгоритм работы протокола FTP:

Сервер FTP использует в качестве управляющего соединение на TCP порт 21, который всегда находится в состоянии ожидания соединения со стороны пользователя FTP.

После того как устанавливается управляющее соединение модуля “Интерпретатор протокола пользователя” с модулем сервера -- “Интерпретатор протокола сервера”, пользователь (клиент) может отправлять на сервер команды. FTP-команды определяют параметры соединения передачи данных: роль участников соединения (активный или пассивный), порт соединения (как для модуля “Программа передачи данных пользователя”, так и для модуля “Программа передачи данных сервера”), тип передачи, тип передаваемых данных, структуру данных и управляющие директивы, обозначающие действия, которые пользователь хочет совершить (например, сохранить, считать, добавить или удалить данные или файл и другие).

После того как согласованы все параметры канала передачи данных, один из участников соединения, который является пассивным (например, “Программа передачи данных пользователя”), становится в режим ожидания открытия соединения на заданный для передачи данных порт. После этого активный модуль (например, “Программа передачи данных сервера”) открывает соединение и начинает передачу данных.

После окончания передачи данных, соединение между “Программой передачи данных сервера” и “Программой передачи данных пользователя” закрывается, но управляющее соединение “Интерпретатора протокола сервера” и “Интерпретатора протокола пользователя” остается открытым. Пользователь, не закрывая сессии FTP, может еще раз открыть канал передачи данных.

Основу передачи данных FTP составляет механизм установления соединения между соответствующими портами и выбора параметров передачи. Каждый участник FTP-соединения должен поддерживать порт передачи данных по умолчанию. По умолчанию “Программа передачи данных пользователя” использует тот же порт, что и для передачи команд (обозначим его “U”), а “Программа передачи данных сервера” использует порт L-1, где “L”- управляющий порт. Однако, участниками соединения используются порты передачи данных, выбранные для них “Интерпретатором протокола пользователя”, поскольку из управляющих процессов участвующих в соединении, только “Интерпретатор протокола пользователя” может изменить порты передачи данных как у “Программы передачи данных пользователя”, так и у “Программы передачи данных сервера”.

Пассивная сторона соединения должна до того, как будет подана команда “начать передачу”, “слушать” свой порт передачи данных. Активная сторона, подающая команду к началу передачи данных, определяет направление перемещения данных.

После того как соединение установлено, между “Программой передачи данных сервера” и “Программой передачи данных пользователя” начинается передача. Одновременно по каналу “Интерпретатор протокола сервера” -- “Интерпретатор протокола пользователя” передаются уведомления о получении данных. Протокол FTP требует, чтобы управляющее соединение было открыто, пока по каналу обмена данными идет передача. Сессия FTP считается закрытой только после закрытия управляющего соединения.

Как правило, сервер FTP ответственен за открытие и закрытие канала передачи данных. Сервер FTP должен самостоятельно закрыть канал передачи данных в следующих случаях:

Сервер закончил передачу данных в формате, который требует закрытия соединения.

Сервер получил от пользователя команду “прервать соединение”.

Пользователь изменил параметры порта передачи данных.

Было закрыто управляющее соединение.

Возникли ошибки, при которых невозможно возобновить передачу данных.

Протокол HTTP

HTTP -- сетевой протокол прикладного уровня для передачи файлов. В стеке TCP/IP для HTTP зарезервированы порты 80 и 8080 транспортных протоколов TCP и UDP. Основным назначением протокола HTTP является передача веб-страниц (текстовых файлов с разметкой HTML), хотя с помощью него с успехом передаются и другие файлы, как связанные с веб-страницами (изображения и приложения), так и не связанные с ними.

Структура протокола

HTTP -- протокол прикладного уровня, аналогичными ему явлются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

Каждый запрос/ответ состоит из трёх частей:

1. стартовая строка;

2. заголовки;

3. тело сообщения, содержащее данные запроса, запрашиваемый ресурс или описание проблемы, если запрос не был выполнен.

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

‹Метод› ‹URI› HTTP/‹Версия›

где ‹Метод› может быть:

OPTIONS

Возвращает методы HTTP, которые поддерживаются сервером. Этот метод может служить для определения возможностей веб-сервера.

GET

Запрашивает содержимое указанного ресурса. Запрашиваемый ресурс может принимать параметры (например, поисковая система может принимать в качестве параметра искомую строку). Они передаются в строке URI (например: http://www.example.net/resource?param1=value1&param2=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

(далее следует текст запрошенной страницы)

Протокол 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.

4.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 управляющая информация делится на восемь категорий: (см слайд № 36)

MIB каждый объект должен иметь имя (object identifier), синтаксис и метод кодировки.

Стандарт ASN.1 определяет форму представления информации и имен. Имена переменных MIB соответствуют в свою очередь стандартам ISO и CCITT.

Протокол DNS

DNS (англ. Domain Name System -- система доменных имён) -- это система, позволяющая преобразовывать символьные имена доменов в IP-адреса (и наоборот) в сетях TCP/IP.

Домемн -- определённая зона в системе доменных имён (DNS) Интернета, выделенная какой-либо стране, организации или для иных целей.

DNS важна для работы Интернета, ибо для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-сервера, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла DHOSTS.TXT, который составлялся централизованно и обновлялся на каждой из машин сети вручную. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы описано в RFC 882. В 1987 публикация RFC 1034 и RFC 1035 изменили спецификацию DNS и отменили RFC 882 и RFC 883 как устаревшие. Некоторые новые RFC дополнили и расширили возможности базовых протоколов.

Доменное имя содержит, как минимум, две части (обычно называются метками), разделённые точкой. Самая правая метка является доменом верхнего уровня (например, для адреса ru.wikipedia.org домен верхнего уровня -- org). Каждая следующая метка справа налево является поддоменом (например, wikipedia.org -- поддомен домена org, а ru.wikipedia.org -- домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.

Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative -- авторитетный, заслуживающий доверия; в Рунете применительно к DNS и серверам имен часто употребляют и другие варианты перевода: авторизированный, авторитативный), на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

Как работает DNS?

DNS работает в режиме вопрос/ответ. Допустим Вы ввели в строке своего браузера ipipe.ru. Рассмотрим работу DNS пошагово:

Шаг 1. Ваш браузер об IP адресе ipipe.ru ничего не знает и с запросом IP адреса ipipe.ru, через специальную программу resolver обращается к локальному серверу имен.

Локальный DNS сервер это сервер имен Вашей локальной сети или DNS сервер Вашего Интернет провайдера (если вы используете DialUp). Откуда браузеру известно о существовании этого локального DNS? Спросите Вы. Все очень просто: При настройках сетевого подключения Вы прописываете IP адреса DNS серверов (предпочитаемого и/или альтернативного) один из которых будет отвечать на запросы посылаемые Вашим браузером через resolver - это и есть локальный или местный сервер Вашей сети. Если Вы используете модемное подключение (через телефонную линию) то для Вас местным сервером имен - будет DNS сервер Вашего провайдера. IP адрес этого сервера также будет прописан в настройках сетевого подключения, не зависимо от того как осуществлялась настройка (вручную или автоматически). Вы всегда сможете посмотреть IP адрес Вашего локального DNS сервера. Для этого достаточно посмотреть свойства сетевого подключения, используемого на Вашем компьютере.

Шаг 2. Запрос на IP адрес ipipe.ru доходит до местного сервера имен. Этот сервер об этом IP адресе ничего не знает, и посылает запрос одному из корневых серверов "." (root).

Шаг 3. Корневой сервер отдает локальному серверу IP адрес сервера, который поддерживает зону .ru.

Шаг 4. Далее по полученному адресу локальный сервер имен обращается к DNS серверу, который поддерживает .ru.

Шаг 5. Этот DNS сервер по полученному запросу отдает IP адрес сервера, который поддерживает зону ipipe.ru.

Шаг 6. Местный DNS сервер с запросом IP адреса ipipe.ru обращается к DNS серверу зоны ipipe.ru.

Шаг 7. Локальный сервер имен получает IP адрес ipipe.ru. от DNS сервера зоны ipipe.ru.

Шаг 8. Получив адрес ipipe.ru локальный DNS сервер сообщает его Вашему браузеру.

Теперь браузер занет IP адрес ipipe.ru и напрямую обращается к серверу, на котором расположен сайт ipipe.ru.

Простейший алгоритм работы представлен на структурной схеме:

Имя хоста и IP-адрес не тождественны -- хост с одним IP-адресом может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо -- одному имени может быть сопоставлено множество хостов: это позволяет создавать балансировку нагрузки.

Запрос на определение имени обычно не идёт дальше кеша DNS, который помнит (ограниченное время) ответы на запросы, проходившие через него ранее. Организации или провайдеры могут по своему усмотрению организовывать кэш DNS. Вместе с ответом приходит информация о том, сколько времени следует хранить эту запись в кэше.

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию. Существует 13 корневых серверов, расположенных по всему миру и привязанных к своему региону, их адреса никогда не меняются, а информация о них есть в любой операционной системе.

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса.

Обратный DNS-запрос

DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

Записи DNS

Наиболее важные категории DNS записей:

· Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имя referrals.icann.org вернет его IP адрес -- 192.0.34.164

· Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя

· Запись MX (mail exchange) или почтовый обменник указывает сервер(а) обмена почтой для данного домена.

· Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org.

· Запись NS (name server) указывает на DNS-серверы для данного домена.

· Запись SOA (Start of Authority) указывает, на каком сервере хранится эталонная информация о данном домене.

Зарезервированные доменные имена

Документ RFC 2606 (Reserved Top Level DNS Names -- Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

4.4 Протоколы организации электронной почты

Протокол SMTP

SMTP (англ. Simple Mail Transfer Protocol -- простой протокол передачи почты) -- это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.

SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы POP3 или IMAP.

Данные передаются при помощи TCP, при этом обычно используется порт 25 или 587. При передаче сообщений между серверами обычно используется порт 25.

Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. Mail eXchange -- обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов (например, Exim^[1]) для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись (RFC 2782).

Сервер SMTP -- это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда<пробел>параметры<перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа -- число от 100 до 999, представленное в виде строки, трактующийся следующим образом:

· 2ХХ -- команда успешно выполнена

· 3XX -- ожидаются дополнительные данные от клиента

· 4ХХ -- временная ошибка, клиент должен произвести следующую попытку через некоторое время

· 5ХХ -- неустранимая ошибка

Текстовая часть ответа носит справочный характер и предназначен для человека, а не программы.

Безопасность SMTP и спам

Изначально SMTP не поддерживал единой схемы авторизации. В результате этого спам стал практически неразрешимой проблемой, так как было невозможно определить, кто на самом деле является отправителем сообщения -- фактически можно отправить письмо от имени любого человека. В настоящее время производятся попытки решить эту проблему при помощи спецификаций SPF, Sender ID, Yahoo Domain Keys. Единой спецификации на настоящий момент не существует.

Протокол POP3

POP3 (англ. Post Office Protocol Version 3 -- протокол почтового отделения, версия 3) -- это сетевой протокол, используемый для получения сообщений электронной почты с сервера. Обычно используется в паре с протоколом SMTP.

Рис. 10. Схема «Клиент-сервер по протоколу POP3»

Описание протокола РОРЗ

Рассмотрим представленную на Рис. 10. схему «Клиент-сервер по протоколу POP3». Конструкция протокола РОРЗ обеспечивает возможность пользователю обратиться к своему почтовому серверу и изъять накопившуюся для него почту. Пользователь может получить доступ к РОР-серверу из любой точки доступа к Интернет. При этом он должен запустить специальный почтовый агент (UA), работающий по протоколу РОРЗ, и настроить его для работы со своим почтовым сервером. Итак, во главе модели POP находится отдельный персональный компьютер, работающий исключительно в качестве клиента почтовой системы (сервера). Подчеркнем также, что сообщения доставляются клиенту по протоколу POP, а посылаются по-прежнему при помощи SMTP. То есть на компьютере пользователя существуют два отдельных агента-интерфейса к почтовой системе - доставки (POP) и отправки (SMTP). Разработчики протокола РОРЗ называет такую ситуацию "раздельные агенты" (split UA). Концепция раздельных агентов кратко обсуждается в спецификации РОРЗ.

В протоколе РОРЗ оговорены три стадии процесса получения почты: авторизация, транзакция и обновление. После того как сервер и клиент РОРЗ установили соединение, начинается стадия авторизации. На стадии авторизации клиент идентифицирует себя для сервера. Если авторизация прошла успешно, сервер открывает почтовый ящик клиента и начинается стадия транзакции. В ней клиент либо запрашивает у сервера информацию (например, список почтовых сообщений), либо просит его совершить определенное действие (например, выдать почтовое сообщение). Наконец, на стадии обновления сеанс связи заканчивается. Далее перечислены команды протокола РОРЗ, обязательные для работающей в Интернет реализации минимальной конфигурации.

Команды протокола POP версии 3 (для минимальной конфигурации)

USER Идентифицирует пользователя с указанным именем

PASS Указывает пароль для пары клиент-сервер

QUIT Закрывает TCP-соединение

STAT Сервер возвращает количество сообщений в почтовом ящике плюс размер почтового ящика

LIST Сервер возвращает идентификаторы сообщений вместе с размерами сообщений (параметром команды может быть идентификатор сообщения)

RETR Извлекает сообщение из почтового ящика (требуется указывать аргумент-идентификатор сообщения)

DELE Отмечает сообщение для удаления (требуется указывать аргумент - идентификатор сообщения)

NOOP Сервер возвращает положительный ответ, но не совершает никаких действий

LAST Сервер возвращает наибольший номер сообщения из тех, к которым ранее уже обращались

RSET Отменяет удаление сообщения, отмеченного ранее командой DELE

В протоколе РОРЗ определено несколько команд, но на них дается только два ответа: +ОК (позитивный, аналогичен сообщению-подтверждению АСK) и -ERR (негативный, аналогичен сообщению "не подтверждено" NAK). Оба ответа подтверждают, что обращение к серверу произошло и что он вообще отвечает на команды. Как правило, за каждым ответом следует его содержательное словесное описание. В RFC 1225 есть образцы нескольких типичных сеансов РОРЗ. Сейчас мы рассмотрим несколько из них, что даст возможность уловить последовательность команд в обмене между сервером и клиентом.

Авторизация пользователя

После того как программа установила TCP-соединение с портом протокола РОРЗ (официальный номер 110), необходимо послать команду USER с именем пользователя в качестве параметра. Если ответ сервера будет +ОК, нужно послать команду PASS с паролем этого пользователя:

CLIENT: USER kcope ERVER: +ОК CLIENT: PASS secret SERVER: +ОК kcope's maildrop has 2 messages (320 octets) (В почтовом ящике kcope есть 2 сообщения (320 байтов) ...)

Транзакции РОРЗ

После того как стадия авторизации окончена, обмен переходит на стадию транзакции. В следующих примерах демонстрируется возможный обмен сообщениями на этой стадии.

Команда STAT возвращает количество сообщений и количество байтов в сообщениях:

CLIENT: STAT

SERVER: +ОК 2 320

Команда LIST (без параметра) возвращает список сообщений в почтовом ящике и их размеры:

CLIENT: LIST

SERVER: +ОК 2 messages (320 octets)

SERVER: 1 120

SERVER: 2 200

SERVER: . ...

Команда NOOP не возвращает никакой полезной информации, за исключением позитивного ответа сервера. Однако позитивный ответ означает, что сервер находится в соединении с клиентом и ждет запросов:

CLIENT: NOOP

SERVER: +ОК

Следующие примеры показывают, как сервер POP3 выполняет действия. Например, команда RETR извлекает сообщение с указанным номером и помещает его в буфер местного UA:

CLIENT: RETR 1 SERVER: +OK 120 octets SERVER: <the POPS server sends the entire message here> (РОРЗ-сервер высылает сообщение целиком) SERVER: . . . . . .

Команда DELE отмечает сообщение, которое нужно удалить:

CLIENT: DELE 1

SERVER: +OK message 1 deleted ... (сообщение 1 удалено) CLIENT: DELE 2 SERVER: -ERR message 2 already deleted сообщение 2 уже удалено)

Команда RSET снимает метки удаления со всех отмеченных ранее сообщений:

CLIENT: RSET

SERVER: +OK maildrop has 2 messages (320 octets)

(в почтовом ящике 2 сообщения (320 байтов) )

Как и следовало ожидать, команда QUIT закрывает соединение с сервером:

CLIENT: QUIT SERVER: +OK dewey POP3 server signing off CLIENT: QUIT SERVER: +OK dewey POP3 server signing off (maildrop empty) CLIENT: QUIT SERVER: +OK dewey POP3 server signing off (2 messages left)

Обратите внимание на то, что отмеченные для удаления сообщения на самом деле не удаляются до тех пор, пока не выдана команда QUIT и не началась стадия обновления. В любой момент в течение сеанса клиент имеет возможность выдать команду RSET, и все отмеченные для удаления сообщения будут восстановлены.

Протокол IMAP

IMAP (англ. Internet Message Access Protocol) -- интернет-протокол прикладного уровня для доступа к электронной почте.

IMAP предоставляет пользователю богатые возможности для работы с почтовыми ящиками, находящимися на центральном сервере. Почтовая программа, использующая этот протокол, получает доступ к хранилищу корреспонденции на сервере так, как будто эта корреспонденция расположена на компьютере получателя. Электронными письмами можно манипулировать с компьютера пользователя (клиента) без необходимости постоянной пересылки с сервера и обратно файлов с полным содержанием писем.

Преимущества по сравнению с POP

IMAP был разработан для замены более простого протокола POP3 и имеет следующие преимущества по сравнению с последним:

· Письма хранятся на сервере, а не на клиенте. Возможен доступ к одному и тому же почтовому ящику с разных клиентов. Поддерживается также одновременный доступ нескольких клиентов. В протоколе есть механизмы с помощью которых клиент может быть проинформирован об изменениях, сделанных другими клиентами.

...