【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會完成路由尋找和發送功能）

多點接入

統一