线上运行的 APISIX 为 1.5 版本，而社区已经发布了 Apisix 2.2，是时候需要升级到最新版了，能够享受最版本带来的大量的BugFix，性能增强，以及新增特性的支持等~

从Apisix 1.5升级到Apisix 2.2过程中，不是一帆风顺的，中间踩了不少坑，所谓前车之鉴后事之师，这里给大家简单梳理一下我们团队所在具体业务环境下，升级过程中踩的若干坑，以及一些需要避免的若干注意事项等。

下文所说原先版本，皆指Apisix 1.5，新版则是Apisix 2.2版本。

一、已有服务发现机制无法正常工作

针对上游Upstream没有使用服务发现的路由来讲，本次升级没有遇到什么问题。

公司内部线上业务大都基于Consul KV方式实现服务注册和服务发现，因此我们自行实现了一个 consul_kv.lua 模块实现服务发现流程。

这在Apisix 1.5下面一切工作正常。

但在Apisix 2.2下面，就无法直接工作了，原因如下：

• 服务发现配置指令变了
• 上游对象包含服务发现时需增加字段 discovery_type 进行索引

2.1 服务发现配置指令变了

原先运行中仅支持一种服务发现机制，需要配置在 apisix层级下面：

apisix:
    ......
    discover: consul_kv
    ......    

新版需要直接在config*.yaml文件中顶层层级下进行配置，可支持多种不同的路由发现机制，如下：

discovery:                      # service discovery center
  eureka:
    host:                       # it's possible to define multiple eureka hosts addresses of the same eureka cluster.
      - "http://127.0.0.1:8761"
    prefix: "/eureka/"
    fetch_interval: 30          # default 30s
    weight: 100                 # default weight for node
    timeout:
      connect: 2000             # default 2000ms
      send: 2000                # default 2000ms
      read: 5000

我们有所变通，直接在配置文件顶层配置consul_kv多个集群相关参数，避免 discovery 层级过深。

 discovery:
    consul_kv: 1
consul_kv:
  servers:
    -
      host: "172.19.5.30"
      port: 8500
    -
      host: "172.19.5.31"
      port: 8500
  prefix: "upstreams"
  timeout:
    connect: 6000
    read: 6000
    wait: 60
  weight: 1
  delay: 5
  connect_type: "long" # long connect
  ......

当然，这仅仅保证了服务发现模块能够在启动时被正常加载。

推荐阅读：

• https://github.com/apache/apisix/blob/master/doc/zh-cn/discovery.md#upstream-%E9%85%8D%E7%BD%AE

2.2 upstream对象新增字段discovery_type

Apisix当前同时支持多种服务发现机制，这个很赞。对应的代价，就是需要额外引入 discovery_type 字段，用于索引可能同时存在的多个服务发现机制。

以 Cousul KV方式服务发现为例，那么需要在已有的 upstream 对象中需要添加该字段：

"discovery_type" : "consul_kv"

原先的一个upstream对象，仅仅需要 service_name 字段属性指定服务发现相关地址即可：

{
    "id": "d6c1d325-9003-4217-808d-249aaf52168e",
    "name": "grpc_upstream_hello",
    ......
    "service_name": "http://172.19.5.30:8500/v1/kv/upstreams/grpc/grpc_hello",
    "create_time": 1610437522,
    "desc": "demo grpc service",
    "type": "roundrobin"
}

而新版的则需要添加discovery_type字段，表明该service_name 字段对应的具体模块名称，效果如下：

{
    "id": "d6c1d325-9003-4217-808d-249aaf52168e",
    "name": "grpc_upstream_hello",
    ......
    "service_name": "http://172.19.5.30:8500/v1/kv/upstreams/grpc/grpc_hello",
    "create_time": 1610437522,
    "desc": "demo grpc service",
    "type": "roundrobin",
    "discovery_type":"consul_kv"
}

后面我们若支持Consul Service或ETCD KV方式服务发现机制，则会非常弹性和清晰。

调整了配置指令，添加上述字段之后，后端服务发现其实就已经起作用了。

但gRPC代理路由并不会生效……

二、gRPC当前不支持upstream_id

在我们的系统中，上游和路由是需要单独分开管理的，因此创建的HTTP或GRPC路由需要处理支持upstream_id的索引。

这在1.5版本中，grpc路由是没问题的，但到了apisix 2.2版本中，维护者 @spacewander 暂时没做支持，原因是规划grpc路由和dubbo路由处理逻辑趋于一致，更为紧凑。从维护角度我是认可的，但作为使用者来讲，这就有些不合理了，直接丢弃了针对以往数据的支持。

