Shulou(Shulou.com)06/01 Report--

TcpIP Protocol, HTTP,DNS practice: packet capture Analysis based on wireshark and BurpSuite

Basic configuration before using wireshark

A beard well lathered is half shaved. In order to make efficient use of wireshark to help us analyze, learn network protocols, and troubleshoot, we need to configure it before use, as follows:

one. Adjust the precision of the "time" column in the packet summary list (packet list) to 1 millisecond.

By default, the time display accuracy of wireshark is 1 nanosecond, but such high accuracy is usually not used in the real environment. It is generally used to evaluate site response speed and user experience performance indicators, accurate to the millisecond level is enough, and nanosecond will display more than 6 decimal places, resulting in a waste of display space in the packet summary list. The specific setting method is as follows:

two. Select the display format of the time column according to the application scenario. By default, taking the time of the first packet captured as the reference point, the capture time of subsequent packets is calculated relative to the time of the start of packet capture (the first). However, in some scenarios, the display format needs to be adjusted to the time difference between the last captured packet, that is, the packet capture interval of two adjacent packets.

We know that some network applications, such as instant messaging, video and audio traffic of conference software, are very sensitive to the continuous sending or receiving time interval of data packets. If the interval between two or more adjacent packets is too long, it will cause the picture and sound delay of the application. A more obvious example is the "card" phenomenon of online games. The long interval between sending and receiving packets leads to the inconsistency and continuity of sound and picture. (it is usually related to the TCP segment retransmission caused by packet loss caused by the load of the communication link at both ends and the high load of the router in it.)

At this time, it is very useful to display the time interval. You can quickly view the stability and fluency of the current network. The specific configuration method is as follows:

three. Modify and export wireshark's default packet shading recognition rules. Through the packet coloring function, users can quickly locate the packet analysis they are interested in, but the default coloring rules are so complex that when color recognition is enabled, "colorful" information is displayed in a packet list, which distracts our attention. in general, we are only interested in one or two types of packets, or further. We only need to identify one or two types of packet colors at a time, so we need to modify the default coloring rules. For more information, please see the figure below:

Select "View" and "Coloring Rules" in the menu bar in order to open the color matching rules dialog box:

four. The display column of the custom packet list. The default display columns from left to right are: data frame number, grab time, source address, destination address, protocol, packet (frame) length, summary information.

In an actual combat scenario, these columns may not provide enough information. For example, I want to quickly browse the lifetime (TTL) field value of each package's IP packet header, and instead of looking for this field in the detailed structure window (packet details) of each package, to save time, you can follow the following figure:

Select "Edit" and "Preferences" in the menu bar in order to open the preferences dialog box:

five. Configure the name resolution function of wireshark according to the actual requirements.

Select "Edit" and "Preferences" in the menu bar in order, switch to the "Name Resolution" tab in the preferences dialog box, and configure it with reference to the illustration below:

Usually you only need to keep the default unparsed link layer, network layer address and transport layer port number, but sometimes you need to turn on the corresponding parsing function, as the old saying goes: case-by-case analysis. You can study the remaining configuration options for name resolution that are not explained in the above figure.

six. Hide the packet byte window (Packet Btyes) of the wireshark main user interface

In the default user interface layout, the window is divided into three parts: packet list, packet structure (details), and packet bytes, which displays the contents of the packet in hexadecimal bytes, which is usually of no concern to us. unless you have some special need to modify the original packet; otherwise, you can hide the byte window to free up additional display space. Select "View" in order and uncheck "Packet Bytes".

seven. Configuration parameters related to IPv4 protocol in wireshark

Configuring the parameters of various protocols is actually changing the way wireshark "captures" and "presents" packets of the protocol. To configure the IPv4 protocol, select the

"Edit", "Preferences", expand the "Protocols" tab in the preferences dialog box, and navigate to the "IPv4" subtab. Refer to the illustration below for configuration:

Let's compare the difference between wireshark parsing the ToS field of the IP packet header of the same packet with the old quality of service standard (service type) and the new quality of service standard (that is, differentiated / differentiated service). You can see that the two only have a different interpretation of each bit in this one-byte header field:

eight. Configuration parameters related to TCP protocol in wireshark

To configure the TCP protocol, select the

"Edit", "Preferences", expand the "Protocols" tab in the preferences dialog box, and navigate to the "TCP" subtab. Refer to the illustration below for configuration:

(due to the complexity of the TCP protocol specification and the different implementations of various operating systems, each of the following options may not necessarily produce the desired results in the description on all systems, and only some important and common TCP protocol features related option configurations are described here. The rest of you can study for yourself, ideally, after reading the TCP/IP detailed explanation series. You should be able to understand the meaning of most of the configuration parameters in the following figure)

The following parses the meaning of some of the configuration options in the figure above. The first is the hardware checksum, which is related to the configuration interface provided by the Nic hardware driver, as shown in windows:

Filter expressions through the display supported by wireshark:

Tcp.checksum_bad = = 1

You can display only packets with TCP checksum errors (verified by wireshark or Nic):

