In order to analyze the characteristics of TCP, we use a subcontracting tool to strip TCP of its clothes.

1. Invisible invisible network packets

Packet interaction in the network world is invisible to our naked eyes, as if they are invisible. When we learn computer network from textbooks, we will feel very abstract, which increases the difficulty of learning.

After work, I realized two powerful tools for network analysis: tcpdump and Wireshark. These two powerful tools can display invisible data packets in front of us at a clear sight.

  • What is the difference between tcpdump and Wireshark?

Tcpdump and Wireshark are the most common network packet capture and analysis tools and indispensable tools for analyzing network performance.

Tcpdump supports only the command line format. It is used to capture and analyze network packets on Linux servers. In addition to capturing packets, the Wireshark provides graphical pages for visually analyzing network packets.

You can use the tcpdump command to capture packets on the Linux server, drag the captured packets to a Windows PC, and then use the Wireshark to visualize the captured packets

1.1 How can TCPdump Capture Packets in Linux?

Suppose we want to grab the following ping packet:

To capture packets using the ping command, you need to know that the ping packets are icmp packets. When using the tcpdump command to capture packets, you can specify that only icmp packets are captured.

When tcpdump captures icmp packets, the output format is as follows:

From the ICMP packets captured by tcpdump, we can see the interaction process of ICMP Echo. First, the sender sends an ICMP Echo Request message, and the receiver sends an ICMP Echo Reply message. And then seQ is increasing.

1.2 Tcpdump Usage options and Filtering Conditions

As you’ve probably noticed, tcpdump is powerful, but the output format is not intuitive.

Therefore, the Tcpdump is used to capture data packets rather than analyze them. Instead, the captured data packets are saved as pCAP files and then analyzed using the Wireshark.

1.3 How do Wireshark Analyze Data Packets?

Wireshark download address: www.wireshark.org/download.ht…

In addition to capturing packets, the Wireshark provides graphical pages for analyzing network packets, and provides a series of built-in summary and analysis tools.

For example, using the ping example above, we can use the following command to save captured packets to the ping.pcap file.

Then drag the ping.pcap file to your computer and open it with Wireshark. When opened, you should see the following interface:

Then, after you select a network packet from the network packet list, you can see the detailed information about this network packet at each layer of the protocol stack in the network packet details below it. For example, take network package number 1:

1. In the data link layer, you can view the MAC packet header information, such as the source MAC address and destination MAC address. 2. At the IP layer, you can view the IP packet header information, such as the number and meaning of each field of the IP protocol, such as the source IP address and destination IP address, TTL, IP packet length, and protocol. 3. At the ICMP layer, you can view ICMP header information, such as the values and meanings of ICMP fields such as Type and Code.Copy the code

From the ping example, we can see that network layering is like an orderly division of labor. Each layer has its own scope of responsibility and information, and the work of the upper layer protocol is handed over to the next layer to form a complete network package.

2. Decrypt the TCP three-way handshake and four-way wave

Since learned tcpdump and Wireshark network analysis tool, and that we work fast, took with it two fetching and HTTP protocol network packet analysis, and understand the TCP three-way handshake and four wave principle.

For this example, we’ll visit the http://192.168.3.200 server. Run the tcpdump command on terminal 1 to capture data packets:

Curl curl curl curl curl curl curl curl curl

Finally, go back to Terminal 1 and press Ctrl+C to stop tcpdump and take the resulting HTTP.pcap out to the computer.

After using the Wireshark to open http.pcap, you can view the following page in the Wireshark:

We all know that HTTP is based on TCP protocol for transmission, so:

1. The first three packets are TCP three-way handshake packets. In the middle are HTTP request and response packets 3. The last three packets are TCP disconnection wave packetsCopy the code

The Wireshark can display data packets in sequence graphs. From the menu bar, choose Statistics > Flow Graph ᰁ. In the displayed dialog box, choose TCP Flows from ᰁ type. The execution of the TCP flow in the whole process:

  • You might wonder, why is Seq zero for the three-way handshake connection?

