http | websocket 实现的 b/s 架构稳定性哪个好？

Question

http ，属于 短链接，现在可以通过 keep-alive 头可以维持一定时间内连接的存活时间。本质是 tcp 连接。

websocket 属于长连接，第一次发起 http 请求，服务端响应协议升级的响应建立 websocket 连接。本质是 tcp 连接。

我采取纯 websocket 的方式开发了一款即时通信产品：

• 嗨聊-OJBK 网页版，网页版需要配合 app 扫码登录
• 嗨聊-OJBK app 下载

然而出现了非常令人头痛的 断线 问题。在弱网的环境下，比如 wifi 信号很弱的情况下，app 的表现非常糟糕，由于采取纯 websocket ，app 所有的请求都依赖于 ws 连接，而弱网环境下，客户端很容易断线，一旦断线整个 app 都不可用！这个非常糟糕。又 ws 重连会耗费一定的时间（ws 察觉网络断开或者 ping 设置的延迟时间都会额外增加一些时间）,且目前客户端程序上没有做失败的请求队列，断线期间发送的请求如果失败，重连成功后并不会重新发起请求，这导致 app 在不稳定的网络环境下使用表现非常糟糕。

如果不采取纯 websocket 的开发方式，而是采取：

• 登录/注册/会话列表/好友列表/群列表等非消息发送（及时性要求不高的）的请求采取 http 请求的方式。
• 消息发送等及时性要求高的请求采取 ws 请求的方式

以上这种方式是否稳定性会更好？

但我这边又有一个疑问，http|websocket 本质上都是 tcp 连接，不同点在于 http 每次请求都会建立一个新连接，websocket 则使用单个连接。如果 websocket 发生了断线导致请求失败的话，http 按道理来说应该也是无法请求成功的，因为 websocket 都已经断线了，说明网络环境是真的不好，然后同为 tcp 本质的 http 如果在这种环境下发起请求，实际上也是请求建立 tcp 连接，那肯定也无法成功建立，所以，我左思右想都觉得 websocket 和 http 稳定性应该是一样的，然后他们不同的地方应该在于 http 的开发 比 websocket 开发便利，而 websocket 由于是长连接，性能上却优于 http。

以上都是个人见解，请问即时通信程序开发一般采取怎样的开发方式？他们是如何移动端网络环境恶劣情况下的稳定通信的？

Answer 1

1. 是否要即时消息ws，非即时消息http
   都可以
2. ws中断期间的请求丢失
   请求一定要考虑失败，如果不考虑，使用http也是一样有问题的
3. ws不通畅，http是不是也不行
   是的。
   如果不是，说明是http的用例处理了请求失败的情况
4. 其他人如何应对
   他们都用loading，必要请求就全局loading，非必要请求就局部loading，例如，打开APP后请求auth，那么就是全局loading，请求成功前禁止所有操作；例如发送消息，就局部loading，在收到成功的响应前，那条消息边上一直有loading状态，明确的让用户知道这条消息还没有发送成功，而且需要处理失败情况，例如消息发送的请求没有收到响应（或者服务器返回错误响应）就在那条消息上作出提示
   所以，谁也避免不了网络问题，只要你让用户知道现在是“网络有问题了”，用户也不会怪你这个APP。