MTOM 是如何工作的？
MTOM 是 W3C 消息传输优化机制，是一种高效地向 Web 服务发送二进制数据或从 Web 服务发送二进制数据的方法。
它一般如何运作？
MTOM is the W3C Message Transmission Optimization Mechanism, a method of efficiently sending binary data to and from web services.
How does it work in general?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这一切都始于 SOAP 是XML这一事实。 当您发送文本以外的任何内容（例如图像）时，必须将其转换为 XML 处理器可以理解的数据类型。
如果没有 MTOM，您的图像将被转换为 base64Binary 并放置在 SOAP 信封的中间。 这个转换过程使得数据变得很胖。
这是一个简单的说明：
使用 MTOM，图像将被传输到外部信封作为 MIME 附件 - 简而言之，它根据其原始数据类型发送：jpg、png 或 gif。 当然，它仍然以二进制数据的形式传输，但这一次，没有 XML 相关的转换，避免了计算开销。 XOP 之所以出现，是因为它给出了外部化图像的位置。
It all begins with the fact that SOAP is XML. And when you send anything other than text, for instance, an image - it has to be converted into a datatype that an XML processor can understand.
Without MTOM, your image will be converted to base64Binary and placed smack in the middle of your SOAP envelope. This conversion process makes the data fat.
Here's a simple illustration:
With MTOM, the image will be transmitted outside the envelope as a MIME attachment - in short, it's sent according to its original datatype: a jpg, png, or gif. Of course it's still transmitted as binary data, but this time, there's no XML-related conversion, avoiding the computational overhead. XOP comes into the picture as it's the one that gives the location of the externalized image.
如果您放置 Wireshark （或启用 System.Net Logging) 在非 MTOM 启用的服务上，您应该看到带有编码为 BASE64 的二进制数据的 SOAP 请求。 将其作为 BASE64 发送会增加二进制数据的大小，但（我认为）使其更具互操作性。
使用 MTOM，SOAP 消息作为 MIME 消息发送，其中 BASE64 编码被替换为占位符。 然后，二进制数据被放置在分隔符之间（每段二进制数据都会发生这种情况），然后放置在 SOAP 请求的末尾。 然后二进制数据以未编码的形式发送。 IIRC、MTOM 还确定将其作为 MIME 消息发送是否会增加 SOAP 调用的大小，如果不提供节省，则会将其作为普通 SOAP 消息发送。
这提供了消息发送内容的示例在电线上看起来像。
If you put Wireshark (or enabled System.Net Logging) on the non-MTOM enabled service, you should see the SOAP requests with the binary data encoded as BASE64. Sending it as BASE64 increases the size of the binary data but (I assume) makes it more interoperable.
With MTOM, the SOAP messages are sent as MIME messages with the BASE64 encoding being replaced with a placeholder. The binary data is then placed between delimiters (which happens for each piece of binary data), and then placed at the end of the SOAP request. The binary data is then sent unencoded. IIRC, MTOM also determines whether sending it as a MIME message will increase the size of the SOAP call and if doesn't provide a saving, it will send it as a normal SOAP message.
This provides an example of what the message sent over the wire looks like.
有一些其他答案没有提到的因素。 人们可能会想为什么 MTOM 不用作默认值，因为它比文本消息编码 (Base64)“更快”。 这是因为 MTOM 并不总是更快。 MTOM 只能用于大型消息传输，因为它会带来开销。 对于小尺寸消息，MTOM 的性能会比文本消息编码 (Base64) 差。
如果 MTOM 用于大型消息，它比 Base64 更快，因为它使用原始二进制文件进行数据传输。 要理解这一点，我们应该了解 Base64 的工作原理。
Base64使用6位(log2(64))来表示1个字符，这意味着base64使用4个字符来表示24位( 3 个字节）。 因此，如果消息大小为 n 字节，base64 将使用 4*(n/3) 字节 来表示您的数据，这意味着它会慢 1/ 3 比 MTOM 低。
There are a few factors that other answers don't mention. One might think why MTOM is not used as default since it's "faster" than Text message encoding (Base64). It's because MTOM is not faster always. MTOM should only be used on large message transfers because it comes with an overhead. For small size of messages, MTOM's performance will be worse than Text message encoding (Base64).
If MTOM is used for large messages, it's faster than Base64 since it uses raw binary for data transfer. To understand that, one should understand how Base64 works.
Base64 uses 6 bits (log2(64)) to represent 1 character which means that base64 uses 4 characters to represent 24 bits (3 bytes). So if the message size is n bytes, base64 will use 4*(n/3) bytes to represent your data which means it will be slower by 1/3 than MTOM.