Next, let's analyze the role of the "Analyze TCP sequence numbers" option:

Next, we compare the difference between the TCP relative sequence number ("overwritten" by wireshark) starting at 0 and the randomly generated absolute sequence number (the real sequence number populated by the operating system protocol stack):

That is, the use of relative sequence numbers gives us a more intuitive view of the role of TCP sequence numbers (in the entire TCP session data flow).

Finally, explain a very important concept in the TCP protocol: window scaling.

During the TCP three-way handshake, both parties announce their receive window size (rwnd), in bytes, which is usually the size of the receive buffer of the operating system's protocol stack. Rwnd is used to control the flow of TCP. In short, the data sent by the sender each time (in parallel) cannot exceed the rwnd value advertised by the receiver. This value is dynamic and updated with each ACK sent by both parties. This process will last throughout the life cycle of the TCP session. In this way, the speed of data sent by both parties can be dynamically adjusted: if the application process of one party is slow to read the data located in the kernel receiving buffer, then when sending ACK, the value of rwnd will be lowered and the other party will be notified, and the latter will send data according to the upper limit of the updated rwnd. After the application takes the data from the buffer, you can update a larger rwnd value and notify each other in the corresponding ACK.

In real scenarios, sometimes the initial rwnd values advertised by both parties during the handshake are too "conservative" to maximize the peak bandwidth of the link. The common initial value is 8192 bytes, which means that in the early stage of communication, the data sent by both parties in parallel cannot exceed 8KBytes. Assuming a round trip time of 100ms, the data sent per second does not exceed 80KBytes. This is equivalent to sending no more than 53 TCP segments per second (100 milliseconds for "to", that is, a maximum of 5 TCP segments per 100ms), and assuming that the link bandwidth is 10MBits/s = 1.25MBytes/s, that is, "theoretically" the link can carry data throughput of 1.25MBytes per second (or the upper limit of rwnd that can be supported is 125KBytes per 100ms). Up to 83 TCP segments can be sent in parallel every 100ms), while the actual bandwidth is only 80KBytes/s, which results in low bandwidth utilization (6.4%).

Through the previous simple calculation, we find that it is difficult to make full use of rwnd if we do not increase it to 125KBytes.

The link with 10m bandwidth, because even if the initial congestion window (the upper limit of TCP segments that can be sent in parallel each time) is gradually increased by the TCP slow start effect, the upper limit of 83 parallel every 100ms can be reached from the initial five parallel every 100ms, but because the original TCP specification limits the maximum 65KBytes of rwnd (the rwnd field occupies 2 bytes in the TCP header, that is, 16 bits, the 16 power of 2 is 65536). In practice, you can only parallel 43 TCP segments every 100ms at most (this also requires both parties to "understand" to increase the rwnd to 65KBytes), wasting 50% of the bandwidth resources!

In order to solve the above dilemma that the "theoretical bandwidth" does not match the "actual bandwidth", the concept of window scaling is introduced in the RFC 1323 standard. Window scaling is a 3-byte field in the TCP header, in which a hexadecimal byte is used to represent the "scaling factor". The value is from 00 (the power of current rwnd * 2 = current rwnd * 1 = no scaling) to 0e (14 power of current rwnd * 2 = current rwnd * 16384).

Since the maximum value of rwnd is 65536 bytes and the scaling factor is up to 16384 times, the maximum rwnd value supported by the standard is: 65536 * 16384 = 1073741824 bytes, that is, 1GBytes, which is enough to make efficient use of gigabit (gigabit) bandwidth fiber links!

In addition, the standard stipulates that the window scaling factor must be negotiated during the TCP three-way handshake, and the good value of the protocol is not allowed to be changed thereafter. To make full use of the bandwidth of the previous 10m link through window scaling, take the initial rwnd = 8KBytes as an example, you only need to set the scaling factor to the hexadecimal byte "04"

(4 power of 2 = 16 128KBytes 8 * 16 = 2, has exceeded 125KBytes)

With the basics above, let's review the configuration parameters related to TCP window scaling in wireshark, and you can easily understand:

Finally, there is a TCP configuration option "calculate conversation timestamps"

Its function is to calculate the timestamp (difference) of each frame (or TCP segment) in each TCP session relative to the first frame and the previous frame, which is helpful for detecting the performance of time-sensitive TCP applications, that is, applications that require high user experience. The results are as follows:

You can study the remaining four TCP-related configuration options on your own. It is recommended to read the detailed explanation of tcpip before understanding it.

About TCP timeout and retransmission

The most important part of TCP timeout and retransmission is the measurement of the round trip time (RTT) of a given connection. Since both router and network traffic change, we believe that this RTT may change frequently, and TCP should track these changes and change its retransmission timeout (RTO,Retransmission TimeOut) accordingly.

The RTT timer is started when the message segment is sent. When the ACK corresponding to the message segment is received, the timer is stopped to calculate the RTT, and then the TCP RTO is calculated according to this RTT. When the next message segment is sent, the retransmission timer will retransmit the message segment according to the latest TCP RTO value and no ACK is received after the time indicated by this value.

Instance resolution:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.