不要追求绝对的公平,红尘之中没有公平而言,人活一世,难得糊涂。                                           it is no use doing what you like, you have got to like what you do.

winsock的buffer简单解析

上一篇 / 下一篇  2007-04-17 16:25:24 / 个人分类:Mercury LoadRunner

51Testing软件测试网j${/G Fi4r

为了理解socket机制和buffer原理,我录制了一个从IE访问web站点的winsock脚本,并对此脚本的数据简单地解析了一下。
kn] ~;s"Vx W0在用VU访问web的同时,我也在server端抓包,把两个包进行对比。51Testing软件测试网!Oi2c~+`,vnZC[
好,我启动VU,选择winsock协议,然后启动IE,输入URL,回车!51Testing软件测试网?tF@'CA!r/Z$ZO
在server上,我抓到的数据如下:
w u&Q'Kbs1}q7~0IE -> web     TCP D=8888 S=15105 Syn Seq=2724368295 Len=0 Win=65535 ōptions=<mss 1332,nop,nop,sackOK>
QU#w h.u0
dszDB2k)n0      0: 0003 ba50 1f65 0008 74eb 7f05 0800 4500   ...P.e..t.....E.51Testing软件测试网T^ u8nP5a*z,[P
      16: 0030 f9e3 4000 8006 8651 ac1c 10d4 ac1c   .0..@....Q......
r e0v C+uDe3J0      32: 1186 3b01 22b8 a262 8fa7 0000 0000 7002   ..;."..b......p.51Testing软件测试网)@b1a"li,^l m
      48: ffff 7949 0000 0204 0534 0101 0402       ..yI.....4....51Testing软件测试网 \h'O8D/k'{"e
51Testing软件测试网@D#C4qm @s
    web -> IE TCP D=15105 S=8888 Syn Ack=2724368296 Seq=837817715 Len=0 Win=25308 ōptions=<nop,nop,sackOK,mss 1460>
~9{B#z2mVX051Testing软件测试网kIJ"n)~jj%q
      0: 0008 74eb 7f05 0003 ba50 1f65 0800 4500   ..t......P.e..E.51Testing软件测试网"G9O {f*E
      16: 0030 cbac 4000 4006 f488 ac1c 1186 ac1c   .0..@.@.........51Testing软件测试网8C'd%|c.JE)Ls#J
      32: 10d4 22b8 3b01 31f0 1573 a262 8fa8 7012   ..".;.1..s.b..p.
[bf_7n4v4LP0      48: 62dc 7ab5 0000 0101 0402 0204 05b4       b.z...........
B,R4`K;YfL051Testing软件测试网0RT_M.}
IE -> web     TCP D=8888 S=15105   Ack=837817716 Seq=2724368296 Len=0 Win=6553551Testing软件测试网 y z2q#z0i5u(oIN3@6s
51Testing软件测试网 K!R+i@O ZR
      0: 0003 ba50 1f65 0008 74eb 7f05 0800 4500   ...P.e..t.....E.51Testing软件测试网qGI \\%k%ln*ra3k
      16: 0028 f9e5 4000 8006 8657 ac1c 10d4 ac1c   .(..@....W......51Testing软件测试网j"~1sX-I |[J
      32: 1186 3b01 22b8 a262 8fa8 31f0 1574 5010   ..;."..b..1..tP.
(B7rt]$B5W0      48: ffff 5e19 0000 0000 0000 0000         ..^.........
EC1Y Q4n`0呵呵,可以看到在TCP层上,我们看到了server和client端的三次交互,但奇怪的是在winsock脚本中却没生成对应的函数和buffer。后来想想,这是TCP的三次握手,只是具有TCP的头和尾,其中并没有数据,可能lr将其忽略了。
o?1rqG/u&|*_2_0那各位就要问了凭什么你说那些十六进制数据就是TCP的头尾,而不是真正有意义的数据呢,别着急,咱们往下看下一个真正的请求是什么样子的。51Testing软件测试网2e2gy F&hRm6DWvn
在server上,下一个数据包如下(数据包太大了,我们只看整个数据包的前部):
.Ln }JcS\,hD0IE -> web     TCP D=8888 S=15209   Ack=2865793660 Seq=3555244501 Len=401 Win=65535
QF&R4w`:x0
i%a i+Lp5o/Uw0      0: 0003 ba50 1f65 0008 74eb 7f05 0800 4500   ...P.e..t.....E.
no2\1D-Pm/Kc0      16: 01b9 02e9 4000 8006 7bc3 ac1c 10d4 ac1c   ....@...{.......51Testing软件测试网_'Ll V.@/C ?$nW b;|
      32: 1186 3b69 22b8 d3e8 b9d5 aad0 8a7c 5018   ..;i"........|P.
F3G:v/_5@c,};L5O0      48: ffff d68c 0000 4745 5420 2f70 6f72 7461   ......GET /porta51Testing软件测试网q2XD.MN,t
      64: 6c38 3030 302f 6164 6d69 6e2e 6a73 7020   l8000/admin.jsp51Testing软件测试网yDFIqM.h
      ................................................................
5mXJ5d#oO9r0这是一个http的get请求,各位注意看,这个数据包的offset从0-56是不是和第一个请求很象啊,没错,这支持了我们刚才的判断,那只是tcp的头,真正的数据是从get开始,即从57位开始。
pY5d].H'uuel0同时,我们VU中生成的send buffer如下:51Testing软件测试网0x;K Gg6mPrL&q9UP2Y
send buf0
aaAA0ec0    "GET /portal8000/admin.jsp HTTP/1.1\r\n"
.N2|F?S,Nnkgn0    "Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/v"
/wC/L$i+q1ut0    "nd.ms-powerpoint, application/vnd.ms-excel, application/msword, applicatio"
,T{f%ghK#|X/l0    "n/x-shockwave-flash, */*\r\n"51Testing软件测试网+V l[8EM
    "Accept-Language: zh-cn,en;q=0.5\r\n"51Testing软件测试网e%UD%@h R
    "Accept-Encoding: gzip, deflate\r\n"
)\EW#A0WM0    "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; (R1 1.3))\r"
:}k5nP4^C Q0    "\n"
!Ia$t+hN$D*z t z)ps0    "Host: 172.28.17.134:8888\r\n"
w,[2g4W"^ lR)V0    "Connection: Keep-Alive\r\n"51Testing软件测试网?z5rD'?K
    "\r\n"
6MRy"}&c3GYI'Y;@z0在buffer0里已经没有了0-56一些看不懂的数据,直接是get请求。这说明lr的winsock捕获了tcp传输中的数据部分,而略去了tcp的头。我们明白一点了。51Testing软件测试网4wNtGH7K~v4fz(u
但是我们看到server端抓到的数据其实都是十六进制的数据,lr直接显示的是文本,那lr是怎样将其转换为文本的呢(我用的是snoop命令在server端抓包,它也有自动将其转换文本的功能,就是数据的右侧文本)?
Bw"^6o#TE^6y0我们知道在编码过程中,一个英文字母用一个字节来表示,一个中文汉字则用两个字节来表示。(有时lr不能正确地显示中文,就是因为它不支持中文,无法知道怎样去合并两个字节成为中文汉字)51Testing软件测试网1}4C%C6uHF([/U
那么我们试着去解析下面的一行
^c|"N{}064: 6c38 3030 302f 6164 6d69 6e2e 6a73 7020   l8000/admin.jsp
@q{*an8^7Z0snoop命令给我们已经解析好了,“l8000/admin.jsp”, 按一个英文字母对应一个字节的规则的话,英文字母l应该对应6c,6c是十六进制,转化十进制是108,而l的ascii码正是108。这个字母对上了。
Qe#V.Xa z(tBX0往下就简单了,38对应8,30对应0,依次a d m i n . j s p都能对应下去。解析完毕!51Testing软件测试网3@q z3KnUY1h[V
51Testing软件测试网i%a8gKb2SpR"d)G
如果都能这样解析,那么lr中的send buffer和receive buffer都应该能够解析出来,不会出现乱码。我们也能很轻松地去参数化buffer了。51Testing软件测试网;gRu4E3SKU
51Testing软件测试网)yLMm GG IZ'c#d
但是很不幸,看起来,lr犯了一个错误,在receive buffer和send buffer中。lr不管三七二十一,都按照此规则解析。解析不出来就显示大段的乱码。让使用者无所适从。51Testing软件测试网!Tty+yg
51Testing软件测试网zy"\&Igu^'s
例如我在下面请求中,试图get一个图片,server端返回一个图片,图片是二进制的,用十六进制在网络传输。但是lr还是试图去解析这个图片,结果得到了一大批的乱码,让我们都判断不出来这段buffer的含义了。
vl3qN"@k9cn"M0
Y p5I%N,Be9[0还有一种乱码的情况,前不久用lr录制QQ的例子,结果录下来,发现满篇都是乱码,晕啊。如果都能象http协议这样透传的话,最起码能够录到登陆口令的英文字母啊。所以我只好怀疑在上层加密了数据,导致socket层全是乱码,解析不出来。

TAG:

 

评分:0

我来说两句

Open Toolbar