Do you know the phrase “three handshakes, four waves”? At this time I will “have a plan” to “recite” the early prepared “answer”, the first time how how, the second time…… After answering, there is no below, the interviewer seems to have no further meaning, further DOWN I do not understand, everyone is happy!
As a programmer, have the spirit of “asking questions”. Know why, but also know why. This article hopes to dissect and restore the principle behind it. [toc]
What is “Three handshakes, four waves”?
TCP is a connection-oriented unicast protocol. Before sending data, communication parties must establish a connection. The so-called “connection” is actually a piece of information about each other, such as IP address and port number, stored in the memory of the client and server.
TCP can be thought of as a byte stream that handles packet loss, duplication, and errors at the IP layer and below. During the establishment of a connection, the two parties need to exchange some connection parameters. These parameters can be placed in the TCP header.
TCP provides a reliable, connection-oriented, byte stream, transport layer service that establishes a connection using a three-way handshake. Use 4 waves to close a connection.
TCP service model
Now that we’ve looked at the “three handshakes and four waves” of establishing and closing a connection, let’s take a look at TCP.
A TCP connection consists of two IP addresses and two port numbers. A TCP connection is typically divided into three phases: start, data transfer, and exit (close).
When TCP receives data from the other end, it sends an acknowledgement, but this acknowledgement is not sent immediately, usually after a while. Acks are cumulative, and an ACK with an acknowledgment byte number N indicates that all bytes up to N (excluding N) have been received successfully. The advantage of this is that if one ACK is lost, it is likely that subsequent acks will be sufficient to confirm the previous packet segment.
A complete TCP connection is bidirectional and symmetric, and data can flow equally in both directions. Provide a duplex service to the upper-layer application. Once a connection is established, each TCP segment in one direction of the connection contains an ACK for the segment in the opposite direction.
The sequence number enables a TCP receiver to discard duplicate segments and record the segments that arrive in disordered order. Because TCP uses IP to transport segments, IP does not provide the ability to eliminate duplicates or ensure correct order. TCP, on the other hand, is a byte stream protocol that never sends data to upper-layer programs in a random order. So the TCP receiver is forced to hold data with a large sequence number from the application until the missing segment with a small sequence number is filled.
The TCP header
Source port and destination port in the TCP layer determine process on both sides, the serial number represents the period of the first byte of data message, ACK said the confirmation, the confirmation number of the sender are looking forward to receiving the next sequence number, which was finally successfully received data byte sequence number plus 1, this field is only valid when ACK bit is enabled.
When a new connection, the first message from a client sends to the service period of the SYN bit is enabled, this is called the SYN segment, the serial number field contains a in the direction of this connection to use the first serial number, namely initial sequence number ISN, after sending data is ISN + 1, so the SYN bit field will consume a sequence number, This means reliable transmission using retransmission. An ACK that does not consume the sequence number does not.
The header length (the data offset in the figure) is in 32-bit words, that is, in 4bytes. It has only 4 bits and the maximum size is 15, so the maximum header length is 60 bytes and the minimum is 5, that is, the minimum header length is 20 bytes (the variable option is empty).
ACK — confirm, making the confirmation number valid. RST — Resetting the connection (often seen as reset by peer) is the result of this field. SYN – The sequence number used to initialize a connection. FIN: The sender of the packet has stopped sending data to the other party.
When a connection is established or terminated, the segment exchanged contains only the TCP header and no data.
State transition
The transitions between three handshakes and four waves are shown below.
Why “Three handshakes, four waves”
Three-way handshake
Put it in an easy way to understand why three handshakes are necessary.
The client and server need to connect before communication. The “three-way handshake” is used to ensure that the receiving and sending capabilities of the client and the other side are normal.
First handshake: The client sends a network packet and the server receives it. In this way, the server can conclude that the sending capability of the client and the receiving capability of the server are normal.
Second handshake: The server sends the packet and the client receives it. In this way, the client can conclude that the receiving and sending capabilities of the server and the client are normal. From the perspective of the client, I received the response packet sent by the server, indicating that the server received the network packet sent by me during the first handshake and successfully sent the response packet, which indicates that the receiving and sending capabilities of the server are normal. On the other hand, I received the response packet from the server, indicating that the network packet I sent for the first time successfully reached the server, so that my own sending and receiving capabilities are normal.
Third handshake: The client sends the packet and the server receives it. In this way, the server can conclude that the receiving and sending capabilities of the client and the sending and receiving capabilities of the server are normal. After the first and second handshakes, the server does not know whether the receiving capability of the client and its own sending capability are normal. On the third handshake, the server receives the client’s response to the second handshake. From the server’s point of view, my response data from the second handshake is sent out, and the client receives it. So, my ability to send is normal. The reception capacity of the client is also normal.
After the above three handshakes, both the client and server confirm that their receiving and sending capabilities are normal. Then you can communicate normally.
Each time, the person receiving the packet can draw some conclusions, while the person sending the packet has no clue. Although I have the action of sending a packet, but how do I know I have sent, and the other party has received it?
As you can see from the above procedure, a minimum of three handshakes are required. Both failed to reach the conclusion that their own and the other’s ability to receive and send were normal. In fact, each time the party receiving the network packet can at least get: the other party’s sending, our receiving is normal. Each step is related, and the next “response” is triggered by the first “request,” so each handshake can lead to additional conclusions. Third handshake, for example, the server receives packets, show that see the server can only get the client to send, received from the server is normal, but the second time, shows that the response of the server in a second send package, the client receives, and make the response, additional conclusion is obtained: the client receiving, sent from the server is normal.
To summarize:
| perspective | The guest closed | The guest to send | Take charge | Take to send |
|---|---|---|---|---|
| Customer perspective | two | One plus two | One plus two | two |
| Take perspective | 2 + 3 | one | one | 2 + 3 |
Four times to wave
TCP connections are two-way peer-to-peer, which means that both parties can send or receive data to each other at the same time. When either party wants to close the connection, it sends a command to tell the other party that I’m closing the connection. An ACK is sent back, and the connection in one direction is closed. But the other direction can continue to transmit data, and when all data is sent, a FIN segment is sent to close the connection in that direction. The receiver sends an ACK to confirm closing the connection. Notice that the party that receives a FIN packet can reply only one ACK, but cannot immediately return a FIN segment to the other party. The “instruction” to end data transmission is given by the upper application layer. I am only a porter, and I cannot understand the “will of the upper layer”.
How to complete “three handshakes, four waves”?
In fact, the purpose of the three-way handshake is not only to let the communication parties know that a connection is being established, but also to use the options of the packet to transmit special information and exchange the initial SEQUENCE number ISN.
The three-way handshake means that three packet segments are sent, and the four-way wave means that four packet segments are sent. Note that both SYN and FIN segments are reliably transmitted using retransmission.
Three-way handshake
- The client sends a SYN segment with an initial sequence number, ISN(c), for the client.
- The server replies with its SYN segment, specifying its ISN(s). To confirm the client’s SYN, the ISN(c)+1 is used as the ACK value. Each SYN sent is incremented by 1. If a SYN is lost, it is retransmitted.
- To confirm the SYN on the server, the client returns the ISN(s)+1 as the ACK value.
Four times to wave
- The client sends a FIN segment with its current serial number k. that it wants the recipient to see. It also contains an ACK to confirm the latest data sent by the other party.
- The server adds K to 1 as the ACK sequence number, indicating that the last packet was received. The upper application is notified that the other end initiated a shutdown, which usually causes the application to initiate its own shutdown.
- The server initiates its own FIN segment, ACK=K+1, Seq=L
- Client confirmation. ACK=L+1
Why is it three handshakes to establish a connection, but four waves to close it?
This is because in LISTEN state, the server receives a SYN packet for establishing a connection and sends the ACK and SYN packets to the client. When a FIN packet from the peer party is received, the peer party only stops sending data but can still receive data. The upper-layer application determines whether to close the data transmission channel. Therefore, the PEER ACK and FIN packets are sent separately.
“Three handshakes, four waves” advanced
ISN
An important function of the three-way handshake is that the client and server exchange ISN(Initial Sequence Number) so that the other side knows how to assemble the data by Sequence Number when they receive the data next.
If the ISN is fixed, an attacker can easily guess the subsequent confirmation number.
ISN = M + F(localhost, localport, remotehost, remoteport)
Copy the codeM is a timer that increments by one every four milliseconds. F is a Hash algorithm that generates a random value based on the source IP address, destination IP address, source port, and destination port. Make sure that the hash algorithm cannot be easily extrapolated externally.
Serial number winding
Because the ISN is random, the sequence number can easily exceed 2^31-1. TCP’s judgment on packet loss and disorder depends on sequence number comparison. This is where the so-called TCP sequence wraparound problem occurs. How to solve it?
/*
* The next routines deal with comparing 32 bit unsigned ints
* and worry about wraparound (automatic with unsigned arithmetic).
*/
static inline int before(__u32 seq1, __u32 seq2)
{
return (__s32)(seq1-seq2) < 0;
}
#define after(seq2, seq1) before(seq1, seq2)
Copy the codeThe code above is the code in the kernel to resolve the wrap problem. __s32 stands for signed integer, while __u32 stands for unsigned integer. When the sequence number is wound, the sequence number becomes smaller, and when subtracted, the result becomes a signed number, so the result is negative.
Suppose that SEQ1 =255 and seq2=1 (winding occurs). Seq1 = 1111 1111 seq2= 0000 0001 We want the comparison result to be seQ1 - seQ2 = 1111 1111-0000 0001 ----------- 1111 1110 since we converted the result to a signed number, Since the highest bit is 1, the result is a negative number, and the absolute value of a negative number is 0000 0001 + 1 = 0000 0010 = 2 so seQ1 - seq2 < 0Copy the codeSyn flood attack
The most basic DoS attack is to use reasonable service requests to occupy too many service resources, so that legitimate users can not get the response of the service. Syn flood is a Dos attack.
If a large number of SYN packets are maliciously sent to a server port, the server can open a large number of half-open connections and allocate Transmission Control blocks (TCBS), consuming a large number of server resources and preventing normal connection requests from being processed. When a TCP port is opened, the port is in Listening state and monitors Syn packets sent to the port. Once a Syn packet is received from the Client, a TCB needs to be allocated to the request. Usually, a TCB needs at least 280 bytes. On some operating systems, TCB takes 1300 bytes and returns a SYN ACK command that immediately changes to SYN-received, a half-opened connection. The system will run out of resources.
Common anti-attack methods are:
Monitor release of invalid connections
Monitors half-open and inactive connections of the system and disconnects them when a certain threshold is reached, freeing system resources. This method treats all connections equally. In addition, the number of half-open connections caused by SYN Flood is large, and normal connection requests are drowned and mistakenly released in this method. Therefore, this method is an entry-level SYN Flood method.
Delay TCB allocation method
Server resources are consumed because TCBS are allocated as soon as SYN packets arrive. However, it is difficult to establish a normal connection for SYN Flood. Therefore, allocating TCB after the normal connection is established can effectively reduce the consumption of server resources. Common methods are Syn Cache and Syn Cookie.
The Syn Cache technology
When the system receives a SYN packet, it stores the half-connection information in a dedicated HASH table until it receives a correct ACK packet and then allocates the TCB. This overhead is much less than that of TCB. You also need to save the serial number.
The Syn Cookie technology
Syn Cookie technology does not use any storage resources at all. This method is ingenious. It uses a special algorithm to generate Sequence numbers. For example, MSS(Maximum Segment Size) indicates the Maximum length of a TCP packet, excluding the length of the TCP header. And time. After receiving the ACK message from the other party, it recalciates it to see whether it is the same as (Sequence number-1) in the reply message from the other party, so as to decide whether to allocate TCB resources.
Use the SYN Proxy firewall
One way is to prevent wall DQYWB connections from being valid after the firewall makes a SYN request to the internal server. The SYN ACK packet sent by the firewall on behalf of the server uses the SEQUENCE number C, while the real server responds with the sequence number C ‘, so that the sequence number is changed as each packet passes through the firewall. After confirming the connection security, the firewall sends the safe reset command. In this case, the client reconnects to the firewall and permits syn packets. So you don’t need to change the serial number. However, the client needs to initiate a two-handshake process, so the connection takes longer to establish.
The connection queue
When the external request arrives, the connection may be in the SYN_RCVD or ESTABLISHED state before it is finally sensed by the server, but not yet accepted by the application.
Similarly, the server maintains two types of queues: the half-connection queue in the SYN_RCVD state, and the full-connection queue in the ESTABLISHED state but not yet accepted by the application. If these two queues are full, all kinds of packet loss will occur.
Check whether there is connection overflow netstat -s | grep LISTENCopy the codeThe half-connection queue is full
In the three-way handshake protocol, the server maintains a half-connection queue, which creates an entry for each client’s SYN packet. The request_SOCK structure is stored in the half-connection queue when the server receives the SYN packet. This entry indicates that the server has received the SYN packet and sends an acknowledgement to the client. Waiting for the customer’s confirmation package. The connection identified by these entries is in the Syn_RECV state on the server. When the server receives an acknowledgement packet from the customer, the entry is deleted and the server enters the ESTABLISHED state.
In Linux, the syn-ACK packet is resent five times by default. The retry interval starts at 1s. The next retry interval is twice as long as the previous one. After sending the 5th time, it has to wait 32s to know that the 5th time also timed out. Therefore, the total need 1s + 2s + 4s+ 8s+ 16s + 32s = 63s, TCP will disconnect the connection. The SYN timed out takes 63 seconds. The attacker sends massive SYN packets to the Server in a short period of time to exhaust the SYN queues of the Server. For this problem, Linux provides several TCP parameters: tcp_syncookies, tcp_synack_retries, tcp_max_syn_backlog, and tcp_abort_on_overflow to adjust the response.
| parameter | role |
|---|---|
| tcp_syncookies | SYNcookie returns the connection information encoded in the ISN(InitialSequencenumber) to the client. In this case, the server does not need to save the semi-connection in the queue, but restores the connection information using the ISN returned by the ACK sent by the client to complete the establishment of the connection. The half-connection queue is prevented from being filled with attack SYN packets. |
| tcp_syncookies | The number of SYN packets sent by the kernel before the connection is abandoned. |
| tcp_synack_retries | The number of SYN+ACK packets sent by the kernel before the connection is abandoned |
| tcp_max_syn_backlog | The default is 1000. This indicates the length of the half-connection queue, if exceeded the current connection will be abandoned. |
| tcp_abort_on_overflow | If this is set, the server resets the connection. Otherwise, no action is done, so that the server reaccepts the connection when the half-connection queue is empty.Linux insists on not ignoring incoming connections as far as capabilities permit. The client sends the SYS packet repeatedly during this period, and when the number of retries reaches the upper limit, the sys packet is returnedconnection time outThe response. |
The full connection queue is full
On the third handshake, when the server receives an ACK packet, it enters a new queue called Accept.
ListenOverflows+1 and the server determines how to return ACK packets by using tcp_ABORT_ON_overflow. 0 indicates that the ACK packets are discarded. 1: sends an RST notification to the client. The client returns read Timeout or Connection reset by peer, respectively. If tcp_ABORT_ON_overflow is 0, the server will send syn+ ACK to the client again after a certain period of time. If the client timeout wait is short, an exception may occur. If the client receives multiple SYN ACK packets, it considers that the previous ACK packets are lost. This prompts the client to send an ACK again and finally complete the connection when the Accept queue is free. If the ACCEPT queue is always full, the client receives the RST packet (at this point, the server sends SYN + ACK packets more times than the TCP_SYNack_retries).
The server simply creates a timer to retransmit the SYN and ACK to the server at regular intervals
| parameter | role |
|---|---|
| tcp_abort_on_overflow | If this is set, the server resets the connection. Otherwise, no action is done, so that the server reaccepts the connection when the half-connection queue is empty.Linux insists on not ignoring incoming connections as far as capabilities permit. The client sends the SYS packet repeatedly during this period, and when the number of retries reaches the upper limit, the sys packet is returnedconnection time outThe response. |
| min(backlog, somaxconn) | Length of the full connection queue. |
The command
Netstat -s command
[root@server ~]# netstat -s | egrep "listen|LISTEN"
667399 times the listen queue of a socket overflowed
667399 SYNs to LISTEN sockets ignored
Copy the code667399 times, which indicates the number of times the full connection queue overflowed, if executed every few seconds, the full connection queue must occasionally be full if this number keeps increasing.
[root@server ~]# netstat -s | grep TCPBacklogDrop
Copy the codeCheck whether the Accept queue overflows
Ss command
[root@server ~]# ss -lnt State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:6379 *:* LISTEN 0 128 22 * * : : *Copy the codeIf State is listen, send-q indicates that the maximum size of the full connection queue on the LISTEN port in column 3 is 50, and recV-q indicates how much the full connection queue is currently used. In the non-Listen state, recv-q indicates the number of bytes in the receive queue. Send-q Indicates the bytes in the Send queue.
summary
When external connection requests arrive, the TCP module first looks at the max_syn_backlog. If the number of connections in the SYN_RCVD state exceeds this threshold, incoming connections are rejected. Discard or reset directly based on the tcp_ABORT_ON_overflow field.
On the server side, the server receives a SYN from the client in the first step of the three-way handshake, puts the related information in the semi-connection queue, and replies with a SYN + ACK to the client. Step 3 When receiving an ACK from the client, add the connection to the full connection queue.
Generally, the full connection queue is small and full first, while the half-connection queue is not full. If a SYN packet is received, the system enters the half-connection queue. However, if step 3 (ACK) of the three-way handshake is received, the tcp_ABORT_ON_overflow field is used to determine whether to discard or reset directly. At this point, the client sends an ACK, and the client thinks the three-way handshake is complete. It thinks the server is ready to receive the data. However, the server may not be able to place the connection because the full connection queue is full, so it resends the SYN + ACK in step 2. If any data arrives, the server TCP module will queue the data. If the client does not receive any reply after a period of time, the client automatically closes the connection.
“Three handshakes, four waves” Redis instance analysis
- I deployed the Redis service on the dev machine with port number 6379,
- To obtain data packets using tcpdump, run the following command
Tcpdump -w/TMP /a.cap port 6379 -s0 -w Writes data to a file. -s0 sets the size of each data packet to 68 bytes by default. If -s0 is used, complete data packets will be capturedCopy the code- Access dev:6379 with redis-cli on the dev2 machine and send a ping to reply pong
- Stop packet capture and use tcpdump to read captured packets
Tcpdump - r/TMP/a.c ap - n - nn - A - x | vim - (- x in hexadecimal form features, the back analysis purposes)Copy the codeA total of seven packages were received.
The captured IP packet is divided into IP header and IP data part, and IP data part is TCP header and TCP data part.
The data format of IP is:
10:55:45.662077 IP dev2.39070 > dev.6379: Flags [S], seq 4133153791, win 29200, options [mss 1460,sackOK,TS val 2959270704 ecr 0,nop,wscale 7], length 0
0x0000: 4500 003c 08cf 4000 3606 14a5 0ab3 b561
0x0010: 0a60 5cd4 989e 18eb f65a ebff 0000 0000
0x0020: a002 7210 872f 0000 0204 05b4 0402 080a
0x0030: b062 e330 0000 0000 0103 0307
Copy the codeUnpack the meaning of the packet against the IP header format.
| Byte value | Byte meaning |
|---|---|
| 0x4 | The IP version is ipv4 |
| 0x5 | The header length is 5 * 4 bytes =20B |
| 0x00 | Service type, now basically set to 0 |
| 0x003c | The total length is 3*16+12=60 bytes, and all the above lengths are 60 bytes |
| 0x08cf | Logo. A unique identifier for the same datagram. When IP datagrams are split, they are copied to every piece of data. |
| 0x4000 | 3bit flag + 13bit offset. The 3-bit flag corresponds to R, DF, and MF. Currently, only the last two bits are valid. DF bit: 1 indicates no sharding, and 0 indicates sharding. MF: a value of 1 means “more slices” and a value of 0 means this is the last slice. 13bit bit shift: indicates the bit offset of the fragment relative to the first digit in the original data packet. (We need to multiply by 8) |
| 0x36 | TTL of the TTL. Indicates the maximum number of routers that IP packets are allowed to pass. Each time it passes through a router, the TTL decreases by 1. When it is 0, the router discards the datagram. The TTL field is an 8-bit field initially set by the sender. The recommended initial value is specified by the allocation number RFC. The TTL is often set to the maximum value 255 when sending an ICMP echo reply. TTL prevents datagrams from falling into routing loops. Here is 54. |
| 0x06 | Protocol type. Indicates the protocol used by the data carried by the IP packet so that the IP layer of the destination host can know which process to submit the data packet to. The PROTOCOL number of TCP is 6, and that of UDP is 17. The protocol number of ICMP is 1, and that of IGMP is 2. The data carried by the IP packet is authenticated using TCP. |
| 0x14a5 | 16bitIP header checksum. |
| 0x0ab3 b561 | 32-bit Source IP address. |
| 0x0a60 5cd4 | 32-bit Destination IP address. |
The rest of the data is related to TCP. TCP is also a 20B fixed length + variable length part.
| Byte value | Byte meaning |
|---|---|
| 0x989e | 16-bit source port. 1161616 + 81616 + 1416 + 11 = 39070 |
| 0x18eb | 16bit destination port 6379 |
| 0xf65a ebff | 32-bit serial number. 4133153791 |
| 0x0000 0000 | 32-bit confirmation number. |
| 0xa | 4bit length of the header, expressed in 4 bytes. 10 x 4=40 bytes. Therefore, the optional length of TCP packets is 40 to 20=20 |
| 0b000000 | 6bit reserved bits. This is set to 0. |
| 0b000010 | 6bit Indicates the TCP flag bit. From left to right are emergency URG, ACK confirmation, PSH push, RST reset, SYN synchronization, and FIN termination. |
| 0x7210 | Sliding window size: Sliding window is the size of the TCP receive buffer, used for TCP congestion control. 29200 |
| 0x872f | 16bit checksum. |
| 0x0000 | Emergency pointer. It is only meaningful if URG = 1, which indicates the number of bytes of urgent data in this paragraph. When URG = 1, the sender TCP inserts the emergency data at the top of the column data, while the data after the emergency data remains normal data. |
For variable length, the protocol is as follows:
| Byte value | Byte meaning |
|---|---|
| 0x0204 05b4 | The maximum packet length is 1460 = 05B4. The maximum packet length that can be received is 40 bytes (MTU), 20 bytes (IP header) and 20 bytes (TCP header) |
| 0x0402 | Express support for SACK |
| 0x080a b062 e330 0000 0000 | The time stamp. Ts val=b062 e330=2959270704, ecr=0 |
| 0x01 | No operation |
| 0x03 0307 | The window expansion factor is 7. Shift 7, multiplied by 128 |
This completes the analysis of the first package. Dev2 sends a SYN request to dev. That’s the first of three handshakes. SYN seq(c)=4133153791
The second packet, dev response connection, ack=4133153792. Indicates that DEV is ready to receive the packet with this serial number next time, for order control of TCP byte notes. Dev =4264776963, syn=1. Syn ACK =seq(c)+1 seq(s)=4264776963
The third package, client package validation, uses relative value replies. Ack =4264776964. ack=seq(s)+1, seq=seq(c)+1 so far, the three-way handshake is complete. The next step is to send the ping and pong data.
Then the fourth bag.
10:55:48.090073 IP dev2.39070 > dev.6379: Flags [P.], seq 1:15, ack 1, win 229, options [nop,nop,TS val 2959273132 ecr 3132256230], length 14
0x0000: 4500 0042 08d1 4000 3606 149d 0ab3 b561
0x0010: 0a60 5cd4 989e 18eb f65a ec00 fe33 5504
0x0020: 8018 00e5 4b5f 0000 0101 080a b062 ecac
0x0030: bab2 6fe6 2a31 0d0a 2434 0d0a 7069 6e67
0x0040: 0d0a
Copy the codeThe length of the TCP header is 32 BYTES and the optional length is 12 BYTES. The total length of an IP packet is 66 bytes and the length of the header is 20 bytes. Therefore, part of the LENGTH of TCP data is 14 bytes. The data is 2A31 0D0A 2434 0D0A 7069 6E67 0D0A
0x2a31 -> *1
0x0d0a -> \r\n
0x2434 -> $4
0x0d0a -> \r\n
0x7069 0x6e67 -> ping
0x0d0a -> \r\n
Copy the codeDev2 sends the ping data to Dev, and the fourth packet is complete.
The fifth package, Dev2 sends an ACK response to Dev. The serial number is 0xFE33 5504=4264776964, and the ACK confirmation number is 0xf65A EC0E =4133153806=(4133153792+14).
In the sixth package, Dev responds to The Pong message to Dev2. Sequence number FE33 5504, confirmation number F65A EC0E, TCP header optional length is 12B, IP datagram total length is 59B, header length is 20B, so TCP data length is 7B. Data part 2B50 4F4e 470d 0a, which translates to +PONG\r\n.
At this point, the analysis of the three-way handshake between Redis client and Server is completed.
conclusion
“Three handshakes, four waves” seems simple, but if you dig deeper, you can extend a lot of knowledge points. Such as half-connection queues, full-connection queues, and so on. It’s easy to forget about the process of establishing and closing a TCP connection in the past, probably because you just memorized a few processes without delving into the underlying principles.
So, “Three handshakes, four waves.” Do you really get it? Welcome to discuss with us.
The resources
Redis segmentfault.com/a/119000001 】…
TCP option blog.csdn.net/wdscq1234/a 】…
“Sliding window” www.zhihu.com/question/32…
All the connection queue jm.taobao.org/2017/05/25/ 】…
【 Client fooling】 github.com/torvalds/li…
【 backlog RECV_Q 】 blog.51cto.com/59090939/19…
“Timer” www.cnblogs.com/menghuanbia…
Queue here 】 【 www.itcodemonkey.com/article/583…
[TCP flood attack] www.cnblogs.com/hubavyn/p/4…
MSS MTU blog.csdn.net/LoseInVain/ 】…