[Network protocol] establishes and releases a TCP connection.

Reprinted please indicate the source: http://blog.csdn.net/ns_code/article/details/29382883

TCP Header Format

First look at the format of the TCP packet segment, as shown below;

The first 20 bytes of the TCP segment header are fixed, and the next 4 bytes are added as needed. Therefore, the minimum length of TCP packets is 20 bytes.

The meanings of fields in the fixed part of the header are as follows:

1. Source Port and destination port: add the source IP address and destination IP address of the IP header to determine a unique TCP connection. In addition, the target port is used to determine the application that TCP delivers the datagram, so as to achieve the TCP sharing function.

2. Serial number: 4 bytes. The serial number ranges from 0 to. Because TCP is oriented to byte streams, every byte in the byte stream transmitted in a TCP connection is numbered sequentially, the sequence number field in the first part refers to the sequence number of the first byte of the data sent in this section. In addition, the sequence number is used cyclically. When the sequence number is increased to the maximum value, the next sequence number returns to 0.

3. Confirmation Number: valid when the ACK flag is 1, indicating the sequence number of the First Data byte of the next packet segment to be received. If the validation number is N, it indicates that all data bytes until the serial number N-1 have been correctly received.

4. Header Length: the length of the header of the TCP packet segment. It indicates the distance between the start position of the Data Segment of the TCP packet segment and the start position of the TCP packet segment. The Header Length occupies 4 bytes, but its unit is 32 characters, that is, 4 bytes. Therefore, the maximum length of the header is 15*4 = 60 bytes, this means that the length of the option cannot exceed 40 bytes.

5. Reserved bits: Must be 0.

6. The following six control bits describe the nature of the packet segment:

1) URG: used with the emergency pointer field in the header. When URG is 1, it indicates that the emergency pointer field is valid. The sending application process tells the sender that TCP has urgent data to be transmitted, as a result, the sender's TCP inserts the emergency data to the beginning of the data in this section, and the end is still normal data.

2) ACK: The ACK is valid only when ACK = 1. When ACK = 0, the ACK is invalid. TCP specifies that ACK must be set to 1 for all transmission packets after the connection is established.

3) PSH: If the psh in the sent packet segment is 1, the receiver will directly deliver it to the application process after receiving the packet segment, instead of waiting for the entire cache to be filled up before delivery.

4) When RST: RST = 1, it indicates a serious error occurred in the TCP connection. You must release the connection and re-establish the transport connection.

5) SYN: Synchronous sequence number, used to initiate a connection. When SYN = 1 and ACK = 0, it indicates that this is a connection request message segment. If the other party agrees to establish a connection, SYN = 1 and ACK = 1 should be made in the response packet segment.

6) FIN: Used to release a connection. When FIN = 1, it indicates that the data of the sender of the message segment has been sent and the connection must be released.

7. Window: the size of the sending window set by the receiver for the next message segment sent by the sender.

8. checksum: the range of fields for verification includes the header and data.

9. Emergency pointer: The emergency pointer is valid only when URG = 1. It indicates the number of bytes of emergency data in this section. It is worth noting that emergency data can be sent even if the window is 0.

10. Options and fill: the option should be an integer multiple of 4 bytes; otherwise, it should be filled with 0. The most common optional field is the Maximum Message Size (MSS) (Maximum Segment Size). Each connection usually specifies this option in the first packet Segment of the communication. It specifies the maximum length of packets that can be received by the local end. If this option is not set, the default value is 536 (20 + 20 + 536 = 576 bytes of IP datagram). The ip header and tcp Header are each 20 bytes, the standard MTU (minimum) on the internet is 576B.

TCP connection Establishment

Establish a TCP three-way handshake:

The TCP process on the server first creates a transmission control block TCB, prepares to accept connection requests from the client process, and then the server process is in the LISTEN status, waiting for the client connection request. If yes, the server responds.

