Less code, more hair
This article has been included in my GitHub, welcome everyone to participate in star and issues.
Github.com/midou-tech/…
Three handshakes to establish a link, four waves to disconnect it. This is a classic question and one that interviewers like to ask.
It is no exaggeration to say that every company asked about the three handshakes and four waves during the recruitment interview of Uncle Long in school. I believe that everyone was similarly attacked by the interviewer.
The importance of this problem has been realized. Don’t talk nonsense, the next is to listen to uncle Long to arrange for you clearly.
Let’s draw a picture of the TCP connection setup and disconnection process.
By the end of this diagram, you are smart enough to have some basic control over the three-way handshake and four-way wave overall. However, the details are bound to be a little rusty or vague, and the nature of the next issue is revealed one by one.
Before we explain it, let’s take a look at the basics.
Description of TCP status transfer
| state | describe |
|---|---|
| CLOSED | Blocked or closed: No links are being transmitted or established on the host |
| LISTEN | Listening status, indicating that the server is ready to establish a transport link |
| SYN RECV | First transfer request received, not confirmed |
| SYN SENT | After the first SYN packet is sent, the SYN packet is received |
| ESTABLISHED | After the connection is established, the data transfer phase begins |
| FIN WAIT1 | The state is changed after the first FIN packet is sent |
| FIN WAIT2 | The first FIN acknowledgement signal has been received, and the FIN is waiting for the closing request |
| TIMED WAIT | The bidirectional link is closed and the packet disappears |
| CLOSING | When both parties close the request at the same time and wait for confirmation from the other party |
| CLOSE WAIT | Receive the shutdown request from the other party and confirm that the state is entered |
| LAST ACK | Wait for the last confirmation of closing the packet |
Take a look at the TCP packet format
The header has a fixed length of 20 bytes, meaning as follows:
- Source port and destination port
The source port number and destination port number are stored in 2 bytes each
- The serial number seq
The value is 4 bytes, representing the range of the integer [0 to 2^32]. Ordinal is used to number each byte of the data section in mod 2^32.
- Confirm the ack number
It is 4 bytes and the range is also the range of unsigned integers. Use the serial number of the last byte of the data transmitted to me at the peer end. For example, when A transmits to B 101-500, B must return an acknowledgement number less than or equal to 501. The confirmation number is returned when segment B receives the data correctly, in other words, all the data before the confirmation number has been received.
- Data migration
4 bits, data offset. A lot of people tend to think that this is the length of the data, and that’s wrong. Offset is the offset from the start of the TCP connection to the start of the data section.
- keep
6 bits, reserved field, as the name implies, is for future use, default to 0.
- Emergency URG control bit
1bit, URG=1: indicates that the emergency pointer is valid and TCP data is preferentially transmitted. It is equivalent to the emergency channel in life, which is used in special circumstances.
In the network will also have special case, for example, send a long program running on the remote server, the discovery program has a bug, need to interrupt operation, so we from the keyboard input Ctrl c, if do not use emergency data, need to queue in buffer, all know is a bug, also line up, it will not out of the pot.
This time using emergency data transmission, no need to queue, direct interrupt program is not more in line with our expectations.
It is important to note that emergency data can be sent even when the window is 0.
How to use emergency URG control bit, send function flag parameter in socket programming
send(int socket, const void *buffer, size_t length, int flags);
Flags parameter when MSG_OOB macro is passed, emergency data is present. MSG_OOB is a macro,
- Confirm ACK
It takes effect when ACK=1. In TCP, ACK must be set to 1 for all transmitted packets after a connection is established.
- Push PSH
The packet occupies 1bit. When the sender sets PSH to 1, the packet is immediately sent. After the receiver receives a packet whose PSH is 1, the packet is immediately processed and delivered to the application layer for processing. Is not the feeling and URG very similar, in fact there are some differences.
- Similarities:
Both URG and PSH are used in emergency situations to quickly transfer emergency data.
- Differences between the two
When URG is set to 1, out-of-band data is encapsulated into datagrams and sent together with the message data that should be sent normally, saving the waiting time in the queue. After the receiver parses the packet, the data is still stored in the cache and delivered up to the application layer after it is full.
When PSH is set to 1, the sender does not need to wait for the cache for downward transmission to be full, encapsulates the data into packets immediately and sends the data, saving the time for waiting for the cache for downward transmission to be full. On the receiving side, there is no need to wait for the receive cache to be full and deliver directly up to the application layer.
- Reset RST
1bit. When RST = 1, TCP will release the link.
When a serious TCP error occurs, the TCP server releases the connection, reestablishes the connection, and transmits data.
RST is set to 1 when illegitimate packets or connections are rejected.
- Synchronous SYN
It is a 1bit synchronization control bit used to synchronize the connection serial number when the transmission connection is established.
If SYN is 1, it is a connection request or confirmation packet.
SYN=1, ACK=0: indicates that this is a connection request data segment. If the peer party agrees to establish a connection, the peer party will send an acknowledgement of SYN=1, ACK=1.
- FIN control bits
1bit, used to release a transport connection.
If the FIN value is 1, data transmission is complete and the sender has no data to transmit. The sender needs to release the current connection. However, the receiver can continue to receive incomplete data.
FIN=0. Data is normally transmitted.
- The window size
The value is 16 bits and 2 bytes, indicating the maximum data size that can be accepted by the sender.
This window changes dynamically and is used for flow control.
- Inspection and
The value is 16 bits and 2 bytes, used to verify THE TCP header, pseudo header, and data.
- Pointer to an emergency
The value contains 16 bits and 2 bytes, which records the position of the end of emergency data in the data segment.
This pointer takes effect only when URG=1.
- optional
The maximum value is 40 bytes. This parameter is optional. When the TCP header does not exist, the length of the TCP header is 20 bytes.
Options can include Window ScaleOption (WSopt), MSS (maximum data segment size) option, SACK (selective confirmation) option, Timestamp option, etc.
- data
The TCP data section, the data submitted by the application layer application.
TCP headers are the basics, and you must understand them to better understand how TCP data is encapsulated and transferred, and where it is manipulated when establishing and breaking links.
Three handshakes establish a connection
How does a three-way handshake establish a connection?
It can be clearly seen from the picture that the process of shaking hands for three times. I am explaining the process clearly, and by the way, I will mention the knowledge points that are easy to be asked in each process.
C/S mode is adopted to explain, assuming that the C terminal initiates the transmission request.
The C end remains CLOSED until the connection request is sent. The S end is also initially CLOSED and enters the passive listening state when the LISTEN socket is executed.
Passive listening means that when there is no client request, the socket is in the “sleep” state, and only when the client request is received, the socket will be “wake up” to respond to the request.
First: The C end sends a SYN=1 request packet. Then the C end enters the SYN SENT state and waits for confirmation from the server.
What happens if the packet is lost and cannot be sent to the peer end?
After sending a packet, the C end starts a timer. If the C end does not receive an acknowledgement from the S end after the timeout, the C end sends a SYN request again. The duration of each attempt is twice that of the first one.
Second time: After receiving a SYN packet (a request for establishing a link) from the C end, the S end must return the confirmation number and send a SYN packet at the same time. In this case, the S end enters the SYN RCVD state.
Why SYN packets are sent?
TCP is full-duplex communication. According to the TCP protocol, after receiving a request for establishing a link, the serial number must be returned and the communication link between the local end and the peer end must be established. This is also called piggyback reply.
What if the packet is lost the second time?
After an ACK+SYN packet is sent, the system starts a timer. If no ACK is received after the timeout, the system retries the ACK packet. The timeout period is still doubled each time, and the retry times can be set.
Change the value of /proc/sys/net/ipv4/tcp_synack_retries
Third time: The C end receives an ACK+SYN packet from the S end and needs to return an ACK packet. In this case, the connection enters the half-connection queue. After the S end receives an ACK packet, a full-duplex TCP connection is ESTABLISHED and the two sides enter the ESTABLISHED state.
In a common attack, an attacker sends a FORGED SYN request to the server. After the server responds, it does not receive an ACK from the C server. The server retries the SYN request five times by default.
At this point, the server will maintain all the resources of the link. If there are a large number of such requests, the server will run out of resources.
This is a DOS attack.
What if the packet is lost for the third time?
After sending ACK+SYN packets, the S end starts a timer. After receiving ACK packets due to timeout, the S end confirms that the packets are lost and sends them again.
Each of these states must be understood, and interviewers love to ask about these transitions.
Uncle Long also met an interviewer asked me if I had used socket programming? Which socket functions have I used?
C socket programming code
/ / C side
#define PORT 8080
#define BUFFER_SIZE 1024
int main(int argc, char **argv)
{
// Defines the socket descriptor for IPV4 TCP connections
int sock_cli = socket(AF_INET,SOCK_STREAM, 0);
/ / define sockaddr_in
struct sockaddr_in servaddr;
memset(&servaddr, 0.sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = inet_addr(argv[1]);
servaddr.sin_port = htons(PORT);
// Connect to server, 0 on success, -1 on error
int ret = connect(sock_cli, (struct sockaddr *)&servaddr, sizeof(servaddr));
// The client sends the information input from the console to the server, the server returns the information as is, blocking
while (fgets(sendbuf, sizeof(sendbuf), stdin) != NULL)
{
ret=send(sock_cli, sendbuf, strlen(sendbuf),0); / / / send
recv(sock_cli, recvbuf, sizeof(recvbuf),0); / / / receiving
fputs(recvbuf, stdout);
}
close(sock_cli); // Close the connection
return 0;
}
Copy the codeS-end socket programming code
int main(int argc, char **argv)
{
// Defines the socket descriptor for IPV4 TCP connections
int server_sockfd = socket(AF_INET,SOCK_STREAM, 0);
/ / define sockaddr_in
struct sockaddr_in server_sockaddr;
server_sockaddr.sin_family = AF_INET;
server_sockaddr.sin_addr.s_addr = htonl(INADDR_ANY);
server_sockaddr.sin_port = htons(PORT);
//bind returns 0 on success, -1 on error
if(bind(server_sockfd,(struct sockaddr *)&server_sockaddr,sizeof(server_sockaddr))==- 1)
//listen returns 0 on success, -1 on error, and QUEUE_SIZE is allowed
if(listen(server_sockfd,QUEUE_SIZE) == - 1)
for(;;)
{
struct sockaddr_in client_addr;
socklen_t length = sizeof(client_addr);
// The process is blocked on Accept, returns a non-negative descriptor on success, -1 on error
int conn = accept(server_sockfd, (struct sockaddr*)&client_addr,&length);
// Process the data part
.
}
close(server_sockfd);
return 0;
}
Copy the codeWhy do you need three handshakes to establish a link? Is two ok? Is four ok?
What’s wrong with the interviewer? You know what? You know what? You know what? Definitely not. That’s what the RFC standard says.
The standard is three handshakes to establish a link, but not four. If you answer like this, no problem will receive, classmate, our interview for today is basically over, you go home and wait for the news…
Uncle Long, why not twice?
If SYN+ACK is not sent for the second time but only an ACK is sent, one-way communication can be established and no reply can be made. TCP is full-duplex communication and must be reliable.
If SYN+ACK is sent for the second time, no reply is required. Three things can happen
If the first or second handshake fails, the C end repeatedly sends SYN packets and waits for the peer end to send acknowledgement packets. The S end stores all TCP connection resources. In this case, resources in S are exhausted.
2. If the handshake succeeds, S sends SYN+ACK packets again if it fails to receive ACK packets.
3. After the second handshake, the two parties assume that the connection has been established successfully and can start communication. If the connection is not successfully established at this time, the S end starts to send messages, which will cause network congestion.
Why can’t it be four times?
The second ACK and SYN are sent in two separate packets. In theory is completely feasible, but TCP in line with the premise of saving network resources.
There is also an incidental reply without breaking the second handshake. After the third handshake, C continues to send the SYN, which is futile. After the third time, the link has been established, and no matter how many times after that, it is in vain.
What happens if both parties establish a connection at the same time?
That’s the case when both sides set up a link at the same time, and it’s not bad, but it works, that’s for sure. But there are two caveats
First, only one full-duplex TCP connection is established, not two.
Second, there is no CS on both sides. Both ends assume two roles at the same time, client and server.
Four waves to disconnect the link
Let’s take a look at the four waves and the state shift. Take a closer look at the state transfer exam.
C/S model is still used to explain this process.
First: When the application on the C end ends data transmission, the APPLICATION on the S end sends a packet segment marked with FIN (FIN indicates Finish). Then the C end enters the FIN_WAIT1 state and cannot send data to the S end.
Second: After receiving a FIN packet, the S end responds with an ACK packet and enters CLOSE_WAIT state. After entering this state, the S terminal sends the remaining unsent data to the C terminal. After receiving the ACK from the S terminal, the C terminal enters the FIN_WAIT2 state.
At the same time, it continues to receive other data packets transmitted by the S terminal.
Third time: After processing the data to be sent, the S end also sends a FIN disconnection request and enters the LAST_ACK state.
Fourth time: after receiving the disconnection request from the S end, the C end starts a timer with the duration of 2MSL(maximum packet lifetime) and sends the last ACK packet.
Why do you wave four times?
TCP is a full-duplex communication mechanism. Each direction must be disabled separately.
The principles for closing TCP transport connections are as follows:
When one end completes its data transmission task, it can send a data segment with the FIN field set to 1 to terminate data transmission in this direction. When the other end receives the FIN segment, it must notify its application layer peer that it has terminated data transmission in that direction.
Why not reduce one handshake by using pigry-on replies?
This can be confusing, but it’s not difficult to master the details of TCP transport.
TCP is a full-duplex communication. After S receives the disconnection request, it only means that the C end does not transmit data to the S end, but does not mean that the S end does not transmit data to the C end.
If piggy-back replies are used, the S side will not be able to transfer the remaining data to the C side.
Why wait 2MSL after last ACK?
The network is unreliable. TCP is a reliable protocol. You can disconnect the TCP connection only after the last packet is sent.
The wait time of 2MSL is to ensure that the last lost message can be sent again.
Why 2MSL time?
2MSL is the maximum round-trip time of a packet. Assuming that less than this time will happen, ACK will be lost, but we re-send ACK before receiving the FIN retransmitted by the other side.
What if the connection has been established, but the client suddenly fails?
By default, TCP has a timer. After receiving a request from the client, the timer is set. Usually, the timer is set for two hours.
The server sends a probe packet every 75 seconds. If there is no response after 10 probe packets are sent, the server assumes that the client is faulty and closes the connection.
conclusion
The knowledge of three handshakes and four waves basically comes to an end, and that’s it. If you don’t understand anything, you can add my wechat to discuss it.
There will also be an article on Linux command-line tools commonly used for network programming, such as ping, tcpdump, netstat, NC, etc., and a summary article on computer networking. This part of the computer network is basically over, if you do not know how to look inside the public number in front of the article.