Step 1 - 明确需求
一些可供参考的需求讨论点：
- 哪种类型的聊天系统，一对一还是群聊？=>都支持
- 移动端 or 网页端 or both？=> both
- 用户规模多大？适用于初创公司还是大公司？=> 日活按5000万计算
- 群聊人数有限制吗？=> 最多100人
- 需要支持哪些特性？支持附件吗？=>一对一，群聊，上线提示，只支持文本。
- 消息大小有限制吗？=>单条不超过1万字
- 需要端对端加密吗？=>当前不需要，后续可能需要
- 聊天记录需要保持多久？=>永久保存
接下来以下面的需求作为系统设计的目标：
- 一对一低延时聊天系统
- 支持最多100人的群聊
- 上线提示
- 多平台同时线支持。
- 消息通知推送。
- 日活5000万。
Step 2 - 高阶设计
客户端与客户端不直接通信，而是通过聊天服务进行通信，聊天服务需要支持以下特性：
- 从客户端接收消息
- 将消息发送给接收者
- 如果接收者不在线，则将消息暂存起来，直到接收者上线
客户端上线时需要与聊天服务建立连接，这里涉及到连接协议的问题。对于客户端来说，使用HTTP协议是一个常见的选择，客户端使用HTTP协议向服务端发起请求，并且将聊天内容和接收者附加在HTTP消息中，聊天服务器收到HTTP请求后会将消息转发给接收者。客户端和服务器之间使用保活维持聊天连接，减少TCP握手次数。
使用HTTP协议对于客户端来说很方便，但是对于服务端来说就比较复杂了，因为HTTP请求只能由客户端发起，这就导致服务端无法主动发起会话。有很多针对服务端主动发起会话的技术，包括轮询，长轮询，WebSocket。
轮询
指客户端循环检测服务器是否有新消息。根据循环的间隔，轮询可能非常占用资源，导致系统效率低。
长轮询
针对轮询系统效率低的问题，发展出了长轮询。长轮询是指客户端向查询服务器端是否有新消息时，不立即返回，而是等服务器有消息，或是超时之后再返回，这种方式有以下缺点：
- 发送者和接收者可能不在同一个聊天服务器上。HTTP协议通常是无状态的，如果使用轮转的方式做负载均衡，则有可能发送者和接收者不在同一个聊天服务器上。
- 服务器无法判断客户端是否下线。
- 效率不高。如果用户发送聊天信息不频繁，那么维护长轮询也会导致周期性的重连。