学习总结：即时通信的方式

近段时间对微信等即时通信工具的通信方式很是好奇，就学习钻研了一下，粗浅心得记录如下。
一、长连接
客户端好比风筝，长连接好比牵着风筝的线，线的这一端系在服务器的“手里”。“风筝”漫天飞，IP号很可能不停地变，每变一次，客户端就将新IP号告诉服务器，以确保长连接通畅。服务器若想找那个客户端，只用通过长连即可。长连接的存在与客户端的IP号老是变化有重要关系。
IM服务器（即时通信服务器）总是“一对多”，一台服务器同时维持百万级别的长连接应该不罕见。这么多客户端如果长时间（比如4.5分钟，或30分钟）不与服务器通信，通信系统就会“掐断”这个联系。为了不被掐断，就每隔一段时间（小于掐断时间，如4.4分钟、29分钟）“假”联系一次（比如发一个空包），告诉通信系统：我们还联系着呢！这就是“心跳”。
二、即时通信的“通信方式”
方式一：只通过TCP连接，如下图:

通过TCP连接，可靠性高，适用于诸如QQ、微信、支付宝等通信软件的账户登录和支付相关功能。其缺点是时延较长，但由于已经建立了长连接，省去了连接时间，而且使用场景对时间要求不高，使用频率较低，这种较长时延还是可以接受的。比如超市付款，等待后台反应时间，0.1秒和0.5秒的消费体验差距不大。但这种较长时延放在文字聊天、视频通话上，体验是很糟糕的。
方式二：客户端、服务器之间的“双向UDP连接”
“简单文字信息”传递，如下图:

A和B之间通过IM中转连接。A和IM、B和IM之间都是双向UDP连接。比如A和IM之间，A要向B发信息，先以UDP方式将信息发给IM，IM收到信息后，马上以UDP方式给A一个反馈：我收到了！这就是双向UDP连接。随后IM再把该信息以UDP方式传给B，B收到信息后，马上以UDP方式给IM一个反馈：我收到了。
UDP连接信息传递快，时延低，适合聊天场景，为了克服其传递信息不可靠的缺点，再多加一个对方的反馈：如果信息发过去，一定时间内没有反馈，说明对方可能没收到信息，那就再发一遍，或给出“信息传递失败”提示。即使带上反馈，总时延可能也是用户无法察觉的。
“大文件”（视频、图片、音频等）的传递，如下图:

这种情况与传递简单文字信息相似，不同的是此时通过IM中转的不是信息的内容，而是信息存储的地址。A发送信息之前，先把文件存储在“文件服务器”中，将返回的地址传给IM，IM再把地址信息传给B，让B根据地址，去“文件服务器”自取。
此过程时延较长，但使用频率不大，用户总体体验还行。
方式三：点对点UDP连接，如下图：

首先，A从客户端获取B的IP及状态（如是否在线），将数据打成“包”，源源不断地向B“扔去”，B也将要发送的数据打成包，源源不断地向A“扔过来”。这其中应该有一些技术手段保障接收到的数据包尽量少丢包、不乱序。
以前学UDP时，总是迷迷糊糊，书本上讲的一带而过，感觉UDP就像“广播”，漫无目的地“播送”，其实不然。UDP方式下要向某客户端发数据包，必然要知道对方的IP，就像投篮必然要知道篮筐在哪里。而对方的IP总在变化（一会用流量，一会用WiFi），要想时刻知道对方的IP，必然要用到服务器到客户端的长连接，通过长连接，服务器才能清楚知道客户端的IP。这些知识，在讲UDP时大多书本没说清楚，讲得初学者如坠云雾。UDP连接由于有其速度快的优越性，其不可靠性又可以通过技术手段大大降低，在现实中被广泛应用（视频/语音聊天、视频会议、直播等），但书本上具体应用的介绍却偏少了。
三、心得体会
写此文之前，觉得都想清楚了，可真提笔写时，又觉得困难重重：一些原理还是没搞清楚，一些名词还有待进一步确认，示意图怎么画，材料怎么组织；可真正写出来了，觉得脑子清晰多了，收获多多，力量倍增，有一种征服的快感。
所以，一个阶段的学习之后，要总结总结，写一写，整理一下脑子，做一下记录，从而有真正的提高。
要有想法，更要勇于、善于将想法变成现实。