长连接

本篇是工程开发的网络一个分篇，整体见：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 会完成路由寻找和发送功能）

多点接入

引入长连接后建立连接的代价少，可以维持高速通道，就近设置接入点，接入点到真正的业务接入点之间可以走专线，更快