本文在编写时参考了博客作者“鹿呦呦”和在线课程“即时消息技术剖析与实战”的相关资料，一并表示感谢。1、系列文章引言IM系统看似简单（没错，很多土老板认为开发个qq和微信也就是几万块钱的事... ），实责是众多技术的应用合体，包括网络编程、移动开发、后端开发、高并发、高可用、高安全等技术范畴，再加上多端使用不同的编程语言，想要凑齐一个

随着数字通讯的飞速发展“IM办公(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fwww.yinmaisoft.com%2F%3Ffrom%3Dseo)”模式普遍被事企单位接受，那么IM是什么？IM的定义即时消息传递，通常称为IM，是一种类似电子邮件的联机通信方式

发送消息UDP打洞,登录的时候HTTP。登录成功后，会有一个TCP连接来保持在线状态。这个TCP连接的远程端口一般是80，采用UDP方式登录的时候，端口是8000。如果采用UDP协议，通过服务器中转方式。UDP协议是不可靠协议，它只管发送，不管对方是否收到的。如果client使用UDP协议发送消息后，服务器收到该包，需要使用UDP协议发回一个

1、点评IM聊天消息的可靠投递，是每个线上产品都要考虑的IM热点技术问题。IM聊天消息能保证可靠送达，对于用户来说，就好比把钱存在银行不怕被偷一样，是信任的问题。试想，如果用户能明显感知到聊天消息无法保证送达，谁还愿意来用你的APP？谁也不希望自已的话就像浮云一样随风飘逝。必竟用IM聊天，虽然很多时候是费话，但总有关键时刻存在——比如向

1、前言一个安全的信息系统，合法身份检查是必须环节。尤其IM这种以“人”为中心的社交体系，身份认证更是必不可少。一些PC时代小型IM系统中，身份认证可能直接做到长连接中（也就是整个IM系统都是以长连接为中心：身份鉴权、数据收发、文件传送等等）。但当前主流的IM（尤其新一代的移动端IM）中，都是“长”（指TCP或UDP长连接）、“短”（是指H

IM协议设计在实际开发中，为了及时的通知APP端一些事情，我们会借助第三方平台，进行推送。今天，我们来分析一下推送系统协议。推送系统遇到的问题在设计协议之前，我们考虑一些实际的问题：1.APP没有一个固定的网络地址，只能通过主动连接服务器，建立TCP长链接，来进行推送。2.移动环境下，AP

1、前言IM的群聊消息，究竟存1份（即扩散读方式）还是存多份（即扩散写方式）？上一篇文章《IM群聊消息的已读回执功能该怎么实现？(https://www.oschina.net/action/GoToLink?urlhttp%3A%2F%2Fwww.52im.net%2Fthread161111.html)》是说，

产品经理的需求是，App端需要集成腾讯云(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fl.gushuji.site%2Ftencent)IM来接收消息。在技术层面有两个实现方案：1.如果App端只需要收发IM消息，不涉及远程推送功能，则可以使用腾讯云(https://ww

IM业务涉及许多技术点，比如点对点通信，组播，实时语音和视频等等，不同的业务也是需要用不同的协议去实现。近期我们的项目面临许多IM业务比如群聊，群语音，群组播等等；有关IM的技术虽然我们有研究一段时间，但是受时间限制就只能先用了第三方でserver。语音技术不太熟悉，这里就基本的IM通信对我学习到的个别几个协议进行对比和说明（不熟悉的协议我就略过了）