為了理解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層全是亂碼，解析不出來。
先說到這里。希望大家能看懂。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
