TCP (Transmission Control Protocol) is a connection-oriented protocol , which means that before sending and receiving data, a connection must be established with the other party.
A TCP connection must go through three "dialogues" to be established. The process is very complicated. I will only briefly describe the simple process of these three dialogues: host A sends a connection request packet to host B: "I want to send you data. , can you?", this is the first conversation; host B sends a data packet to host A that agrees to connect and requires synchronization (synchronization is two hosts, one is sending, the other is receiving, coordinating work): "Yes, what are you doing? When to send?", this is the second dialogue; host A sends another data packet to confirm the synchronization of host B's request: "I will send it now, you can continue!", this is the third dialogue. The purpose of three "conversations" is to synchronize the sending and receiving of data packets. After three "conversations", host A sends data to host B formally.
Information to know:
ACK : The TCP protocol stipulates that it is only valid when ACK=1, and it also stipulates that the ACK of all sent messages after the connection is established must be 1
SYN (SYNchronization): Used to synchronize the sequence number when the connection is established. When SYN=1 and ACK=0, it indicates that this is a connection request message. If the other party agrees to establish a connection, it should set SYN=1 and ACK=1 in the response message. Therefore, setting SYN to 1 indicates that this is a connection request or connection acceptance message.
Illustration of three-way handshake:
First, the client sends a request to connect, that is, SYN=1 ACK=0 (please see the introduction of the header field). TCP stipulates that data cannot be carried when SYN=1, but a sequence number is consumed, so it declares that its sequence number is seq=x
Then the server confirms the reply, that is, SYN=1 ACK=1 seq=y, ack=x+1, and then the client confirms again, but does not need SYN, then it is ACK=1, seq=x+1, ack=y+1.
Then the connection is established, why do you need to do a three-way handshake (two confirmations) .
The establishment of the three-way handshake is mainly because A sends another confirmation, so why does A confirm it again, mainly to prevent the failed connection request segment from being suddenly transmitted to B, resulting in an error.The so-called "invalid connection request message" is generated in this way. Under normal circumstances, A sends a connection request, but does not receive an acknowledgement because the connection message request is lost, so A retransmits the connection request and later receives the request. , and received the confirmation, established the connection, and released the link after the data transmission was completed. A sent a total of two connection request segments, the first one was lost, the second one reached B, and there was no "defunct connection" Request message segment", but there are exceptions, the connection segment of the request message sent by A is not lost, but stays at a network node for a long time, so that it is delayed until a certain time after the request is released to reach B, Originally it was a segment that had already expired, but after B received the invalid connection request segment, it mistakenly thought that A re-sent the connection request segment, and sent the confirmation segment to A, agreeing to establish the connection, If there is no three-way handshake, then after B sends the confirmation, the connection is established, and at this time, A does not send the request segment for establishing the connection, so it ignores the confirmation of B, and does not send data to B, but B keeps waiting. A sends data, so many resources of B are wasted. The three-way handshake can prevent this from happening. For example, just now, A ignores B, and will not send confirmation to B, and B cannot receive confirmation from A. Just know that A does not require a connection to be established, and it will not waste resources in vain.
Four waves of hands:
当客户A 没有东西要发送时就要释放 A 这边的连接，A会发送一个报文（没有数据），其中 FIN 设置为1, 服务器B收到后会给应用程序一个信，这时A那边的连接已经关闭，即A不再发送信息（但仍可接收信息）。 A收到B的确认后进入等待状态，等待B请求释放连接， B数据发送完成后就向A请求连接释放，也是用FIN=1 表示， 并且用 ack = u+1(如图）， A收到后回复一个确认信息，并进入 TIME_WAIT 状态， 等待 2MSL 时间。
为什么要等待呢？
为了这种情况： B向A发送 FIN = 1 的释放连接请求，但这个报文丢失了， A没有接到不会发送确认信息， B 超时会重传，这时A在 WAIT_TIME 还能够接收到这个请求，这时再回复一个确认就行了。（A收到 FIN = 1 的请求后 WAIT_TIME会重新记时）
另外服务器B存在一个保活状态，即如果A突然故障死机了，那B那边的连接资源什么时候能释放呢？ 就是保活时间到了后，B会发送探测信息， 以决定是否释放连接
为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。