In fact, the Wireshark tool optimized it for us. By default, the serial number seQ is displayed relative, not real.

If you want to see the value of the actual serial number, you can right-click the menu and go to “Protocol Preferences”, then go to “Relative Seq” and cancel it as follows:

As you can see, the client and server serial numbers are actually different, and the serial number is a random value.

This is very similar to the TCP three-way handshake and four-way wave that we read about in our books. For comparison, you can see TCP three-way handshake and four-way wave flow basically like this:

  • Why do you catch TCP waving three times instead of four times as the book says?

After the server receives the FIN from the client, the server also closes the connection. In this way, the ACK and FIN can be sent together, saving one packet and becoming “three waves”.

Usually, after the server receives the client’s FIN, it is likely that the data has not been sent, so it will reply the client with an ACK packet and wait for a while to send all the packets before sending the FIN packet, which is the four times of waving.

Here are the four waves:

3. Actual analysis of TCP three-way handshake exceptions

The TCP three-way handshake process is familiar to everyone, so have you ever thought of these three exceptions:

  1. TCP lost packets in the first handshake. What happens?
  2. The TCP SYN and ACK packets in the second handshake are lost. What happens?
  3. What happens if the ACK packet for the TCP third handshake is lost?

Some friends might say, “It’s easy. If you lose your bag, it will be retransmitted.”

  1. How many times will ᯿ pass?
  2. What happens to the RTO for timeout retransmission?
  3. How do I set the number of ᯿ transmissions in Linux?
  4. .

Are you speechless, unable to answer?

I’m going to take you through three experimental cases to explore these three abnormalities.

  • The experimental scene

Two virtual machines were used in this experiment, one as the server and the other as the client. Their relationship is as follows:

1. Both the client and server are CentOs 6.5 Linux, Linux kernel version 2.6.32 2. Server 192.168.12.36, Apache Web service 3. The client 192.168.12.37Copy the code

3.1 SYN Packet Loss during the first TCP Handshake

Curl = curl = curl = curl = curl = curl = curl = curl

The following commands are used to capture packets:

Curl returns a timeout connection error:

Curl returns an error after a timeout of nearly 1 minute.

Then, the tcp_sys_timeout.pcap file was opened and analyzed with Wireshark, as shown in the following figure:

The client sends a SYN packet, but does not receive an ACK from the server. Therefore, the client sends the SYN packet five times, and the RTO timeout is different each time:

1. The first attempt is retransmitted in 1 second timeout. 2. The third time is 7 seconds timed out 4. The fourth time is 15 seconds timed out 5. The fifth time was retransmission in 31 secondsCopy the code

As you can see, the RTO of each timeout increases exponentially (doubled), and the client stops sending SYN packets when the maximum number of ᯿ packets is exceeded.

In Linux, the SYN timeout for the first handshake ᯿ is specified by the following kernel parameters:

The default value of tcp_syn_retries is 5. That is, the maximum number of SYN attempts is ᯿.

Next, we try again, setting tcp_syn_retries to two times:

After retransmitting the captured packet, use Wireshark to open it for analysis, and the following picture is displayed:

  • Summary of experiment 1

Through the experimental results of experiment 1, we can know that when the client initiated the FIRST TCP handshake SYN packet, within the timeout period did not receive the server’S ACK, it will send SYN packets in timeout ᯿, each timeout retransmission RTO is doubled and increased. The client stops sending SYN packets until the SYN packet ᯿ number reaches the tcp_SYN_retries value.

3.2 SYN and ACK Packets are Lost during the second TCP handshake

In order to simulate the client cannot receive the server’s SECOND handshake SYN and ACK packets, I add firewall restrictions on the client and directly discard the data from the server. The firewall configuration is as follows:

Delete from the client with curl:

Curl returned an error about 1 minute later.

The data packets captured by the client during this period were opened and analyzed by Wireshark, and the sequence diagram is shown as follows:

As can be seen from the figure:

After the client sends a SYN packet, the firewall blocks all packets from the server. With curl, the client cannot receive a SYN or ACK packet from the server. If a timeout occurs, the client retransmits the SYN packet. After receiving a SYN packet from the client, the server replies with a SYN or ACK packet. However, the client does not reply with an ACK packet. After the server times out, it retransmits the SYN or ACK packet. After a while, the SYN packet retransmitted by timeout from the client arrives at the server. After the server receives the SYN packet, the timeout timer is reset and the SERVER replies with a SYN or ACK packet. Therefore, the timeout timer is triggered only once and reset again. 3. The client stops sending SYN packets when the SYN retransmits times out to five times (the default value of five times is tcp_SYN_retries)Copy the code

Therefore, when SYN and ACK packets are lost during the second handshake, the client and the server timeout to retransmit SYN and ACK packets.

  • If a firewall is configured on the client, the network packet on the server is blocked. Why can tcpdump still catch the network packet on the server?
After the iptables restriction is added, whether tcpdump can catch packets depends on the added iptables restriction: 1. If the OUTPUT rule is added, packets can be captured. 2. If the OUTPUT rule is added, packets cannot be capturedCopy the code
  • Sequence of network packets entering the host

Enter Wire -> NIC -> tcpdump -> netfilter/iptables

Iptables -> tcpdump -> NIC -> Wire

  • Tcp_syn_retries limits the number of SYN retries. What is the maximum number of SYN and ACK retries allowed during the second handshake?

The maximum retransmission times of SYN and ACK packets in the second TCP handshake are limited by the tcp_SYNack_retries kernel parameters. The default values are as follows:

Yes, the default maximum number of retransmission times for SYN and ACK packets in the second TCP handshake is 5.

  • Verify the maximum retransmission times of SYN and ACK packets

For the next experiment, set the tcp_SYN_retries to 1, indicating that the maximum SYN timeout on the client is one. The purpose is to reset the SYN and ACK timeout timers on the server to prevent multiple SYN retransmissions.

Then, again, the above steps:

1. Configure a firewall on the client to block data packets from the server. 2Copy the code

Wireshark was used to open and analyze the captured data packets, and the sequence diagram was shown as follows:

From the above figure, we can analyze that:

1. The SYN on the client times out ᯿ only once because the tcp_syn_retries value is 1 2. After the server replies to the SYN packet retransmitted by the client, it cannot receive the ACK packet from the client. Therefore, the server retransmits the SYN packet and ACK packet with timeout. The RTO of each packet increases exponentially and the server retransmits five times because the TCP_SYNack_retries value is 5Copy the code
  • Set tcp_synack_retries to 2 and tcp_syn_retries to 1:

Then the captured data packets were opened and analyzed with Wireshark, and the sequence diagram was shown as follows:

1. The SYN packet on the client times out ᯿ only once, which is consistent with the value set on tcp_SYN_retries. 2. The SYN and ACK times out at ᯿ on the server twice, which match the value set on tcp_SYNack_retriesCopy the code
  • Summary of experiment 2

According to the results of Experiment 2, when THE SYN and ACK packets are lost during the second TCP handshake, the client’s SYN and ACK packets will be retransmitted timeout, and the server’s SYN and ACK packets will also be retransmitted timeout.

The maximum number of SYN packets retransmitted timeout is determined by tcp_SYN_retries. The default value is 5. The maximum number of retransmissions for SYN and ACK packets on the server is determined by tcp_SYNack_retries. The default value is five

3.3 PACKET Loss in TCP Handshake ACK for the third time

In order to simulate the LOSS of TCP ACK packets for the third handshake, I used the following command to configure a firewall on the server to shield the PACKETS with ACK bits. That is, when the server receives the TCP ACK packets from the client, the server discards them:

Then, run the following command on the client:

Then, the client sends a Telnet command to the server. Since the Telnet command initiates a TCP connection, use this command to test:

The server is in the SYN_RECV state because it did not receive the ACK packet for the third handshake:

The client is in the ESTABLISHED state after the TCP connection is ESTABLISHED:

One minute later, the TCP connection on the server is missing:

After 30 minutes, the client is still in the ESTABLISHED state:

Then, in the Telnet session established by the client, enter 123456 characters to send:

Telnet disconnects from the client for a long time:

  • The above is the phenomenon of realization three of this time, there are two doubts:
1. Why does the connection in the SYN_RECV state disappear one minute later? 2. Why does it take a long time for the Client to disconnect from Telnet after 123456 characters are entered in Telnet?Copy the code

Take your time. We opened and analyzed the data packets just captured with Wireshark, and the sequence diagram is shown as follows:

1. The client sends a SYN packet to the server. After receiving the PACKET, the server sends a SYN or ACK packet back to the client. 2. After receiving the SYN and ACK packets from the server, the client sends an ACK packet back to the server. The TCP connection is in the ESTABLISHED state. 3. The firewall is configured on the server to block the ACK packet of the client. Therefore, the server is in the SYN_RECV state and does not enter the ESTABLISHED state. This is because the sequence of data packets entering the system is tcpudMP first and iptables later. 4. The server times out ᯿ and sends SYN and ACK packets. ᯿ sends packets for five times, exceeding the value of the TCP_SYNack_retries (the default value is 5). So the TCP connection in the SYN_RECV state is broken, and the client is still in the ESTABLISHED state. 5. Although the TCP connection on the server is disconnected, the client is still in ESTABLISHED state after a period of time. Therefore, you enter 123456 characters in the Telnet session on the client. 6. At this time, the server is disconnected and the data packets sent by the client are retransmitted timeout. The RTO value increases exponentially each time.Copy the code
  • Through this wave of analysis, the last two doubts have been resolved
1. When the server retransmits SYN and ACK packets, the maximum number of ᯿ attempts exceeds the tcp_synack_retries. As a result, the TCP connection on the server is interrupted. 2. When the client sends the data packet to the server, the TCP connection on the server has been terminated. Therefore, the data packet is continuously transmitted ᯿ due to timeout.Copy the code
  • The TCP connection after the maximum packet timeout ᯿ pass times is specified by what parameter?

The maximum timeout ᯿ is specified by tcp_retries2. The default value is 15.

  • If the client does not send data, when does a connection in the ESTABLISHED state disconnect?

TCP’s keepalive mechanism needs to be mentioned: Define a time period, in this time period, if there is no link related activities, mechanism of TCP keep alive will start, every time, between sending a message “, “detection of the detecting data packet contains very little, if several continuous detecting messages are not getting response, argues that the current TCP connection is dead, The system kernel notifies the upper-layer application of the error message.

The Linux kernel has corresponding parameters to set the keepalive time, number of keepalive probes, and interval of keepalive probes. The default values are as follows:

net.ipv4.tcp_keepalive_time=7200 net.ipv4.tcp_keepalive_intvl=75 net.ipv4.tcp_keepalive_probes=9 1. Tcp_keepalive_time =7200: indicates that the keepalive time is 7200 seconds (2 hours), that is, if there is no connection-related activity within 2 hours, the keepalive mechanism will be started. 2. Tcp_keepalive_intvl =75: indicates that each detection interval is 75 seconds. Tcp_keepalive_probes =9: indicates that no response is detected for nine times, and the other party is considered unreachable and the current connection is interrupted.Copy the code

This means that on Linux, it takes at least 2 hours, 11 minutes and 15 seconds to discover a “dead” connection.

  • Summary of experiment 3

When establishing a TCP connection, if the server fails to receive the ACK for the third handshake, the server is in the SYN_RECV state and the client is in the ESTABLISHED state.

1. On the server: The server retransmits SYN and ACK packets until the number of retransmission attempts exceeds the TCP_SYNack_retries value (the default value is five times). Then the server disconnects the TCP connection. 1. If the client does not send data packets and remains in the ESTABLISHED state, it takes 2 hours, 11 minutes and 15 seconds to discover a dead connection, and the client connection is disconnected. 2. If the client sends a data packet and does not receive a confirmation packet for the data packet from the server, the client sends the data packet ᯿ until ᯿ sends the data packet more than the tcp_retries2 value (15 times by default). Then the client disconnects the TCP connectionCopy the code