TCP's three handshake and four waves (detailed + moving diagram) __tcp

Background Description

Through the introduction of the IP layer in the network model in the previous article, we know that the network layer can realize the communication between the two hosts. But this is not specific, because the entity that is actually communicating is the process in the host, a process in one host exchanging data with a process in another host. Although the IP protocol can send the data message to the destination host, it has not been delivered to the host's specific application process. End-to-end communication should be the communication between application processes.

UDP, do not need to establish a connection before transmitting the data, the host in the far place does not need to give any confirmation after receiving the UDP message. Although UDP does not provide reliable delivery, but it is because of this, save and a lot of overhead, make it faster, such as some of the real-time requirements of higher services, often use UDP. The protocol of corresponding application layer mainly has DNS,TFTP,DHCP,SNMP,NFS and so on.

TCP, which provides connection-oriented services, must establish a connection before transferring data, and release the connection after the data transfer completes. So TCP is a reliable transportation service, but because of this, it inevitably adds a lot of overhead, such as confirmation, flow control, etc. The protocol of corresponding application layer mainly has smtp,telnet,http,ftp and so on. common familiar port number

Application	FTP	TFTP	TELNET	SMTP	DNS	HTTP	SSH	MYSQL
Familiar with ports	21,20	69	23	25	53	80	22	3306
Transport Layer Protocol	Tcp	Udp	Tcp	Tcp	Udp	Tcp

Overview of TCP

TCP takes the connection as the most basic object, each TCP connection has two endpoints, which we call a socket, which is defined as a socket for the port number concatenation to the IP address, for example, if the IP address is 192.3.4.16 and the port number is 80, Then the resulting socket is 192.3.4.16:80. The first source and destination ports of the TCP message , each representing 2 bytes, are written to the source and destination ports, and the ordinal number, which is 4 bytes, is numbered sequentially for each byte in the stream of bytes transferred in the TCP connection. For example, the ordinal field value of a message is 301, with a total of 100 fields, and it is clear that the data number of the next message segment (if any) should start at 401, and the confirmation number, which is 4 bytes, is the ordinal number of the first byte of data expected to receive the next message. For example, B receives a message sent by a, whose serial number field is 501 and the data length is 200 bytes, indicating that B correctly received the data from a sent to ordinal 700. Therefore, B expects that the next data number for a is 701, and B sends the confirmation number to 701 in the confirmation segment sent to a; Data migration, which accounts for 4 bits, indicates how far the data of TCP packet is from the beginning of TCP segment, the reservation is 6 digits, and it is reserved for future use, but it should be 0; Emergency Urg , when Urg=1, indicates that the emergency pointer field is valid. Tell the system that there are urgent data in this segment, confirm Ack, only when ack=1, the confirmation Number field is valid. TCP rules, after the connection is established, all messages must be transmitted to the ACK 1, push PSH, when two application processes for interactive communication, sometimes at one end of the application process want to type a command immediately after receiving the response of the other, this time will be psh=1; reset rst, when rst= 1, indicating that there is a serious error in the TCP connection, the connection must be released, and then the connection will be established, and synchronous SYN will be used to synchronize the serial number when the connection is established. When the syn=1,ack=0 indicates the connection request message, if the connection is agreed, the syn=1,ack=1 should be made in the response message, and the fin should be terminated to release the connection. When the fin=1, indicating that the sender of this message has been sent the data is completed, and ask for release; window, 2 bytes, refers to the notification receiver, send this article you need to have how much space to accept; test and, accounting for 2 bytes, check the header and data these two parts; emergency pointer, 2 bytes, Indicates the number of bytes of the emergency data in this section; options, variable length, define some other optional parameters. Establishment of TCP connections (three-time handshake)

At the beginning, both the client and the server were in a closed state. Actively open the connection for the client, passively open the connection is the server. the TCP server process first creates the transport control block TCB, is ready to accept the connection request of the client process, when the server enters the listen (listening) state, the TCP client process creates the transport control block TCB, and then sends the connection request message to the server, This is the same part syn=1 in the header of the message and select an initial serial number seq=x, at which point the TCP client process enters the syn-sent (sync sent state) state. TCP stipulates that the SYN message segment (syn=1) cannot carry data, but consumes an ordinal number. When the TCP server receives the request message, it sends a confirmation message if it agrees to connect. The confirmation message should be ack=1,syn=1, the confirmation number is ack=x+1, also must initialize a serial number seq=y for itself, at this time, the TCP server process enters the SYN-RCVD (synchronously receives) the state. This message cannot carry data, but it also consumes an ordinal number. After the TCP client process receives confirmation, it also gives confirmation to the server. Confirmation message ack=1,ack=y+1, own serial number seq=x+1, at this time, TCP connection establishes, the client enters established (already established connection) state. TCP stipulates that the ACK segment can carry data, but does not consume the serial number if it is not carrying data. When the server receives the confirmation from the client, it also enters the established state, after which the two sides can begin to communicate.
Why does the TCP client have to send a confirmation at the end?

In a word, the main prevention of the failure of the connection request message suddenly sent to the server, resulting in errors.

If you are using a two-time handshake to establish a connection, suppose there is a scenario where the client sends the first request connection and is not lost, simply because it is too long in the network node, because the TCP client is slow to receive a confirmation message that the server is not received, then resend the message to the server, After that, the client and the server complete the connection through two handshake, transfer the data, and then close the connection. At this time before the detention of the request connection, the network unblocked to the server, the text should be invalid, but, two handshake mechanism will let the client and server to establish a connection again, which will lead to unnecessary errors and waste of resources.

If the use of three times handshake, even if the failure of the newsletter sent over, the server received the failure message and reply to the confirmation message, but the client will not issue a confirmation. Because the server is not receiving a confirmation, the client is aware that the connection is not requested. release of TCP connections (four waves)

After the data transfer is complete, both sides can release the connection. At the very beginning, both the client and the server are in a established state, and then the client shuts down actively and the server shuts down passively. The client process issues a connection release message and stops sending data. Releases the header of the datagram, Fin=1, whose serial number is seq=u (equal to the ordinal of the last byte of the previously transmitted data plus 1), at which point the client enters the fin-wait-1 (terminating wait 1) state. TCP stipulates that fin segments consume an ordinal number even if they do not carry data. The server receives the connection release message, sends out the confirmation message, ack=1,ack=u+1, and takes its own serial number seq=v, at this time, the service end enters the close-wait (closes waits) the state. The TCP server notifies the high-level application process, the client direction to the server is released, at this time in the half shutdown state, that is, the client has no data to send, but the server to send data, the client will still accept. This state continues for a period of time, which is the duration of the entire close-wait state. When the client receives a confirmation request from the server, the client then enters the fin-wait-2 (Terminate wait 2) state, waiting for the server to send a connection release message (before that, the final data sent by the server will be accepted). The server will send the final data, send a connection to the client release message, Fin=1,ack=u+1, because in the half shutdown state, the server is likely to send some data, assuming that the serial number is seq=w, at this time, the server entered the Last-ack (final confirmation) state, Wait for confirmation from the client. The client receives the server's connection to release the message, must issue the confirmation, ack=1,ack=w+1, but own serial number is seq=u+1, at this time, the client enters time-wait (time waits) the state. Note that at this point the TCP connection has not been released, must pass 2∗*MSL (the longest message segment life) after the time, when the client to revoke the corresponding TCB, before entering the closed state. The server immediately enters the closed state as soon as it receives a confirmation from the client. Similarly, when the TCB is revoked, the TCP connection is ended. As you can see, the server ended the TCP connection a little earlier than the client.

Why does the client finally have to wait for 2MSL.

MSL (Maximum Segment Lifetime), TCP allows different implementations to set different MSL values.

First, to ensure that the client sent the last ACK message can reach the server, because this ACK message may be lost, from the point of view of the server, I have sent a fin+ack message request disconnected, the client has not given me a response, should be I sent the request disconnected message it did not receive, The server then sends it again, and the client receives the retransmission message within the 2MSL time period, then gives the response message and restarts the 2MSL timer.

Second, to prevent a similar "failed connection request message segment" mentioned in "three handshake" from appearing in this connection. After the client sends the last acknowledgment message, in this 2MSL time, all segments of the message generated during the duration of the connection will be removed from the network. The request message for the old connection will not appear in this new connection.

Why the connection is three times handshake, close the connection is four times to wave.

When establishing a connection, the server sends the ACK and SYN in a message to the client in a listen state, after receiving the SYN message that establishes the connection request.
When the server receives the fin message from the other side when the connection is closed, only means that the other side no longer send data but also can receive data, and they may not all of the data are sent to each other, so the side can immediately shut down, you can send some data to each other, and then send a fin message to the other side to express their consent to now close the connection, Therefore, the own ACK and fin generally will be developed to send, resulting in one more time. What if a connection has been established, but the client suddenly fails.

TCP also has a live timer, obviously, if the client fails, the server can not be kept waiting, wasted resources. Every time the server receives a client request will reset this timer, the time is usually set to 2 hours, if two hours have not received any data from the client, the server will send a probe message segment, the next every 75 minutes sent once. If you send 10 probe messages in a row and still do not respond, the server thinks the client has failed, and then closes the connection.