51Testing软件测试论坛

标题: winsock的buffer简单解析。 [打印本页]

作者: sunshinelius 时间: 2005-5-18 11:47
标题: winsock的buffer简单解析。
为了理解socket机制和buffer原理，我录制了一个从IE访问web站点的winsock脚本，并对此脚本的数据简单地解析了一下。
在用VU访问web的同时，我也在server端抓包，把两个包进行对比。
好，我启动VU，选择winsock协议，然后启动IE，输入URL，回车！
在server上，我抓到的数据如下：
IE -> web    TCP D=8888 S=15105 Syn Seq=2724368295 Len=0 Win=65535 Options=<mss 1332,nop,nop,sackOK>

         0: 0003 ba50 1f65 0008 74eb 7f05 0800 4500 ...P.e..t.....E.
      16: 0030 f9e3 4000 8006 8651 ac1c 10d4 ac1c .0..@....Q......
      32: 1186 3b01 22b8 a262 8fa7 0000 0000 7002 ..;."..b......p.
      48: ffff 7949 0000 0204 0534 0101 0402       ..yI.....4....

   web -> IE TCP D=15105 S=8888 Syn Ack=2724368296 Seq=837817715 Len=0 Win=25308 Options=<nop,nop,sackOK,mss 1460>

         0: 0008 74eb 7f05 0003 ba50 1f65 0800 4500 ..t......P.e..E.
      16: 0030 cbac 4000 4006 f488 ac1c 1186 ac1c .0..@.@.........
      32: 10d4 22b8 3b01 31f0 1573 a262 8fa8 7012 ..".;.1..s.b..p.
      48: 62dc 7ab5 0000 0101 0402 0204 05b4       b.z...........

