tcp-about connecting, disconnecting, and sliding windows

1.TCP Overview

TCP (transmission Control Protocol Transmission Protocol) is a connection-oriented, reliable, byte-stream-based Transport layer communication protocol. TCP provides full-duplex services, A and B can be active to send data to each other (can be compared with the HTTP protocol, the general case is only the client to the server to send data "h5 newly added websocket can communicate in two directions"). The control information for TCP is stored in the header of the TCP message, as shown in the format

Each TCP segment contains the port number of the source and destination ports, which is used to find the originating and receiving application processes. These two values, together with the source IP address and destination IP address in the IP header, uniquely determine a TCP connection (IP address + disconnect number is also the socket).

The serial number is the unsigned number of the 232-1 bit and starts at 0 after the sequence number is reached. That is, the serial number is calculated using MoD 232. TCP is byte-stream oriented, and each of the bytes transmitted in a TCP connection is numbered sequentially . The starting sequence number of the entire stream of bytes to be transmitted must be set when the connection is established. The sequence number in the header of the TCP message is the ordinal of the first byte of the data sent by this message segment. For example, the ordinal field value of a message segment is 1 and carries 1440 bytes of data data, the first byte ordinal of this segment is 1, and the last byte is the ordinal 1440. Clearly the next message segment (if any) should start at 1441. The sequence number is used to solve the problem of network packet disorder and the confirmation number is used to confirm the receipt, which is used to solve the packet loss. The data is re-transmitted if the originator does not receive an acknowledgement from the receiver for a certain amount of time. (Note that the confirmation number, many articles are simple introduction of the confirmation number = The originator sequence number +1, in fact, the confirmation number should be the last byte of the originating data sequence number +1, or the above example is sent when the ordinal number = 1, the confirmation number will be 1441, that is, the confirmation number is related to the length of the data sent).

The 6 flag bits of the TCP header are:

In the TCP flag bit:

The ACK:TCP agreement stipulates that only ack=1 is valid and that all messages sent after the connection is established must have an ACK of 1.

SYN: Used to synchronize the sequence number when the connection is established. When Syn=1 ack=0, indicates that this is a connection request message, if the other party agrees to establish a connection, the response message should make Syn=1 ack=1. Therefore, the SYN 1 indicates that this is a connection request or a connection acceptance message.

FIN: That means to complete the end, to release the connection. When Fin=1, the data indicating the sender of this segment has been sent, and the connection is required to be released.

Window (Advertised-window): Related to the sliding window described in this article, which is used to control the flow of data during the transfer process.

2. Establishing a connection (TCP three-time handshake)

First the client makes a connection request, the TCP flag bit syn=1 ack=0,tcp the syn=1, but consumes an ordinal number, so declare its own ordinal seq=x, When a connection request is sent, the client state changes from closed to Syn-sent, which is the first handshake. After the server receives the request, discovers that Syn=1 knows is a connection request, carries on the reply confirms the Syn=1 Ack=1 declares own ordinal seq=y, the confirmation number is ack=x+1, at this time the server state changed from listen to SYN-RCVD, this is the second handshake. After the client receives the connection confirmation from the server, check that the confirmation number ACK is correct, the first time the ordinal +1 (x+1) is sent, and whether the flag bit ACK is 1, if correct, send the confirmation packet to the server ack=1 syn=0, ordinal seq=x+1, confirmation number ack=y+ 1, the client status is changed from Syn-sent to established after sending the confirmation message, this is the third handshake. When the server receives the acknowledgement, the state changes from SYN-RCVD to established, and the connection is established. (Note: The uppercase ACK in the text indicates the TCP flag bit, and the lowercase ACK indicates the acknowledgment number)

Why do I have to do three handshakes (two confirmations, server acknowledgement, client acknowledgement)? The client's reconfirmation is to prevent the failed connection request packet from suddenly being transmitted to the server, resulting in an error. The so-called "failed connection request message segment" is generated. Consider a normal situation where the client makes a connection request but does not receive a recovery acknowledgement from the server because the connection request message is missing. The client then re-transmit the connection request, after receiving confirmation to establish a connection, start data transfer, and then release the connection, in this case the client sent a total of two connection requests, one lost one to reach the server side. No "Failed connection request message segment" was generated. It is assumed that an exception occurs when the first connection request made by the client is not lost and has been stranded for a long time on some network nodes, causing the delay to arrive at the server some time after the connection request is released. Originally is a long-overdue message segment, but the server received this failure message segment, mistakenly considered to be the client and issued a new connection request, then sent a reply to the client to confirm, agreed to establish a connection. Assuming that the three-time handshake is not used, the new connection is established only if the server-side sends a confirmation. Because the client does not make a connection request now, it does not acknowledge the banking server and does not send data to the server. However, the server thinks that the new connection has been established, and waits for the client to send the data, which can cause the wasting of the server resources, but the method of three handshake will prevent the occurrence of the above phenomenon. For example, in the case just now, the client will not confirm the confirmation to the server, because the server cannot receive confirmation, it knows that the client is not required to establish a connection.