作为当前Geek一些方式，在 apisix/init.lua 中，最小成本 （优雅和成本成反比）修改如下，找到如下代码：

    -- todo: support upstream id
    api_ctx.matched_upstream = (route.dns_value and
                                route.dns_value.upstream)
                               or route.value.upstream 

直接替换为下面代码即可解决燃眉之急：

    local up_id = route.value.upstream_id
    if up_id then
        local upstreams = core.config.fetch_created_obj("/upstreams")
        if upstreams then
            local upstream = upstreams:get(tostring(up_id))
            if not upstream then
                core.log.error("failed to find upstream by id: " .. up_id)
                return core.response.exit(502)
            end
            if upstream.has_domain then
                local err
                upstream, err = lru_resolved_domain(upstream,
                                                    upstream.modifiedIndex,
                                                    parse_domain_in_up,
                                                    upstream)
                if err then
                    core.log.error("failed to get resolved upstream: ", err)
                    return core.response.exit(500)
                end
            end
            if upstream.value.pass_host then
                api_ctx.pass_host = upstream.value.pass_host
                api_ctx.upstream_host = upstream.value.upstream_host
            end
            core.log.info("parsed upstream: ", core.json.delay_encode(upstream))
            api_ctx.matched_upstream = upstream.dns_value or upstream.value
        end
    else
        api_ctx.matched_upstream = (route.dns_value and
                                route.dns_value.upstream)
                               or route.value.upstream  
    end

三、自定义auth插件需要微调

新版的apisix auth授权插件支持多个授权插件串行执行，这个功能也很赞，但此举导致了先前为具体业务定制的授权插件无法正常工作，这时需要微调一下。

原先调用方式：

    local consumers = core.lrucache.plugin(plugin_name, "consumers_key",
            consumer_conf.conf_version,
            create_consume_cache, consumer_conf)

因为新版的lrucache不再提供 plugin 函数，需要微调一下：

local lrucache = core.lrucache.new({
  type = "plugin",
})
......
    local consumers = lrucache("consumers_key", consumer_conf.conf_version,
        create_consume_cache, consumer_conf)

另一处是，顺利授权之后，需要赋值consumer相关信息：

    ctx.consumer = consumer
    ctx.consumer_id = consumer.consumer_id

此时需要替换成如下方式，为（可能存在的）后续的授权插件继续作用。

consumer_mod.attach_consumer(ctx, consumer, consumer_conf)

更多请参考：apisix/plugins/key-auth.lua 源码。

四、ETCD V2数据迁移到V3

迁移分为三步：

1. 升级线上已有ETCD 3.3.*版本到3.4.*，满足新版Apisix的要求，这时ETCD实例同时支持了V2和V3格式数据
2. 迁移V2数据到V3
   • 因为数据量不是非常多，我采取了一个非常简单和原始的方式
   • 使用 etcdctl 完成V2数据到导出
   • 然后使用文本编辑器vim等完成数据的替换，生成etcdctl v3格式的数据导入命令脚本
   • 运行之后V3数据导入脚本，完成V2到V3的数据导入
3. 修改V3 /apisix/upstreams 中包含服务注册的数据，一一添加 "discovery_type" : "consul_kv"属性

基于以上操作之后，从而完成了ETCD V2到V3的数据迁移。

五、启动apisix后发现ETCD V3已有数据无法加载

我们在运维层面，使用 /usr/local/openresty/bin/openresty -p /usr/local/apisix -g daemon off; 方式运行网关程序。

这也就导致，自动忽略了官方提倡的：apisix start 命令自动提前为ETCD V3初始化的一些键值对内容。

因此，需要提前为ETCD V3建立以下键值对内容：

Key                         Value
/apisix/routes          :   init_dir
/apisix/upstreams       :   init_dir
/apisix/services        :   init_dir
/apisix/plugins         :   init_dir
/apisix/consumers       :   init_dir
/apisix/node_status     :   init_dir
/apisix/ssl             :   init_dir
/apisix/global_rules    :   init_dir
/apisix/stream_routes   :   init_dir
/apisix/proto           :   init_dir
/apisix/plugin_metadata :   init_dir

不提前建立的话，就会导致apisix重启后，无法正常加载ETCD中已有数据。

其实有一个补救措施，需要修改 apisix/init.lua 内容，找到如下代码：

            if not dir_res.nodes then
                dir_res.nodes = {}
            end

比较geek的行为，使用下面代码替换一下即可完成兼容：

                if dir_res.key then
                    dir_res.nodes = { clone_tab(dir_res) }
                else
                    dir_res.nodes = {}
                end

六、apisix-dashboard的支持

我们基于apisix-dashboard定制开发了大量的针对公司实际业务非常实用的企业级特性，但也导致了无法直接升级到最新版的apisix-dashboard。