1. the TCP process on the client also first creates the transmission control module TCB, and then sends a connection request message segment to B. SYN = 1, ACK = 0, select an initial sequence number seq = I. According to TCP rules, packets with SYN = 1 cannot carry data, but consume a serial number. The TCP client process enters the SYN-SENT (synchronous sent) state, the first handshake of the TCP connection.

2. After receiving the request message from the client, the server sends a confirmation message to the client if it agrees to establish a connection. In the confirmation message, SYN = 1, ACK = 1, ack = I + 1, and select an initial sequence number seq = j. The message segment is also a SYN = 1 packet segment, which cannot carry data, but also consumes a serial number. At this point, the TCP server enters the SYN-RCVD (synchronously received) state, which is the second handshake of the TCP connection.

3. After receiving confirmation from the server process, the TCP client process should also confirm with the server. The ACK of the validation packet segment is 1, The ack is j + 1, and its serial number is seq = I + 1. According to TCP standards, ACK packets can carry data, but if no data is carried, no serial number is consumed. Therefore, if no data is carried, the serial number of the next packet segment is still seq = I + 1. At this time, the TCP connection has been ESTABLISHED, and the client enters the ESTABLISHED (ESTABLISHED connection) status. This is the third handshake of a TCP connection. It can be seen that the client can send packets with data.

When the server receives the confirmation, it also enters the ESTABLISHED (ESTABLISHED connection) status.

TCP Connection established by both parties at the same time
Under normal circumstances, the transmission connection is initiated by one party, but it is also possible that both Parties initiate the connection at the same time. In this case, a connection collision occurs and only one connection can be established. Because all connections are identified by their endpoints. If the first connection request establishes a connection identified by socket (x, y), and the second connection also establishes such a connection, there is only one socket table item in the TCP object.
When a connection request is sent at the same time, the two ends send a data segment with the SYN field set to 1 almost simultaneously and enter the SYN_SENT state. When each end receives the SYN data segment, the status changes to SYN_RCVD. At the same time, both ends send the data segment where the SYN field is set to 1 and the ACK field is set to 1 to confirm the received SYN data segment. When both parties receive the SYN + ACK data segment from the other party, the request enters the ESTABLISHED status. Figure 10-39 shows the connection process for initiating a connection at the same time, but a TCP connection is established instead of two. Pay special attention to this.

It can be seen that a transmission connection opened by both parties needs to exchange four data segments, and exchange one data segment more than the three-way handshake established by a normal transmission connection. In addition, we do not call any end a customer or server because each end is both a customer and a server.

Why do we have to perform three handshakes?

The first two handshakes are obviously necessary, mainly the last one. That is, why do the client want to send a confirmation message after receiving the confirmation from the server? This is mainly to prevent connection misjudgment when invalid request packets are suddenly transmitted to the server.

Consider the following situation: the client sends a connection request packet segment to the server, but has been stuck on some network nodes for a long time, then the client times out and resends a connection request message segment to the server. Then the connection is established normally, data transmission is complete, and the connection is released. If the request message segment sent for the first time is delayed for a period of time and then arrives at the server, it is obviously a long-overdue message segment, after receiving the message, the server mistakenly thinks that the client has sent a connection request again. Therefore, the server sends a confirmation message segment to the client and agrees to establish a connection. If three handshakes are not used, the server only needs to send a confirmation message, and the new connection is established. However, since the client does not send a connection establishment request more than you, the server does not accept the confirmation, it does not send data to the server, but the server considers that a new connection has been established and is waiting for the client to send data, so that the server will keep waiting, the connection will not be closed until the value of the active/active counter is exceeded and the client is determined to be faulty. This wastes a lot of server resources. If the three-way handshake is used, the client will not send a confirmation to the server. Because the server cannot receive the confirmation, it will know that the client does not require a connection and thus does not establish the connection.

Release of TCP Connection

Four Waves of TCP release process:

After data transmission is complete, both parties can release the connection and stop sending data. Assume that both the client and server are in the ESTABLISHED state.

