TCP建立连接的三次握手和断开连接的四次挥手

1.连接前的准备
服务端：
分配文件描述符–>绑定–>监听–>阻塞等待客户端连接。
客户端：
分配文件描述符–>发起连接请求–>阻塞等待服务器应答。
2.三次握手
第一次握手：主机A发送同步报文段（SYN）请求建立连接。

第二次握手：主机B听到连接请求，就将该连接放入内核等待队列当中，并向主机A发送针对SYN的确认ACK，同时主机B也发送自己的请求建立连接（SYN）。

第三次握手：主机A针对**主机B**SYN的确认应答ACK。

3.四次挥手
第一次挥手：当主机A发送数据完毕后，发送FIN结束报文段。

第二次挥手：主机B收到FIN报文段后，向主机A发送一个确认序号ACK（为了防止在这段时间内，对方重传FIN报文段）。

第三次挥手：主机B准备关闭连接，向主机A发送一个FIN结束报文段。

第四次挥手：主机A收到FIN结束报文段后，进入TIME_WAIT状态。并向主机B发送一个ACK表示连接彻底释放。

 

4.为什么是三次握手？
如果是2次
①当客户端发出一个请求报文段并没有丢失，而是滞留在了某个网络节点，过了好长时间才发送到服务端，此时服务端建立连接。但是由于现在客户端并没有发出连接请求，因此不会理睬服务端的确认，而服务端以为新的连接产生，服务端的好多资源被白白浪费。
②当确认应答ACK总是丢失时，客户端以为服务端没有连接，它将会不断地重新请求连接，而服务端会连接大量的无效连接，给服务器增加维护成本，服务器很容易受到SYN洪水攻击。
如果是3次
就算客户端发送的ACK丢失，也不影响服务端，客户端不断重发，总会连接成功。三次握手相当于将安全问题抛给了客户端，对服务端影响很小。
如果是4次
3次已经很好的解决了，没有必要4次，况且4次也会造成2次握手的问题。1.为什么是三次握手？
如果是2次
①当客户端发出一个请求报文段并没有丢失，而是滞留在了某个网络节点，过了好长时间才发送到服务端，此时服务端建立连接。但是由于现在客户端并没有发出连接请求，因此不会理睬服务端的确认，而服务端以为新的连接产生，服务端的好多资源被白白浪费。
②当确认应答ACK总是丢失时，客户端以为服务端没有连接，它将会不断地重新请求连接，而服务端会连接大量的无效连接，给服务器增加维护成本，服务器很容易受到SYN洪水攻击。
如果是3次
就算客户端发送的ACK丢失，也不影响服务端，客户端不断重发，总会连接成功。三次握手相当于将安全问题抛给了客户端，对服务端影响很小。
如果是4次
3次已经很好的解决了，没有必要4次，况且4次也会造成2次握手的问题。