因为非常基础的上游和路由没有发生多大改变，因此这部分升级的需求可以忽略。

实际上，只是在提交上游表单时，包含服务注册信息JSON字符串中需要增加 discovery_type 字段和对应值即可完成支持。

七、小结

花费了一些时间完成了从Apisix 1.5升级到Apisix 2.2的行为，虽然有些坑，但整体来讲，还算顺利。目前已经上线并全量部署运行，目前运行良好。

针对还停留在Apisix 1.5的用户，新版增加了Control API以及多种服务发现等新特性支持，还是非常值得升级的。

升级之前，不妨仔细阅读每一个版本的升级日志（地址：https://github.com/apache/apisix/blob/2.2/CHANGELOG.md ），然后需要根据具体业务做好兼容测试准备和准备升级步骤，这些都是非常有必要的。

针对我们团队来讲，升级到最新版，一方面降低了版本升级的压力，另一方面也能够辅助我们能参与到开源社区中去，挺好~

最近一段时间，要为一个手机终端APP程序从零开始设计一整套HTTP API，因为面向的用户很固定，一个新的移动端APP。目前还是项目初期，自然要求一切快速、从简，实用性为主。

下面将逐一论述我们是如何设计HTTP API，虽然相对大部分人而言，没有什么新意，但对我来说很新鲜的。避免忘却，趁着空闲尽快记录下来。

技术堆栈的选择

PHP嘛？团队内也没几个人熟悉。

Java？好几年没有碰过了，那么复杂的解决方案，再加上团队内也没什么人会 ……

团队使用过Lua，基于OpenResty构建过TCP、HTTP网关等，对Lua + Nginx组合非常熟悉，能够快速的应用在线上环境。再说Lua语法小巧、简单，一个新手半天就可以基本熟悉，马上开工。

看来，Nginx + Lua是目前最为适合我们的了。

HTTP API，需要充分利用HTTP具体操作语义，来应对具体的业务操作方法。基于此，没有闭门造车，我们选择了 http://lor.sumory.com/ 这么一个小巧的框架，用于辅助HTTP API的开发开发。

嗯，OpenResty + Lua + Lor，就构成了我们简单技术堆栈。

HTTP API简要设计

HTTP API路径和语义

每一具体业务逻辑，直接在URL Path中体现出来。我们要的是简单快速，数据结构之间的连接关系，尽可能的去淡化。eg：

/resource/video/ID

比如用户反馈这一模块，将使用下面比较固定的路径：

/user/feedback

• GET，以用户维度查询反馈的历史列表，可分页
  • curl -X GET http://localhost/user/feedback?page=1
• POST，提交一个反馈
  • curl -X POST http://localhost/user/feedback -d "content=hello"
• DELETE，删除一个或多个反馈，参数附加在URL路径中。
  • curl -X DELETE http://localhost/user/feedback?id=1001
• PUT，更新评论内容
  • curl -X PUT http://localhost/user/feedback/1234 -d "content=hello2"

用户属性很多，用户昵称只是其中一个部分，因此更新昵称这一行为，HTTP的 PATCH 方法可更精准的描述部分数据更新的业务需求：

/user/nickname

• PATCH，更新用户昵称，昵称是用户属性之一，可以使用更轻量级的 PATCH 语义
  • curl -X PATCH http://localhost/user/nickname -d "nickname=hello2"

嗯，同一类的资源URL虽然固定了，但HTTP Method呈现了不同的业务逻辑需求。

HTTP API的访问授权

实际业务HTTP API的访问是需要授权的。

传统的Access Token解决方案，有session回话机制，一般需要结合Web浏览器，需要写入到Cookie中，或生产一个JSessionID用于标识等。这针对单纯面向移动终端的HTTP API后端来讲，并没有义务去做这一的兼容，略显冗余。

另外就是 OAUTH 认证了，有整套的认证方案并已工业化，很是成熟了，但对我们而言还是太重，不太适合轻量级的HTTP API，不太可能花费太多的精力去做它的运维工作。

最终选择了轻量级的 Json Web Token，非常紧凑，开箱即用。

最佳做法是把JWT Token放在HTTP请求头部中，不至于和其它参数混淆：

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1aWQiOiI2NyIsInV0eXBlIjoxfQ.LjkZYriurTqIpHSMvojNZZ60J0SZHpqN3TNQeEMSPO8" -X GET http://localhost/user/info

下面是一副浏览器段的一般认证流程，这与HTTP API认证大体一致：

JWT的Lua实现，推荐: https://github.com/SkyLothar/lua-resty-jwt.git，简单够用。

