TCP third handshake data transmission process diagram

The process packets with the SYN flag in the RFC793 document cannot carry data, that is to say, the first two of the three-way handshake cannot carry data (logically speaking, the connection has not been established yet, so it seems a bit unreasonable to carry data). The key point is whether the third handshake can carry data.

Let me first state the conclusion: the third handshake in the three-way handshake process of the TCP protocol to establish a connection allows data to be carried.

Referring to the connection establishment part of the TCP state change diagram above, let's look at what the RFC793 document says. The RFC793 document states the following (omitting unimportant parts):

The key point is this sentence "Data or controls which were queued for transmission may be included", which means that the standard indicates that the ACK packet of the third handshake can carry data.

First of all, the packet of the third handshake is sent by the connection initiator (hereinafter referred to as the client) to the port listener (hereinafter referred to as the server), so you only need to find the processing process of the kernel protocol stack after receiving the packet when a connection is in the SYN-RECV (SYN_RECEIVED in the figure) state. After some searching, I found that the tcp_rcv_state_process function in the tcp_input.c file in the net\ipv4 directory handles this process. As shown in the figure:

This function is actually a TCP state machine, which is used to handle the processing of data packets received when the TCP connection is in various states. There are several parallel switch statements here. Because the function is very long, it is easy to misread the hierarchical relationship. The following figure shows the processing of the SYN-RECV state after simplifying the code that does not need to be concerned:

It is important to note that the two switch statements are in parallel. Therefore, when the TCP_SYN_RECV state receives a legal and standardized two-way handshake packet, the socket state will be immediately set to the TCP_ESTABLISHED state. When the execution reaches the following TCP_ESTABLISHED state case, it will continue to process the data it contains (if any).

The above shows that when the ACK of the third handshake sent by the client contains data, the server can process it normally. So what about the client side? Let’s see how the client sends the third ACK packet when it is in the SYN-SEND state. As shown in the figure:

The implementation of the tcp_rcv_synsent_state_process function is relatively long, so here are the final key points:

It’s clear at a glance, right? If the condition is not met, directly reply with a separate ACK packet. If any condition is met, use the inet_csk_reset_xmit_timer function to set a timer to wait for a short time. If there is data during this period, ACK is sent along with the data, but there is no data to reply with ACK.

The previous doubts have been resolved.

Condition 1: sk->sk_write_pending != 0

This value defaults to 0, so what will cause it to be non-0? The answer is that when the protocol stack's function for sending data encounters a socket status that is not ESTABLISHED, it will perform a ++ operation on this variable and wait for a short while to try to send data. See the picture:

The sk_stream_wait_connect function in net/core/stream.c does the following:

sk->sk_write_pending is incremented, and data is sent after the socket connection reaches the ESTABLISHED state. That explains it clearly.

The default working mode of Linux socket is blocking, that is, the client's connect call will be blocked by default, and will not return until the three-way handshake process is completed or an error occurs. Then nc, a command-line applet that is completely implemented with blocking sockets and does not modify the default socket parameters, will wait for connect to return success or failure before sending data. This is why we cannot capture the data in the packet of the third handshake.

Then set up a non-blocking socket and send data immediately after connecting. If the connection process is not successful instantly, you may have a chance to see the third handshake packet with data. However, even if the open source network library is a non-blocking socket, it still monitors the writable events of the socket and will write data only after confirming that the connection is successful. Saving this negligible performance gain is really not as valuable as having safe and reliable code.

Condition 2: icsk->icsk_accept_queue.rskq_defer_accept != 0

This condition is very strange. defer_accept is a socket option used to postpone accept. In fact, the connection will be created only after the first data is received. The tcp_defer_accept option is generally used on the server side and affects the SYN and ACCEPT queues of the socket. If it is not set by default, after the three-way handshake is completed, the socket enters the accept queue, and the application layer senses and ACCEPTs the related connection. When tcp_defer_accept is set, the three-way handshake is completed, and the socket does not enter the ACCEPT queue, but stays directly in the SYN queue (there is a length limit, and the kernel rejects new connections if the length exceeds it) until the data is actually sent and then put into the ACCEPT queue. The server that sets this parameter can read directly after accepting, which means there must be data, and it also saves a system call.

The SYN queue stores sockets in the SYN_RECV state. The length is controlled by the net.ipv4.tcp_max_syn_backlog parameter. The accept queue is set by the backlog parameter when the listen is called. The kernel hard limit is limited by net.core.somaxconn, that is, the actual value is determined by min(backlog,somaxconn).

What’s interesting is that if the client first binds to a port and IP, then setsockopt(TCP_DEFER_ACCEPT), and then connects to the server, rskq_defer_accept=1 will appear. At this time, the kernel will set a timer to wait for the data before replying to the ACK packet. I personally have never done this. Is it just to reduce the sending of empty ACK packets to improve performance? If any classmate knows please let me know, thank you.

Condition 3: icsk->icsk_ack.pingpong != 0

The pingpong attribute is actually a socket option that indicates whether the current link is an interactive data stream. If its value is 1, it indicates that it is an interactive data stream and a delayed confirmation mechanism will be used.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.