Прямая инкапсуляция интернет-сообщений (DIME) — интернет-стандарт, предложенный корпорацией Microsoft в начале 2000-х годов для потоковой передачи двоичных и других инкапсулированных данных через Интернет.
Согласно веб-сайту IETF , стандарт был отозван и никогда не имел статуса RFC . Однако Microsoft в свое время рекомендовала DIME для передачи файлов через веб-сервисы . Он также использовался в Java EE , но различия в реализации протокола затрудняли это. [ необходима цитата ]
Первая версия [1] была представлена в IETF в ноябре 2001 года; последнее обновление [2] было представлено в июне 2002 года. К декабрю 2003 года DIME проиграл в конкуренции с Message Transmission Optimization Mechanism и SOAP with Attachments . [3] Microsoft теперь описывает DIME как «замененный спецификацией SOAP Message Transmission Optimization Mechanism (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. Это не подрывало аспекты безопасности, поскольку проблема все равно возникала, просто он принимал, что двоичный трафик был нормой на этом порту, и не давал многочисленных ложных срабатываний .