JWT和Lor的结合

jwt需要和业务进行绑定，结合 lor 这个API开发框架提供的中间件机制，可在业务处理之前，在合适位置进行权限拦截。

• 用户需要请求进行授权接口，比如登陆等
• 服务器端会把用户标识符，比如用户id等，存入JWT的payload负荷中，然后生成Token字符串，发给客户端
• 客户端收到JWT生成的Token字符串，在后续的请求中需要附加在HTTP请求的Header中
• 完成认证过程

不同于OAUTH，JWT协议的自包含特性，决定了后端可以将很多属性信息存放在payload负荷中，其token生成之后后端可以不用存储；下次客户端发送请求时会发送给服务器端，后端获取之后，直接验证即可，验证通过，可以直接读取原先保存其中的所有属性。

下面梳理一下Jwt认证和Lor的结合。

• 全局拦截，针对所有PATH，所有HTTP Method，这里处理JWT认证，若认证成功，会直接把用户id注入到当前业务处理上下文中，后面的业务可以直接读取当前用户的id值

app:use(function(req, res, next)
    local token = ngx.req.get_headers()["Authorization"]
    -- 校验失败，err为错误代码，比如 400
    local payload, err = verify_jwt(token)
    if err then
        res:status(err):send("bad access token reqeust")
        return
    end

    -- 注入进当前上下文中，避免每次从token中获取
    req.params.uid = payload.uid

    next()
end)

• 针对具体路径进行设定权限拦截，较粗粒度；比如 /user 只允许已登陆授权用户访问

app:use("/user", function(req, res, next)
    if not req.params.uid then
        -- 注意，这里没有调用next()方法，请求到这里就截止了，不在匹配后面的路由
        res:status(403):send("not allowed reqeust")
    else
        next() -- 满足以上条件，那么继续匹配下一个路由
    end
end)

• 一种是较细粒度，具体到每一个API接口，因为虽然URL一致，但不同的HTTP Method有时请求权限还是有区别的

local function check_token(req, res, next)
    if not req.params.uid then
        res:status(403):send("not allowed reqeust")
    else
        next()
    end
end

local function check_master(req, res, next)
    if not req.params.uid ~= master_uid then
        res:status(403):send("not allowed reqeust")
    else
        next()
    end
end

local lor = require("lor.index")
local app = lor()

-- 声明一个group router
local user_router = lor:Router()

-- 假设查看是不需要用户权限的
user_router:get("/feedback", function(req, res, next)
end)

user_router:put("/feedback", check_token, function(req, res, next)
end)

user_router:post("/feedback", check_token, function(req, res, next)
end)

-- 只有管理员才有权限删除
user_router:delete("/feedback", check_master, function(req, res, next)
end)

-- 以middleware的形式将该group router加载进来
app:use("/user", user_router())

......

app:run()

为什么没有选择GraphQL API ？

我们在上一个项目中对外提供了GraphQL API，其（在测试环境下）自身提供文档输出自托管机制，再结合方便的调试客户端，确实让后端开发和前端APP开发大大降低了频繁交流的频率，节省了若干流量，但前期还是需要较多的培训投入。

但在新项目中，一度想提供GraphQL API，遇到的问题如下：

• 全新的项目数据结构属性变动太频繁
• 普遍求快，业务模型快速开发、调试
• 大家普遍对GraphQL API有些抵触，使用JSON输出格式的HTTP API是约定俗成的习惯选择

毫无疑问，以最低成本快速构建较为完整的APP功能，HTTP API + JSON格式是最为舒服的选择。

虽然有些担心服务器端的输出，很多时候还是会浪费掉一些流量，客户端并不能够有效的利用返回数据的所有字段属性。但和进度以及人们已经习惯的HTTP API调用方式相比，又微乎其微了。

小结

当前这一套HTTP API技术堆栈运行的还不错，希望能给有同样需要的同学提供一点点的参考价值 :))

当然没有一成不变的架构模型，随着业务的逐渐发展，后面相信会有很多的变动。但这是以后的事情了，谁知道呢，后面有空再次记录吧~

一天早上起来，偶然机会看到《环信支持千万并发即使通讯的技术要点》演示文档，简单翻阅之后，感觉干货很多，于是快速记下以下笔记。

一。IM协议和IM Server

XMPP确实很传统，WhatsApp选用了，同时经过压缩、精简（比如说user字符串使用u字符替代）处理，让XMPP轻量不少。

MQTT，如何实现群组、好友呢，这个是业务层面上事情，大家都订阅某一个主题Topic好了，属于业务拓展。

SIP，接触少。

微信私有协议ActivitySync，以前在博客上分享过。

正确拼写是WhatsApp，呵呵。

