What is the handshake process like when connecting to a host whose IP does not exist?

[[410045]]

This article is reprinted from the WeChat public account "Xiaobai debug", the author is Xiaobai. Please contact Xiaobai debug public account for reprinting this article.

I have been postponing this for a long time. I have been very busy recently. I used to take time to write articles after I finished work.

Now after finishing work, I still have to learn to drive on Monday, Wednesday and Friday, and look at furniture on Tuesday, Thursday and Saturday. Friends who feel the same way, don't raise your hands, just scroll to the lower right corner and click "Reading".

Really, it’s all Tik Tok’s fault.

[[410046]]

Let’s get back to today’s topic.

Brother Fang recently wrote a great article for those of you who want to write Go at ByteDance, in which he mentioned two issues.

What is the handshake process like when connecting to a host whose IP does not exist?

What is the handshake process like when connecting to a host whose IP address exists but the port number does not exist?

It reminded me that I was once asked a similar question by an interviewer, and I realized that many of my friends would be interested in this question.

So let me tell you about it.

These two questions can extend to many points.

After reading it, you might get extra points!

[[410047]]

What is the normal handshake process like?

The question mentioned above actually refers to the TCP three-way handshake process. This is definitely a common question in interview writing.

Let’s briefly review the basics.

Normal TCP three-way handshake

After the server is started, the listen() method will be called, entering the LISTEN state, and then quietly waiting for the client's connection request to arrive.

At this time, the client actively calls connect(IP address), initiates the first handshake to a certain IP address, and sends SYN to the destination server.

After receiving the first handshake, the server will respond to the client, which is the second handshake.

After receiving the second handshake message, the client responds to the service with an ACK, which is considered the third handshake. At this time, the client will enter the ESTABLISHED state and believe that the connection has been established.

The process of the three-way handshake can be intuitively seen by capturing packets.

Normal three-way handshake packet capture

What is the handshake process like when connecting to a host whose IP does not exist?

There are two types of non-existent IPs: those within the LAN and those outside the LAN.

Home router LAN interconnection

Let me use my family’s situation as an example.

There is a home router at home. In essence, its functions have integrated the functions of routers, switches and wireless access points that we often talk about.

Routers and switches have been introduced in detail in the previous article "Hardcore Illustrated! 30 pictures to help you understand! What are the differences between routers, hubs, switches, bridges, and optical modems?", so I will not repeat them again. A wireless access point can basically be considered a component that emits a wifi signal.

Under my home router, I have N devices connected to it, including my mobile phone and computer. Their IPs all have something in common. They are all in the form of 192.168.31.xx. Among them, the IP of my computer is 192.168.31.6, which can be checked through ifconfig.

These devices that conform to this form are essentially connected to the e2 port of the router in the above picture through various devices (wifi or switches, etc.), and they together form a local area network.

Therefore, in my home, we can roughly assume that as long as the IP is in the form of 192.168.31.xx, it is an IP in the LAN. Otherwise, it is an IP outside the LAN, such as 192.0.2.2.

The destination IP is in the LAN

Because I can check my LAN IP address as 192.168.31.6 through ifconfig, so I guess the IP address with +1 at the end does not exist. I tried it and found that 192.168.31.7 does not exist.

 $ ping 192.168.31.7
 PING 192.168.31.7 (192.168.31.7): 56 data bytes
 Request timeout for icmp_seq 0
 Request timeout for icmp_seq 1
 Request timeout for icmp_seq 2
 Request timeout for icmp_seq 3
 ^C
 --- 192.168.31.7 ping statistics ---  
 5 packets transmitted, 0 packets received, 100.0% packet loss

So I wrote a program to try to connect to this IP. The following code is written in golang. It doesn't matter if you don't read the code. It is only released for your own use when you reproduce it.

 //tcp client
 package main 
 
 import (
 "fmt"  
 "io"  
 "net"  
 "os"  
 ) 
 
 func main() {
    client, err := net.Dial( "tcp" , "192.168.31.7:8081" )
 if err != nil {
        fmt.Println( "err:" , err)
 return  
 } 
 
 defer client. Close ()
 go func() {
        input := make([]byte, 1024)
 for {
            n, err := os.Stdin. Read (input)
 if err != nil {
                fmt.Println( "input err:" , err)
 continue  
 }
            client.Write([]byte(input[:n]))
 }
 }() 
 
 buf := make([]byte, 1024)
 for {
        n, err := client. Read (buf)
 if err != nil {
            if err == io.EOF {
 return  
 }
            fmt.Println( "read err:" , err)
 continue  
 }
        fmt.Println(string(buf[:n]))
 }
 }

Then try to capture the packet.

Capture packets from a non-existent IP (within the LAN)

It can be found that there is no three-way handshake packet at all, only some ARP packets asking "Who is 192.168.31.7, tell me 192.168.31.6".

There are three issues here

• Why is an ARP request sent?
• Why is there no TCP handshake packet?
• ARP itself does not have a retry mechanism. Why does the ARP request send so many times?

First, let's look at the process of executing connect under normal circumstances, which is the first handshake.

Normal connect process

After the application layer executes the connect, it will pass through the socket layer and the operating system interface, and the process will enter the kernel state from the user state. At this time, it will enter the transport layer. Because it is the first TCP handshake, the TCP header will be added and the SYN flag will be set.

SYN in TCP header

Then I entered the network layer. The address I wanted to connect to was 192.168.31.7. Although I made it up, I still had to add it to the IP header.

The neighbor subsystem is the one that needs to be introduced at this time. It is between the network layer and the data link layer. The destination IP can be converted to the corresponding MAC address through the ARP protocol, and then the data link layer can use this MAC address to assemble the frame header.

Let's take a look at the process of the ARP protocol.

ARP Process

1. First check the local ARP table to see if there is a MAC address corresponding to 192.168.31.7. If there is, return it. Obviously, there is no such a MAC address here.

You can use the arp -a command to view what information is recorded in the local arp table.

 $ arp -a
 ? (192.168.31.1) at 88:c1:97:59:d1:c3 on en0 ifscope [ethernet]
 ? (224.0.0.251) at 1:0:4e:0:1:fb on en0 ifscope permanent [ethernet]
 ? (239.255.255.250) at 1:0:3e:7f:ff:fb on en0 ifscope permanent [ethernet]

2. Check if 192.168.31.7 and the local IP 192.168.31.6 are in the same LAN. If so, send an ARP broadcast in the LAN, the content is the aforementioned "Who is 192.168.31.7, tell 192.168.31.6".

3. If the destination IP and the local IP are not in the same LAN, the MAC address of the default gateway will be obtained, which refers to the MAC address of the home router. Then the message will be sent to the home router, which will send it to the Internet, find the next hop router, and send data hop by hop until the message is sent to the destination IP, or it cannot find the destination and is finally discarded.

4. Points 2 and 3 are both situations where no ARP cache record is found locally. At this time, the SYN message will be put into a queue (called unresolved_queue) for temporary storage, and then an ARP request will be initiated; after the ARP layer receives the ARP response message, it will take out the SYN message from the cache, assemble the MAC frame header, and complete the sending process that was not completed just now.

If the MAC address can be returned normally through the ARP process, everyone is happy. It is directly given to the data link layer, passed through the ring buffer, and then sent to the network card.

But because the IP address is made up, it is impossible to get the destination MAC address, so the message can never reach the data link layer. The whole process is stuck in the ARP process.

Packet capture is performed after the data link layer, so the packets of the first TCP handshake have not been captured. Only the ARP request to obtain the MAC address of 192.168.31.7 can be captured.

When sending data, the packet capture operation is performed by the dev_queue_xmit_nit method after passing through the data link layer, which belongs to the method of the network card driver layer.

By the way, the receiving end packet capture is performed in the __netif_receive_skb_core method, which also belongs to the network card driver layer. Interested friends can use this as a keyword to search for related knowledge points.

At this time, because the TCP protocol is a reliable protocol, for the TCP layer, the first handshake message has been sent, but no ACK has been received. It is unknown what happened to the message after it was sent out. In order to ensure reliability, it will be resent continuously.

Each time the message is resent, it gets stuck in the ARP process for the same reason (no destination MAC address). Therefore, we see repeated ARP messages several times.

Let’s go back to the three questions just now.

• Why is an ARP request sent?

Because the destination address is randomly generated, the local ARP table does not have the MAC address of the destination machine, so an ARP message is sent.

• Why is there no TCP handshake?

Because after the data of the protocol stack reaches the network layer, before the data link layer, it cannot be sent out because there is no destination MAC address. Therefore, the packet capture software cannot capture the relevant data.

• Why are ARP requests sent so many times?

Due to the reliability of the TCP protocol, the first handshake message will be resent, but it will fail each time because there is no destination MAC address, and an ARP request will be sent each time.

summary

When connecting to a host whose IP does not exist, if the destination IP is in the LAN, the first handshake will fail, and then the handshake request will be resent. At the same time, the machine will continue to send ARP requests in an attempt to obtain the MAC address of the destination machine. And, because the destination MAC address cannot be obtained, these TCP handshake requests will eventually fail to be sent out.

The destination IP is outside the LAN

The above mentioned is the case where the destination IP is within the LAN. The following discusses the case where the destination IP is outside the LAN.

Make up an IP that is not in the format of 192.168.31.xx as the extra-LAN IP to be used this time, such as 10.225.31.11.

Let’s capture the packet first.

Capture packets from a non-existent IP (outside the LAN)

The phenomenon this time is that the SYN packet of the first TCP handshake can be sent.

There are two problems here

• Why is the IP connection outside the LAN inconsistent with the connection inside the LAN?
• The retry rule of the first TCP handshake seems to be wrong?

Why is the IP phenomenon outside the LAN inconsistent with that inside the LAN?

The answer to this question has actually been mentioned in the ARP process above. If the destination IP and the local IP are not in the same LAN, then the MAC address of the default gateway will be obtained, which refers to the MAC address of the home router.

At this point, the ARP process successfully returns the MAC address of the home router, the data link layer adds a frame header, and the message is sent to the home router through the network card.

The message will be transmitted through the Internet to a router in a local area network named 10.225.31.xx. The router will send out an ARP request to ask if there is any machine in their local area network named 10.225.31.11 (of course there is none).

Ultimately, the message was not sent successfully, and the sender was unable to receive the second handshake response from the destination machine.

Thus triggering a TCP retransmission.

The retry rule of the first TCP handshake seems to be wrong?

In Linux, the number of SYN retransmissions for the first handshake is controlled by the tcp_syn_retries parameter. You can view it in the following way:

 $cat /proc/sys/net/ipv4/tcp_syn_retries
 6

This means that syn retransmission will occur 6 times.

Each retry will be separated by a certain time interval, which is usually 1s, 2s, 4s, 8s, 16s, 32s.

SYN Retransmission

In fact, looking at my screenshots, I first retry 4 times, each time for 1s, and then retry for 1s, 2s, 4s, 8s, 16s, and 32s.

This is not quite what we know.

This is because I used macOS to capture the package, which is not the same system as Linux. The implementation of sync retransmission in their respective TCP protocol stacks may be somewhat different.

I also heard that the SYN retransmission of OPPO and Vivo starts from 0.5s, and Windows has its own patent for SYN retransmission.

You don't need to care about these little-known facts. Knowing Linux is enough for the interview, and the rest can be used to show off. After all, the interviewer doesn't care how many ways the word "卉" can be written.

The handshake process of connecting to a host whose IP address exists but the port number does not exist

The above mentioned is the case where the IP address does not exist at all. What if the IP address exists but the port number is made up?

The destination IP is the loopback address

Even the loopback address and port do not exist to capture packets

The phenomenon is relatively simple. The IP address already exists, which means that the machine exists on the Internet.

Then we can send messages to the destination IP normally, because the corresponding MAC address and IP are correct, so the data is OK from the data link layer to the network layer.

Until the transport layer, when the TCP protocol recognizes that the process corresponding to this port number does not exist at all, it will discard the data and respond with an RST message to the sender.

The port does not exist when connecting to the loopback address

What is RST?

We all know that TCP disconnects by waving four times under normal circumstances, which is an elegant approach under normal circumstances.

But under abnormal circumstances, both the sender and the receiver may not be normal, and even waving may not be possible, so a mechanism is needed to forcibly close the connection.

