MIME – Version (MIME – Версия).
Content – Type (Содержание – Тип).
Content — Transfer – Encoding (Содержание – Передача – Кодирование).
Content – Id (Содержание – Идентификатор).
Content – Description (Содержание — Описание).
Заголовок "MIME-Version: 1.0". Он указывает версию MIME (в настоящий момент 1.0) и используется для обозначения того, что настоящее сообщение является не простым email-сообщением согласно RFC-822, а составлено по спецификации MIME.
Наиболее интересным и полезным является дополнительный заголовок "Content-Type:", который определяет соответственно тип данных, содержащихся в сообщении (разделе сообщения)
Он имеет формат:
Content-Type: тип/подтип [; параметр=значение [;...]]
Стандартные типы и подтипы данных можно найти по адресу http://www. iana. org/assignments/media-types/index. html
Примеры
text
Текстовые данные (в том числе восьмибитные); наиболее распространенные подтипы: plain (обычный текст) и html. Возможный параметр: "charset=название_кодировки_символов"; наличие параметра необязательно. (Примеры кодировок символов: us-ascii [текст в узком смысле, только семибитные символы], кириллица: koi8-r, windows-1251, iso8859-5.) Если не указан charset, считается, что это us-ascii. Пример заголовка:
Content-Type: text/plain; charset=koi8-r
Если заголовок "Content-Type:" отсутствует, то считается, что это
Content-Type: text/plain; charset=us-ascii
image
Неподвижные изображения; примеры подтипов: jpeg, gif. Пример заголовка (параметры необязательны):
Content-Type: image/jpeg; name="portrait. jpg"
audio
Звук; примеры подтипов: mpeg, x-realaudio. Пример заголовка (параметры необязательны):
Content-Type: audio/x-realaudio; name="song. ra"
video
Видео; примеры подтипов: mpeg, quicktime. Пример заголовка (параметры необязательны):
Content-Type: video/mpeg; name="movie. mpeg"
application
Двоичные данные (поток байт), в общем случае предназначенные для какой-то прикладной программы и не попадающие в вышеперечисленные категории. Подтип позволяет определить, для какой именно программы предназначены данные. Определено большое число различных подтипов (например, postscipt, msword, zip, x-javascript). Если неизвестно, как интерпретировать данные, используется общий подтип octet-stream. Пример заголовка (параметры необязательны):
Content-Type: application/msword; name="my_file. doc"
Очевидно, что использование указанных заголовков, типов, подтипов и параметров может сделать фильтрацию более гибкой и эффективной.
Нужно заметить, что многие пользователи используют популярные бесплатные почтовые службы, такие как mail. ru, yandex. ru, и им подобные. Интерфейс таких служб строится на базе WEB сервера, доступ к которому производится стандартным образом по протоколу http (описанному ранее). Следовательно, в этом случае для фильтрации пользовательских запросов (как на отсылку, так и на чтение почты), можно использовать все приведенные выше рекомендации.
1.2.2 Особенности построения современных протоколов и возможности их гибкой фильтрации
1.2.2.1 Структура и фильтрация ICQ (протокол OSCAR)
OSCAR – (Open System for Communication in Realtime) – прикладной протокол программ мгновенного обмена сообщениями в реальном времени (instant messengers). Протокол обеспечивает передачу текстовых и мультимедийных сообщений для систем ICQ и AIM. Он был создан в 1999 году компанией AOL (America Online, Inc.) в качестве альтернативы и дополнения существовавшего на тот момент протокола icq, разработанного в 1996 для первой версии ICQ-клиента израильскими программистами компании Mirabilis. Протокол способен работать со старыми и новыми ICQ-серверами вне зависимости от типа выбранного клиента. Популярными альтернативными программами-клиентами, использующими OSCAR для общения в сети ICQ являются QIP, Miranda IM, R&Q и др. На сегодняшний день не существует полной и достоверной официальной спецификации этого протокола.
Для идентификации пользователей служба ICQ использует UIN (Universal Identification Number) — уникальный для каждой учётной записи номер, состоящий из 5-9 арабских цифр. Этот номер присваивается учётной записи при первичной регистрации пользователя в системе, после чего, в паре с паролем, может использоваться для аутентификации в системе. С каждой учётной записью ассоциирован статус присутствия, являющийся индикатором того, подключён пользователь к сети или нет, и готов ли он в данный момент отвечать на сообщения. После успешной авторизации клиент ICQ загружает с сервера список контактов пользователя. Контакты в списке могут быть распределены по группам, имена и количество которых изменяются пользователем. В ICQ реализована передача файлов по технологии P2P, минуя сервер. Передача файлов возможна только тогда, когда статус у получателя «В сети». Подобный способ передачи файлов может быть опасен тем, что отправитель узнает IP получателя (или наоборот) или отправит ему вредоносное программное обеспечение. Начиная же с ICQ 5, появилась возможность передавать файлы через сам сервер ICQ, который играет посредническую роль. Это необходимо в том случае, если клиент ICQ определил, что P2P-соединение установить невозможно (закрытые порты в межсетевых экранах, отсутствие персонального внешнего IP и др.).
Серверную часть IM составляют следующие серверы:
Серверы api. screenname обеспечивают работу всех служб идентификации, также известных как AOL Auth. Первое действие в сессии IM – использование clientLogin для идентификации пользователя.
Серверы api. oscar обеспечивают доступ к сетевым сервисам IM. В IM они обеспечивают процедуру открытия сервиса для клиента – поиск сервера BOSS, соответствующего данному клиенту. Любой клиент проводит большую часть времени, общаясь с Основным Сервисным Сервером OSCAR (Basic OSCAR Service Server), сокращенно BOSS. Сервер BOSS обеспечивает все уведомления от контактов, пересылку сообщений и другие сервисы. Он также является шлюзом к некоторым другим серверам баз данных IM. Соединение клиента с сервером BOSS крайне важно, т. к. этим определяется продолжительность сессии. Если клиент отключится от сервера BOSS, он вернется в состояние offline, и информация по данной сессии будет стерта.
Сервер Buddy Art, или BART, обеспечивает для клиента возможность скачивать рисунки, звуковые файлы и объекты xml для выражений.
Пользователь может одновременно использовать несколько клиентов на основе одного или различных движков. По идее, все сообщения и уведомления о друзьях должны отправляться на все клиенты, хотя есть некоторые правила пересылки сообщений, в соответствии с которыми пользователи, имеющие статус away или idle, могут не получить сообщения.
Любое клиентское приложение IM использует протокол OSCAR для взаимодействия с выходными буферами IM для того, чтобы, например, получать списки контактов, посылать и получать сообщения. Протокол OSCAR – бинарный, то есть он использует побайтный способ передачи информации. Описание структуры состоит из основных уровней передачи – главного функционального уровня FLAP (Frame Layer Protocol), и следующего за ним уровня SNAC (Simple Network Atomic Communication), отвечающего за передачу специальных сообщений, обеспечивающих работу клиента с сервером. В рамках SNAС существуют его отдельные подгруппы – Errors, OSERVICE (группа базовых операций и типов данных, являющихся общими для множества групп и различных серверов), Permit/Deny (для изменения одноимённых установок и настроек передачи трафика, не входящего в группу сообщений) и ICBM (группа, описывающая протокольные сообщения, для взаимодействия между клиентами, организацию каналов связи и пр.) (см. рис. 1.1). Число этих подгрупп постоянно увеличивается, а сами они подвергаются существенным изменениям со стороны разработчиков с выходом каждой новой версии клиента. Многие из серверных соединений поддерживают TLS между уровнями FLAP и TCP, если требуется однократное шифрование. В большинстве случаев, бинарный поток данных формируется с использованием вышеперечисленных элементов в указанном порядке без добавочного дополнения нулевыми битами.

Рис.1.1. Описание структуры протокола OSCAR
Таким образом, контроль отдельных типов FLAP и SNAC может сделать фильтрацию эффективней. Разрешая или запрещая передачу данных по отдельным заголовкам этиx субпротоколов, мы можем управлять отдельными функциями или режимами работа ICQ-клиента.
Протокол использует некоторые базовые типы данных, описанные ниже; это «строительные блоки» для остальных типов данных и SNACs. При шифровании или дешифровании этих типов необходимо помнить про порядок пересылки байтов (см. табл. 1.1).
Таблица 1.1. Основные типы данных протокола OSCAR.
Условное название | Размер | Комментарии |
u08 | 1 байт | Беззнаковый byte |
u16 | 2 байта | Беззнаковый двухбайтный short |
u32 | 4 байта | Беззнаковый четырехбайтный int |
f32 | 4 байта | Четырехбайтный float |
t70 | 4 байта | Беззнаковый четырехбайтный timestamp (из UNIX EPOCH) |
UUID | 16 байт | Шестнадцать байт, представляющих UUID (также известный как GUID). |
blob | варьируется | Используется в TLV (см. ниже), тип и размер данных зависит от внешних величин |
empty | 0 байт | Используется в TLV, существование этой переменной влияет на поведение объекта, данные игнорируются |
Строковые типы не заканчиваются значением NULL и хранятся в кодировке UTF8. Строка считается сжатой, если все пробелы удалены, а все буквы верхнего регистра преобразованы в нижний (см. табл. 1.2).
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 |