针对XMPP协议的改进，很有参考价值。

心跳单向四个字节，在XMPP协议下，估计应该是极限了吧。在私有协议协议下，一来一往两个字节足够。

文件传输方式，这是业界通用方式。

移动互联网环境下，用户永远在线，大家的共识。可是取决于手机有没有连接到服务器端，这是无法逾越的障碍。

Muc聊天室，业务层面改进。

这个针对使用OpenFire的同学，很有参考意义。

话说，我以前也安装过OpenFire，定制过在线聊天/咨询的代码。

二。移动网络环境下的网络、电量等客户端优化

IM或推送，建立长连接是必须的，可以节省TCP来回创建的开销，但断线之后，是否需要即刻重连，尤其是处于地铁、WIFI边缘地带，可能会造成重连风暴，需要添加稍加延迟连接机制。

针对发送的消息的回执，客户端一定要发送回执反馈，否则不知道是否发送成功与否。

流量跑马测速，心跳智能，压缩传输。

Android手机端优化措施，干货、细节很实用，可以直接拿来用，分享很给力，呵呵！

批量、合并数据请求/发送，增量更新，这是一个大家都应该使用的常规节省流量手段，应牢记！

难得的是，分享了：

2G 文件上传最佳buffer size 1024个字节，3G/4G下直接设置为10K

2G 文件下载最佳buffer size 2048个字节，3G/4G下 30K

绝对经验的总结，赞！

心很细，给出了频繁的属性访问直接声明protected/publish了，不创建新的Java对象只能static类型了。记得很久以前写J2ME程序时，就用过这样的方式。

实践中走过多少弯路才总结出来的同步、绘图、渲染页面惊艳，尤其是支持离线方式的数据同步机制，很受用。

三。百万级架构经验分享

虽然很简单，熟悉TCP/IP协议，这是毫无疑问。

无状态协议交互，才能够很容易水平横向扩展，也是当今共识。

让所有操作都要尽可能的异步

典型的按照机房进行完整部署，若不能够在DNS层面做到按照用户ID进行指派（HTTP DNS进行接入IP分配），那么就必须处理用户乱入机房的问题，必然要做到一些数据的跨机房的同步，大家都会采用增量式同步方式，跨机房一般常见30毫秒的延迟，批量形式增量同步，那都不叫事。

可以看到业务垂直切分，各个业务之间水平扩展。

貌似可以看到单元化CELL/SET架构的影子，但这只是自己的瞎猜而已。

PPT上架构图文字细节不甚清晰，再加上自己近视，分辨不太老好的，可以看到消息存储使用了Kafka（和数据库集群之间存定时拉取关系），分布式锁基于Zookeeper，前端LVS做负载均衡，业务非常垂直。

在PPT上只看到了两个机房，若用户量级上亿，可能需要扩展到第三个、第三机房，可能跨机房同步的压力就就凸显出来了。

四。小结

总之，干货不少，很给力，再次对刘少壮大牛表示感谢！

原PPT下载地址：http://vdisk.weibo.com/s/A0GI9rXObFMd

PS: 若有侵权，请及时告知。

微信可调研点很多，这里仅仅从协议角度进行调研，会涉及到微信协议交换、消息收发等。所谓“弱水三千，只取一瓢”吧。

杂七杂八的，有些长，可直接拉到最后看结论好了。

一。微信协议概览

微信传输协议，官方公布甚少，在微信技术总监所透漏PPT《微信之道—至简》文档中，有所体现。

纯个人理解：

因张小龙做邮箱Foxmail起家，继而又做了QQ Mail等，QQ Mail是国内第一个支持Exchange ActiveSync协议的免费邮箱，基于其从业背景，微信从一开始就采取基于ActiveSync的修改版状态同步协议Sync，也就再自然不过了。

一句话：增量式、按序、可靠的状态同步传输的微信协议。

大致交换简图如下：

如何获取新数据呢：

1. 服务器端通知，客户端获取
2. 客户端携带最新的SyncKey，发起数据请求
3. 服务器端生成最新的SyncKey连同最新数据发送给客户端
4. 基于版本号机制同步协议，可确保数据增量、有序传输
5. SyncKey，由服务器端序列号生成器生成，一旦有新消息产生，将会产生最新的SyncKey。类似于版本号

服务器端通知有状态更新，客户端主动获取自从上次更新之后有变动的状态数据，增量式，顺序式。

二。微信Web端简单调试

在线版本微信：

https://webpush.weixin.qq.com/

通过Firefox + Firebug组合调试，也能证实了微信大致通过交换SyncKey方式获取新数据的论述。

1. 发起GET长连接检测是否存在新的需要同步的数据

