TCP三次握手和四次挥手

一、TCP三次握手

tcp标志位,有6种表示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)

2种号码：Sequence number(顺序号码) Acknowledge number(确认号码)

1. 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
2. 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
3. 第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手

不是三次握手而是两次握手会怎么样？

可能A发送的已经失效的连接i请求报文端突然又传送到了B。如果不采用三次握手，B发出确认就建立了新连接。A并没有发出建立连接的请求，不会理睬B的确认，也不会向B发送数据，B却以为新的运输连接已经建立，并一直等待A发来的数据。B的许多资源就这样浪费了。采用三次握手就不会发生这种现象。

TCP三次握手有什么漏洞

泛洪攻击SYN Flood
SYN Flood利用了TCP协议三次握手的过程来达到攻击的目的。三次握手的第三步中如果服务器没有收到客户端的ACK报文，服务端一般会进行重试，也就是再次发送SYN+ACK报文给客户端，并且一直处于SYN_RECV状态，将客户端加入等待列表。重发一般会进行3~5次，大约每隔30秒左右会轮询一遍等待队列，重试所有客户端；另一方面，服务端在发出SYN+ACK报文后，会预分配一部分资源给即将建立的TCP连接，这个资源在等待重试期间一直保留，服务器资源有限，可以维护的等待队列超过极限后就不再接收新的SYN报文，也就是拒绝建立新的TCP连接。

攻击者伪造大量的IP地址给服务器发送SYN报文，但是由于伪造的IP地址几乎不可能存在，也就不可能从客户端得到任何回应，服务端将维护一个非常大的半连接等待列表，并且不断对这个列表中的IP地址进行遍历和重试，占用了大量的系统资源。服务器资源有限，大量的恶意客户端信息占满了服务器的的等待队列，导致服务器不再接收新的SYN请求，正常用户无法完成三次握手与服务器进行通信。

二、TCP四次挥手

数据传输结束后，通信的双方都可释放连接。

第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，其序号seq=u，它等于前面已经传送过的数据的最后一个字节序号加1。这时Client进入FIN_WAIT_1状态。TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。
FIN=1，seq=u A进入FIN-WAIT-1状态

第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。TCP服务器进程这时应通知高层应用进程，因此从客户端到服务器端这个方向的连接就释放了，这时的TCP连接处于半关闭half-close状态，即客户端A已经没有数据要发送了，但服务器端B若发送数据，客户端A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。

A收到来自B的确认后，就进入FIN-WAIT-2状态，等待B发出的连接释放报文段。

ACK=1，seq=v，ack=u+1，B进入CLOSE-WAIT状态，A进入FIN-WAIT-2状态。

第三次挥手：若B已经没有要想A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。现假定B的序号为w（在半关闭状态B可能又发送了一些数据）。B还必须重复上次已发送过的确认号ack=u+1。这时B就进入LAST-ACK（最后确认）状态，等待A的确认。
A发送：FIN=1，ACK=1，seq=w，ack=u+1 B进入LAST-ACK状态。

第四次挥手：Client收到FIN后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack=w+1，而自己的序号是seq=u+1（根据TCP标准，前面发送过的FIN报文段要消耗一个序号）。然后进入到TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉，必须经过时间等待计时器TIME-WAIT timer设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命。

为什么A在TIME-WAIT状态必须等待2MSL的时间呢？
第一，为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。

第二，防止“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文。

整理自《计算机网络》第6版