Transmission Control Protocol (TCP) (lower)

3.4. Establish a connection

A three-message handshake is used to establish a connection application. If both parties send SYN at the same time, the two parties will find that the SYN is not confirmed, so they will know this situation. Generally, A "reset" segment should be sent to solve this problem. The three-message handshake reduces the possibility of connection failure. The following is an example. The angle brackets are the content and tags in the data segment. I will not talk about anything else.

In row 2nd, tcp a sends the SYN initialization serial number, indicating that it uses the serial number 100. In row 3rd, tcp B provides confirmation and expects a data segment with the serial number 101; line 4th, tcp a gives confirmation, and In line 5th, it also gives confirmation, and sends some data, note that the serial number of line 4th is the same as that of line 5th, because ack does not occupy the serial number in the serial number space. Shows the situation where requests are generated at the same time, which is only a little more complex.

The main reason for using a three-message handshake is to prevent the use of expired data segments. For this purpose, a new control message, reset, must be introduced. If the received TCP processing is not in the synchronous state, the listen status is returned after the reset is received. If TCP processes the following statuses established, fin-wait-1, fin-wait-2, close-Wait, closing, LAST-ACK, time-Wait, discard the connection and pass through the user. Next we will describe the latter situation in detail.

Through the above example, we can see how the TCP connection recovers from the interference of the expired data segment. Note the RST (reset signal) in lines 4th and 5th ).

Semi-open connection and other abnormal statuses

If one party closes the connection without passing through the other, or the two parties fail to synchronize, we call it a semi-open connection. When one party tries to send data, the connection will automatically reset. However, this situation is abnormal. Corresponding processing should be made. If the connection at location a is closed, it is unknown at location B. When B wants to send data to A, B will receive a reset signal, indicating that the TCP connection is incorrect and the current connection needs to be aborted.

Assume that tcp of a fails when processes a and B communicate with each other, and a relies on the operating system to support the existence of TCP. In this case, the recovery mechanism usually works, when TCP is restored, A may want to start from the recovery point. In this way, a may attempt to open the connection and transmit data on the connection that it deems to be open. In this case, a will locally (that is, a's) TCP receives the error message "connection not opened ". A's TCP will send data segments including SYN. The following example shows the process:

In the above example, the information received by Party A does not confirm anything. At this time, Party A finds a problem and sends the RST control information. Another case is that a fails while B tries to send data. The following example shows this case, note that the information sent from row A to B is sent to Alibaba Cloud.

In the following example, the passive connections between A and B are waiting for SYN information. The expired package is sent to Party B to send B a response, but the response a finds that it is incorrect. The RST control information is sent, and Party B returns the passive listen status.

In reality, there are too many situations. We will list some rules that generate rst control information as follows: Normally, RST will generate information that is not expected. If you are not sure, do not send the RST control information easily. There are three types of scenarios:

If the connection does not exist and the sent message is not the rst, the RST is returned. This method can be used if you want to reject non-existing connections. If an ACK domain exists, the returned rst can obtain the serial number from the ACK domain. If no such domain exists, set the serial number of the RST to 0, the ack domain is the sum of the device serial number and the length of the arrival segment. The connection is still close.

If the connection is in a non-synchronous state (Listen, SYN-SENT, SYN-RECEIVED ), in addition, an RST is sent when the security level of the received data segment is the same as that of the data segment that cannot be connected. If the SYN is not confirmed and the received data segment has a higher priority than the required, either increase the local priority (with prior permission from the user and the system) or send the RST; if the priority of the received data segment is lower than the required priority, even if it is matched, of course, if the recipient finds that the priority is incorrect, the priority is increased in the next packet, which is not a match. If the connection already enters SYN, the priority of the received data segment must be the same as that of the local data segment; otherwise, the RST is sent. If an ACK domain exists, the returned rst can obtain the serial number from the ACK domain. If no such domain exists, set the serial number of the RST to 0, the ack domain is the sum of the device serial number and the length of the arrival segment. The connection is still in the same status as the original one.

If the connection is in the synchronous state (established, fin-wait-1, fin-wait-2, close-Wait, closing, LAST-ACK, time-Wait ), any data segment that exceeds the serial number of the Receiving Window generates the following result: An empty validation data segment is sent, which includes the serial number of the currently sent data segment and the serial number of the next data segment to be received, the connection is still saved in the original status. If problems such as security level and priority are caused, send the RST signal and enter the closed status.

RST Process

All rst data segments can be identified in other States except the SYN-SENT status by checking the seq domain. If the serial number is in the receiving window, the RST is valid. When the connection is in the SYN-SENT state, the RST is also legal if the ACK domain confirms syn.

The receiver of RST first confirms its legitimacy and then performs state conversion. If the receiver is in the listen state, it ignores the RST package. If the receiver is in the SYN-RECEIVED state and previously in the listen state, the receiver returns the listen state; otherwise, the receiver closes the connection and enters the closed state. When the receiver is in another State, the connection is directly closed and returned to the closed state.

3.5. Close the connection

Close is an operation, which means "data has been sent by the local party ". Because it is full-duplex, it may cause some trouble, because the receiver is a little difficult to process the connection of the receiver. We treat close in a simple way. The sender and receiver of close must continue to receive data before receiving the other party's closed. ThereforeProgramYou can initialize several sends after a close operation, and then start receive until the recipient's closed is received and the receive fails. We assume that TCP can notify the user that the connection is closed, even if the receive is still in progress, so that the user can close it normally. In this way, TCP can send data reliably before the connection is closed. Three basic conditions are listed below:

Case 1: the local user is disabled.

In this case, you can create a fin segment and put it into the sending queue. TCP no longer receives user send commands. TCP enters the fin-wait-1 state. Receive is allowed in this status. All data segments and fin are sent until confirmation is received. When another TCP confirms the fin and sends its own fin, the local TCP can confirm the fin. Note that TCP also does not return its own fin when confirming the fin, until the user closes the connection and returns its own fin.

Case 2: TCP receives a fin from the network

If you receive fin without a request, TCP can return ack and notify the user that the connection has been closed. You can send a close response. TCP sends its own fin after sending the remaining data. TCP then waits for confirmation of the fin and closes the connection after receiving it. If you confirm that the connection times out, you can close the connection and notify the user to complete the process.

Case 3: both parties close

Both parties close at the same time, causing fin exchange. Both parties will close the connection after receiving confirmation of their fin.

3.6. Priority and security

TCP operations must be performed between two ports with the same priority. The priority and security parameters used by TCP are defined in the IP protocol. The security/interval mentioned here refers to the priority defined in the IP address, user group and handling rules. If not, RST is sent. Please refer to the description in the previous section. TCP also checks the priority of the received data segment during the operation, and can also increase the priority in the operation. Although running in a secure environment, the host must be able to process security parameters.

3.7. Data Communication

After a connection is established, data is transmitted. TCP retransmits each data segment to the other party. Because of the re-transmission, the other party may receive two identical packets, you must determine which data segment can be received based on the internal serial number. The sender uses SND. NXT to track the next data segment to be sent, while the receiver tracks RCV. NXT to know the next data segment to be received. The sender needs to save the oldest serial number that has not been confirmed to SND. Una.

When the sender forms a data segment and sends it, SND. NXT increases. When the receiver receives the data segment, RCV. NXT increases and confirmation is sent. When the sender receives the confirmation, SND. Una increases. The three of them increase at different times because of the transmission delay. The increase is determined by the data size in the data segment. Note: after the connection enters the established status, all the segments must contain the current validation information. The nature of the Close user operation is the push operation, which is the same as the fin mark in the received data segment.

Retransmission timeout

Because there are non-network types in the network, and the range of TCP is wide, the Retransmission timeout must be dynamically determined. The following example shows how to determine the Retransmission timeout process. The following two variables describe the latency. One is the Loop Time (RTT), which is obtained by a sequence code, which is given at the time of sending, it is overwritten when confirmation is received; another smooth Loop Time (SRTT ):

SRTT = (alpha * SRTT) + (1-alpha) * RTT)