会携带上最新SyncKey

https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?callback=jQuery18306073923335455973_1393208247730&r=1393209241862&sid=s7c%2FsxpGRSihgZAA&uin=937355&deviceid=e542565508353877&synckey=1_620943725%7C2_620943769%7C3_620943770%7C11_620942796%7C201_1393208420%7C202_1393209127%7C1000_1393203219&_=1393209241865

返回内容：

 window.synccheck={retcode:"0",selector:"2"}

selector值大于0，表示有新的消息需要同步。

据目测，心跳周期为27秒左右。

2. 一旦有新数据，客户端POST请求主动获取同步的数据

https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid=s7c%2FsxpGRSihgZAA&r=1393208447375

携带消息体：

{"BaseRequest":{"Uin":937355,"Sid":"s7c/sxpGRSihgZAA"},"SyncKey":{"Count":6,"List":[{"Key":1,"Val":620943725},{"Key":2,"Val":620943767},{"Key":3,"Val":620943760},{"Key":11,"Val":620942796},{"Key":201,"Val":1393208365},{"Key":1000,"Val":1393203219}]},"rr":1393208447374}

会携带上最新的SyncKey，会返回复杂结构体JSON内容。

但浏览端收取到消息之后，如何通知服务器端已确认收到了？Web版本微信，没有去做。

在以往使用过程中，曾发现WEB端有丢失消息的现象，但属于偶尔现象。但Android微信客户端（只要登陆连接上来之后）貌似就没有丢失过。

3. 发送消息流程

1. 发起一个POST提交，用于提交用户需要发送的消息

   https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsendmsg?sid=lQ95vHR52DiaLVqo&r=1393988414386

发送内容：

{"BaseRequest":{"Uin":937355,"Sid":"lQ95vHR52DiaLVqo","Skey":"A6A1ECC6A7DE59DEFF6A05F226AA334DECBA457887B25BC6","DeviceID":"e937227863752975"},"Msg":{"FromUserName":"yongboy","ToUserName":"hehe057854","Type":1,"Content":"hello","ClientMsgId":1393988414380,"LocalID":1393988414380}}

相应内容：

{
"BaseResponse": {
"Ret": 0,
"ErrMsg": ""
}
,
"MsgID": 1020944348,
"LocalID": "1393988414380"
}

1. 再次发起一个POST请求，用于申请最新SyncKey

   https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/webwxsync?sid=lQ95vHR52DiaLVqo&r=1393988414756

发送内容：

{"BaseRequest":{"Uin":937355,"Sid":"lQ95vHR52DiaLVqo"},"SyncKey":{"Count":6,"List":[{"Key":1,"Val":620944310},{"Key":2,"Val":620944346},{"Key":3,"Val":620944344},{"Key":11,"Val":620942796},{"Key":201,"Val":1393988357},{"Key":1000,"Val":1393930108}]},"rr":1393988414756}

响应的（部分）内容：

"SKey": "8F8C6A03489E85E9FDF727ACB95C93C2CDCE9FB9532FC15B"  

1. 终止GET长连接，使用最新SyncKey再次发起一个新的GET长连接

   https://webpush.weixin.qq.com/cgi-bin/mmwebwx-bin/synccheck?callback=jQuery1830245810089652082181393988305564&r=1393988415015&sid=lQ95vHR52DiaLVqo&uin=937355&deviceid=e937227863752975&synckey=1620944310%7C2620944348%7C3620944344%7C11620942796%7C2011393988357%7C10001393930108&=1393988415016

三。微信Android简单分析

Windows桌面端Android虚拟机中运行最新版微信(5.2)，通过tcpdump/Wireshark组合封包分析，以下为分析结果。

0. 初始连接记录

简单记录微信启动之后请求：

11:20:35 dns查询 
dns.weixin.qq.com
返回一组IP地址

11:20:35 DNS查询
long.weixin.qq.com
返回一组IP地址，本次通信中，微信使用了最后一个IP作为TCP长连接的连接地址。

11:20:35
http://dns.weixin.qq.com/cgi-bin/micromsg-bin/newgetdns?uin=0&clientversion=620888113&scene=0&net=1
用于请求服务器获得最优IP路径。服务器通过结算返回一个xml定义了域名:IP对应列表。仔细阅读，可看到微信已经开始了国际化的步伐：香港、加拿大、韩国等。
具体文本，请参考：https://gist.github.com/yongboy/9341884

11:20:35
获取到long.weixin.qq.com最优IP，然后建立到101.227.131.105的TCP长连接

11:21:25
POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/getprofile HTTP/1.1  (application/octet-stream)
返回一个名为“micromsgresp.dat”的附件，估计是未阅读的离线消息

