Экзамен вопросы и ответы / 1_45

FTP – File Transfer Protocol

Разработан в 1971-1980 Джонатаном Постелом.

Является одним из базовых протоколов Ethernet.

Протокол определяет следующее:

Как будет осуществляться проверка на ошибку

Метод упаковки данных (если упаковка используется)

Каким образом посылающее устройство сообщает, что оно закончило сообщение

Каким образом принимающее устройство сообщает, что оно получило сообщение

Целями FTP являются

1) содействие совместному использованию файлов (компьютерных программ и/или данных),

2) поощрение косвенного или неявного (с помощью программ) использования удаленных компьютеров,

3) защита пользователя от изменений в системах хранения файлов между хостами и

4) надежная и эффективная передача данных. FTP, хотя и может использоваться непосредственно пользователем на терминале, предназначен в основном для использования программами.

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

Подключение к данным

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

Порт данных

Процесс пассивной передачи данных "прослушивает" порт передачи данных для подключения от процесса активной передачи, чтобы открыть соединение для передачи данных.

Протокол передачи файлов не предоставляет FTP-клиентам и серверам возможности различать несколько DNS-имен, зарегистрированных для одного IP-адреса.

SMTP

Simple Mail Transfer Protocol

Разработан в 1982 Джонатаном Постелом.

SMTP — требующий соединения текстовый протокол, по которому отправитель сообщения связывается с получателем посредством выдачи командных строк и получения необходимых данных через надёжный канал, в роли которого обычно выступает TCP-соединение (Transmission Control Protocol — протокол управления передачей). SMTP-сессия состоит из команд, посылаемых SMTP-клиентом, и соответствующих ответов SMTP-сервера. Когда сессия открыта, сервер и клиент обмениваются её параметрами. Сессия может включать ноль и более SMTP-операций (транзакций).

SMTP-операция состоит из трёх последовательностей команда/ответ (см. пример ниже). Описание последовательностей:

• MAIL FROM — устанавливает обратный адрес (то есть Return-Path, 5321.From, mfrom). Это адрес для возвращённых писем.

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

• DATA — для отправки текста сообщения. Это само содержимое письма, в противоположность его оболочке. Он состоит из заголовка сообщения и тела сообщения, разделённых пустой строкой. DATA, по сути, является группой команд, а сервер отвечает дважды: первый раз на саму команду DATA, для уведомления о готовности принять текст; и второй раз после конца последовательности данных, чтобы принять или отклонить всё письмо.

Помимо промежуточных ответов для DATA-команды, каждый ответ сервера может быть положительным (код ответа 2хх) или отрицательным. Последний, в свою очередь, может быть постоянным (код 5хх) либо временным (код 4хх). Отказ SMTP-сервера в передаче сообщения — постоянная ошибка; в этом случае клиент должен отправить возвращённое письмо. После сброса — положительного ответа, сообщение скорее всего будет отвержено. Также сервер может сообщить о том, что ожидаются дополнительные данные от клиента (код 3xx).

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

MUA знает SMTP-сервер для исходящей почты из своих настроек. SMTP-сервер, действующий как клиент, то есть пересылающий сообщения, определяет, к какому серверу подключиться, просмотром ресурса записей MX (Mail eXchange) DNS для домена каждого получателя. В случае, если запись MX не найдена, совместимые MTA (не все) возвращаются к простой А-записи. Пересылающие сервера также могут быть настроены на использование Smart host.

SMTP-сервер, действующий как клиент, устанавливает TCP-соединение с сервером по разработанному для SMTP порту 25. MUA должен использовать порт 587 для подключения к агенту предоставления сообщений (MSA). Основное различие между MTA и MSA заключается в том, что SMTP-аутентификация обязательна только для последнего.

Основная задача протокола SMTP (Simple Mail Transfer Protocol) заключается в том, чтобы обеспечивать передачу электронных сообщений (почту). Для работы через протокол SMTP клиент создаёт TCP соединение с сервером через порт 25. Затем клиент и SMTP сервер обмениваются информацией пока соединение не будет закрыто или прервано. Основной процедурой в SMTP является передача почты (Mail Procedure). Далее идут процедуры Mail Forwarding, проверка имён почтового ящика и вывод списков почтовых групп. Самой первой процедурой является открытие канала передачи, а последней – его закрытие.

Команды ( или хз как ещё их назвать )

500 Синтаксическая ошибка, команда не распознана

• 501 Синтаксическая ошибка в параметрах или аргументах

• Команда 502 не реализована; параметр команды 504 не реализован

• 503 Неверная последовательность команд

• 211 Состояние системы или ответ на системную справку

• 214 Справочных сообщений

• 220 <домен> Служба готова

• 221 <домен> Служба закрытия канала передачи

• 421 Услуга <домен> недоступна, закрывает канал передачи

• 250 Запрошенных почтовых действий в порядке, завершено

• 451 Запрошенное действие прервано: ошибка в обработке

• 452 Запрошенное действие не выполнено: недостаточно системного хранилища

• 354 Начните ввод почты; заканчивайте <CRLF>.<CRLF>

• 554 Транзакции завершились неудачно

HTTP

Разработан Тимоти Бё(е)рнсом-Ли в 1990?,1994,1995,1997 годах.

HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам). Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616. Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает данный запрос, формирует ответ и передаёт его обратно клиенту. После этого клиентское приложение может продолжить отправлять другие запросы, которые будут обработаны аналогичным образом. Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины. Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт». API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON. Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.

Команды(или хз как правильно назвать (написать только основное)):

"100"; Продолжить

• "101"; Протоколы переключения

• "200"; ОК

• "201"; Создан

• "202"; Принято

• "203"; Неавторизованная информация

• "204"; Нет Содержимого

• "205"; Сброс содержимого

• "206"; Частичное содержание

• "300"; Несколько вариантов

• "301"; Перемещен Навсегда

• "302"; Временно перемещен

• "303"; См. Другие

• "304"; Не Изменено

• "305"; Использовать прокси-сервер

"400"; Плохой запрос

• "401"; Несанкционированный

• "402"; Требуется Оплата

• "403"; Запрещено

• "404"; Не найден

• "405"; Метод Не Разрешен

• "406"; Неприемлемо

• "407"; Требуется Аутентификация Через Прокси-Сервер

•"*"408"; Время ожидания запроса

• "409"; Конфликт

• "410"; Пропал

• "411"; Требуемая Длина

• "412"; Не Удалось Выполнить Предварительное условие

• "413"; Объект Запроса Слишком Велик

• "414"; Запрос-URI Слишком большой

• "415"; Неподдерживаемый Тип Носителя

"500"; Внутренняя ошибка Сервера

• "501"; Не реализовано

• "502"; Плохой шлюз

• "503"; Услуга недоступна

• "504"; Время ожидания шлюза

• "505"; Версия HTTP не поддерживается

SIP

Разработан в 1999 Хенингом Шулзри и Марком Хэндли.

В основу протокола заложили следующие принципы:

• Простота: включает в себя только шесть методов (функций)

• Независимость от транспортного уровня, может использовать UDP, TCP, ATM и т. д.

• Персональная мобильность пользователей. Пользователи могут перемещаться в пределах сети без ограничений. Это достигается путём присвоения пользователю уникального идентификатора. При этом набор предоставляемых услуг остается неизменным. О своих перемещениях пользователь сообщает с помощью сообщения REGISTER своему серверу.

• Масштабируемость сети. Структура сети на базе протокола SIP позволяет легко её расширять и увеличивать число элементов.

• Расширяемость протокола. Протокол характеризуется возможностью дополнять его новыми функциями при появлении новых услуг.

• Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом IETF. Кроме SIP, эта архитектура включает в себя протоколы RSVP, RTP, RTSP, SDP.

• Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с другими протоколами IP-телефонии, протоколами ТфОП, и для связи с интеллектуальными сетями.

SGCP/ MGCP

Разработан в 1998 Кристианом Хитема и Маурицио Аранго

Media Gateway Control Protocol - протокол управления шлюзом-носителем

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

Протокол MGCP используется контроллерами шлюза-носителя (Media Gateway Controller— MGC), называемыми также агентами вызова (call agent), для управления шлюзом-носителем (Media Gateway— MG). В основе протокола MGCP лежит принцип главный-подчиненный (master/slave), где контроллер MGC является главным, а шлюз MG — подчиненным. Шлюз MG подтверждает команду, выполняет ее и уведомляет контроллер MGC о результате (успешном или не успешном). В этой архитектуре шлюз MG выполняет функции мультимедийной среды, например преобразование сигналов мультиплексирования с разделением времени (Time-Division Multiplexing — TDM) в аналоговые или потоков протокола передачи данных в реальном масштабе времени (Real-time Transport Protocol— RTP) в потоки протокола управления в реальном масштабе времени (Real-time Transport Control Protocol — RTCP). Функции сигнализации вызова выполняет контроллер MGC. В этой модели интеллект управления вызовом располагается на контроллере MGC, а шлюз MG — бессловесный объект, выполняющий команды контроллера MGC. Сообщения MGCP передаются поверх протокола пользовательских дейтаграмм (User Datagram Protocol — UDP). Поскольку протокол UDP не гарантирует передачи сообщения, они при необходимости передаются повторно. Историческими корнями протокола MGCP являются два прежних протокола — простой протокол управления шлюзом (SGCP) и протокол Интернета для управления устройствами (Internet Protocol Device Control — IPDC).

Для описания мультимедийных сеансов протокол MGCP использует протокол описания сеанса связи (Session Description Protocol — SDP). Протокол SDP описывает параметры сеанса передачи мультимедийных данных между шлюзами MG, включая IP-адреса, порты UDP, профили RTP и мультимедийные возможности конференций. Протокол MGCP следует соглашениям SDP, определенным в документе RFC 2327. Спецификация SDP определяет несколько типов мультимедийных средств, однако протокол MGCP ограничивает использование протокола SDP только двумя из них — звуковыми каналами и каналами доступа к данным. Для поддержки телефонных шлюзов агенты вызова используют следующие параметры SDP:

• IP-адрес. Для обмена пакетами RTP может использоваться отдаленный шлюз, локальный шлюз или многоадресатная звуковая конференция.

• Порт UDP. Указывает транспортный порт, используемый для получения пакетов RTP от отдаленного шлюза.

• Звуковая мультимедийная среда. Определение звуковой мультимедийной среды, включая кодек.