Through the above formula, you can get the Retransmission timeout (RTO ):

RTO = min [ubound, Max [lbound, (Beta * SRTT )}

Here, ubound is the upper bound of timeout (for example, 1 minute), lbound is the lower bound of timeout (for example, 1 second), alpha is the smoothing factor (for example, 0.8 to 0.9 ), beta is a latency variable (such as 1.3 to 2.0 ).

Send emergency messages

The TCP urgency mechanism allows the sender to enable the receiver to receive some urgent messages, and the receiver to notify the user immediately after receiving the message. This mechanism adds a vertex to the data stream, indicating that this is the end point of the emergency data. When the receiver wants to receive this vertex, it notifies the user of the emergency, after receiving the data at this point, it will notify the user to enter the normal state. If the emergency point is updated when the user enters the emergency state, the update must be transparent to the user.

The URG Control Mark specifies whether an emergency domain is used and the serial number indicating the emergency point must be added to the data segment, if this flag is not displayed, there is no emergency point. To send emergency data, the sender must send at least one byte.

Management window

If we have learned the basics of the network, we must know that there is a window protocol. Each data segment in TCP includes the next serial number to be received. The window comparison Conference increases the transmission speed. If the transmitted data exceeds the window size, the data will be discarded. This will increase the network burden. If the receiving window is large at the beginning of TCP and the window is reduced at the end, this method is not a good solution. For robust TCP, it is best not to narrow the window by yourself, but to prepare the TCP narrowing window of the other party.

Even if the size of the sending window is zero, TCP must be prepared to receive data and send at least one new data. Even if the receiving window is zero, the sender resends the message. The interval between resends is generally two minutes. When the Receiving Window of TCP is zero, when it receives data, it returns confirmation, including the sequence code to be received and the current window size (zero ).

Sending TCP splits the data into packages of the current size, but may be repackaged in the re-transmission queue. This type of repackaging is not necessary, but it is very beneficial. If a connection has only one-way data flow, the window information can be obtained in the confirmation information. These serial numbers are all one, so there is no way to distinguish who is first and who is later. But this is not a serious problem. The improved method is to add the latest expected serial number to the data segment, so that you can identify who is first and then who is later. Window Management has a great impact on transmission efficiency. The following are some suggestions:

When using less big data to achieve high efficiency, a very small window is allocated so that data is transmitted in many small segments. For the sender, do not wait until the window is large to a certain extent when sending small data segments. Do not be delayed. If the size of the receiving window is zero, the data segment to be transferred may be smaller and smaller. If only the data segments allowed in the sending window of TCP are sent, these data segments may be sent by a data segment that is larger (or smaller) than this data segment. When the receiver adjusts the window size from time to time, the big data segment is divided into small segments, but not paired. Try to merge small windows into large windows.

3.8. Interface

The layered structure of the network protocol determines that TCP has two interfaces: the upstream user interface and the following interface. The description of the lower-layer receiving port is not very clear. This work is described by the lower-layer protocol, but here we also describe some parameters required for TCP.

User/tcp Interface

The following describes some TCP commands that are functional and may vary depending on different systems. Finally, we must be clear that different TCP implementations may have different user interfaces, but some functions are the most basic. The functions described in this section are the basic functions.

Tcp user command

The commands defined below are similar to the methods defined in other advanced languages, but some traps are required, such as SVC, UUO, AND EMTs. The following is just a function introduction. The specific implementation may be quite different. For example, some systems will combine multiple commands into one command. To implement the communication function, TCP cannot only receive commands and return messages to the processes that serve them. These messages include:

(A) General messages about connections, such as interruptions and remote shutdown;

(B) Whether it is successful or failed to respond to user commands.

Open

Format: open (local port, foreign socket, active/passive [, timeout] [, precedence] [, security/compartment] [, options])-> local connection name

We assume that the local TCP has noticed the process tag it serves and will check the process authentication. Depending on the implementation, TCP authentication for the local network and source address may also be performed by the lower-layer protocol (such as the IP protocol ). These considerations are mainly based on security considerations.

If the active/passive flag is set to passive, TCP detects the incoming connection request, which is passive, A passive connection can have a completely specified external socket used to wait for a specific connection or unspecified external socket to wait for any call. A fully defined passive call can become active by executing a series of send commands. Create a transmission control block (TCB), some of which come from the open command parameters. When active open is enabled, TCP will immediately start the synchronous connection. If the timeout parameter is provided, the caller is allowed to apply all TCP data. If data has not been sent to the destination within the time specified by timeout, the connection is closed. The default value is 5 minutes.

The precedence or security/compartment parameter is used to regulate the security of a user for a connection. If not specified, the default value is used. TCP will match these two parameters. The connection will be opened only when the security/compartment is consistent and the received precedence is less than or equal to the required precedence. When the precedence of the connection is greater than the required value, this value is obtained from the received data segment and this large value is always used in the connection. In specific implementation, users can be given the right to control the decision process of precedence. For example, a user may require that the precedence be secure and consistent, or notify the user when promoting the precedence.

The local connection name is returned to the user by TCP. It can mark a connection instead of <local socket, external socket>.

Send

Format: Send (local connection name, buffer address, byte count, push flag, Urgent Flag [, timeout])

This command sends data in the specified buffer to the specified connection. If the connection is not opened, an error is returned. In some implementations, you may call send before the connection is opened, and send automatically opens the connection. If the push tag is set, the data must be transmitted to the receiver immediately, and the last segment of the push bit in the buffer must be set. If this parameter is not set, the data segment is transmitted together with the data transmitted by the next send command because of efficiency. If the URGent flag is set, it must be handled urgently as described above. The number of urgent set by the sender does not have to be equal to the number of times the receiver user is notified.

If no external socket is specified in open, the buffer data is sent to the implicit external socket. Users who do not use external sockets to open the connection can still send without knowing the external socket address. However, if you send data before the specified external socket, an error occurs. You can use statues to determine the connection status. If timeout is specified, the current user timeout of the current connection is changed to a new connection.

The simplest implementation method is that before sending data, send does not give control to the sending process, but this may cause a deadlock (for example, both parties attempt to send, but do not prepare receive), the efficiency is not good. A good implementation method is to return control to the sending process after sending a piece of data. Of course, it would be better if multiple sending requests can be sent at the same time. When multiple sending requests require services, the service is first served.

For the local system, we assume that the sending process sends data with something similar to the interrupt after sending data; of course, sending can also notify you of the data sending status immediately after sending. We can be optimistic that the sending is successful. If the sending fails, the connection will be closed due to timeout. In implementation, even synchronous responses require some asynchronous signals, but these asynchronous signals are used to process connections rather than data transmission. Since multiple sending operations are allowed at the same time, it is necessary to distinguish the returned message from the one sent. The specific situation will be discussed below.

Receive

Format: receive (local connection name, buffer address, byte count)-> Byte Count, URGent flag, push flag

This command allocates a receiving buffer to the specified connection. If the following is not an open command or the call is not authorized to use the connection, an error is returned. The simplest way to achieve this is to do not return control before the buffer is fully filled, but this may cause serious deadlocks.