论文部分内容阅读
摘要：基于手机支付客户端连接超时的问题，分析出网关在处理ssl会话中Chunked编码时，按照大小和时间分割数据，致使结束符不能被识别，进而影响了业务。本文提供了一种处理该类问题的思路。
关键字：WAP网关、手机支付、HTTPS访问流程、Chunked编码传输
中图分类号：TN929.53文献标识码： A 文章编号：
手机支付业务介绍
手机支付业务也称移动支付业务，允许移动用户使用移动终端（通常是手机）对所消费的产品或者服务进行支付的一种服务方式，该方式由于其方便 、快捷等特点，受到广大消费者的亲睐。将手机支付专用的RF-UIM卡置入手机中，即可持手机在超市、便利店、商场等特约商户的收银POS机上轻轻一刷，就能安全快速地进行付款，享受“刷手机”消费购物的乐趣。手机支付客户端是电信运营商推出的手机客户端软件，向手机用户提供综合性移动支付业务，如手机购彩、游戏充值、水电煤缴费、话费充值、院线通、购火车票、购长途汽车票等。通过安全键盘、支付密码多重保障体系，用户可尽享运营商提供的便利生活及娱乐休闲服务。
问题描述
2012年12月，测试人员发现通过客户端在CTWAP（互联星空）模式下使用手机支付业务时异常，登陆及使用业务时十分缓慢，界面显示“连接超时”。但用户通过ctnet、wlan的方式可以正常登陆。联系使用相同WAP网关的其他省份进行测试也有类似情况发生。
问题分析
网络排查
WAP网关位于移动承载网络与Internet应用服务器之间，能够实现无线应用协议(WAP)堆栈的转换、内容格式转换(如无线置标语言(WML)到超文本置标语言(HTML))等功能，将用户的pull请求经过处理后发送至CP（内容提供商）、SP（服务提供商），并将后者返回的结果经过匹配后发回到用户终端。
用户选择CTWAP作为网络接入点，且代理地址设置为10.0.0.200时，业务消息要经过WAP网关处理。终端提示“连接超时”，首先需要排查网络方面的原因，查看WAP网关解析出来的对端地址是否正确，网关与该地址的路由是否顺畅。在WAP网关服务器上使用nslookup 命令对“手机客户端”所请求的地址域名进行解析，解析结果与手机支付平台提供地址一致，DNS解析正常。在WAP网关服务器上使用ping命令对nslookup解析出来的IP地址进行网络测试，测试结果也正常，未发现超时的现象。通过以上手段的排查，确定网络正常。
故障初步定位
排除了网络方面的原因后，判断故障出现在WAP网关侧或者手机支付平台侧，WAP网关近期做过链路扩容，手机支付平台侧也新增了两台服务器，但是操作回退的风险较大。在WAP网关上对正常、异常消息分别进行了跟踪，发现消息可以送到手机支付平台，平台侧也可以正常发响应消息回来。在异常消息中，WAP网关向用户返回的HTTP消息中Transfer-Encoding为chunked，且消息中多了一个block1消息。
图1 WAP网关跟踪消息示意图
经过分析，初步判断是WAP网关处理手机支付平台侧返回的数据异常，进而启动保护机制，并向用户弹出报错对话框，提示“连接超时”。
异常业务流程分析
通过现场抓包信息和信令跟踪文件，确认出现问题的业务流程。定位这一流程属于通过WAP网关代理实现的https访问流程，如下所示：
图2 出现异常的业务流程
定位故障在流程中位置
故障出现在WAP网关收到手机支付平台侧响应消息，协议栈解密并转发的过程中。分析现场反馈的信令跟踪数据，发现响应的第二个数据包发送不完整。查看对应的抓包数据，发现响应的数据有成功的情况，也有失败的情况，检查多个数据包，发现异常的情况响应数据包均为chunked方式，见下图：
图3 异常响应数据包
原因分析
Wap网关与手机支付平台侧之间采用ssl加密方式交互，无法通过抓包来准确分析故障情况，转而通过排查业务流程并结合现场详细日志进行分析。
首先，通过复现问题时的业务详细日志，定位故障问题出现在协议栈处理ssl响应的chunked部分流程；
其次，通过协议栈详细日志，发现读取ssl会话内容的时候是分阶段读出的，读出过程中会截断chunked编码的结束符”0/r/n/r/n”，无法定位chunked包结束标志。当到达内部传输分片时间节点的时候，先转发已经收到的数据，后续被截断的数据无法判断出数据流何时结束。
第一次读取到875个字符，第二次读取到1个字符为“0”，然后httppro检查到达到时间分片故转发给业务，第三次读取到4个字符为“\r\n\r\n”。此时在httppro缓存的数据无法进行“0\r\n\r\n”匹配操作，数据滞留在httppro缓存中。然后sp回复完响应断链，httppro检测到对端断链，但是发现接受缓存中仍然有数据，误认为对端未回复完整http响应，所以向业务产生707告警。
最后，通过修改各业务处理机配置项zxweb.scr中Downloadmode的值，将内部传输分片方式由之前的“按接收数据的大小和时间”调整为“只根据接收到数据大小” （Downloadmode=3）来分割数据，避免协议栈传输过程中截断chunked编码结束符。
问题解决
修改业务版本中的配置文件，临时屏蔽了现场问题；
后续将优化协议栈版本，更改对ssl会话chunked编码响应的处理方式，彻底解决该问题。
WAP网关侧对于分片下载的模式在系统开局时候就已经固定，近期未做过过调整。应
该是手机支付平台侧进行升级或者改动导致问题发生。
参考文献
[1] 中国电信集团公司.中国电信CDMA WAP网关设备规范v1.0[s],2008.03
[2] 中國电信集团公司. 中国电信CDMA WAP网关接口规范v1.0[s],2008.03
关键字：WAP网关、手机支付、HTTPS访问流程、Chunked编码传输
中图分类号：TN929.53文献标识码： A 文章编号：
手机支付业务介绍
手机支付业务也称移动支付业务，允许移动用户使用移动终端（通常是手机）对所消费的产品或者服务进行支付的一种服务方式，该方式由于其方便 、快捷等特点，受到广大消费者的亲睐。将手机支付专用的RF-UIM卡置入手机中，即可持手机在超市、便利店、商场等特约商户的收银POS机上轻轻一刷，就能安全快速地进行付款，享受“刷手机”消费购物的乐趣。手机支付客户端是电信运营商推出的手机客户端软件，向手机用户提供综合性移动支付业务，如手机购彩、游戏充值、水电煤缴费、话费充值、院线通、购火车票、购长途汽车票等。通过安全键盘、支付密码多重保障体系，用户可尽享运营商提供的便利生活及娱乐休闲服务。
问题描述
2012年12月，测试人员发现通过客户端在CTWAP（互联星空）模式下使用手机支付业务时异常，登陆及使用业务时十分缓慢，界面显示“连接超时”。但用户通过ctnet、wlan的方式可以正常登陆。联系使用相同WAP网关的其他省份进行测试也有类似情况发生。
问题分析
网络排查
WAP网关位于移动承载网络与Internet应用服务器之间，能够实现无线应用协议(WAP)堆栈的转换、内容格式转换(如无线置标语言(WML)到超文本置标语言(HTML))等功能，将用户的pull请求经过处理后发送至CP（内容提供商）、SP（服务提供商），并将后者返回的结果经过匹配后发回到用户终端。
用户选择CTWAP作为网络接入点，且代理地址设置为10.0.0.200时，业务消息要经过WAP网关处理。终端提示“连接超时”，首先需要排查网络方面的原因，查看WAP网关解析出来的对端地址是否正确，网关与该地址的路由是否顺畅。在WAP网关服务器上使用nslookup 命令对“手机客户端”所请求的地址域名进行解析，解析结果与手机支付平台提供地址一致，DNS解析正常。在WAP网关服务器上使用ping命令对nslookup解析出来的IP地址进行网络测试，测试结果也正常，未发现超时的现象。通过以上手段的排查，确定网络正常。
故障初步定位
排除了网络方面的原因后，判断故障出现在WAP网关侧或者手机支付平台侧，WAP网关近期做过链路扩容，手机支付平台侧也新增了两台服务器，但是操作回退的风险较大。在WAP网关上对正常、异常消息分别进行了跟踪，发现消息可以送到手机支付平台，平台侧也可以正常发响应消息回来。在异常消息中，WAP网关向用户返回的HTTP消息中Transfer-Encoding为chunked，且消息中多了一个block1消息。
图1 WAP网关跟踪消息示意图
经过分析，初步判断是WAP网关处理手机支付平台侧返回的数据异常，进而启动保护机制，并向用户弹出报错对话框，提示“连接超时”。
异常业务流程分析
通过现场抓包信息和信令跟踪文件，确认出现问题的业务流程。定位这一流程属于通过WAP网关代理实现的https访问流程，如下所示：
图2 出现异常的业务流程
定位故障在流程中位置
故障出现在WAP网关收到手机支付平台侧响应消息，协议栈解密并转发的过程中。分析现场反馈的信令跟踪数据，发现响应的第二个数据包发送不完整。查看对应的抓包数据，发现响应的数据有成功的情况，也有失败的情况，检查多个数据包，发现异常的情况响应数据包均为chunked方式，见下图：
图3 异常响应数据包
原因分析
Wap网关与手机支付平台侧之间采用ssl加密方式交互，无法通过抓包来准确分析故障情况，转而通过排查业务流程并结合现场详细日志进行分析。
首先，通过复现问题时的业务详细日志，定位故障问题出现在协议栈处理ssl响应的chunked部分流程；
其次，通过协议栈详细日志，发现读取ssl会话内容的时候是分阶段读出的，读出过程中会截断chunked编码的结束符”0/r/n/r/n”，无法定位chunked包结束标志。当到达内部传输分片时间节点的时候，先转发已经收到的数据，后续被截断的数据无法判断出数据流何时结束。
第一次读取到875个字符，第二次读取到1个字符为“0”，然后httppro检查到达到时间分片故转发给业务，第三次读取到4个字符为“\r\n\r\n”。此时在httppro缓存的数据无法进行“0\r\n\r\n”匹配操作，数据滞留在httppro缓存中。然后sp回复完响应断链，httppro检测到对端断链，但是发现接受缓存中仍然有数据，误认为对端未回复完整http响应，所以向业务产生707告警。
最后，通过修改各业务处理机配置项zxweb.scr中Downloadmode的值，将内部传输分片方式由之前的“按接收数据的大小和时间”调整为“只根据接收到数据大小” （Downloadmode=3）来分割数据，避免协议栈传输过程中截断chunked编码结束符。
问题解决
修改业务版本中的配置文件，临时屏蔽了现场问题；
后续将优化协议栈版本，更改对ssl会话chunked编码响应的处理方式，彻底解决该问题。
WAP网关侧对于分片下载的模式在系统开局时候就已经固定，近期未做过过调整。应
该是手机支付平台侧进行升级或者改动导致问题发生。
参考文献
[1] 中国电信集团公司.中国电信CDMA WAP网关设备规范v1.0[s],2008.03
[2] 中國电信集团公司. 中国电信CDMA WAP网关接口规范v1.0[s],2008.03