11:21:31
POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/whatsnews HTTP/1.1  (application/octet-stream)
大概是资讯、订阅更新等

中间进行一些资源请求等，类似于
GET http://wx.qlogo.cn/mmhead/Q3auHgzwzM7NR4TYFcoNjbxZpfO9aiaE7RU5lXGUw13SMicL6iacWIf2A/96
图片等一些静态资源都会被分配到wx.qlogo.cn域名下面

不明白做什么用途
POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/downloadpackage HTTP/1.1  (application/octet-stream)
输出为micromsgresp.dat文件

11:21:47
GET http://support.weixin.qq.com/cgi-bin/mmsupport-bin/reportdevice?channel=34&deviceid=A952001f7a840c2a&clientversion=620888113&platform=0&lang=zh_CN&installtype=0 HTTP/1.1 
返回chunked分块数据

11:21:49
POST http://short.weixin.qq.com/cgi-bin/micromsg-bin/reportstrategy HTTP/1.1  (application/octet-stream)

1. 心跳频率约为5分钟

上次使用Wireshark分析有误（得出18分钟结论），再次重新分析，心跳频率在5分钟左右。

2. 登陆之后，会建立一个长连接，端口号为8080

简单目测为HTTP，初始以为是双通道HTTP，难道是自定义的用于双通道通信的HTTP协议吗，网络上可见资料都是模棱两可、语焉不详。

具体查看长连接初始数据通信，没有发现任何包含"HTTP"字样的数据，以为是微信自定义的TCP/HTTP通信格式。据分析，用于可能用于获取数据、心跳交换消息等用途吧。这个后面会详谈微信是如何做到的。

2.0 初始消息传输

个人资料、离线未阅读消息部分等通过 POST HTTP短连接单独获取。

2.1 二进制简单分析

抽取微信某次HTTP协议方式通信数据，16进制表示，每两个靠近的数字为一个byte字节：

微信协议可能如下：

一个消息包 = 消息头 + 消息体

消息头固定16字节长度，消息包长度定义在消息头前4个字节中。

单纯摘取第0000行为例，共16个字节的头部:

00 00 00 10 00 10 00 01 00 00 00 06 00 00 00 0f

16进制表示，每两个紧挨着数字代表一个byte字节。

微信消息包格式： 1. 前4字节表示数据包长度，可变 值为16时，意味着一个仅仅包含头部的完整的数据包（可能表示着预先定义好的业务意义），后面可能还有会别的消息包 2. 2个字节表示头部长度，固定值，0x10 = 16 3. 2个字节表示谢意版本，固定值，0x01 = 1 4. 4个字节操作说明数字，可变 5. 序列号，可变 6. 头部后面紧跟着消息体，非明文，加密形式 7. 一个消息包，最小16 byte字节

通过上图（以及其它数据多次采样）分析：

1. 0000 - 0040为单独的数据包
2. 0050行为下一个数据包的头部，前四个字节值为0xca = 202，表示包含了从0050-0110共202个字节数据
3. 一次数据发送，可能包含若干子数据包
4. 换行符\n，16进制表示为0x0a，在00f0行，包含了两个换行符号
5. 一个数据体换行符号用于更细粒度的业务数据分割 是否蒙对，需要问问做微信协议的同学
6. 所有被标记为HTTP协议通信所发送数据都包含换行符号

2.2 动手试试猜想，模拟微信TCP长连接

开始很不解为什么会出现如此怪异的HTTP双通道长连接请求，难道基于TCP通信，然后做了一些手脚？很常规的TCP长连接，传输数据时(不是所有数据传输)，被wireshark误认为HTTP长连接。这个需要做一个实验证实一下自己想法，设想如下：

写一个Ping-Pong客户端、服务器端程序，然后使用Wireshark看一下结果，是否符合判断。

Java版本的请求端，默认请求8080端口：

C语言版本的服务器程序，收到什么发送什么，没有任何逻辑，默认绑定8080端口：

这里有一个现场图：

可以尝试稍微改变输出内容，去除换行符“\n”，把端口换成9000，试试看，就会发现Wireshark输出不同的结果来。

2.3 结论是什么呢？

若使用原始TCP进行双向通信，则需要满足以下条件，可以被类似于Wireshark协议拦截器误认为是HTTP长连接：

1. 使用80/8080端口（81/3128/8000经测试无效） 也许8080一般被作为WEB代理服务端口，微信才会享用这个红利吧。
2. 输出的内容中，一定要包含换行字符"\n"

因此，可以定性为微信使用了基于8080端口TCP长连接，一旦数据包中含有换行"\n"符号，就会被Wireshark误认为HTTP协议。可能微信是无心为之吧。

