标签 Tcpdump 下的文章

使用Golang开发微信公众平台-接收文本消息

一旦接入验证成功,成为正式开发者,你可能会迫不及待地想通过手机微信发送一条"Hello, Wechat”到你的公众号服务器。不过上一篇的那个程序还无法处理手机提交的文本消息,本篇将介绍如何用Golang编写公众号程序来接收手机端发送的 文本消息以及回复响应消息。

根据微信公众平台开发文档中描述:“当普通微信用户向公众账号发消息时,微信服务器将POST消息的XML数据包到开发者填写的URL上”。我们 用一个示意图展示一下这个消息流程:

微信服务器通过一个HTTP Post请求将终端用户发送的消息转发给公众号服务器,消息内容被包装在HTTP Post Request的Body中。数据包以XML格式存储,文本类消息XML格式样例如下(引自微信公众平台开发文档):

数据包中各个字段的含义都显而易见,我们重点关注的时Content这个字段填写的内容,也就是终端用户发送的消息内容。为了得到这个字段值,我 们需要解析微信服务器发来的HTTP Post包的Body。

在“接入验证”一文中我们提到过,微信服务器发起的请求都带有验证字段,可被公众号服务用于验证HTTP Request是否来自于微信服务器,避免恶意请求。这些用于验证来源的信息,不仅仅在接入验证阶段会发给公众号服务器,在后续微信服务器与公众号服务器 的消息交互过程中,HTTP Request中也都会携带这些信息(注意:没有echostr参数了)。

下面我们来看接收文本消息的Golang程序。

一、接收文本消息

公众号所用的HTTP Server可以沿用“接入验证”一文中的那个main中的Server,我们需要修改的是procRequest函数。

在procRequest函数中,我们保留validateUrl,用于校验请求是否来自于微信服务器。

func procRequest(w http.ResponseWriter, r *http.Request) {
        r.ParseForm()
        if !validateUrl(w, r) {
                log.Println("Wechat Service: this http request is not from Wechat platform!")
                return
        }
        log.Println("Wechat Service: validateUrl Ok!")
       
        … …//在此解析HTTP Request Body
}

通过验证后,我们开始解析HTTP Request的Body,Body中的数据是XML格式的,我们可以通过Golang标准库encoding/xml包中提供的函数对Body进行解 析。encoding/xml根据xml字段名与struct字段名或struct tag(struct中每个字段后面反单引号引用的内容,比如xml: "xml")的对应关系将xml数据中的字段值解析到struct的字段中,因此我们需要根据这个xml包的组成定义出对应该格式的struct,这个 struct定义如下:

type TextRequestBody struct {
        XMLName      xml.Name `xml:"xml"`
        ToUserName   string
        FromUserName string
        CreateTime   time.Duration
        MsgType      string
        Content      string
        MsgId        int
}

其中FromUserName是发送方账号,这是一个OpenID,每个微信用户针对某个关注的公众号都有唯一OpenID。举个例 子:"tonybai"这个微信用户,关注了"GoNuts"和"GoDev"两个公众号,则"tonybai"发给GoNuts的消息中的 OpenID是“tonybai-gonuts”,而tonybai发给GoDev的消息中的OpenID则是“tonybai-godev”。

MsgId是一个64位整型,可用于消息排重。对于一个HTTP Post,微信服务器在五秒内如果收不到响应会断掉连接,并且针对该消息重新发起请求,总共重试三次。严谨的公众号服务端实现是应该实现消息排重功能的。

通过encoding/xml包中的Unmarshal函数,我们将上面的xml数据转换为一个TextRequestBody实例,具体代码如 下:

//recvtextmsg_unencrypt.go
func parseTextRequestBody(r *http.Request) *TextRequestBody {
        body, err := ioutil.ReadAll(r.Body)
        if err != nil {
                log.Fatal(err)
                return nil
        }
        fmt.Println(string(body))
        requestBody := &TextRequestBody{}
        xml.Unmarshal(body, requestBody)
        return requestBody
}

func procRequest(w http.ResponseWriter, r *http.Request) {
        r.ParseForm()
        if !validateUrl(w, r) {
                log.Println("Wechat Service: this http request is not from Wechat platform!")
                return
        }

        if r.Method == "POST" {
                textRequestBody := parseTextRequestBody(r)
                if textRequestBody != nil {
                        fmt.Printf("Wechat Service: Recv text msg [%s] from user [%s]!",
                                textRequestBody.Content,
                                textRequestBody.FromUserName)
                }
        }
}

构建并执行该程序:

$>sudo ./recvtextmsg_unencrypt
2014/12/19 08:03:27 Wechat Service: Start!

通过手机微信或公众开发平台提供的页面调试工具发送"Hello, Wechat",我们可以看到如下输出:

2014/12/19 08:05:51 Wechat Service: validateUrl Ok!
Wechat Service: Recv text msg [Hello, Wechat] from user [oBQcwuAbKpiSAbbvd_DEZg7q27QI]!

上述接收"Hello, Wechat"文本消息的Http抓包分析文本如下(Copy from wireshark output):

POST /?signature=9b8233c4ef635eaf5b9545dc196da6661ee039b0&timestamp=1418976343&nonce=1368270896 HTTP/1.0\r\n
User-Agent: Mozilla/4.0\r\n
Accept: */*\r\n
Host: wechat.tonybai.com\r\n
Pragma: no-cache\r\n
Content-Length: 286\r\n
Content-Type: text/xml\r\n

公众号服务器给微信服务器返回的HTTP Post Response为:

HTTP/1.0 200 OK\r\n
Date: Fri, 19 Dec 2014 08:05:51 GMT\r\n
Content-Length: 0\r\n
Content-Type: text/plain; charset=utf-8\r\n

二、响应文本消息

上面的例子中,终端用户发送"Hello, Wechat",虽然公众号服务器成功接收到了这段内容,但终端用户并没有得到响应,这显然不那么友好!这里我们来给终端用户补发一个文本消息的响 应:Hello,用户OpenID。

这类响应消息可以通过HTTP Post Request的Response包携带,将数据放入Response包的Body中,当然也可以单独向微信公众平台发起请求(后话)。微信公众平台开发 文档中关于被动的文本消息响应的定义如下:

这与前面的接收消息结构极其类似,字段含义也不说自明。Golang encoding/xml中的Marshal(和MarshalIndent)函数提供了将struct编码为XML数据流的功能,它是 Unmarshal的逆过程,Golang实现回复 文本响应消息的代码如下:

type TextResponseBody struct {
        XMLName      xml.Name `xml:"xml"`
        ToUserName   string
        FromUserName string
        CreateTime   time.Duration
        MsgType      string
        Content      string
}

func makeTextResponseBody(fromUserName, toUserName, content string) ([]byte, error) {
        textResponseBody := &TextResponseBody{}
        textResponseBody.FromUserName = fromUserName
        textResponseBody.ToUserName = toUserName
        textResponseBody.MsgType = "text"
        textResponseBody.Content = content
        textResponseBody.CreateTime = time.Duration(time.Now().Unix())
        return xml.MarshalIndent(textResponseBody, " ", "  ")
}

func procRequest(w http.ResponseWriter, r *http.Request) {
        r.ParseForm()
        if !validateUrl(w, r) {
                log.Println("Wechat Service: this http request is not from Wechat platform!")
                return
        }

        if r.Method == "POST" {
                textRequestBody := parseTextRequestBody(r)
                if textRequestBody != nil {
                        fmt.Printf("Wechat Service: Recv text msg [%s] from user [%s]!",
                                textRequestBody.Content,
                                textRequestBody.FromUserName)
                        responseTextBody, err := makeTextResponseBody(textRequestBody.ToUserName,
                                textRequestBody.FromUserName,
                                "Hello, "+textRequestBody.FromUserName)
                        if err != nil {
                                log.Println("Wechat Service: makeTextResponseBody error: ", err)
                                return
                        }
                        fmt.Fprintf(w, string(responseTextBody))
                }
        }
}

编译执行上面程序后,通过手机微信或网页调试工具发送一条"Hello, Wechat"到公众号,公众号会响应如下信息:“Hello, oBQcwuAbKpiSAbbvd_DEZg7q27QI",手机端微信会正确接收该响应。

上述响应的抓包分析如下。公众号服务器给微信服务器返回的HTTP Post Response为:

HTTP/1.0 200 OK\r\n
Date: Fri, 19 Dec 2014 09:03:55 GMT\r\n
Content-Length: 220\r\n
Content-Type: text/plain; charset=utf-8\r\n

\r\n
<xml><ToUserName>oBQcwuAbKpiSAbbvd_DEZg7q27QI</ToUserName><FromUserName>gh_xxxxxxxx</FromUserName><CreateTime>1418979835</CreateTime><MsgType>text</MsgType><Content>Hello, oBQcwuAbKpiSAbbvd_DEZg7q27QI</Content></xml>

三、关于Content-Type设置

虽然Content-Type为:text/plain; charset=utf-8的 响应信息可以被微信平台正确解析,但通过抓取微信平台给公众号服务器发送的HTTP Post Request来看,在发送xml数据时微信服务器用的Content-Type为Content-Type: text/xml。我们的响应信息Body也是xml数据包,我们能否为响应信息重新设置Content-Type为 text/xml呢?我们可以通过如下代码设置:

w.Header().Set("Content-Type", "text/xml")
fmt.Fprintf(w, string(responseTextBody))

不过奇怪的是我通过AWS EC2上抓包得到的Content-Type始终是“text/plain; charset=utf-8”。但利用ngrok映射到本地端口后抓包看到的却是正确的"text/xml",在AWS本地用 curl -d xxx.xxx.xxx.xxx测试公众号服务程序而抓到的包也是正确的。通过代码没看出什么端倪,因为逻辑上显式设置Header的Content- Type后,Go标准库不会在sniff内容的格式了。

通过ngrok映射本地80端口后,得到的HTTP Post Response抓包分析文字:

HTTP/1.1 200 OK\r\n
Content-Type: text/xml\r\n
Date: Sat, 20 Dec 2014 04:29:16 GMT\r\n
Content-Length: 220\r\n

xml数据包这里忽略。

四、CDATA的使用

从抓包可以看到,我们回复的响应中的XML数据包是不带CDATA,即便这样微信客户端接收也没有问题。但这并未严遵循协议样例。

XML下CDATA含义是:在标记CDATA下,所有的标记、实体引用都被忽略,而被XML处理程序一视同仁地当做字符数据看待,CDATA的形 式如下:

<![CDATA[文本内容]]>

我们尝试加上为每个文本类型的字段值上直接添加CDATA标记。

func value2CDATA(v string) string {
        return "<![CDATA[" + v + "]]>"
}

func makeTextResponseBody(fromUserName, toUserName, content string) ([]byte, error) {
        textResponseBody := &TextResponseBody{}
        textResponseBody.FromUserName = value2CDATA(fromUserName)
        textResponseBody.ToUserName = value2CDATA(toUserName)
        textResponseBody.MsgType = value2CDATA("text")
        textResponseBody.Content = value2CDATA(content)
        textResponseBody.CreateTime = time.Duration(time.Now().Unix())
        return xml.MarshalIndent(textResponseBody, " ", "  ")
}

这样修改后,我们试着发一条消息给微信公众号平台,不过结果并不正确。手机微信无法收到响应信息,并显示“该公众号暂时无法提供服务,请稍后再 试”。通过Println输出Body可以看到:

<xml><ToUserName>&lt;![CDATA[oBQcwuAbKpiSAbbvd_DEZg7q27QI]]&gt;&lt;![CDATA[gh_1fd4719f81fe]]&gt;</FromUserName><CreateTime>1419051400</CreateTime><MsgType>&lt;![CDATA[text]]&gt;</MsgType><Content>&lt;![CDATA[Hello, oBQcwuAbKpiSAbbvd_DEZg7q27QI]]&gt;</Content></xml>

可以看到左右尖括号分别被转义为&lt;和&gt;了,这显然不是我们想要的结果。那如何加入CDATA标记呢。Golang并 不直接显式支持生成CDATA字段的xml流,我们只能间接实现。前面提到过struct定义时的struct tag,golang xml包规定:"a field with tag ",innerxml" is written verbatim, not subject to the usual marshalling procedure"。 大致的意思是如果一个字段的struct tag是",innerxml",则Marshal时字段值原封不动,不提交给通常的marshalling程序。我们就利用innerxml来实现 CDATA标记。

type TextResponseBody struct {
        XMLName      xml.Name `xml:"xml"`
        ToUserName   CDATAText
        FromUserName CDATAText
        CreateTime   time.Duration
        MsgType      CDATAText
        Content      CDATAText
}

type CDATAText struct {
        Text string `xml:",innerxml"`
}

func value2CDATA(v string) CDATAText {
        return CDATAText{"<![CDATA[" + v + "]]>"}
}

编译程序后测试,这回CDATA标记正确了,微信客户端也收到的响应信息。

五、用ngrok在本地调试微信公众平台接口

在“接入验证”一文中,我们建议申请诸如AWS EC2来应对微信公众平台接口开发,但其方便程度毕竟不如本地。网上一开源工具ngrok可以帮助我们实现本地调试微信公众平台接口。

使用ngrok的步骤如下:

1、下载ngrok
 ngrok也是使用golang实现的,因此主流平台都支持。ngrok下载后就是一个可执行的二进制文件,可直接执行(放在PATH路径 下)。

2、注册ngrok
到ngrok.com上注册一个账号,注册成功后,就能看到ngrok.com为你分配的auth token,把这个auth token放到~/.ngrok中:

auth_token:YOUR_AUTH_TOKEN

3、执行ngrok

$ngrok 80

ngrok                                                                                                                                                           (Ctrl+C to quit)

Tunnel Status                 online
Version                       1.7/1.6
Forwarding                    http://xxxxxxxx.ngrok.com -> 127.0.0.1:80
Forwarding                    https://xxxxxxxx.ngrok.com -> 127.0.0.1:80
Web Interface                 127.0.0.1:4040
# Conn                        1
Avg Conn Time                 1.90ms

其中"xxxxxxxx.ngrok.com"就是ngrok为你分配的子域名。

在你的微信开发者中心将这个地址配置到URL字段中,提交验证,验证消息就会顺着ngrok建立的隧道流到你的local机器的80端口上。

另外本地调试抓包,要用loopback网口,比如:
$sudo tcpdump -w http.cap -i lo0 tcp port 80

本篇文章涉及的代码在这里可以找到。

回顾TCP协议那些事儿

我不是计算机科班出身。记得大学的时候旁听计算机系的网络课,当时计算机系使用教材是"计算机网络–自顶向下方法与Internet特色"的影印版,这本教材与众不同的一个地方就是作者JAMES F.KUROSEKEITH W.ROSS采用了'自顶向下'的编排思路,先从应用层开始,最后讲到物理层。而且这本书在语言上形象生动,通俗易懂。只怪我当初没有一心一意听讲,到现在存在我的脑子中的基本概念居多,深刻理解甚少。以致于工作后遇到此类的问题,只能恶补。这不,在12月1日凌晨全国统一短信类服务接入代码的调整工作中,我就遇到了此类问题,不得不再次抱起W.Richard Stevens的'TCP详解卷一'啃了啃,回顾一下TCP协议那些事儿。

做应用层网络程序开发的,手头上都有一把利器:抓包工具,更专业的名词就是协议分析工具,常用的且功能强大的协议分析工具有:TCPDUMP(Windows平台上的叫Windump)、Ethereal等。工作中常常会遇到因应用层程序在协议字段发送和接收解析上不一致而出现'纠纷'问题,这时我们一般采用的在TCP层用协议分析工具抓取该层原始数据包作为'对峙'的证据;还有的就是在客户端与服务器端链接问题上的一些现象也需要到TCP层去分析原因,这就需要对TCP层的基本工作原理有一个清晰的认识。

首先我们要明确:TCP头部中设置的一系列域都是为了能达到分割、重传、查重、重组、流控、全双工的协议功能而设置的,这里比较重要的字段就是序列号和确认号。由于要达到重传、查重、重组、全双工这些目的,TCP层需要通过序列号和确认号来保证。序列号用来标识发送端传送数据包的顺序,并且指导接收端对多数据包进行顺序重组;发送端传送一个数据包后,它会把这个数据包放入重发队列中,同时启动计时器,如果收到了关于这个包的确认信息,便将此数据包从队列中删除;如果在计时器超时的时候仍然没有收到确认信息,则需要重新发送该数据包。

TCP层以"三次握手"建立链接而"闻名于世",三次握手的目的:建立链接,为后续的数据流传输奠基,因为TCP是双工的,因此在握手过程需告知彼此数据包发送的起始序列号。

Client –> 置SYN标志 序列号 = J,确认号 = 0 —-> Server
Client <– 置SYN标志 置ACK标志 序列号 = K, 确认号 = J + 1 <– Server
Clinet –> 置ACK标志 序列号 = J + 1,确认号 = K + 1 –> Server

链接建立后,接下来Client端发送的数据包将从J + 1开始,Server端发送的数据包将从K + 1开始,这里要说明的是:建立链接时,Client端宣称自己的初始序列号是J,Server端宣称自己的初始序列号是K,但是建立连接后的数据包却各自中初始序列号+1开始,这是因为SYN请求本身需要占用一个序列号。

在数据传输阶段,按照常理应用层数据的传输是这样的:(我们假定建立连接阶段Client端最后的确认包中序列号 = 55555, 确认号 = 22222)
Client –> 置PSH标志,置ACK标志 序列号 = 55555, 确认号 = 22222,数据包长度 = 11 —> Server
Client <– 置ACK标志,序列号 = 22222, 确认号 = 55566 (=55555 + 11),数据包长度 = 0 <— Server
Client <– 置PSH标志,置ACK标志 序列号 = 22223, 确认号 = 55566,数据包长度 = 22 <— Server
Client –> 置ACK标志,序列号 = 55566, 确认号 = 22244(=22222+22),数据包长度 = 0 —> Server

注:PSH标志指示接收端应尽快将数据提交给应用层。从我协议分析的经历来看,在数据传输阶段,几乎所有数据包的发送都置了PSH位;而ACK标志位在数据传输阶段也是一直是置位的。

但是实际我们在分析过程看到的却都是如下这样的:
Client –> 置PSH标志,置ACK标志 序列号 = 55555, 确认号 = 22222,数据包长度 = 11 —> Server
Client <– 置PSH标志,置ACK标志 序列号 = 22222, 确认号 = 55566 (=55555 + 11),数据包长度 = 22 <— Server
Client –> 置PSH标志,置ACK标志 序列号 = 55566, 确认号 = 22244 (=22222 + 22),数据包长度 = 33 —> Server
Client <– 置PSH标志,置ACK标志 序列号 = 22244, 确认号 = 55599 (=55566 + 33),数据包长度 = 44 <— Server

也就是说:数据接收端将上一个应答和自己待发送的应用层数据组合在一起发送了。TCP的传输原则是尽量减少小分组传输的数量,所以一般默认都开启"带时延的ACK"。一般实现中,时延在200ms。Nagle算法多用来实现"带时延的ACK",它要求一个TCP连接上最多只能有一个未被确认的小分组。在该分组的确认到达之前不能发送其他小分组。也就是说:发送端在发送一个分组后,需等待这个分组的ACK确认后,才可以进行下一个分组的发送。这样一来网络的传输效率被大大降低了。对于大数据块的传输来说,这样很多时候是难以忍受的。另一种拥塞控制策略被引入,那就是TCP的滑动窗口协议,滑动窗口协议是分组发送和分组确认不再同步,发送端可以连续发送n个分组,接收端同样也可以用一个确认包来一起确认这n个分组,通常n = 2。各种OS的TCP协议栈在实现上都是综合了Nagle算法和滑动窗口协议的,TCP层对应用层数据分组大小进行多次判断(一般分组大小都是和MSS做比较的),以在Nagle和滑动窗口协议之间抉择到底选择哪一种控制方式进行发送。"The Linux Network Architecture: Design and Implementation of Network Protocols in the Linux Kernel"一书介绍了Linux在TCP层上的设计和实现,当然最直观的还是去分析Linux源代码了。

拆除TCP连接过程用一句话表述就是:你关你的发送通道,我关我的发送通道(因为TCP是全双工)。当一方关闭发送通道后,仍可接收另一方发送过来数据,这样的情况就成为"半关闭"。然而多数情况下,"半关闭"使用的很少,而且半关闭需要SOCKET AIP支持在SOCKET上的shutdown(而不是调用close)。

正常的关闭流程是源于Fin报文的:
Client –> Fin ACK –> Server
Client <– ACK <– Server
Client <– Fin ACK — Server
Client –> ACK –> Server
发送Fin分组的一端会先将发送缓冲中的报文按序发完之后,再发出Fin;所以说Fin又叫做:orderly release。

异常的关闭流程是源于Rst报文的。一个典型的例子就是当客户端所要链接的服务器端的端口并没有程序在listen,这时服务器端的TCP层会直接发送一个Rst报文,告诉客户端重置连接。Rst报文是无需确认的。客户端在收到Rst后会通知应用层对方异常结束链接(需通过SOCKET API的设置才能得知对方是异常关闭)。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats