ВОПРОС 36 Прикладной уровень модели OSI. Электронная почта. Принципы организации и функционирования протокола SMTP. Основные команды.

Прикладной уровень (уровень приложений; англ. application layer) — верхний уровень модели, обеспечивающий взаимодействие пользовательских приложений с сетью:

позволяет приложениям использовать сетевые службы:

удалённый доступ к файлам и базам данных,

пересылка электронной почты;

отвечает за передачу служебной информации;

предоставляет приложениям информацию об ошибках;

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

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

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

Когда клиент отправляет сообщение электронной почты, процесс SMTP-клиента подключается к процессу SMTP-сервера на широко известном порте 25. Установив соединение, клиент пытается отправить по нему сообщение электронной почты серверу. Когда сервер получает сообщение, он помещает его в очередь сообщений локальной учётной записи или пересылает другому серверу, выполнив такой же процесс установки SMTP-соединения.

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

 

Прикладной уровень модели OSI. Электронная почта. Принципы организации и функционирования протоколов POP3, IMAP. Основные команды протокола РОР3.

Прикладной уровень - седьмой уровень модели OSI, предназначенный для обеспечения взаимодействия пользователя (процесса-отправителя) с приложениями на удаленном компьютере (процессом-получателем).

Прикладной уровень обеспечивает:

- описание форм и методов взаимодействия прикладных процессов;

- управление заданиями, передачу файлов, управление системой и т.д.;

- идентификацию пользователей по их паролям, адресам и электронным подписям;

- определение функционирующих абонентов;

- объявление о возможности доступа к новым прикладным процессам;

- определение достаточности имеющихся ресурсов;

- посылку запросов на соединение с другими прикладными процессами;

- управление данными, которыми обмениваются прикладные процессы;

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

Обычно прикладной уровень подразделяется:

 - на верхний подуровень, включающий сетевые службы; и

- на нижний подуровень, содержащий стандартные сервисные элементы, поддерживающие работу сетевых служб.

Электронная почта

Электронная почта — технология и предоставляемые ею услуги по пересылке и получению электронных сообщений (называемых «письма» или «электронные письма») по распределённой (в том числе глобальной) компьютерной сети.

1. Марк решает отправить почту на [email protected], он пишет его в почтовой программе

2. Почтовая программа пересылает письмо на почтовый сервер Марка (relay.example.net)

3. Сервер relay.example.net ищет данные о DNS-зоне org

4. relay.example.net ищет данные о зоне example.org

5. Он узнаёт у ns.example.org, что почту надо слать на smtp.example.org и узнаёт его IP-адрес

6. Сервер relay.example.net соединяется с сервером smtp.example.org и передаёт письмо

7. smtp.example.org видит, что письмо для локального пользователя и помещает его в почтовый ящик

8. Билл приходит, включает компьютер, запускает почтовую программу

9. Почтовая программа обращается к серверу smtp.example.org

10. Программа находит письмо я ящике, скачивает его - письмо доставлено Биллу

POP 3

Предназначен для работы с удаленным почтовым ящиком. 

Клиент начинает работать с установки TCP-соединения на порт №110. На этом порту должен быть сервер, который прослушивает соединение. Когда соединение установлено, сервер посылает клиенту приглашение. После этого клиент и сервер обмениваются информацией, пока соединение не будет закрыто или прервано.

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

Длина ключевых слов – 3-4 символа. Длина аргументов – не более 40 каждый. Каждая команда должна завершаться символами CRLF. Ответы на некоторые команды могут состоять из нескольких строк. В этом случае каждая строка разделена символом CRLF, а весь ответ - точкой и CRLF.

Когда отвечает сервер, команды бывают в двух формах:

+ OK текст – успешно

- ERR текст – ошибка

IMAP

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

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

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

Как и POP3, протокол IMAP использует концепцию клиент-сервер с набором команд. С помощью команд осуществляется передача сообщений электронной почты от сервера клиенту. Клиент устанавливает для этой цели TCP-соединение с портом 143 на сервере. Далее сервер должен ответить специальным сообщением-приглашением.

Пример сеанса по протоколу IMAP:

1 [jessica@shadrach jessical$ telnet localhost 143

2 Trying 127.0.0.1...

3 Connected to localhost.

4 Escape character is '^]'.

5 * OK shadrach.smallorg.org IMAP4rev1 V12.250 server ready

6 a001 LOGOUT

7 * BYE shadrach.smallorg.org IMAP4rev1 server terminating connection

8 a001 OK LOGOUT completed

9 Connection closed by foreign host.

10 [jessica@snadrach jessica]$

В строке 1 показана команда на открытие сеанса с помощью telnet с портом 143 (порт IMAP по умолчанию). Строка 5 отображает приглашение, выданное сервером IMAP. В строке 6 клиентом задана команда закончить сеанс с сервером. Затем сервер посылает сообщение об окончании сеанса (строка 7) и закрывает соединение с клиентом.

Каждая команда, выдаваемая клиентом, предваряется уникальным идентификатором. Сервер может затем использовать этот идентификатор в своих ответах, что позволяет клиенту определить, к какой команде относится ответ сервера. Это особенно важно при выполнении сервером нескольких команд за сеанс. Идентификатор обычно представляет собой короткую строку алфавитно-цифровых символов, которая генерируется клиентом. Так, в строке 6 листинга клиентом был выбран идентификатор a001. Если бы клиенту потребовалось задавать и другие команды, то следующим идентификатором был бы a002 и т.д. Часто для упрощения идентификаторы команд в течение сеанса IMAP просто последовательно увеличивают один из своих разрядов.

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

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

Основные команды pop 3:

C: USER Dmitry

S: +OK Dmitry is real user

 C: PASS Surkov

S: +OK Dmitry’s maildrop has 2 messages

 C: STAT

S: +OK 2 320

 C: LIST

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200

C: RETR 1

S: +OK 120 octets

C: DELE 1

S: +OK message 1 deleted

C: RETR 2

S: +OK 200 octets

C: DELE 2

S: +OK message 2 deleted

C: QUIT

S: +OK desk POP3 server signing off

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

PASS  передает пароль пользователя. Если пользователь есть, пароль подошел, ящик не заблокирован другими соединениями, значит +OK.

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

LIST выдает информацию о сообщении с указанным номером.

DELE удаляет сообщение с указанным номером.

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

RETR извлекает содержание сообщения с указанным номером.

QUIT переводит POP3-сервер в состояние update (обновления). В этом режиме сервер удаляет сообщения, помеченные к удалению, и завершает POP3 сессию.

TOP выдает заголовки сообщений (сообщения с указанным номером), выдаются первые n строк.

 

 

38 Протокол HTTP. Принципы организации и функционирования. Основные команды и их формат.

HTTP — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

HTTP используется в качестве «транспорта» для протоколов SOAP, XML-RPC.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

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

Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния.

Достоинства:

Простота

Расширяемость

Распространённость

Недостатки:

Большой размер сообщений

Отсутствие «навигации»

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

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

1. Стартовая строка — определяет тип сообщения;

2. Заголовки — характеризуют тело сообщения, параметры передачи и прочие сведения;

3. Тело сообщения — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа.

Стартовая строка

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

1. GET URI — для версии протокола 0.9.

2. Метод URI HTTP/Версия — для остальных версий.

Метод — название запроса, одно слово заглавными буквами.

URI определяет путь к запрашиваемому документу.

Версия — пара разделённых точкой арабских цифр. Например: 1.0.

 

Стартовая строка ответа сервера имеет следующий формат:

HTTP/Версия КодСостояния Пояснение

Здесь:

Версия — пара разделённых точкой арабских цифр как в запросе.

КодСостояния — три арабские цифры. По коду статуса определяется дальнейшее содержимое сообщения и поведение клиента.

Пояснение — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

Пример:

HTTP/1.0 200 OK

Методы

Метод HTTP — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Название метода чувствительно к регистру.

Кроме методов GET и HEAD, часто применяется метод POST.

GET

Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «? »:

GET /path/resource? param1=value1& param2=value2 HTTP/1.1

Согласно стандарту HTTP, запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.

 

 

HEAD

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD применяется для извлечения метаданных, проверки наличия ресурса и чтобы узнать, не изменился ли он с момента последнего обращения.

POST

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

POST не считается идемпотентным.

PUT

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

PATCH – аналогично PUT, но применяется только к фрагменту ресурса.

DELETE – удаляет указанный ресурс.

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

LINK – устанавливает связь указанного ресурса с другими.

UNLINK – убирает связь указанного ресурса с другими.

CONNECT – преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенному SSL соединению через не шифрованный прокси.

Коды состояния

1xx Informational (русск. Информационный)

2xx Success (русск. Успешно)

3xx Redirection (русск. Перенаправление)

4xx Client Error (русск. Ошибка клиента)

5xx Server Error (русск. Ошибка сервера)

 

Заголовки

Заголовки HTTP (Headers) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

Примеры заголовков:

Server: Apache/2.2.11 (Win32) PHP/5.3.0

Last-Modified: Sat, 16 Jan 2010 21: 16: 42 GMT

Content-Type: text/plain; charset=windows-1251

Content-Language: ru

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

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

General Headers (русск. Основные заголовки) — должны включаться в любое сообщение клиента и сервера.

Request Headers (русск. Заголовки запроса) — используются только в запросах клиента.

Response Headers (русск. Заголовки ответа) — только для ответов от сервера.

Entity Headers (русск. Заголовки сущности) — сопровождают каждую сущность сообщения.

GET-запрос

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

GET /wiki/страница HTTP/1.1

Host: ru.wikipedia.org

User-Agent: Mozilla/5.0

Accept: text/html

Connection: close

⇐ Предыдущая1234567Следующая ⇒

Поделиться: