一般情况发送消息，把消息通过流发送给接收方{"MessageBody": "消息内容"}，但是作为聊天系统这样发送消息存在两个问题：1，接收方不知道如何解析消息，消息是文本还是图片，语音，视频和文件消息。2，图片语音视频文件等消息内容很大，就算现在网络环境很好，压缩比例很大，但是现在图片视频质量也越来越高。如果依靠发现送文本的端口和服务器发送图片和语音等消息，会一直占用连接，必须等大消息内容发送完毕，才能发送其他消息。
基于上面提出的问题，我们首先要把消息分成两个类型，第一个文本消息，第二个是图片，语音视频和文件等大内容的消息，我们把此类型消息归纳成一类文件消息，文本和文件消息分开发送。
目前普遍的做法有两种：
第一方式是文件消息另外创建一条网络连接，通过新的网络连接来发送消息给服务器，方式方法都跟发普通文件消息一样，弊端就是比如同时发送很多文件，如果只创建一个链接会导致文件发送堵塞，如果创建很多链接，增加了服务器维持连接的难度。所以现实中采用此方法的聊天软件中一般都会控制同时发送文件的数量，比如微信同时只允许发送9张图片，并且微信也不是同时创建9个连接，仅仅创建3个连接，同时发送的图片只有3张，一个连接发完一张图片后再发送另一张图片。
第二方式是通过Http来上传文件。以客户端A发送文件给客户端B为例，A首先把文件通过HTTP方式上传到服务器，文件上传完成后服务器服保存图片，并把文件的全局路径返回给上传的客户端A，客户端A把返回回来的路径作为文本消息再发送给服务器，服务器收到文本消息把消息发送给目标客户端B，目标客户端B收到文本消息后解析出文件的全局路径然后下载，这时整个文件传送过程完成。国外即时通讯系统一般采取此方式，比如WhatsApp。好处是http服务器天然的请求应答方式很容易满足需求，坏处是相对于消息体发送多了一次冗余的文本消息发送，而且需要对http保存的文件全局路径做权限控制，不然消息内容泄露会导致文件被任意下载。
本人倾向选择第二种模式，毕竟要处理的http和文件系统权限都有比较成熟的方案去选择使用。
