day42-1 TCP three-way handshake protocol fourth wave

TCP protocol

Data from the client -> server protocol

Three-way handshake

For example, go to the server to download the video between the client and server must have access, that is, three-way handshake

The client and server before the connection is in a closed state.

Three-way handshake process (A: Client, B: server)

1. A initiates a connection request packet (SYN), do not carry data to B (I want you to connect)
2. After B receives the connection request packet, as agreed to establish the connection, it sends an acknowledgment message to A. (Well, are you sure you want to connect it)
3. After receiving confirmation B of A, B again be given an acknowledgment packet (yes, I'm sure you are connecting)

connection succeeded

common problem

• Why A final confirmation of it should be sent once, twice shaking hands can do?

A: The main is to prevent expired connection request segment suddenly transferred to a B, because produce errors

As A connection request is issued, but the connection request packet loss does not receive confirmation, then A retransmit a connect request (like you and point a mouse). Later received a confirmation, a connection is established. After the data transmission is completed, the connection is released. A total of two then sends a connection request packet segments, wherein first lost, the second arrival to B, but the first lost segment only certain long stay of the network nodes, connected to the delay after some time before the release hit B , B at this time will mistakenly think that a has issued a new connection request, so they send a confirmation message to the a segment, we agreed to establish a connection. Since no three-way handshake, as long as the B issue, confirm that, to establish a new connection, and this time ignore A confirmation of B does not send data, while the B and A have been waiting to send data, a waste of resources.

• Server-side vulnerable to SYN attacks?

A: server-side resource allocation is assigned when the second handshake, and client resources are allocated upon completion of the three-way handshake, the server vulnerable to SYN flooding attack.

SYN attack is a large number of forged Client ip address does not exist in a short time, and keeps sending SYN packets Server, Server back to confirm the package and wait for Client to determine, but the source address does not exist, and therefore need to continue to retransmit Server until the timeout, the forged SYN packet for a longer period of occupation of the connection queue, leading to the normal SYN requests because the queue is full are discarded, thereby causing network congestion or even system failure.

防范措施：降低主机的等待时间使主机尽快的释放半连接的占用，短时间受到某ip的重复SYN则丢弃后续请求。（所以不要卡了就一直点点点）

四次挥手

比如你不想看视频了，那就要断开和服务端的连接，也就是四次挥手

四次挥手的过程（A：客户端，B：服务端）

1. A向B发送断开连接请求报文（FIN），并停止传输数据（A告诉B我没有数据要发了）
2. B接到请求后，不返回FIN报文（也就是不断开），而是返回一个ACK报头。（B告诉A你的请求我收到了，但是我还没有准备好，还有数据在传输，请你继续等我的消息）
3. B将剩余数据传输完毕之后，把FIN+ACK报头的请求发给A。（B告诉A我所有数据都发完了，可以断开了）
4. A接到请求后就知道可以关闭连接了，但是他还是不相信网络，怕B不知道要关闭，所以发送了ACK且进入一个TIME_WAIT状态，如果B没有没有收到ACK就会重新发送一个ACK，B收到ACK后就断开了连接，而A在2MSL后依然没有收到回复，就知道B已经关闭了，那A也就关闭了。（A告诉B我知道了，断开吧）

　断开TCP连接

常见问题

• 为什么连接的时候是三次握手，而断开却要四次挥手？

答：因为在连接时Server端收到Client的SYN连接请求报文后，可以直接回复SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，因为Server端收到FIN断开请求报文时，因为可能还需要传输数据，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到Server端所有的报文都发送完了，才会把FIN报文发送过去，故而需要四次挥手。

• 为什么Client端需要在TIME-WAIT状态等待2MSL的时间？

答：两个理由：1，保证Client端发送的最后一个ACK报文能够到底B。

​ 2， 防止“已失效的连接请求报文段”出现在下次连接中

1. Client-ACK segment may be lost emitted using a B can not receive the disconnect confirmation sent, found resend B FIN + ACK after a timeout, and A can receive the retransmitted packet within a time 2MSL, A retransmit time is then also, and restarts the timer 2MSL, and finally to ensure that A and B can enter the off state. Immediately release the connection if A does not wait 2MSL time, but sending the ACK segment, then FIN + ACK segment B after the loss can not receive retransmission, so it will not send a confirmation message segment , then B can not enter into the closed state.

• If you have established a connection, but the client suddenly fails how to do?

A: TCP also has a keep-alive timer, apparently, a client if a failure occurs, the server can not keep on waiting, wasted resources. Each time the server receives the client's request will reset the timer set time is usually 2 hours, if two hours has not received any data from the client, the server sends a detection message segment, then every 75 send seconds once. If sending 10 consecutive probe packets still did not respond, the server brought out customers considered a failure, and then they close the connection.

Reproduced in: https: //www.cnblogs.com/lucky75/p/11093660.html