3. Disconnect (TCP four waves)

　　　

When the client has no data to send to release its connection, at this time it will send a message (no data), the flag bit fin=1 ack=1 Set the sequence number Seq=u, the confirmation number Ack=v, the state from established to Fin-wait-1. The server received information after the client request to release the connection, but at this time there may be no data transmission completed, so first reply ACK message, set ack=1, serial number for seq= received confirmation number =v, confirmation number ack= received the serial number +1=u+ 1, when the state changes from established to close-wait. The client receives the service-side ACK message and the state is changed from Fin-wait-1 to Fin-wait-2 and continues to wait for the server's fin signal, during which time the client can receive data sent by the service side. When all data transfer is completed, the fin message is sent, the Fin=1 ack=1, the sequence number seq=w, the confirmation number ack=u+1, and the status is changed from Close-wait to Last-ack. After the client receives the fin message from the service, it sends the confirmation message, the ack=1, the sequence number seq=u+1, the confirmation number ack=w+1, the status is changed from Fin-wait-2 to Time-wait, and then the client waits for 2MSL (the maximum message life cycle) to close after the time, The status changes to closed. When the server receives the final acknowledgement from the client, it shuts down and the status changes to closed. (Note that when a party actively shuts down, it will go through time-wait for a period of time before it can be closed, and the passive shut-off is directly closed after receiving the final confirmation message).

Summarize the above summary of the TCP life cycle state transition diagram as follows

4. Sliding window

The distinction between a simple transport protocol such as TCP and UDP is the quality of the data it transmits. TCP tracks the sending of data, and this data management requires that the protocols have the following two key functions:

Reliability: Ensure that the data really arrives at the destination. If it does not arrive, it can be found and re-transmitted.

Data flow control: manages the sending rate of data so that the receiving device is not overloaded.

To accomplish these tasks, the entire protocol operation is performed around a sliding window confirmation mechanism. TCP detects drops through the sliding window mechanism and adjusts the data transfer rate as the packet drops occur. The first part of this article mentions that the TCP header has a window field that corresponds to the sliding window, which is the end of the receiver telling the originator how many buffers are available to receive the data. The originator can then send the data according to the processing power of the receiver, without causing the receiver to be unable to handle the packet loss phenomenon. To illustrate the sliding window mechanism, let's first look at the data structure of the TCP buffers:

In the picture we can see:

• The end point Lastbyteread points to the read location in the TCP buffer (that is, the data before this position in the buffer has been consumed), where nextbyteexpected points to the last position of the successive packets received. Lastbytercved points to the last position of the received packet, and we can see that some of the data in the middle has not arrived, so there is a blank area of data.
• The lastbyteacked of the originator points to the position where the receiver has been ACK (indicating a successful confirmation), lastbytesent indicates that it has been sent, but has not yet received a successful confirmation ack,lastbytewritten pointing to where the upper application is writing.

So:

• The receiver returns its own Advertisedwindow in the ACK to the originator (the window field that is written to the TCP header mentioned at the beginning of this article) = maxrcvbuffer–lastbytercvd–1;
• The originator will control the size of the sending data according to this window to ensure that the receiver can handle it normally.

Let's take a look at the sender sliding window:

The figure is divided into four parts: (where the black model is the originator window, and the entire black box moves to the right as soon as the confirmation ACK is received, so it becomes a sliding window)

• #1已发送并收到ack确认的数据
• #2已发送但还未收到ack确认的数据.
• #3未发送但收端已准备好接收的数据 (that is, the size of the receiving window-the size of the data that was sent but not received = the current available size of the receiving window) or the data has not been sent in the window.
• #4未发送收端也没有准备好接收的数据或者叫窗口外数据 (the originator is sending the content but the receiver buffer has no space).

The following is a sliding (received 36 ack and emits 46-51 bytes.) Note that this is the case where the Advertisedwindow is not changed in the receiver ACK):

Let's take a look at an illustration of the terminal control originator (the case where the end changes Advertisedwindow):

It is known that the window size of the originator is controlled by the window size of the receiving end, when the receiver receives the data but the data is not consumed, because the data is in the buffer, the remaining available space is reduced, and for the control traffic end, the notification originator is reduced to the Advertisedwindow size. The overall sliding form size shrinks until the originator receives the signal, and the data is no longer sent until it is reduced to 0. When the TCP Header window field is reduced to 0, the originator will use the Zero window Probe (0 window probing) technology for short ZWP, send the ZWP packet to tell received I also keep-alive, the receiver received the ZWP package will report its window size, if several times after the window size or 0, The TCP implementation will send the RST to break the link.

Sliding windows are a key and difficult concept in the TCP protocol, and an animated demo will be inserted below to get a deeper understanding.

Finally, this article quoted a lot of author content plus their own understanding, if necessary to explain, I will promptly deal with.

tcp-about connecting, disconnecting, and sliding windows