[Linux] linuxtcp three-way handshake and four-way handshake

[Linux] linuxtcp three-way handshake and four-way handshake
1. What is TCP?

7-layer OSI model

• TCP is on the fourth layer -- the Transport layer, and the data on the fourth layer is the Segment-> message.
• IP address on Layer 3-Network layer, data on Layer 3 is called Packet-"data Packet
• ARP on the second layer -- Data Link layer; on the second layer, we call it Frame-"Frame.

When data is sent from the application layer, header information is added to each layer for encapsulation and then sent to the data receiver. This means that each data is encapsulated and encapsulated.

Shows the packets captured by wireshark and the corresponding protocol layer.

 

• Frame 36441: data Frame overview of the Physical Layer
• Ethernet II: Ethernet frame header information at the data link layer
• Internet Protocol Version 4: IPV4 network layer
• Transmission Control Protocol: TCP Transport Layer
• Hypertext Transfer Protocol: Application Layer HTTP

In the OSI Layer-7 model, the role of each layer and corresponding protocols are as follows:

Packets captured by wireshark at the Transmission Layer

TCP is a protocol. How is this protocol defined? What is its data format?

The above is the format of the TCP Header. Because it is too important, it is the basis for understanding other content. The following describes the information of each field in detail.

• Source PortAndDestination Port: The Source Port Number and the destination port number respectively occupy 16 bits, which are used to distinguish different processes in the host, while IP addresses are used to distinguish different hosts, the source port number and the destination port number can be used together with the source IP address and the destination IP address in the IP address header to uniquely determine a TCP connection;
• Sequence NumbeR: identifies the Data byte stream sent from the beginning of TCP to the TCP receiving end. It indicates the sequence number of the First Data byte in the data stream in this packet segment; it is mainly used to solve the problem of disordered network reporting;
• Acknowledgment Number: The 32-bit validation serial number contains the next serial number expected to be received by the sending confirmation end. Therefore, the confirmation serial number should be the byte number successfully received last time plus 1. However, the field of the confirmed serial number is valid only when the ACK mark in the flag is 1. It is mainly used to solve the problem of no packet loss;
• Offset: The number of 32-bit characters in the header. This value is required because the length of any field is variable. This field occupies 4 bits (up to 15 32 bits, that is, 4*15 = 60 bytes of header length), so TCP has a maximum of 60 bytes of header. However, there are no optional fields, and the normal length is 20 bytes;
• TCP Flags: There are 6 flag bits in the TCP Header. Multiple of them can be set to 1 at the same time, which is mainly used to manipulate the state machine of TCP.URG,ACK,PSH,RST,SYN,FIN. The meanings of each flag are as follows:

• • URG: This flag indicates that the emergency pointer domain of the TCP packet is valid to ensure that the TCP connection is not interrupted, and urge the intermediate layer device to process the data as soon as possible;
  • ACK: This flag indicates that the response domain is valid, that is, the TCP response number mentioned above will be included in the TCP packet. If there are two values: 0 and 1, it indicates that the response domain is valid, the opposite is 0;
  • PSH: This flag indicates the Push operation. The Push operation refers to transmitting data packets to the application immediately after they arrive at the receiving end, rather than queuing in the buffer;
  • RST: Indicates the Connection reset request. Used to reset connections that generate errors and reject error and illegal data packets;
  • SYN: Indicates the synchronization sequence number, used to establish a connection.SYNFlag andACKWhen the flag is used together,SYN= 1,ACK= 0; when the connection is responded,SYN= 1,ACK= 1; packets with this flag are often used for port scanning. The scanner sends only oneSYNIf the other host returns a packet, it indicates that the host has this port. However, this scan method only performs the first handshake of TCP three handshakes, therefore, the success of this scan indicates that the machine to be scanned is not safe. A secure host will force a connection to strictly perform TCP three-way handshake;
  • FIN: Indicates that the sender has reached the end of the data, that is, the data transfer between the two parties is complete, no data can be transferred, sendFINThe TCP packet of the flag is disconnected. Packets with this flag are often used for port scanning.