3. 新消息获取方式

1. TCP长连接接收到服务器通知有新消息需要获取
2. APP发起一个HTTP POST请求获取新状态消息，会带上当前SyncKey 地址为：http://short.weixin.qq.com/cgi-bin/micromsg-bin/reportstrategy HTTP/1.1，看不到明文
3. APP获取到新的消息，会再次发起一次HTTP POST请求，告诉服务器已确认收到，同时获取最新SyncKey 地址为：http://short.weixin.qq.com/cgi-bin/micromsg-bin/kvreport，看不到明文
4. 接受一个消息，TCP长连接至少交互两次，客户端发起两次HTTP POST请求
   具体每次交互内容是什么，有些模糊
   
5. 服务器需要支持：状态消息获取标记，状态消息确认收取标记。只有被确认收到，此状态消息才算是被正确消费掉
6. 多个不同设备同一账号同时使用微信，同一个状态消息会会被同时分发到多个设备上

此时消息请求截图如下：

4. 发送消息方式

发送消息走已经建立的TCP长连接通道，发送消息到服务器，然后接受确认信息等，产生一次交互。

小伙伴接收到信息阅读也都会收到服务器端通知，产生一次交互等。

可以确定，微信发送消息走TCP长连接方式，因为不对自身状态数据产生影响，应该不交换SyncKey。

• 在低速网络下，大概会看到消息发送中的提示，属于消息重发机制
• 网络不好有时客户端会出现发送失败的红色感叹号
• 已发送到服务器但未收到确认的消息，客户端显示红色感叹号，再次重发，服务器作为重复消息处理，反馈确认
• 上传图片，会根据图片大小，分割成若干部分（大概1.5K被划分为一部分），同一时间点，客户端会发起若干次POST请求，各自上传成功之后，服务器大概会合并成一个完整图片，返回一个缩略图，显示在APP聊天窗口内。APP作为常规的文字消息发送到服务器端
• 上传音频，则单独走TCP通道，一个两秒的录制音频，客户端录制完毕，分为两块传输，一块最大1.5K左右，服务端响应一条数据通知确认收到。共三次数据传输。
  音频和纯文字信息一致，都是走TCP长连接，客户端发送，服务器端确认。

四。微信协议小结

1. 发布的消息对应一个ID（只要单个方向唯一即可，服务器端可能会根ID判断重复接收），消息重传机制确保有限次的重试，重试失败给予用户提示，发送成功会反馈确认，客户端只有收到确认信息才知道发送成功。发送消息可能不会产生新SyncKey。
2. 基于版本号（SynKey）的状态消息同步机制，增量、有序传输需求水到渠成。长连接通知/短连接获取、确认等，交互方式简单，确保了消息可靠谱、准确无误到达。
3. 客户端/服务器端都会存储消息ID处理记录，避免被重复消费客户端获取最新消息，但未确认，服务器端不会认为该消息被消费掉。下次客户端会重新获取，会查询当前消息是否被处理过。根据一些现象猜测。
4. 总体上看，微信协议跨平台（TCP或HTPP都可呈现，处理方式可统一），通过“握手”同步，很可靠，无论哪一个平台都可以支持的很好
5. 微信协议最小成本为16字节，大部分时间若干个消息包和在一起，批量传输。微信协议说不上最简洁，也不是最节省流量，但是非常成功的。
6. 若服务器检测到一些不确定因素，可能会导致微启用安全套接层SSL协议进行常规的TCP长连接传输。短连接都没有发生变化
   
   

以上，根据有限资料和数据拦截观察总结得出，啰啰嗦嗦，勉强凑成一篇，会存在一些不正确之处，欢迎给予纠正。在多次

五。附录

Microsoft Exchange Active Sync协议，简称EAS，分为folderrsync(同步文件夹目录，即邮箱内有哪几个文件夹)和sync（每个文件夹内有哪些文档）两部分。

某网友总结的协议一次回话大致示范：

Client:   synckey=0 //第一次key为0
Server:  newsynckey=1235434    //第一次返回新key
Client:   synckey=1235434   //使用新key查询
Server:  newsynckey=1647645,data=*****//第一次查询，得到新key和数据
Client:   synckey=1647645
Server:  newsynckey=5637535,data=null //第二次查询，无新消息
Client:   synckey=5637535
Server: newsynckey=8654542, data=****//第三次查询，增量同步

• 上页中的相邻请求都是隔固定时间的，如两分钟
• 客户端每次使用旧key标记自己的状态，服务端每次将新key和增量数据一起返回。
• key是递增的，但不要求连续
• 请求的某个参数决定服务器是否立即返回