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