Прямая инкапсуляция интернет-сообщений

Прямая инкапсуляция сообщений Интернета (DIME) — интернет-стандарт, предложенный Microsoft в начале 2000-х годов для потоковой передачи двоичных и других инкапсулированных данных через Интернет.

Согласно веб-сайту IETF , стандарт был отозван и так и не получил статуса RFC . Однако Microsoft в свое время рекомендовала DIME для передачи файлов через веб-сервисы . Он также использовался в Java EE , но различия в реализации протокола усложняли его. ^{[ нужна ссылка ]}

Первая версия ^[1] был представлен IETF в ноябре 2001 г.; последнее обновление ^[2] был представлен в июне 2002 года. К декабрю 2003 года DIME проиграл конкуренцию механизму оптимизации передачи сообщений и SOAP с вложениями . ^[3] Microsoft теперь описывает DIME как «замененный спецификацией механизма оптимизации передачи сообщений SOAP (MTOM)». ^[4]

Стандарт задумывался как улучшенная версия MIME . ^[5] В частности, сложность MIME заключается в том, что каждое сообщение должно быть закодировано как текст и что его разделы разделены разделителем, указанным в заголовке сообщения. Это означает, что весь поток данных должен быть известен отправителю до начала связи, чтобы выбрать разделитель, которого нет в данных. Это бесполезно, если весь поток недоступен при инициировании связи или если его поиск требует больших затрат. DIME больше ориентирован на потоковую передачу, позволяя, например, получателю обрабатывать фрагменты сообщения по мере их поступления, не дожидаясь всего сообщения.

Критика

Проблемы с HTTP

DIME был определен как формат передачи на уровне канала передачи данных в модели OSI, хотя обычно он передавался через HTTP . Одна из трудностей здесь заключалась в том, что оно могло формировать HTTP-сообщение практически любого размера (ограничением была информация о размере каждого фрагмента, которая составляла 32 бита, то есть 1 гигабит). Многие HTTP-приемники не привыкли к таким большим сообщениям, и если бы они буферизовали сообщения, они просто терпели бы неудачу из-за того, что программное обеспечение ожидало короткое сообщение, а вместо этого получало длинное. Более того, если бы получатель HTTP был защищен, он отправил бы обратно отправителю сообщение с запросом (код 400) после получения сообщения. Поскольку HTTP не поддерживает соединение, он полностью потеряет, возможно, огромный объем данных, которые были отправлены на него, просто для того, чтобы принять или отклонить вызов. Ответ на вызов, конечно, может быть успешным за счет двойной отправки данных, что, если бы они были огромными, скорее противоречит сути.

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

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

Проблемы на сетевом уровне

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

См. также

SOAP с вложениями

Ссылки

^ Нильсен, Хенрик; Сандерс, Генри; Кристенсен, Эрик Д.; Уитема, Кристиан (июль 2002 г.). "draft-nielsen-dime-00 Прямая инкапсуляция интернет-сообщений (DIME)" . Проверено 11 февраля 2021 г.
^ Нильсен, Хенрик; Сандерс, Генри; Кристенсен, Эрик Д.; Уитема, Кристиан (июль 2002 г.). "draft-nielsen-dime-02 Прямая инкапсуляция интернет-сообщений (DIME)" . Проверено 11 февраля 2021 г.
^ Зальц, Рич (12 декабря 2003 г.). «Re: Где я могу узнать о текущем статусе DIME» . Архивировано из оригинала 27 сентября 2007 г. Проверено 31 октября 2006 г.
^ «Указательная страница характеристик сообщений» . Майкрософт . Архивировано из оригинала 6 июня 2011 г. Проверено 31 октября 2006 г.
^ «Техническая документация» .

Внешние ссылки

Обзор от Microsoft .
Ссылки на статьи о DIME
Последний проект IETF
Архив списка обсуждений DIME. Архивировано 5 декабря 2006 г. на Wayback Machine.

[1] Нильсен, Хенрик; Сандерс, Генри; Кристенсен, Эрик Д.; Уитема, Кристиан (июль 2002 г.). "draft-nielsen-dime-00 Прямая инкапсуляция интернет-сообщений (DIME)" . Проверено 11 февраля 2021 г.

[2] Нильсен, Хенрик; Сандерс, Генри; Кристенсен, Эрик Д.; Уитема, Кристиан (июль 2002 г.). "draft-nielsen-dime-02 Прямая инкапсуляция интернет-сообщений (DIME)" . Проверено 11 февраля 2021 г.

[3] Зальц, Рич (12 декабря 2003 г.). «Re: Где я могу узнать о текущем статусе DIME» . Архивировано из оригинала 27 сентября 2007 г. Проверено 31 октября 2006 г.

[4] «Указательная страница характеристик сообщений» . Майкрософт . Архивировано из оригинала 6 июня 2011 г. Проверено 31 октября 2006 г.

[5] «Техническая документация» .

[1]

[2]

[3]

[4]

[5]