三次握手四次挥手

1、三次握手过程

1、（建立之前的准备，不算“握手”）服务端在连接之前被动打开，使用socket(),bind(),listen()三个函数完成，调用之后服务器进程处于listen状态；
2、客户端调用connect申请建立连接，客户TCP使用同步的方式发送一个同步位SYN=1，初始序列号seq=x的报文段，TCP中规定申请建立连接的报文段不能携带数据，但是也会消耗掉一个序列号，申请完之后客户端进入SYN-SENT状态；
3、服务端收到客户端的连接申请请求如果同意建立，则发送确认（ACK=1,ack=y,seq=x+1）,然后TCP服务器处于SYN-RCVD状态；
4、TCP客户端收到确认之后还要给服务端发送确认（ACK=1,ack=y+1，seq=x+1），然后TCP建立成功，双方处于estanblished状态。

2、可以采用二次握手吗

不可以，如果二次握手就建立连接，如果客户端使用connect发起连接申请的报文段因为网络问题在网络中某个节点滞留，将导致延长了一段时间再到达服务端，但是在这之前服务端都没有收到这个申请，也就不会发送确认报文段，服务端就会在一段时间之后再次发送连接申请，假设这次成功了（如果没有成功就继续滞留），服务端就返回确认，连接成功。但是在一段时间之后，之前滞留在网络中的报文段可能到达服务端，服务端就又一次发送确认，并建立连接，但是这个连接是没有用的，服务端的资源白白浪费，并且也不会客户端也不会为这个连接申请断开连接。

3、四次挥手

1、客户端需要断开连接时调用close()申请断开连接，将FIN置为1，seq=u，其中u为之前发送的数据的最后一个字节加1，表示数据发送完成，客户端进入FIN-WAIT-1状态；
2、服务端收到断开申请之后发出确认，ack=u+1，seq=v，其中v是服务端之前发送的数据的最后一个字节加1，然后服务端进入CLOSE-WAIT状态；
这个过程结束之后，整个TCP连接处于半关闭状态，就是说客户端已经没有数据需要发送了，但是服务端可能还是有数据需要发送，客户端还是需要接受，
客户端收到这个确认之后进入FIN-WAIT-2状态，等待服务端发送断开连接；
3、等到服务端已经没有数据需要发送之后，就发送断开连接报文段，FIN=1,seq=w（w与v没有直接联系，因为在此之间，服务端可能又发送了一些数据），ack=u+1，进入LAST-ACK状态，等待确认；
4、客户端收到断开连接之后需要确认，ACK=1,ack=w+1,seq=u+1但是发送确认之前需要等待2MSL（time_wait状态），2MSL为报文最长寿命，通常为两分钟，发送之后进入closed状态；

4、time_wait状态的用处

1、保证断开确认到达服务端
如果这个报文段丢失，服务端没有收到这个确认就会重新发送之前的连接释放报文段，等待的2MSL可以保证客户端收到第二个确认报文段，客户端就知道之前发送的确认丢失了，然后重新发送确认报文段，并重新计时；如果不等待2MSL，客户端发送了确认之后就进入CLOSED状态，如果这个确认丢失，客户端将会一直处于LAST-ACK状态等待这个确认。
2、防止收到已失效的连接请求报文段
在服务端发送完之后，经过2MSL之后，就可以确保本次连接中所有产生的报文段都从网络中消失，这样下一个新的连接中就不会出现这种旧的报文段。

5、这种协议有什么漏洞

如ddos攻击，攻击者伪装成客户端给服务端发送连接请求，而客户端收到后将不会回应确认，服务端没有收到确认就会重试发送请求确认，造成服务端的大量开销。
解决方法：
1、监视半连接和不活动连接，当半连接和不活动连接到达一定数值后，就释放系统资源。
2、延缓TCB分配（SYN cache），之前的服务端一收到连接请求之后就分配TCB。当收到连接请求之后先不急分配TCB，而是先回应一个ACK，并且把之前的连接保存在一个专用的HASH表中，确认是正确连接之后再分配TCB。
3、用一种算法生成sequence number，算法通过对方信息和自己的信息验证正确之后再生成TCB