Why TCP should be three handshake, why TCP is reliable.

Why can't I shake hands twice: (prevents failed connection requests from being routed to server side, resulting in errors)

Suppose you change to a two-time handshake, a connection request sent by the client is stranded on the server, the connection request is invalid, the client is already in the closed state, and the server thinks the client wants to build

A new connection, the client is sent a confirmation segment, and the client side is the closed state, whatever message is received will be discarded. And if it's a two-time handshake, the connection is now established.

The server waits until the client sends the data, wasting a lot of server-side resources.

(glossing: Because the client does not initiate a connection request, the client is in the closed state, and any package is discarded, Shehiren example of this scenario. However, if the server sends a confirmation of this delayed old connection message, and the client calls the Connect function to initiate the connection, the client enters the Syn_send state, when the server's acknowledgement to the delayed old connection message is passed to the client, because the client is already in the Syn_send State, As a result, the client enters the established state, and the server instead discards the duplicate SYN packet sent via the Connect function, as shown in the third diagram. And after the connection is established, the sending packet due to SEQ is discarded by the SYN packet sequence number, and the server receives the serial number is the delay of the old connection SYN message sequence number, causing the server to discard subsequent sent packets)

The main purpose of the three-time handshake is to ensure that the connection is duplex, and that more reliable is ensured by the retransmission mechanism.

Implementation of TCP reliable transmission:

Each end of a TCP connection must have two Windows-a send window and a receive window. The reliable transmission mechanism of TCP is controlled by the sequence number of bytes. All TCP acknowledgements are based on the sequence number rather than on the message segment.
The sent data must be retained before the acknowledgement is received so that it is used when the retransmission is timed out. The sending window is confiscated until the confirmation is fixed, and a new confirmation is received before moving forward.

The send cache is used for temporary storage: the sending application transmits data to the sender's TCP ready to send, and TCP has sent but not yet received the confirmed data.

The receive cache is used to temporarily store data that arrives sequentially, but is not yet read by the receiving application;

Three points must be emphasized:
    1>   A's send window is not always as large as the receive window of B (because there is a time lag).
    2>   The TCP standard does not specify how data that is not ordered to arrive should be handled. This is usually done temporarily in the receive window until the bytes that are missing in the byte stream are received and then sequentially delivered to the upper application process.
    3>   TCP requires the receiver to have the ability to accumulate acknowledgments, which can reduce the transport overhead

TCP Message Format

(1) Serial number: SEQ sequence number, which is 32 bits, is used to identify the byte stream sent from the TCP source end to the destination, which is flagged when the initiator sends the data.
(2) Confirm the serial number: ACK number, accounting for 32 bits, only the ACK mark bit is 1 o'clock, confirm the ordinal field is valid, ack=seq+1.
(3) Sign: A total of 6, namely Urg, ACK, PSH, RST, SYN, FIN, etc., the specific meaning is as follows:
(A) URG: The emergency pointer (urgent pointer) is effective.
(B) ACK: Confirm the serial number is valid.
(C) PSH: The receiving Party should submit this message to the application layer as soon as possible.
(D) RST: Resets the connection.
(E) SYN: Initiates a new connection.
(F) FIN: Release a connection.

It is important to note that:
(A) Do not confuse the ACK ordinal ack with the acknowledgment in the flag.
(B) Confirmation Party ack= Initiator req+1, paired on both ends. Three-time handshake

TCP Three is a TCP connection that establishes a TCP connection that requires a total of 3 packets to be sent by the client server to confirm the establishment of the connection. In socket programming, this process is triggered by the client executing connect, the process is as follows:

(1) First handshake: The client will set the flag bit SYN to 1 (indicating to initiate a connection), randomly generate a value of seq=j, and send the data packets to server,client into the syn_sent state, waiting for the server to confirm.
(2) Second handshake: After the server receives the packet by the flag bit syn=1 knows the client request to establish a connection, the server sets the flag bit SYN and ACK to 1,ack=j+1, randomly generates a value seq=k, and sends the data packets to the client to confirm the connection request , the server enters the SYN_RCVD state.
(3) Third handshake: After the client receives the acknowledgment, checks whether the ACK is j+1,ack 1, and if correct, resets the flag bit ACK to 1,ack=k+1 and sends the data packets to Server,server to check if the ACK is K+1,ack 1, If the connection is successful, the client and server enter the established state, complete three handshake, and then the client and server can start transmitting data.

SYN attack: During
  three handshake, after the server sends Syn-ack, the TCP connection before receiving the ACK of the client is called a half-connection (Half-open Connect), at which time the server is in SYN_RCVD state, when the ACK is received , the server is transferred to the established state. SYN attack is the client in a short period of time to forge a large number of non-existent IP address, and to the server to continuously send SYN packets, the server replies to confirm the package, and wait for client confirmation, because the source address is not present, so the server needs to continue to resend until time-out, These bogus SYN packets take the time to occupy the disconnected queue, causing the normal SYN request to be discarded because the queue is full, causing network congestion and even system paralysis. SYN attack is a typical DDoS attack, the way to detect SYN attacks is very simple, that is, when the server has a large number of semi-connected state and the source IP address is random, you can conclude that a SYN attack, using the following command can be used:
  #netstat-nap | grep Syn_recv

DDoS:
Distributed denial of service (ddos:distributed denial of service) attack refers to the use of client/server technology to unite multiple computers as an attack platform to launch DDoS attacks against one or more targets, Thereby multiplying the power of denial-of-service attacks. Typically, an attacker would use a theft account to install a DDoS master program on a computer, where a set time master will communicate with a large number of agents, and the agent is already installed on many computers on the network. An agent launches an attack when it receives an instruction. With client/server technology, the master program can activate hundreds of agents within seconds.

Wave four times

The so-called four-time wave (Four-way Wavehand) terminates the TCP connection, that is, when disconnecting a TCP connection, the client and the server are required to send a total of 4 packets to confirm the disconnection of the connection. In socket programming, this process is triggered by executing close on either side of the client or service side, as shown in the following diagram:

Because the TCP connection is full-duplex, each direction must be closed separately, the principle is that when a party completes the data sending task, send a fin to terminate the connection in this direction, the receipt of a fin just means that there is no data flow in this direction, no longer receive data, However, the data can still be sent on this TCP connection until fin is sent in this direction. The first party to close will perform the active shutdown, while the other side performs a passive shutdown, as described in the figure above.
(1) First wave: The client sends a fin to turn off the client to server data transfer, the client enters the fin_wait_1 state.
(2) Second wave: After receiving fin, the server sends an ACK to the client, confirming that the sequence number is received sequence number +1 (same as SYN, one fin occupies a serial number), and the server enters the close_wait state.
(3) Third wave: The server sends a fin to shut down the server-to-client data transfer, and the server enters the Last_ack state.
(4) The fourth wave: After the client receives fin, the client enters the TIME_WAIT state, and then sends an ACK to the server, confirming that the serial number is received +1,server enter the closed state, complete four waves.

Why do I need time_wait

The timewait state is also known as a 2MSL wait state.

1) Reliable release of this full-duplex (Full-duplex) connection for TCP

This allows TCP to send the final ACK again in case the ACK is lost (the other end times out and the last fin is sent again). Another result of this 2MSL wait is that the TCP connection will not be used again during the 2MSL wait, defining the connection's socket (the client's IP address and port number, the server's IP address and port number). This connection can only be used after the end of 2MSL.

2) to make the old packet disappear when the network expires

Each specific TCP implementation must select a message segment Maximum lifetime MSL (Maximum Segment Lifetime). It is the maximum time that any message segment is discarded before it is in the network.

Why a connection is a three-time handshake, while closing the connection is a four-time wave.

This is because the server is in the listen state, after receiving the SYN message to establish the connection request, the ACK and SYN are placed in a message sent to the client. When the connection is closed, when the other side of the fin message, only that the other side no longer send the data but also can receive data, we may not all the data are sent to each other, so we can not immediately close, you can send some data to each other, then send fin message to the other side to express consent to now close the connection , therefore, our ACK and fin are generally divided into development send.