Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Прямая инкапсуляция Интернет-сообщений ( 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 страдает той же проблемой.) В альтернативном и, вероятно, лучшем решении критерии успешного запроса (например, имя пользователя и пароль) устанавливаются вне полосы пропускания, поэтому его можно отправить с сообщением в первый раз и не получить вызов (побочным продуктом протокола HTTP без установления соединения является то, что, поскольку каждое сообщение обрабатывается индивидуально,любое сообщение должно иметь возможность успешно включать свой ответ на запрос).

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

Проблемы на сетевом уровне [ править ]

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

См. Также [ править ]

Ссылки [ править ]

  1. ^ "draft-nielsen-dime-00 Прямая инкапсуляция сообщений в Интернете (DIME)" . Проверено 11 февраля 2021 .
  2. ^ "draft-nielsen-dime-02 Прямая инкапсуляция сообщений в Интернете (DIME)" . Проверено 11 февраля 2021 .
  3. Перейти ↑ Salz, Rich (2003-12-12). «Re: Где я могу узнать о текущем состоянии DIME» . Архивировано из оригинала на 2007-09-27 . Проверено 31 октября 2006 . CS1 maint: обескураженный параметр ( ссылка )
  4. ^ «Индексная страница спецификаций обмена сообщениями» . Microsoft . Архивировано из оригинала 2011-06-06 . Проверено 31 октября 2006 . CS1 maint: обескураженный параметр ( ссылка )
  5. ^ http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service01152002.asp

Внешние ссылки [ править ]

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