RST is used in this case, and is generally used to abnormally close a connection. It is in the TCP header. After receiving a data packet with this flag set, the connection will be closed. At this time, the party receiving the RST will generally see a connection reset or connection refused error.

TCP header RST bit

The destination IP is in the LAN

I just mentioned that my local IP is 192.168.31.6, and there is a 192.168.31.1 in the LAN. I also tried to connect to a non-existent port.

Even if the IP in the LAN exists, the port does not exist and the packet capture

The phenomenon at this time is consistent with the previous one.

The only difference is that the former is a loopback address, and the RST data is returned from the transport layer of the local machine. In this case, the RST data is returned from the transport layer of the destination machine.

The port does not exist when connecting to the external network address

The destination IP is outside the LAN

Find an existing external network IP address. Here I took the address of the Alibaba Cloud server that I just got for free, 47.102.221.141. (Show off)

After connecting, I found that it was consistent with the previous two situations. After receiving my request, the destination machine immediately disconnected the connection through the RST flag.

Even if there is an existing IP outside the LAN, the port does not exist to capture packets

This is consistent with the previous two situations.

Friends who are familiar with Xiaobai know that every time he does something or does a test, he will use baidu.com.

This time is no exception. Ping baidu.com and get its IP: 220.181.38.148.

 $ ping baidu.com
 PING baidu.com (220.181.38.148): 56 data bytes
 64 bytes from 220.181.38.148: icmp_seq=0 ttl=48 time =35.728 ms
 64 bytes from 220.181.38.148: icmp_seq=1 ttl=48 time =38.052 ms
 64 bytes from 220.181.38.148: icmp_seq=2 ttl=48 time =37.845 ms
 64 bytes from 220.181.38.148: icmp_seq=3 ttl=48 time =37.210 ms
 64 bytes from 220.181.38.148: icmp_seq=4 ttl=48 time =38.402 ms
 64 bytes from 220.181.38.148: icmp_seq=5 ttl=48 time =37.692 ms
 ^C
 --- baidu.com ping statistics ---  
 6 packets transmitted, 6 packets received, 0.0% packet loss
 round-trip min / avg / max /stddev=35.728/37.488/38.402/0.866 ms

Send a message to the IP behind the Baidu domain name, and randomly specify a port 8080 to capture the packet.

Connect to Baidu, the port does not exist to capture packets

The phenomenon is inconsistent. There is no RST. And the retry message of the first handshake is triggered. Why is this?

This is because Baidu's machines, as online production machines, will set up a series of security policies, such as only exposing certain ports to the outside world, and all other ports will be rejected.

Therefore, many messages sent to port 8080 are rejected at the firewall layer and cannot reach the destination host at all. RST is sent in the TCP/IP protocol stack of the destination host, and it has not reached this layer, so it is even more impossible to send RST. Therefore, when the sender finds that there is no response to the message (because it is lost by the firewall), it will retransmit it. This is why the phenomenon in the above packet capture occurs.

Firewall security policy

Summarize

When connecting to a host whose IP does not exist

• If the IP is in the LAN, N ARP requests will be sent to obtain the MAC address of the destination host, and TCP handshake messages cannot be sent.
• If the IP is outside the LAN, the message will be sent through the router, but because the destination cannot be found in the end, the TCP retry process is triggered.

When connecting to a host whose IP address exists but whose port number does not exist

• Regardless of whether the destination IP is a loopback address or an IP address inside or outside the LAN, the transport layer of the destination host will find that the port is incorrect after receiving the handshake message and send an RST message to disconnect.
• Of course, if the destination machine has a firewall policy set up to restrict others from sending messages to ports that are not exposed to the outside world, then in this case, the sender will continue to retry the first handshake.

Finally, I have a question. When connecting to a non-existent host outside the LAN, we can see that the TCP retransmission pattern is: at the beginning, the TCP SYN message is resent five times every 1s, and then every 2s, 4s, 8s, 16s, and 32s.

In contrast, when connecting to a non-existent host in the LAN, the ARP request is resent 4 times every 1 second, and then an ARP request is sent again after 32 seconds. It is known that ARP request has no retransmission mechanism, and its retry is triggered by TCP retry, but the two patterns are inconsistent. Why?