IE -> web    TCP D=8888 S=15105    Ack=837817716 Seq=2724368296 Len=0 Win=65535

         0: 0003 ba50 1f65 0008 74eb 7f05 0800 4500 ...P.e..t.....E.
      16: 0028 f9e5 4000 8006 8657 ac1c 10d4 ac1c .(..@....W......
      32: 1186 3b01 22b8 a262 8fa8 31f0 1574 5010 ..;."..b..1..tP.
      48: ffff 5e19 0000 0000 0000 0000             ..^.........
呵呵，可以看到在TCP层上，我们看到了server和client端的三次交互，但奇怪的是在winsock脚本中却没生成对应的函数和buffer。后来想想，这是TCP的三次握手，只是具有TCP的头和尾，其中并没有数据，可能lr将其忽略了。
那各位就要问了凭什么你说那些十六进制数据就是TCP的头尾，而不是真正有意义的数据呢，别着急，咱们往下看下一个真正的请求是什么样子的。
在server上，下一个数据包如下（数据包太大了，我们只看整个数据包的前部）：
IE -> web    TCP D=8888 S=15209    Ack=2865793660 Seq=3555244501 Len=401 Win=65535

         0: 0003 ba50 1f65 0008 74eb 7f05 0800 4500 ...P.e..t.....E.
      16: 01b9 02e9 4000 8006 7bc3 ac1c 10d4 ac1c ....@...{.......
      32: 1186 3b69 22b8 d3e8 b9d5 aad0 8a7c 5018 ..;i"........|P.
      48: ffff d68c 0000 4745 5420 2f70 6f72 7461 ......GET /porta
      64: 6c38 3030 302f 6164 6d69 6e2e 6a73 7020 l8000/admin.jsp
      ................................................................
这是一个http的get请求，各位注意看，这个数据包的offset从0－56是不是和第一个请求很象啊，没错，这支持了我们刚才的判断，那只是tcp的头，真正的数据是从get开始，即从57位开始。
同时，我们VU中生成的send buffer如下：
send  buf0
"GET /portal8000/admin.jsp HTTP/1.1\r\n"
"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/v"
"nd.ms-powerpoint, application/vnd.ms-excel, application/msword, applicatio"
"n/x-shockwave-flash, */*\r\n"
"Accept-Language: zh-cn,en;q=0.5\r\n"
"Accept-Encoding: gzip, deflate\r\n"
"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; (R1 1.3))\r"
"\n"
"Host: 172.28.17.134:8888\r\n"
"Connection: Keep-Alive\r\n"
"\r\n"
在buffer0里已经没有了0－56一些看不懂的数据，直接是get请求。这说明lr的winsock捕获了tcp传输中的数据部分，而略去了tcp的头。我们明白一点了。
但是我们看到server端抓到的数据其实都是十六进制的数据，lr直接显示的是文本，那lr是怎样将其转换为文本的呢（我用的是snoop命令在server端抓包，它也有自动将其转换文本的功能，就是数据的右侧文本）？
我们知道在编码过程中，一个英文字母用一个字节来表示，一个中文汉字则用两个字节来表示。（有时lr不能正确地显示中文，就是因为它不支持中文，无法知道怎样去合并两个字节成为中文汉字）
那么我们试着去解析下面的一行
64: 6c38 3030 302f 6164 6d69 6e2e 6a73 7020 l8000/admin.jsp
snoop命令给我们已经解析好了，“l8000/admin.jsp”，按一个英文字母对应一个字节的规则的话，英文字母l应该对应6c，6c是十六进制，转化十进制是108，而l的ascii码正是108。这个字母对上了。
往下就简单了，38对应8，30对应0，依次a d m i n . j s p都能对应下去。解析完毕！

如果都能这样解析，那么lr中的send buffer和receive buffer都应该能够解析出来，不会出现乱码。我们也能很轻松地去参数化buffer了。

但是很不幸，看起来，lr犯了一个错误，在receive buffer和send buffer中。lr不管三七二十一，都按照此规则解析。解析不出来就显示大段的乱码。让使用者无所适从。

例如我在下面请求中，试图get一个图片，server端返回一个图片，图片是二进制的，用十六进制在网络传输。但是lr还是试图去解析这个图片，结果得到了一大批的乱码，让我们都判断不出来这段buffer的含义了。

还有一种乱码的情况，前不久和QA_BAY聊了用lr录制QQ的例子，结果录下来，发现满篇都是乱码，晕啊。如果都能象http协议这样透传的话，最起码能够录到登陆口令的英文字母啊。所以我只好怀疑在上层加密了数据，导致socket层全是乱码，解析不出来。

晕，先说到这里。希望大家能看懂。

作者: sunshinelius 时间: 2005-5-18 14:22
在windows下面可以用ethreal，在unix下面可以用snoop。我的例子是在solaris下面用snoop命令抓包的。

作者: sunshinelius 时间: 2005-5-18 22:41
有不少人对winsock协议的录制和参数化感兴趣，怎么都不说话了，讨论一下各自发现的东西，不是挺好。

作者: sunshine_luo 时间: 2005-5-19 11:21
第一，我对楼主的这点提法有点异议：这是TCP的三次握手，只是具有TCP的头和尾，其中并没有数据，可能lr将其忽略了。我个人认为loadrunner只会对应用层的一些协议进行处理，而对于传输层或网络层的东西都会将其过滤掉，或者说应用层以下的东西并不是所loadrunner关注的
第二，在网络上所有的内容都是按照bit流的方式来传输，而所谓的二进制或者说16进制这只是print出来的方式不同而已；在socket协议中data.ws中loadrunner会将sendbuf和recvbuf中的所有数据都按照ascii码的方式来解析，而有些中文或者其他编码没有办法解析所以就以乱码的方式表现出来了（好像loadrunner并不支持unicode编码）。我觉得如果希望参数化buf中的内容首先你要熟悉buf中每个字节的意义，这也就要求你必须熟悉应用层的协议了。
第三，对于qq登录我想应该是经过加密的了，我想腾讯也不会让用户的userid和password应该不会以明文的方式在网络上传输，所以录制qq登录过程中产生的乱码是可以解释的

作者: sunshinelius 时间: 2005-5-19 12:17
^_^，终于看见sunshine_luo了，sunshine_luo可是loadrunner版的元老级人物，与pcl同时代，比我早。
sunshine_luo以上说得很对，一个字，pf。

作者: bluedevils 时间: 2005-5-23 16:40
loadrunner支持unicode的
调用lr_convert_string_encoding函数进行转换

作者: sunshinelius 时间: 2005-5-24 09:36
lr7.8的buffer的转换上是不支持的，不知8.0是否能够做到。
lr的大多函数都与win32的api有关联，就算lr在api上没有这个函数，我们也可以include进来，自己调用。

作者: rain_wind 时间: 2005-7-12 20:52
晕,不理解

作者: weijiang555280 时间: 2005-12-12 15:55
终于明白了用LR录制脚本中为什么总是有乱码的原因了。多谢！

作者: liangjz 时间: 2006-1-4 11:38
可以使用lrs_save_param_ex (....ascii ) 保存，再用 lr_log_message之类函数打印

作者: oscarli 时间: 2006-7-21 14:47
标题: 谢谢
可以把操作步骤说得更详细些吗？

作者: hmilyjch 时间: 2006-7-21 17:16
恩,
挺晕的~

作者: kevinbj 时间: 2006-10-11 15:50
标题: 直接写buf
buf里面有些字符应该是直接从二进制转换为十六进制的，如："\x00\x03\x05"
应该可以直接把ethereal抓到的数据写到buf中，（我还没试验成功,嘿嘿！）

[ 本帖最后由 kevinbj 于 2006-10-11 15:52 编辑 ]

作者: guxingyun 时间: 2007-4-16 22:48
好贴标注先正在学习winsocket

作者: lijuansun 时间: 2007-7-24 15:46
!!!

作者: guxingyun 时间: 2007-7-24 23:41
呵呵再次看到自己在#16楼的回复觉得挺有意思的那时才开始真真地接触论坛还没有使用收藏功能所以回复的内容大多都是标注学习之类三个多月过去了自己在这里收获了很多继续努力与大家一同进步

作者: evergreenwang 时间: 2007-7-26 15:03
需要向你们学习啊
我就遇到把XML文件解析出来之后再写入一些内容就出现乱码的问题现在还没有解决的啊

作者: testman 时间: 2007-10-17 10:48
受益了

作者: 雨加雪 时间: 2008-7-3 14:07
似乎有点明白了晕乎乎的慢慢来

作者: jessica42237728 时间: 2009-6-26 11:32
太佩服了。
前辈们~~~

作者: conanin 时间: 2009-8-13 10:24
学习了，对winsocket确实不熟,谢谢各位高手

作者: liusiyan 时间: 2010-10-15 15:35
具有很好的借鉴作用，说到QQ的脚本录制，应该是lr不支持中文的缘故

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)