【3.工程开发】-长连接

本篇是工程开发的网络一个分篇，整体见：https://segmentfault.com/a/11...。
概述
长连接原本核心只是消息推送和部分数据上报，一般公司里面当成IM用的会比较多
后来演变成一个通道，不只是IM，消息push，就连短连接也走这个通道。降低连接成本，端上到机房连接，尤其是位置上报push等场景。统一做加密，在多点接入时可以统一处理。

一. 外部连接

native APP使用TCP直连长连接域名，通过LVS/TGW的转发（gz机房为FULLNAT模式，QQ机房貌似是TUNNEL模式），连接到某个CONNSVR的对外服务端口上（支持加密和非加密两种），

二. 连接网络过程

此时APP与CONNSVR完成了TCP的三次握手，然后开始业务层面的握手，握手过程如下：

三.架构和功能

下行，push

● 业务向push推送数据，可能提供uid，也可能提供role+phone进行索引
● 如果是role+phone的形式，则push需要向AAASVR发起请求，使用role+phone获取uid，注意这里会导致AAASVR的流量增大很多
● PUSHSVR使用uid向CONNMASTER请求，获取用户所在的CONNSVR
● PUSHSVR将数据推给CONNSVR，后者推给app
● 如果用户不在线（step 3查询失败），或者CONNSVR发送失败， 则PUSHSVR根据消息推送的不同策略（由业务方指定），决定是否将消息写入REPUSHSVR，REPUSHSVR则会不停的将消息重新推回PUSHSVR进行重试

上行统一接入

• 统一接入后，依赖端上请求中Header携带的city_id，配合Apollo实现流量切换（可统一在LVS做）
• 过程
  1.App->Connsvr->Trans, 携带端上从HTTP请求转换来的内容，例如Header、Body等
  2.Trans->Connsvr->App, 这个用于快速回复App刚才发送的Req是否通过了拆包、路由检查等结果，因为App连接变动，这个包可能回不到App上
  3.Trans->Push->Connsvr->App, 这个和一般下行包类似链路，用于携带真正的HTTP RSP
• trans工作：
  1.接受Connsvr转发过来的REQ@PB
  2.配置路由，根据REQ@PB中的Scheme+Host+Uri，找到对应的内网Router VIP:VPORT
  3.翻译REQ@PB到REQ@HTTP，发往Router的内网VIP:VPORT(Router实质上变为了InRoute，域名变为了路由key)
  4.在Timeout内，维护REQ的信息（此时如果Trans down了，则状态丢失，引入缓存来维护state）
  5.收到服务端的RSP@HTTP后，翻译成RSP@PB，通过pushsvr发往App（Pushsvr会完成路由寻找和发送功能）

多点接入

统一