1. the TCP process of client A first sends A connection to the server to release the packet segment, stops sending data, and closes the TCP connection. In the release connection message segment, FIN = 1 and sequence number is seq = u. This sequence number is equal to the sequence number of the last byte of the data that has been transmitted before plus 1. At this time, A enters the FIN-WAIT-1 (Termination WAIT 1) state, waiting for B's confirmation. TCP stipulates that even if the FIN packet segment does not carry data, it consumes a sequence number. This is the first wave of TCP connection release.

2. After B receives the connection release packet segment, it sends the packet segment confirming the release of the connection. In the packet segment, ACK = 1, the validation number is ack = u + 1, its own serial number is v, which is equal to the serial number of the last byte of the data transmitted before B plus 1. Then B enters the CLOSE-WAIT (close wait) State. At this time, the TCP server process should notify the upper-layer application process, so the connection between A and B will be released, at this time, TCP is in the semi-closed state, that is, A has no data to send, but if B sends data, A still needs to accept, that is, the connection from B to A is not closed, this status may last for some time. This is the second wave of TCP connection release.

3. After receiving confirmation from B, A enters the FIN-WAIT (Termination WAIT 2) Status and waits for B to send A connection to release the packet segment, if B has no data to send to A, its application process notifies TCP to release the connection. In this case, the FIN = 1 in the Link sent by B must repeat the confirmation number sent last time, that is, ack = u + 1, sequence number seq = w, because B may send some data in the semi-closed status, this sequence number is the sequence number of the last byte of the data sent in the semi-closed status plus 1. At this time B enters the LAST-ACK (final confirmation) status, waiting for A's confirmation, this is the third wave of TCP connection.

4. After receiving the connection release request from B, A must confirm the request. In the validation packet segment, ACK = 1, ack = w + 1, and its serial number seq = u + 1, and then enters the TIME-WAIT Status. At this time, the TCP connection has not been released, and it must wait for the timer to set the time 2MSL before A enters the CLOSED state. The time MSL is called the longest message life. It is recommended that the RFC be set to 2 minutes, therefore, after A enters the TIME-WAIT state, it takes four minutes to enter the CLOSED state, and B enters the CLOSED state after receiving confirmation from. After both of them enter the CLOSED status, the connection is completely released, which is the fourth wave of the TCP connection.

The release process of TCP connections that are closed by both parties

Like setting up a TCP transmission connection at the same time, both parties can also take the initiative to close the TCP transmission connection. (normally, one Party sends the First FIN data segment for active connection, the other party passively accepts closed connections)

When the network application layer processes at both ends call the CLOSE primitive at the same time and send the FIN data segment to execute the CLOSE command, the two ends change from the ESTABLISHED status to the fin wait 1 status. After receiving the FIN data segment from the peer end, either party changes its status from fin wait 1 to CLOSING and sends the last ACK data segment. When the last ACK data segment is received, the status changes to TIME_WAIT. After waiting for 2MSL, it enters the CLOSED status and finally releases the entire TCP transmission connection.

Why must a wait for 2MSL in TIME-WAIT Status?

1. To ensure that the last ACK packet segment sent by A can reach B. This ACK packet segment is likely to be lost, so that B in the LIST-ACK State cannot receive confirmation of the sent FIN + ACK packet segment, B may re-transmit the FIN + ACK packet segment, and A receives the FIN + ACK packet segment during the 2MSL time. Then A re-transmits the packet and restarts the 2MSL timer, at last, both A and B enter the CLOSED state. If A directly releases the connection to the CLOSED state without waiting for A period of TIME, it will not be able to receive the FIN + ACK packet segment sent by B for A long TIME, then, B will not be able to normally enter the CLOSED status after the ACK packet segment is confirmed again.

2. Prevent invalid request connections from appearing in this connection. After sending the last ACK packet segment and then passing through 2MSL, A can remove all the packet segments generated during the connection duration from the network, in this way, the old connection request packet segment will not appear in the next new connection.