久久男人天堂,国产在线一区二区综合免费视频,久久亚洲精品成人

Apisix 1.5 升��?2.2 �t�坑备忘

nieyong — Tue, 23 Feb 2021 06:57:00 GMT

零、前�a�

�U�上�q�行�?APISIX �?1.5 版本�Q�而社区已�l�发布了 Apisix 2.2�Q�是时候需要升�U�到最新版了，能够享受最版本带来的大量的BugFix�Q�性能增强�Q�以及新增特性的支持�{�~

从Apisix 1.5升��到Apisix 2.2�q�程中，不是一帆风��的�Q�中间踩了不��坑�Q�所谓前车之鉴后事之师，�q�里�l�大家简单梳理一下我们团队所在具体业务环境下�Q�升�U�过�E�中�t�的若干坑，以及一些需要避免的若干注意事项�{��?/p>

下文所说原先版本，皆指Apisix 1.5�Q�新版则是Apisix 2.2版本�?/p>

一、已有服务发现机制无法正常工�?/h2>
针对上游Upstream没有使用服务发现的�\由来�Ԍ��本次升��没有遇到什么问题�?/p>
公司内部�U�上业务大都��Z��Consul KV方式实现服务注册和服务发玎ͼ�因此我们自行实现了一�?`consul_kv.lua` 模块实现服务发现��程�?/p>
�q�在Apisix 1.5下面一切工作正常�?/p>
但在Apisix 2.2下面�Q�就无法直接工作了，原因如下�Q?/p>

服务发现配置指��o变了

上游对象包含服务发现旉��增加字段 `discovery_type` �q�行索引

2.1 服务发现配置指��o变了

原先�q�行中仅支持一�U�服务发现机�Ӟ��需要配�|�在 apisix层��下面�Q?/p>

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

新版需要直接在config*.yaml文�g中顶层层�U�下�q�行配置�Q�可支持多种不同的�\由发现机�Ӟ��如下�Q?/p>

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多个集群相关参数�Q�避�?discovery 层��q�深�?/p>

 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
  ......

当然�Q�这仅仅保证了服务发现模块能够在启动时被正常加蝲�?/p>

2.2 upstream对象新增字段discovery_type

Apisix当前同时支持多种服务发现机制�Q�这个很赞。对应的代�h�Q�就是需要额外引�?discovery_type 字段�Q�用于烦引可能同时存在的多个服务发现机制�?/p>

�?Cousul KV方式服务发现��Z��Q�那么需要在已有�?upstream 对象中需要添加该字段�Q?/p>

"discovery_type" : "consul_kv"

原先的一�?code>upstream对象�Q�仅仅需�?service_name 字段属性指定服务发现相兛_��址卛_��Q?/p>

{
    "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"
}

而新版的则需要添�?code>discovery_type字段�Q�表明该service_name 字段对应的具体模块名�U�ͼ�效果如下�Q?/p>

{
    "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方式服务发现机制�Q�则会非常弹性和清晰�?/p>

调整了配�|�指令，��d��上述字段之后�Q�后端服务发现其实就已经起作用了�?/p>

但gRPC代理路由�q�不会生�?#8230;…

二、gRPC当前不支持upstream_id

在我们的�pȝ��中，上游和�\由是需要单独分开��理的，因此创徏的HTTP或GRPC路由需要处理支�?code>upstream_id的烦引�?/p>

�q�在1.5版本中，grpc路由是没问题的，但到了apisix 2.2版本中，�l�护�?@spacewander 暂时没做支持�Q�原因是规划grpc路由和dubbo路由处理逻辑��于一��_��更�ؓ紧凑。从�l�护角度我是认可的，但作��Z��用者来�Ԍ��q�就有些不合理了�Q�直接丢弃了针对以往数据的支持�?/p>

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

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

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

    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插�g需要微�?/h2>

新版的apisix auth授权插�g支持多个授权插�g串行执行�Q�这个功能也很赞�Q�但此�D��D��了先前�ؓ具体业务定制的授权插件无法正常工作，�q�时需要微调一下�?/p>

原先调用方式�Q?/p>

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

因�ؓ新版�?code>lrucache不再提供 plugin 函数�Q�需要微调一下：

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

另一处是�Q�顺利授权之后，需要赋�?code>consumer相关信息�Q?/p>

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

此时需要替换成如下方式�Q��ؓ�Q�可能存在的�Q�后�l�的授权插�g�l�箋作用�?/p>

consumer_mod.attach_consumer(ctx, consumer, consumer_conf)

更多请参考：apisix/plugins/key-auth.lua 源码�?/p>

四、ETCD V2数据�q�移到V3

�q�移分�ؓ三步�Q?/p>

升��U�上已有ETCD 3.3.*版本�?.4.*�Q�满��x��版Apisix的要求，�q�时ETCD实例同时支持了V2和V3格式数据
�q�移V2数据到V3
- 因�ؓ数据量不是非常多�Q�我采取了一个非常简单和原始的方�?/li>
- 使用 etcdctl 完成V2数据到导�?/li>
- 然后使用文本�~�辑器vim�{�完成数据的替换�Q�生成etcdctl v3格式的数据导入命令脚�?/li>
- �q�行之后V3数据导入脚本�Q�完成V2到V3的数据导�?/li>
修改V3 /apisix/upstreams 中包含服务注册的数据�Q�一一��d�� "discovery_type" : "consul_kv"属�?/li>

��Z��以上操作之后�Q�从而完成了ETCD V2到V3的数据迁�U�R�?/p>

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

我们在运�l�层面，使用 /usr/local/openresty/bin/openresty -p /usr/local/apisix -g daemon off; 方式�q�行�|�关�E�序�?/p>

�q�也��导��_��自动忽略了官�Ҏ��倡的�Q?code>apisix start 命��o自动提前为ETCD V3初始化的一些键值对内容�?/p>

因此�Q�需要提前�ؓETCD V3建立以下键值对内容�Q?/p>

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

不提前徏立的话，��׃��D��apisix重启后，无法正常加蝲ETCD中已有数据�?/p>

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

            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的支�?/h2>
我们��Z��apisix-dashboard定制开发了大量的针对公司实际业务非常实用的企业�U�特性，但也��D��了无法直接升�U�到最新版的apisix-dashboard�?/p>
因�ؓ非常基础的上游和路由没有发生多大改变�Q�因此这部分升��的需求可以忽略�?/p>
实际上，只是在提交上游表单时�Q�包含服务注册信息JSON字符串中需要增�?`discovery_type` 字段和对应值即可完成支持�?/p>

七、小�l?/h2>
��p��了一些时间完成了从Apisix 1.5升��到Apisix 2.2的行为，虽然有些坑，但整体来�Ԍ��q�算��利。目前已�l�上�U��ƈ全量部��v�q�行�Q�目前运行良好�?/p>
针对�q�停留在Apisix 1.5的用��P��新版增加了Control API以及多种服务发现�{�新�Ҏ��支持，�q�是非常值得升��的�?/p>
升��之前�Q�不妨仔�l�阅��L��一个版本的升��日志�Q�地址�Q?a >https://github.com/apache/apisix/blob/2.2/CHANGELOG.md �Q�，然后需要根据具体业务做好兼�Ҏ��试准备和准备升��步骤�Q�这些都是非常有必要的�?/p>
针对我们团队来讲�Q�升�U�到最新版�Q�一斚w��降低了版本升�U�的压力�Q�另一斚w��也能够辅助我们能参与到开源社��Z��去，挺好~

nieyong 2021-02-23 14:57 发表评论

HTTP API设计�W�记

nieyong — Tue, 02 Jan 2018 12:53:00 GMT

前言

最�q�一�D�|��_��要�ؓ一个手机终端APP�E�序从零开始设计一整套HTTP API�Q�因为面向的用户很固定，一个新的移动端APP。目前还是项目初期，自然要求一切快速、从��Q�实用性�ؓ丅R�?/p>

下面��逐一��我们是如何设计HTTP API�Q�虽然相对大部分��言�Q�没有什么新意，但对我来说很新鲜的。避免忘��_��着�I�闲��快记录下来�?/p>

技术堆栈的选择

PHP嘛？团队内也没几个�h熟悉�?/p>

Java�Q�好几年没有��过了，那么复杂的解��x��案，再加上团队内也没什么�h�?……

团队使用�q�Lua�Q�基于OpenResty构徏�q�TCP、HTTP�|�关�{�，对Lua + Nginx�l�合非常熟悉�Q�能够快速的应用在线上环境。再说Lua语法��y、简单，一个新手半天就可以基本熟悉�Q�马上开工�?/p>

看来�Q�Nginx + Lua是目前最为适合我们的了�?/p>

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

嗯，OpenResty + Lua + Lor�Q�就构成了我们简单技术堆栈�?/p>

HTTP API��要设�?/h2>

HTTP API路径和语�?/h3>

每一具体业务逻辑�Q�直接在URL Path中体现出来。我们要的是��单快速，数据�l�构之间的连接关�p�，��可能的��L�E化。eg�Q?/p>

/resource/video/ID

比如用户反馈�q�一模块�Q�将使用下面比较固定的�\径：

/user/feedback

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

用户属性很多，用户�늧�只是其中一个部分，因此更新�늧��q�一行�ؓ�Q�HTTP�?PATCH �Ҏ��可更�_�և�的描�q�部分数据更新的业务需求：

/user/nickname

PATCH�Q�更新用��h��U�ͼ��늧�是用户属性之一�Q�可以��用更轻量�U�的 PATCH 语义
- curl -X PATCH http://localhost/user/nickname -d "nickname=hello2"

嗯，同一�cȝ��资源URL虽然固定了，但HTTP Method呈现了不同的业务逻辑需求�?/p>

HTTP API的访问授�?/h3>

实际业务HTTP API的访问是需要授权的�?/p>

传统的Access Token解决�Ҏ��Q�有session回话机制�Q�一般需要结合Web��览器，需要写入到Cookie中，或生产一个JSessionID用于标识�{�。这针对单纯面向�U�d��l�端的HTTP API后端来讲�Q��ƈ没有义务��d��q�一的兼容，略显冗余�?/p>

另外��是 OAUTH 认证了，有整套的认证�Ҏ��q�已工业化，很是成熟了，但对我们而言�q�是太重�Q�不太适合轻量�U�的HTTP API�Q�不太可能花费太多的�_�֊��d��它的�q�维工作�?/p>

最�l�选择了轻量��?Json Web Token�Q�非常紧凑，开��即用�?/p>

最佛_��法是把JWT Token攑֜�HTTP��h��头部中，不至于和其它参数��h��Q?/p>

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

下面是一副浏览器�D늚�一般认证流�E�，�q�与HTTP API认证大体一��_��

JWT的Lua实现�Q�推�? https://github.com/SkyLothar/lua-resty-jwt.git�Q�简单够用�?/p>

JWT和Lor的结�?/h3>

jwt需要和业务�q�行�l�定�Q�结�?lor �q�个API开发框架提供的中间件机�Ӟ��可在业务处理之前�Q�在合适位�|�进行权限拦截�?/p>

用户需要请求进行授权接口，比如登陆�{?/li>
服务器端会把用户标识�W�，比如用户id�{�，存入JWT的payload负荷中，然后生成Token字符�Ԍ��发给客户�?/li>
客户端收到JWT生成的Token字符�Ԍ��在后�l�的��h��中需要附加在HTTP��h��的Header�?/li>
完成认证�q�程

不同于OAUTH�Q�JWT协议�?strong>自包�?/strong>�Ҏ��，军_��了后端可以将很多属性信息存攑֜�payload负荷中，其token生成之后后端可以不用存储�Q�下�ơ客��L��发送请求时会发送给服务器端�Q�后端获取之后，直接验证卛_��Q�验证通过�Q�可以直接读取原先保存其中的所有属性�?/p>

下面梳理一下Jwt认证和Lor的结合�?/p>

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

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

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

    next()
end)

针对具体路径�q�行讑֮�权限拦截�Q�较�_�粒度；比如 /user 只允许已登陆授权用户讉K��

app:use("/user", function(req, res, next)
    if not req.params.uid then
        -- 注意�Q�这里没有调用next()�Ҏ���Q�请求到�q�里���截止了�Q�不在匹配后面的路由
        res:status(403):send("not allowed reqeust")
    else
        next() -- 满��以上条�g�Q�那么���l�匹配下一个�\�?    end
end)

一�U�是较细�_�度�Q�具体到每一个API接口�Q�因��然URL一��_��但不同的HTTP Method有时��h��权限�q�是有区别的

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()

-- 假设查看是不需要用��h��限的
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加蝲�q�来
app:use("/user", user_router())

......

app:run()

��Z��么没有选择GraphQL API �Q?/h2>
我们在上一个项目中对外提供了GraphQL API�Q�其�Q�在��试环境下）自��n提供文档输出自托��机�Ӟ��再结合方便的调试客户端，��实让后端开发和前端APP开发大大降低了频繁交流的频率，节省了若�q�流量，但前期还是需要较多的培训投入�?/p>
但在新项目中�Q�一度想提供GraphQL API�Q�遇到的问题如下�Q?/p>

全新的项目数据结构属性变动太频繁

普遍求快�Q�业务模型快速开发、调�?/li>
大家普遍对GraphQL API有些抵触�Q��用JSON输出格式的HTTP API是约定俗成的习惯选择

毫无疑问�Q�以最低成本快速构��为完整的APP功能�Q�HTTP API + JSON格式是最��服的选择�?/p>
虽然有些担心服务器端的输出，很多时候还是会��费掉一些流量，客户端�ƈ不能够有效的利用�q�回数据的所有字�D�属性。但和进度以及�h们已�l�习惯的HTTP API调用方式相比�Q�又微乎其微了�?/p>

��结

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

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

nieyong 2018-01-02 20:53 发表评论

nieyong — Thu, 30 Oct 2014 08:15:00 GMT

零。前�a�

一天早上�v来，偶然��Z��看到《环信支持千万�ƈ发即佉K��讯的技术要炏V��演�C�文档，��单翻阅之后，感觉�q�货很多�Q�于是快速记下以下笔记�?

一。IM协议和IM Server

XMPP��实很传�l�，WhatsApp选用了，同时�l�过压羃、精��Q�比如说user字符串��用u字符替代�Q�处理，让XMPP轻量不少�?

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

SIP�Q�接触少�?

微信�U�有协议ActivitySync�Q�以前在博客上分享过�?

正确拼写是WhatsApp�Q�呵��c�?

针对XMPP协议的改�q�，很有参考�h倹{�?

心蟩单向四个字节�Q�在XMPP协议下，估计应该是极限了吧。在�U�有协议协议下，一来一往两个字节��_��?

文�g传输方式�Q�这是业界通用方式�?

�U�d��互联�|�环境下�Q�用��h��q�在�U�，大家的共识。可是取决于手机有没有连接到服务器端�Q�这是无法逾越的障��?

Muc聊天室，业务层面改进�?

�q�个针对使用OpenFire的同学，很有参考意义�?

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

二。移动网�l�环境下的网�l�、电量等客户端优�?/font>

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

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

��量跑马��速，心蟩��Q�压�~�传输�?

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

扚w��、合�q�数据请�?发送，增量更新�Q�这是一个大安��应该使用的常规节省流量手�D�，应牢讎ͼ�

隑־�的是�Q�分享了�Q?

2G 文�g上传最佳buffer size 1024个字节，3G/4G下直接设�|��ؓ10K

2G 文�g下蝲最佳buffer size 2048个字节，3G/4G�?30K

�l�对�l�验的�ȝ��Q�赞�Q?

心很�l�，�l�出了频�J�的属性访问直接声明protected/publish了，不创建新的Java对象只能static�c�d��了。记得很久以前写J2ME�E�序�Ӟ��q��q�这��L��方式�?

实践中走�q�多��弯路才�ȝ��出来的同步、绘图、渲染页面惊艻I��其是支持离�U�方式的数据同步机制�Q�很受用�?

三。百万��架构�l�验分��n

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

无状态协议交互，才能够很�Ҏ��水��^横向扩展�Q�也是当今共识�?

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

典型的按照机房进行完整部�|Ԍ��若不能够在DNS层面做到按照用户ID�q�行指派�Q�HTTP DNS�q�行接入IP分配�Q�，那么��必��d��理用户�ؕ入机房的问题�Q�必然要做到一些数据的跨机房的同步�Q�大安��会采用增量式同步方式�Q�跨机房一般常�?0毫秒的�g�q�，扚w��形式增量同步�Q�那都不叫事�?

可以看到业务垂直切分�Q�各个业务之间水�q�x��展�?

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

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

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

四。小�l?

��M��Q�干货不��，很给力，再次对刘��壮大牛表示感谢�Q?

原PPT下蝲地址�Q?a >http://vdisk.weibo.com/s/A0GI9rXObFMd

PS: 若有侉|��Q�请及时告知�?

nieyong 2014-10-30 16:15 发表评论

nieyong — Wed, 05 Mar 2014 06:15:00 GMT

前言

微信可调研点很多�Q�这里仅仅从协议角度�q�行调研�Q�会涉及到微信协议交换、消息收发等。所�?#8220;弱水三千�Q�只取一�?#8221;吧�?/p>

杂七杂八的，有些长，可直接拉到最后看�l�论好了�?/p>

一。微信协议概�?/h3>

微信传输协议�Q�官方公布甚��，在微信技术�ȝ��所透漏PPT《微信之�?#8212;至简》文档中�Q�有所体现�?/p>

�U�个人理解：

因张���龙做邮���Foxmail起家�Q���而又做了QQ Mail�{�，QQ Mail是国内第一个支持Exchange ActiveSync协议的免贚w�����，��Z��其从业背景，微信从一开始就采取��Z��ActiveSync的修改版状态同步协议Sync�Q�也���再自然不过了�?

一句话�Q�增量式、按序、可靠的状态同步传输的微信协议�?/p>

大致交换��囑֦�下：

如何获取新数据呢�Q?/p>

服务器端通知�Q�客��L��获取
客户端携带最新的SyncKey�Q�发��h��据请�?
服务器端生成最新的SyncKey�q�同最新数据发送给客户�?
��Z��版本��h��制同步协议，可确保数据增量、有序传�?
SyncKey�Q�由服务器端序列��L��成器生成�Q�一旦有新消息��生，��会产生最新的SyncKey。类��g��版本�?

服务器端通知有状态更斎ͼ�客户端主动获取自从上�ơ更��C��后有变动的状态数据，增量式，��序式�?/p>

二。微信Web端简单调�?/h3>
在线版本微信�Q?/p>
https://webpush.weixin.qq.com/

通过Firefox + Firebug�l�合调试�Q�也能证实了微信大致通过交换SyncKey方式获取新数据的��?/p>

1. 发�vGET长连接检��是否存在新的需要同步的数据

会携带上最新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

�q�回内容�Q?/p>

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

selector值大�?�Q�表�C�有新的消息需要同步�?/p>

据目��，心蟩周期�?7�U�左叟�?/p>

2. 一旦有新数据，客户端POST��h��d��获取同步的数�?/h4>

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�Q�会�q�回复杂�l�构体JSON内容�?/p>

但浏览端收取到消息之后，如何通知服务器端已确认收��C��Q�Web版本微信�Q�没有去做�?/p>

在以往使用�q�程中，曑֏�现WEB端有丢失消息的现象，但属于偶��现象。但Android微信客户端（只要登陆�q�接上来之后�Q�貌似就没有丢失�q��?/p>

3. 发送消息流�E?/h4>

发�v一个POST提交�Q�用于提交用户需要发送的消息

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}}

相应内容�Q?/p>

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

再次发�v一个POST��h��Q�用于申��h��新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}

响应的（部分�Q�内容：

"SKey": "8F8C6A03489E85E9FDF727ACB95C93C2CDCE9FB9532FC15B"

�l�止GET长连接，使用最新SyncKey再次发�v一个新的GET长连�?/p>
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��单分�?/h3>
Windows桌面端Android虚拟��Z��q�行最新版微信(5.2)�Q�通过tcpdump/Wireshark�l�合��包分析�Q�以下�ؓ分析�l�果�?/p>

0. 初始�q�接记录

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

11:20:35 dns查询 
dns.weixin.qq.com
�q�回一�l�IP地址

11:20:35 DNS查询
long.weixin.qq.com
�q�回一�l�IP地址�Q�本�ơ通信中，微信使用了最后一个IP作�ؓTCP长连接的�q�接地址�?

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

11:20:35
获取到long.weixin.qq.com最优IP�Q�然后徏立到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)
�q�回一个名�?#8220;micromsgresp.dat”的附�Ӟ��估计是未阅读的离�U�消�?

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

中间�q�行一些资源请求等�Q�类��g��
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文�g

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 
�q�回chunked分块数据

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

1. 心蟩频率�U��ؓ5分钟

上次使用Wireshark分析有误�Q�得�?8分钟�l�论�Q�，再次重新分析�Q�心跳频率在5分钟左右�?/p>

2. 登陆之后�Q�会建立一个长�q�接�Q�端口号�?080

��单目��ؓHTTP�Q�初始以为是双通道HTTP�Q�难道是自定义的用于双通道通信的HTTP协议吗，�|�络上可见资料都是模��׃��可、语焉不详�?/p>

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

2.0 初始消息传输

个�h资料、离�U�未阅读消息部分�{�通过 POST HTTP短连接单独获取�?/p>

2.1 二进制简单分�?/h5>

抽取微信某次HTTP协议方式通信数据�Q?6�q�制表示�Q�每两个靠近的数字�ؓ一个byte字节�Q?/p>

微信协议可能如下�Q?/p>

一个消息包 = 消息�?+ 消息�?

消息头固�?6字节长度�Q�消息包长度定义在消息头�?个字节中�?/p>

单纯摘取�W?000行�ؓ例，�?6个字节的头部:

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

16�q�制表示�Q�每两个紧挨着数字代表一个byte字节�?/p>

微信消息包格式： 1. �?字节表示数据包长度，可变 ��gؓ16�Ӟ��意味着一个仅仅包含头部的完整的数据包�Q�可能表�C�着预先定义好的业务意义�Q�，后面可能�q�有会别的消息包 2. 2个字节表�C�头部长度，固定��|��0x10 = 16 3. 2个字节表�C��意版本，固定��|��0x01 = 1 4. 4个字节操作说明数字，可变 5. 序列��P��可变 6. 头部后面紧跟着消息体，非明文，加密形式 7. 一个消息包�Q�最��?6 byte字节

通过上图�Q�以及其它数据多�ơ采��P��分析�Q?/p>

0000 - 0040为单独的数据�?
0050行�ؓ下一个数据包的头部，前四个字节��gؓ0xca = 202�Q�表�C�包含了�?050-0110�?02个字节数�?
一�ơ数据发送，可能包含若干子数据包
换行�W�\n�Q?6�q�制表示�?x0a�Q�在00f0行，包含了两个换行符�?
一个数据体换行�W�号用于更细�_�度的业务数据分�?是否蒙对�Q�需要问问做微信协议的同�?
所有被标记为HTTP协议通信所发送数据都包含换行�W�号

2.2 动手试试猜想�Q�模拟微信TCP长连�?/h5>
开始很不解��Z��么会出现如此怪异的HTTP双通道长连接请求，��N��Z��TCP通信�Q�然后做了一些手脚？很常规的TCP长连接，传输数据�?不是所有数据传�?�Q�被wireshark误认为HTTP长连接。这个需要做一个实验证实一下自己想法，设想如下�Q?/p>
写一个Ping-Pong客户端、服务器端程序，然后使用Wireshark看一下结果，是否�W�合判断�?/p>
Java版本的请求端�Q�默认请�?080端口�Q?

C语言版本的服务器�E�序�Q�收��C��么发送什么，没有��M��逻辑�Q�默认绑�?080端口�Q?

�q�里有一个现场图�Q?/p>

可以��试�E�微改变输出内容�Q�去除换行符“\n”�Q�把端口换成9000�Q�试试看�Q�就会发现Wireshark输出不同的结果来�?/p>

2.3 �l�论是什么呢�Q?/h5>
若��用原始TCP�q�行双向通信�Q�则需要满��以下条�Ӟ��可以被类��g��Wireshark协议拦截器误认�ؓ是HTTP长连接：

使用80/8080端口�Q?1/3128/8000�l�测试无效）也许8080一般被作�ؓWEB代理服务端口�Q�微信才会��n用这个红利吧�?
输出的内容中�Q�一定要包含换行字符"\n"

因此�Q�可以定性�ؓ微信使用了基�?080端口TCP长连接，一旦数据包中含有换�?\n"�W�号�Q�就会被Wireshark误认为HTTP协议。可能微信是无心��Z��吧�?/p>

3. 新消息获取方�?/h4>

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

此时消息��h��截图如下�Q?/p>

4. 发送消息方�?/h4>
发送消息走已经建立的TCP长连接通道�Q�发送消息到服务器，然后接受��认信息�{�，产生一�ơ交互�?/p>
��伙伴接收到信息阅读也都会收到服务器端通知�Q��生一�ơ交互等�?/p>
可以��定�Q�微信发送消息走TCP长连接方式，因�ؓ不对自��n状态数据��生媄响，应该不交换SyncKey�?/p>

在低速网�l�下�Q�大概会看到消息发送中的提�C�，属于消息重发机制
�|�络不好有时客户端会出现发送失败的�U�色感叹�?
已发送到服务器但未收到确认的消息�Q�客��L��昄��U�色感叹��P��再次重发�Q�服务器作�ؓ重复消息处理�Q�反馈确�?/li>
上传囄��Q�会�Ҏ��囄��大小�Q�分割成若干部分�Q�大�?.5K被划分�ؓ一部分�Q�，同一旉��点，客户端会发�v若干�ơPOST��h��Q�各自上传成功之后，服务器大概会合�ƈ成一个完整图片，�q�回一个羃略图�Q�显�C�在APP聊天�H�口内。APP作�ؓ常规的文字消息发送到服务器端
上传音频�Q�则单独走TCP通道�Q�一个两�U�的录制音频�Q�客��L��录制完毕�Q�分��Z��块传输，一块最�?.5K左右�Q�服务端响应一条数据通知��认收到。共三次数据传输�?br />音频和纯文字信息一��_��都是走TCP长连接，客户端发送，服务器端��认�?/li>

四。微信协议小�l?/h3>

发布的消息对应一个ID�Q�只要单个方向唯一卛_��Q�服务器端可能会根ID判断重复接收�Q�，消息重传机制��保有限�ơ的重试�Q�重试失败给予用��h��C�，发送成功会反馈��认�Q�客��L��只有收到��认信息才知道发送成功。发送消息可能不会��生新SyncKey�?
��Z��版本��P��SynKey�Q�的状态消息同步机�Ӟ��增量、有序传输需求水到渠成。长�q�接通知/短连接获取、确认等�Q�交互方式简单，��保了消息可靠谱、准��无误到达�?
客户�?服务器端都会存储消息ID处理记录�Q�避免被重复消费客户端获取最新消息，但未��认�Q�服务器端不会认��消息被消�Ҏ��。下�ơ客��L��会重新获取，会查询当前消息是否被处理�q�。根据一些现象猜��?
��M��上看�Q�微信协议跨�q�_��Q�TCP或HTPP都可呈现�Q�处理方式可�l�一�Q�，通过“握手”同步�Q�很可靠�Q�无论哪一个��^台都可以支持的很�?
微信协议最��成本�ؓ16字节�Q�大部分旉��若干个消息包和在一��P��扚w��传输。微信协议说不上最��z�，也不是最节省��量�Q�但是非常成功的�?
若服务器��到一些不��定因素�Q�可能会��D��微启用安全套接层SSL协议�q�行常规的TCP长连接传输。短�q�接都没有发生变�?/div>

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

五。附�?/h3>

Microsoft Exchange Active Sync协议�Q�简�U�EAS�Q�分为folderrsync(同步文�g夹目录，即邮��内有哪几个文�g�?和sync�Q�每个文件夹内有哪些文档�Q�两部分�?/p>

某网友�ȝ��的协议一�ơ回话大致示范：

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

上页中的盔R��h��都是隔固定时间的�Q�如两分�?
客户端每�ơ��用旧key标记自己的状态，服务端每�ơ将新key和增量数据一赯��回�?
key是递增的，但不要求�q�箋
��h��的某个参数决定服务器是否立即�q�回

nieyong 2014-03-05 14:15 发表评论