MTOM如何工作？
MTOM是W3C消息传输优化机制，这是一种向Web服务高效发送二进制数据的方法。
它一般如何工作？
如果您将Wireshark （或启用的System.Net日志logging ）放在启用非MTOM的服务上，则应该看到带有编码为BASE64的二进制数据的SOAP请求。 发送它作为BASE64增加二进制数据的大小，但（我认为）使其更具互操作性。
使用MTOM，SOAP消息作为MIME消息发送，BASE64编码被占位符replace。 然后将二进制数据放在分隔符（每一个二进制数据都发生）之间，然后放在SOAP请求的末尾。 二进制数据然后被发送未编码。 IIRC，MTOM还会决定是否将它作为MIME消息发送将增加SOAP调用的大小，如果不提供保存，则会将其作为正常的SOAP消息发送。
这提供了通过线路发送的消息的示例。
这一切都始于SOAP是XML的事实。 而当您发送除文本以外的任何内容时，例如图像 – 必须将其转换为XML处理器可以理解的数据types。
如果没有MTOM，你的图像将被转换为base64Binary，并放在你的SOAP信封的中间。 这个转换过程使数据变胖。
<tns：data>非常looooooooooooooooooooooong base64Binarystring</ tns：data>
这是一个简单的例子：
使用MTOM，图像将作为MIME附件发送到信封之外 – 简言之，它将根据其原始数据types发送：jpg，png或gif。 当然，它仍然是作为二进制数据传输的，但是这次没有XML相关的转换，避免了计算开销。 XOP进入图像，因为它是给出外在化图像的位置。
<soap:Envelope> <soap:Body> <tns:data> <xop:include href="SomeUniqueID-ThatLeadsToTheImage"/> </tns:data> </soap:Body> </soap:Envelope> Content-id：“SomeUniqueID”
内容types：image / png图像二进制数据
有其他答案没有提到的几个因素。 有人可能会想，为什么MTOM不被用作默认值，因为它比文本消息编码（Base64） “更快” 。 这是因为MTOM总是不快。 MTOM只能用于较大的消息传输，因为它带有一个开销。 对于小尺寸的消息，MTOM的性能会比文本消息编码（Base64）差。
如果MTOM用于大消息，它比Base64更快，因为它使用原始二进制数据传输。 要了解这一点，应该了解Base64是如何工作的。
Base64使用6位（log2（64））表示1个字符 ，这意味着base64使用4个字符来表示24位（ 3个字节 ）。 所以如果消息大小是n个字节 ，base64将使用4 *（n / 3）字节来表示您的数据，这意味着它将比MTOM 慢三分之一 。
