Протоколы электронной почты
Система электронной почты состоит из трех компонентов: пользовательского агента, позволяющего пользователям читать и составлять сообщения, транспортных агентов для отправки и доставки сообщений. Задача транспортного агента – принимать почту от пользовательского агента, интерпретировать адреса получателей и перенаправлять почту на соответствующие машины для последующей доставки. Доставочный агент отвечает за прием почты от транспортного агента и ее доставку получателям.
Протокол SMTP
После того как агент передачи почты пошлет сообщение в выходную очередь, за дело принимается агент доставки - МТА. Он извлекает сообщение и посылает его другому МТА. Этот процесс продолжается до тех пор, пока сообщение не достигнет компьютера - получателя. Для передачи сообщений большинство МТА пользуются протоколом SMTP. Сообщения форматированы по правилам виртуального сетевого терминала NVT. Символ в NVT состоит из семи битов набора ASCII и является буквой, цифрой или знаком пунктуации.
Кроме текста, SMTP позволяет передавать и двоичную информацию, например присоединенные графические или звуковые файлы.
Сообщение в почтовый ящик пользователя может быть доставлено различными маршрутами. Чтобы направить почту по нужному пути, указываются промежуточные агенты-MTA. В следующем примере [email protected] является почтовым ящиком, a HOSTI, HOST2 и HOST3 - промежуточными агентами:
MAIL FROM:<@HOSTI, @HOST2, @HOST3: [email protected] >
Как правило, между двумя компьютерами находится один или несколько промежуточных агентов. Аргументом команды MAIL является обратный маршрут, включающий имя источника сообщения и имена всех промежуточных агентов. Обратный маршрут используется SMTP, когда нужно передать сообщение о случившейся ошибке или о невозможности доставить сообщение, когда оно уже прошло через промежуточный агент. По мере продвижения сообщения по Internet записи о его маршрутах изменяются.
Протокол POP3
На компьютере пользователя существуют два отдельных почтовых агента - доставки (POP) и отправки (SMTP).
Post Office Protocol (POP) - протокол доставки почты пользователю. Доставка сообщений осуществляется в почтовые ящики пользователя, расположенные на круглосуточно работающем почтовом сервере. Пользователь может получить доступ к своему почтовому РОР-серверу из любой точки доступа к Интернет. Для этого необходимо запустить почтовый агент и настроить его для работы со своим почтовым сервером.
В протоколе РОРЗ, который является более поздней версией POP, оговорены три стадии процесса получения почты: авторизация, транзакция и обновление. На стадии авторизации клиент себя идентифицирует. Если авторизация прошла успешно, сервер открывает почтовый ящик клиента и начинается стадия транзакции почты. На стадии обновления сеанс связи заканчивается.
Протокол IMAP4
Протокол IMAP4 (Internet Message Access Protocol) позволяет клиентам получать доступ и манипулировать сообщениями электронной почты на сервере. В отличие от протокола РОРЗ, IMAP4 поддерживает работу с системой каталогов удаленных сообщений, как если бы они располагались на локальном компьютере. IMAP4 позволяет клиенту создавать, удалять и переименовывать почтовые ящики, проверять наличие новых сообщений и удалять старые. Структура папок в значительной степени зависит от типа почтовой системы, но в любой системе у клиента есть специальный каталог INBOX, куда попадают поступающие клиенту сообщения. Протокол IMAP4 работает поверх транспортного протокола, который обеспечивает надежный и достоверный канал передачи данных между клиентом, и сервером IMAP4. При работе по TCP, IMAP4 использует 143-й порт. Команды и данные IMAP4 передаются по транспортному протоколу в том виде, в каком их отправляет сервер или пользователь.
Принцип передачи данных по протоколу IMAP4 такой же, как и у других подобных протоколов. Сначала клиент и сервер обмениваются приветствиями. Затем клиент отправляет на сервер команды и данные. Сервер, соответственно, передает клиенту ответы на обработку команд и данных. После завершения обмена канал закрывается.
Важной особенностью протокола IMAP является то, что взаимодействие клиента сервером не строится по принципу "запрос-ответ. Сервер может обрабатывать несколько команд одновременно и отвечать на каждую из них по ее окончанию. При этом ответ на более позднюю команду может поступить раньше, поэтому ответ сервера всегда содержит тег той команды, к которой он относится. Для работы в таком режиме, клиент и сервер должны фиксировать весь поток данных обмена, поскольку как сервер так и клиент в своих запросах и ответах мог ссылаться на команды и данные, введенные на предыдущих стадиях сессии обмена.
IMAP4 - гибкий и многофункциональный протокол с широкими возможностями. Он обслуживает более 20 различных команд клиента по управлению состоянием почты.
Спецификация MIME
Существует стандарт MIME (Multipurpose Internet Mail Extensions), определяющий включение в почтовые сообщения объектов мультимедиа: текста на языках, для которых используются кодировки, отличные от ASCII, и нетекстовый контент, такой как картинки, музыка, фильмы и программы. MIME является также компонентом коммуникационных протоколов HTTP, которым нужно, чтобы данные передавались в контексте сообщений подобных e-mail, даже если данные реально не являются e-mail.
Проблемы с кодировкой
В настоящее время используется несколько кодировок кириллицы позволяяющих использовать восьмибитные коды от 0.. 255: KOI8-R, Windows 1251 и Unicode(UTF-8).
KOI8 является стандартом для серверов, работающих на базе платформы UNIX. Эта кодировка используется при пересылке сообщений электронной почты на русском языке.
Компания Microsoft для работы в Интернете предложила свой стандарт Windows 1251.
Универсальный международный стандарт Unicode (UTF-8) был создан с целью объединить существующие национальные кодировки в одну. Поскольку для отображения одного символа в Unicode отводится не один байт, как это принято во всех остальных стандартах, а два, данная кодировка включает в себя 65536 знаков вместо 256. В это число входят не только буквы всех алфавитов мира, но и множество специальных символов — математических, музыкальных, физических. UTF-8 стал основным стандартом передачи гипертекстовой информации.
Большинство современных серверных программ обладают встроенной функцией автоматического определения кодировки, используемой клиентским программным обеспечением, и перевода текста в необходимый стандарт «на лету».
Что касается нетекстовых файлов, то проблема с ними решается путем создания почтовых вложений (присоединённых файлов). Если нужно отправить длинный документ, его упаковывают архиватором, затем создают сообщение, к которому прикрепляют документ в качестве вложения. Для пересылки хорошо подходит формат PDF. Для просмотра этого формата служит бесплатная программа Acrobate Reader.
Протокол FTP
Технология FTP была разработана еще в рамках проекта ARPA и предназначена для обмена большими объемами информации между машинами с различной архитектурой. FTP-протокол - один из старейших протоколов в Internet. Первые спецификации FTP относятся к 1971 году. Обмен данными в FTP построен на технологии “клиент-сервер” и происходит по TCP-каналу. Алгоритм работы протокола FTP состоит в следующем:
- Сервер FTP прослушивает порт 21, и находится в состоянии ожидания соединения с клиентом.
- Клиент устанавливает соединение и отправляет на сервер команды FTP.
- Клиент становится в режим ожидания открытия соединения на заданный для передачи данных порт. Активный модуль - “Программа передачи данных сервера” начинает передачу данных клиенту.
После окончания передачи данных управляющее соединение сервера и клиента остается открытым, поэтому пользователь, не закрывая сессии FTP, может еще раз открыть канал передачи данных.
HTTP – Протокол передачи гипертекстов
HyperText Transfer Protocol (HTTP) - это протокол уровня приложений, обеспечивающий передачу гипертекстовых данных от клиента к серверу и обратно. HTTP используется проектом World Wide Web, начиная с 1990 года. В настоящее время в Веб используется версия HTTP 1.1. HTTP предоставляет открытое множество методов, которые могут быть использованы для указания целей запроса. Для указания адреса ресурса, к которому должен быть применен данный метод, используется Универсальный Идентификатор Ресурсов (Universal Resource Identifier - URI), в виде местонахождения (URL) или имени (URN). Программа - клиент устанавливает связь с обслуживающей программой- сервером и посылает серверу запрос в следующей форме:
· метод запроса,
· URI,
· версия протокола, за которой следует управляющая информация запроса, информация о клиенте и тело сообщения.
Сервер отвечает сообщением, содержащим строку статуса: версию протокола и код статуса - успех или ошибка. За ней следует сообщение, включающее в себя информацию о сервере, метаинформацию о содержании ответа, и само тело ответа.
Для WWW номер порта по умолчанию 80, но могут быть использованы и другие номера портов.
Для большинства приложений сеанс связи открывается клиентом для каждого запроса и закрывается сервером после окончания ответа на запрос.
Транзакции HTTP
Когда браузер запрашивает Web-страницу с указанного адреса, он создает и отсылает серверу по указанному адресу запрос HTTP, заголовок которого выглядит следующим образом:
GET /my.php HTTP/1.1
Accept: image/gif, image/png, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0;
Windows XP; .NET CLR 1.1.4322)
Host: my.com
Connection: Keep-Alive
Вот что эти строки значат:
GET — метод HTTP который означает: "Дай информацию, находящуюся в му.php, и вышли ее, используя протокол HTTP 1.1".
Accept — "могу понимать графическую информацию в следующих форматах".
Accept-Language — "язык, — английский, американский ".
Accept-Encoding — "можно отправлять данные в сжатом виде, поскольку я понимаю типы сжатия gzip и deflate".
User-Agent — "тип моего браузера — Microsoft Explorer 8, выполняющийся под управлением Windows XP".
Host — "доставь мне информацию /my.php с компьютера, находящегося на хосте my.com".
Connection: Keep-Alive — "держи подключение HTTP открытым, пока браузер не закроет его". Постоянное подключение повышает производительность, поскольку соединение не нужно закрывать и снова открывать для каждого подключения. Без Keep-Alive Web-страница будет иметь множество подключений
Когда Web-сервер получает подобный запрос, он должен просмотреть информацию на сервере, которая представлена /my. php. Если информация на сервере существует, сервер должен отправить клиенту (браузеру) ответ (response ) в виде:
HTTP/1.1 200 OK
Date: Sun, 14 Mar 2010 21:36:39 GMT
Server: Apache/2
Last-Modified: Sat, 28 Nov 2009 03:59:01 GMT
ETag: "1387e3-5f88-479666db44b40"
Accept-Ranges: bytes
Content-Length: 24456
Vary: Accept-Encoding,User-Agent
Connection: close
Content-Type: text/html; charset=utf-8
<html lang="en-US" xml:lang = "en-US"> <nlns="http://www.w3.org/1999/xhtml">
<head>
<script>
HTTP-ответ состоит из двух частей. В начале идет заголовок ответа (response header). Затем идет пустая строка и далее — сама запрошенная информация. Эта вторая часть называется телом (body). Вот что означают части заголовка:
HTTP/1.1 — первая строка сообщает клиенту, что информация будет отправлена по протоколу HTTP версии 1.1. Код 200 состояния HTTP означает: "Все хорошо, документ найден и сейчас будет отправлен".
Date — сообщает клиенту дату, установленную на сервере, с которого поступает информация. Стандартный часовой пояс — GMT, то есть время по Гринвичу.
Server — каков тип сервера, предоставляющего информацию.
Connection — сообщает клиенту, что соединение будет закрыто после того, как сервер завершит отправку информации.
Content-Type — сообщает клиенту, какой тип содержимого будет отправлен. В дополнение также указывается набор символов.
Клиентские методы HTTP
В HTTP метод клиента определяет запрос, отправленный от Web-клиента, либо РНР-сценария, HTTP-серверу. Чаще всего используются три основных типа запросов:
GET-запросы. Когда вы хотите только получить информацию от источника HTTP, то можете сделать это методом GET. Получить информацию можно из файла, либо от исполняемой программы на Web-сервере с указанным URL-адресом.
POST-запросы. Когда вы хотите отправить информацию от клиента Web-серверу, то используете запрос POST. Обычно это имеет место, когда вы отправляете серверу содержимое Web-формы.
HEAD-запросы. Когда вы хотите получить информацию о запрошенном URL, но не информацию самого URL, то используете запрос HEAD.
Несмотря на то, что РНР делает определенные вещи легко, он не реализует их в полной мере. В частности, хотя средство потоков РНР Streams позволяет довольно просто получать доступ к ресурсам HTTP, как если бы они были файлами, оно не дает возможности получить доступ к метаинформации. Чтобы получить доступ к метаинформации, можно обратиться к объекту HttpClient.