• Window: Window size, which is also a famous sliding Window, used for traffic control. This is a complicated problem and will not be summarized in this blog.

About three handshakes and four waves

Wireshark packet capture

Network connection in a reverse proxy

 

2. What is a three-way handshake?

TCP is connection-oriented. Before sending data to the other party, a connection must be established between the two parties. In TCP/IP, TCP provides reliable connection services, and the connections are initialized through three handshakes. The purpose of the three-way handshake is to synchronize the serial number and confirmation number of both parties and exchange the TCP window size information.

First handshake: establish a connection. The client sends the connection request message segmentSYNLocation: 1,Sequence NumberIs x; then, the client entersSYN_SENDStatus, waiting for confirmation from the server;

Second handshake: the server receivesSYNPacket segment. The server receivesSYNThe packet segment.SYNConfirm and set the packet segmentAcknowledgment NumberX + 1 (Sequence Number+ 1); at the same time, you have to sendSYNRequest information, setSYNLocation: 1,Sequence NumberIs y. The server puts all the above information in one packet segment (that isSYN+ACKPacket segment) and send it to the client.SYN_RECVStatus;

The third handshake: the client receivesSYN+ACKPacket segment. ThenAcknowledgment NumberSet to y + 1 and send it to the serverACKPacket segment. After the packet segment is sent, both the client and the server enterESTABLISHEDStatus, TCP three-way handshake is completed.

After the three handshakes are completed, the client and the server can start to transmit data and use tcpdump to capture packets on the server.

[root@dev ~]# tcpdump -i lo  port 12000tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes22:58:54.952917 IP localhost.48383 > localhost.entextxid: Flags [S], seq 439289121, win 65495, options [mss 65495,sackOK,TS val 4017863386 ecr 0,nop,wscale 7], length 022:58:54.952928 IP localhost.entextxid > localhost.48383: Flags [S.], seq 3569639229, ack 439289122, win 65483, options [mss 65495,sackOK,TS val 4017863386 ecr 4017863386,nop,wscale 7], length 022:58:54.952938 IP localhost.48383 > localhost.entextxid: Flags [.], ack 1, win 512, options [nop,nop,TS val 4017863386 ecr 4017863386], length 0

We can see that

Client> server seq = 439289121 flags = S

Server => client ack = seq + 1 = 439289122, seq = 3569639229 flags = S

Client => server ack = 1 flags = NULL

• Win: Window fields are clearly specified.NowAllowPeerSent data volume (frequently changed)
• MSS (Maximum Segment Size): Maximum Segment length, that is, the Maximum length of the data field in each TCP Segment. here we need to negotiate during the handshake. Both parties give MSS, and finally determine the final MSS with the minimum MSS. the Maximum Transmission Unit of IP datagram is MTU (Maximum Transmission Unit, Effect of short board). For most LAN networks that use Ethernet, MTU = 1500. MSS is usually calculated based on MTU. Generally, MSS = MTU-sizeof (IP Header)-sizeof (TCP Header) = 1500-20-20 = 1460
• SackOK validation Field

After the connection is established, we are sending a command

23:08:44.906783 IP localhost.48387 > localhost.entextxid: Flags [P.], seq 1:8, ack 1, win 512, options [nop,nop,TS val 4018453340 ecr 4018450643], length 723:08:44.906802 IP localhost.entextxid > localhost.48387: Flags [.], ack 8, win 512, options [nop,nop,TS val 4018453340 ecr 4018453340], length 023:08:44.906997 IP localhost.entextxid > localhost.48387: Flags [P.], seq 1:1174, ack 8, win 512, options [nop,nop,TS val 4018453340 ecr 4018453340], length 117323:08:44.907008 IP localhost.48387 > localhost.entextxid: Flags [.], ack 1174, win 531, options [nop,nop,TS val 4018453340 ecr 4018453340], length 0

3. What about the four breaking up?

