How to analyze the HTTP or TCP packets captured by the packet capture tool during the test

How to analyze the HTTP or TCP packets captured by the packet capture tool during the test

Http://www.docin.com/p-101479451.html

C/S communication interface testing often causes many problems due to incorrect request structure or packet sending errors. Usually, you need to use the packet capture tool to capture the sent packets, after further analysis, we can easily see the existing errors. Based on my own summary and experience, I have organized a simple analysis method as my own knowledge accumulation for future reference.

This is a packet capture request:

0x0010 0a01 03a6 50a5 2d6f df20 f96b 2f09 fa4d ...... P.-o... k/. M
0x0020 5010 825b ec59 0000 0000 0000 0000 P... [. Y ........
14:23:10. 184430 88.120.40.59.broad.sz.gd.dynamic.163data.com.cn.20645> pcs3166.20.31: P [tcp sum OK] 150: 306 (156) ack 26 win 33371 (DF) (ttl 109, id 23149, len 196)
0x0000 4500 00c4 5a6d 4000 6d06 f19f 3b28 7858 E... Zm @. m...; (xX
0x0010 0a01 03a6 50a5 2d6f df20 f96b 2f09 fa4d ...... P.-o... k/. M
0x0020 5018 825b afcc 0000 0001 9c00 0100 0000 P ..[............
0x0030 0100 0000 0000 0000 3c72 6571 3e3c 6d73 ...... <req> <ms
0x0040 6973 646e 3e31 3336 3332 3631 3734 isdn> 3339
0x0050 3c2f 6d73 6973 646e 3e3c 7077 643e 3733 </msisdn> <pwd> 73
0x0060 3432 3830 3c2f 7077 643e 3c75 613e 506f 4280 </pwd> <ua> Po
0x0070 636b 6574 5f50 433c 2f75 613e 3c76 6572 cket_PC </ua> <ver
0x0080 3e6d 7075 7368 2e31 2e31 2e31 2e30 3835> mpush.1.1.1.085
0x0090 3c2f 7665 723e 3c63 6f6d 6d5f 7665 723e </ver> <comm_ver>
0x00a0 313c 2f63 6f6d 6d5f 7665 723e 3c6d 6574 1 </comm_ver> <met
0x00b0 6169 643e 303c 2f6d 6574 6169 643e 3c2f aid> 0 </metaid> </
0x00c0 7265 713e req>

Refer:

The format of the entered message header is as follows:

CLIENT-> CSVR message Interface Format

Protocal Version 2 bytes, number

Length 4 bytes, number

Type 2 bytes, number

TransactionID 4 bytes, number

Session ID 4 bytes, number

MSG BODY XML format, with an indefinite length

Length: indicates the total length of the entire message, including the protocal version, Length, type, session id, and msg body fields.

Type indicates the message Type. The Type and value are logon requests: 1 (Client-> Server)

According to the above Protocol Analysis:

Before MSGBODY: 2 + 4 + 2 + 4 + 4 = 16 bytes

So it is correct to find 16 bytes from MSGBODY,

The following figure shows the 16 bytes from <req>:

0001 9c00 0100 0000 0100 0000 0000

The comparison Protocol shows that:

0001 9c00 0100 0000 0100 0000 0000

NVersion nLength nType nTransactionID; 4 nSessionId

Because of the differences between the network byte sequence and the host byte sequence, the byte sequence of different CPUs is different. Some CPUs are high bytes in front, and some are low bytes in front. The message streams transmitted over the network are in the network byte order,

If we analyze the packet capture tool message, because the host is a Pentium CPU, we need to first convert the network order to the host order, and we need to replace it before and after. After replacement:

0100 0001 009c 0000 0000 0001 0000

NVersion nLength nType nTransactionID; 4 nSessionId

Convert to 10 hexadecimal: 256, 65692, 0, 1, 0

The actual length value can be counted as follows: 16 + MSGBODY packets (140 bytes) = 156

Also, we can see that ntype is incorrect. In fact, it should be 1. The version is incorrect.

Through this analysis, we can see that the login request is wrong and the cause of the error is known.

(General Packet Capture: I use the root user to directly use the command line to capture packets without using related tools)

The packet capture command is:

/Usr/sbin/tcpdump/-vvx-s 2048-I etho port number