Because the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes its data sending task, it can send a FIN to terminate the connection in this direction. Receiving a FIN only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a FIN. The first party closes the service and the other party closes the service.

The first time you break up: HOST 1 (which can be a client or a server), setSequence NumberAndAcknowledgment Number, SendFINPacket segment; in this case, HOST 1 entersFIN_WAIT_1Status; this indicates that host 1 has no data to send to host 2;

Second breakup: Host 2 receivedFINPacket segment, which returns one packet to the hostACKPacket segment,Acknowledgment NumberIsSequence NumberAdd 1; HOST 1 entersFIN_WAIT_2Status; host 2 tells HOST 1 that I have no data to send. You can close the connection;

Third breakup: Host 2 sends to host 1FINPacket segment, request to close the connection while host 2 entersCLOSE_WAITStatus;

The fourth breakup: HOST 1 receivedFINPacket segment, sent to host 2ACKPacket segment, and then HOST 1 entersTIME_WAITStatus; host 2 receivesACKAfter the packet segment, the connection is closed. At this time, HOST 1 still does not receive a response after waiting for 2MSL, it indicates that the Server has been properly closed. Well, HOST 1 can also close the connection.

So far, the four breaking up of TCP has been completed so happily.

4. Why do I need to shake hands three times?

• LISTEN: This is also an easy-to-understand state, indicating that a SOCKET on the server is in the listening state and can accept connections.
• SYN_SENT: When the client SOCKET executes the CONNECT connection, it first sends the SYN packet, so it enters the SYN_SENT state and waits for the server to send the 2nd packets in the three-way handshake. SYN_SENT status indicates that the client has sent SYN packets. (Sender)
• SYN_RCVD: This status echo SYN_SENT. This status indicates that SYN packets are received. Normally, this status is an intermediate status of the server SOCKET during the three-way handshake session when a TCP connection is established. It is very short. It is hard to see this status with netstat, unless you write a client test program, the last ACK packet is not sent during the three TCP handshakes. Therefore, when an ACK packet is received from the client, it enters the ESTABLISHED status. (Server)
• ESTABLISHED: This is easy to understand, indicating that the connection has been established.

Since TCP's three-way handshake is summarized, why do we have to do it three times? I think it can be done twice. So why does TCP have to perform three connections? Xie xiiren's "Computer Network" says this:

Errors are generated to prevent the invalid Connection Request Message segment from being suddenly transmitted to the server.

Here is an example:

"Invalid Connection Request Message segment" is generated in the case that the first connection request message segment sent by the client is not lost, however, a network node is stuck for a long time, so that it will arrive at the server at a certain time after the connection is released. This is a long-overdue packet segment. However, after the server receives the invalid Connection Request Message segment, it is mistaken for a new connection request sent by the client again. Therefore, the client sends a confirmation message segment and agrees to establish a connection. If the "three-way handshake" is not used, a new connection is established as long as the server sends a confirmation message. Because the client does not send a connection request, it does not accept the confirmation from the server or send data to the server. However, the server thinks that the new transport connection has been established and waits for the client to send data. In this way, many server resources are wasted. The "three-way handshake" method can prevent the above phenomenon. For example, in that case, the client will not send confirmation to the server. Because the server cannot receive the confirmation, it will know that the client does not require a connection ."

This makes it clear that it prevents the server from wasting resources while waiting.

5. Why should I break up four times?

TCP is a connection-oriented, reliable, and byte stream-based transport layer communication protocol. It is a full-duplex mode. Therefore, each direction must be disabled separately. This principle is that when one party completes its data sending task, it can send a FIN to terminate the connection in this direction. Receiving a FIN only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a FIN. The first party closes the service and the other party closes the service.

When HOST 1 is releasedFINIn the packet segment, it only indicates that host 1 has no data to be sent. HOST 1 tells host 2 that all its data has been sent. However, in this case, HOST 1 can still accept data from host 2. When host 2 returnsACKWhen the packet segment is sent, it indicates that host 1 has no data to send, but host 2 can still send data to host 1; When host 2 also sendsFINWhen the packet segment is sent, it indicates that host 2 has no data to send, and then it will tell HOST 1 that I have no data to send, then they will happily interrupt the TCP connection. If you want to correctly understand the principles of the four breaking up, you need to understand the status changes during the four breaking up process.

• FIN_WAIT_1: This status should be well explained. In factFIN_WAIT_1AndFIN_WAIT_2The true meaning of the status is the FIN message waiting for the other party. The difference between the two States is:FIN_WAIT_1The status is actually when the SOCKET is in the ESTABLISHED status, it wants to take the initiative to close the connection and sendFINThe SOCKET entersFIN_WAIT_1Status. When the other Party responds to the ACK packetFIN_WAIT_2Status, of course, under normal circumstances, no matter what circumstances the other party should immediately respond to ACK packets, soFIN_WAIT_1The status is generally difficult to see, whileFIN_WAIT_2The status is often seen with netstat. (Active party)
• FIN_WAIT_2: This status has been explained in detail above. In factFIN_WAIT_2The SOCKET in the status indicates a semi-connection, that is, one party requires a close connection, but also tells the other party that I still have some data to send to you (ACK information ), close the connection later. (Active party)
• CLOSE_WAIT: The meaning of this state is actually waiting to close. How can this problem be solved? Sent when the other party closes a SOCKETFINPacket to yourself, your system will undoubtedly respond to an ACK packet to the other party, then enterCLOSE_WAITStatus. Next, in fact, what you really need to consider is to check if you still have data to send to the other party. If not, you can close this SOCKET and sendFINPackets are sent to the other party, that is, the connection is closed. So you areCLOSE_WAITThe task to complete is to wait for you to close the connection. (Passive)
• LAST_ACK: This status is easy to understand. It is passively disabled when one party sendsFINAfter the packet, wait for the other's ACK packet. After receiving the ACK message, you can enter the CLOSED available status. (Passive)
• TIME_WAIT: Indicates that the other party's FIN packet is received, and the ACK packet is sent concurrently. After 2MSL is sent, it can return to the available state of CLOSED. If FINWAIT1. When the recipient receives a message with both the FIN mark and the ACK markTIME_WAITStatus without passing throughFIN_WAIT_2Status. (Active party)
• CLOSED: Indicates that the connection is interrupted.

6. Why do I use three instead of two handshakes?

If two handshakes are performed, the client may send multiple request packets due to network congestion and other reasons. Then, the server will establish a connection, wasting many server resources.

7. Why is the three-way handshake while the four-way handshake when the connection is closed?

This is because the server receives the SYN Packet of the established connection request in the LISTEN status, and then places ACK and SYN in a packet and sends it to the client. When the connection is closed, when receiving the FIN message from the other party, it only means that the other party no longer sends data but can still receive data, and not all of its data may be sent to the other party, therefore, you can immediately close the connection, send some data to the other party, and then send a FIN message to the other party to agree to close the connection. Therefore, both ACK and FIN are usually sent separately.

8. Why do I have to wait for 2MSL time in four waves? What is 2MSL?

MSL is Maximum Segment life time. MSL is the longest time for any message to exist on the network. If the Maximum time is exceeded, the message will be discarded.

2MSL is twice the MSL, And the TCP TIME_WAIT status is also known as 2MSL waiting status. When one end of TCP initiates an active shutdown, after the last ACK packet is sent, that is, the ACK packet sent after the fourth handshake is completed in the TIME_WAIT status, and the MSL time must be twice in this status. (In RFC 793, MSL is set to 2 minutes. Generally, 30 seconds, 1 minute, and 2 minutes are used in actual applications)

 

The main purpose of waiting for 2MSL time is to ensure that the last ACK packet is not received by the other party. After the timeout, the other party will resend the third handshake FIN packet, after receiving the resending FIN package, you can send an ACK response packet. The ports at both ends of TIME_WAIT cannot be used. You must wait until the end of 2MSL to continue using the port. When the connection is in the 2MSL wait stage, any late packet segment will be discarded. However, in practice, you can set the SO_REUSEADDR option to use this port without waiting for the end of 2MSL.

Survival time: the TCP Message segment is the data part of the IP datagram, And the IP header has a TTL domain, TTL is short for time to live, the survival time is the initial value set by the source host, but not the specific time of storage. Instead, it stores the maximum number of routes that an IP datagram can pass through, this value is reduced by 1 for each vro that processes it. If this value is 0, the datagram is discarded and the source host is notified by ICMP packets.

TTL is related to MSL but not simply equal. MSL must be greater than or equal to TTL.

Why does the TIME_WAIT status need to be 2MSL long?

If the TIME_WAIT status is not long enough, the first connection is terminated normally. The second connection with the same quintuple occurs, and the repeated packets of the first connection arrive, interfering with the second connection. TCP must prevent repeated packets of a connection from appearing after the connection is terminated in advance, so the TIME_WAIT status remains long enough (2MSL). The TCP packets in the corresponding direction of the connection must be completely responded, or be discarded. The second connection is not obfuscated.

9. TIME_WAIT cause

A) nginx uses a short connection, which may cause a large number of connections in the TIME_WAIT status.

B) The TCP/IP designer was originally designed to prevent the packet in the last connection from re-appearing after getting lost, affecting the new connection (after 2MSL, all repeated packets in the last connection will disappear). The last ack (fin) sent by the active closing side of the TCP connection may be lost, and the passive side will re-Send the fin, if the active Party is in the CLOSED state, it will respond to the rst instead of ack. Therefore, the active party must be in the TIME_WAIT state, not the CLOSED state.

C) Too many TIME_WAIT Solutions

Net. ipv4.tcp _ syncookies = 1 // indicates enabling SYN Cookies. When a SYN wait queue overflows, cookies are enabled to prevent a small number of SYN attacks. The default value is 0, indicating that the service is disabled. net. ipv4.tcp _ tw_reuse = 1 // indicates that reuse is enabled. Allow TIME-WAIT sockets to be re-used for a New TCP connection. The default value is 0, indicating that it is disabled. net. ipv4.tcp _ tw_recycle = 1 // indicates that fast recovery of TIME-WAIT sockets in TCP connections is enabled. The default value is 0, indicating that quick recovery is disabled. Net. ipv4.tcp _ fin_timeout = 30 // indicates that if the socket is disabled by the local end, this parameter determines the time it remains in the FIN-WAIT-2 state. Net. ipv4.tcp _ keepalive_time = 1200 // indicates the frequency of keepalive messages sent by TCP when keepalive is in use. The default value is 2 hours, which is changed to 20 minutes. Net. ipv4.ip _ local_port_range = 1024 65000 // indicates the port range used for external connection. The default value is small: 32768 to 61000, Which is changed to 1024 to 65000. Net. ipv4.tcp _ max_syn_backlog = 8192 // indicates the length of the SYN queue. The default value is 1024. The length of the queue is 8192, which can accommodate more network connections waiting for connection. Net. ipv4.tcp _ max_tw_buckets = 5000 // indicates that the system maintains the maximum number of TIME_WAIT sockets at the same time. If this number is exceeded, the TIME_WAIT socket is immediately cleared and the warning message is printed. The default value is 180000, Which is changed to 5000.

For servers such as Apache and Nginx, the number of TIME_WAIT sockets can be greatly reduced by parameters in the previous lines, but the effect on Squid is not great. This parameter can control the maximum number of TIME_WAIT sockets to prevent the Squid server from being dragged to death by a large number of TIME_WAIT sockets.

 

References

Http://www.cnblogs.com/tankxiao/archive/2012/10/10/2711777.html

Http://blog.csdn.net/whuslei/article/details/6667471

Http://molewan.blog.51cto.com/287340/114592

Http://www.jellythink.com/archives/705

Https://wiki.wireshark.org/DisplayFilters