通过抓包对TCP的三次握手及三次挥手剖析

1.TCP为什么需要三次握手？

tcp是面向连接的，可靠的

2.三次握手过程

1）第一握手

客户端将请求SYN设置为1
携带一个随机数seq=2647872859放送一个请求到服务端 。客户端接入SYN_SENT状态，等待服务端确认

2）第二握手

服务端收到数据包后有标志位SYN=1知道客户端请求建立连接，服务器将SYN和ACK都置为1，ack=2647872860随机产生一个值seq=2058361828,并将该数据包发送给客户端以确认连接请求，服务端进入SYN_RCVD状态

3）第三握手

客户端接收到请求后，检查ack是否为seq+1 ACK是否为1，如果正确则将标志位ACK置为1，ack=seq+1,并将数据包发送给服务端，服务端检查ack是否为seq+1,ACK是否为1.如果正确则建成功客户端和服务端进入TABLISHED状态，完成第三次握手，接下来客户端和服务端就开始传输数据了。

3.TCP为什么需要四次分手

由于 TCP 连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当甲方 完成数据发送任务后，发送一个 FIN 给乙方来终止这一方向的连接，乙方收到一个 FIN 只是 意味着不会再收到甲方数据了，但是乙方依然可以给甲方发送数据，直到这乙方也发送了FIN 给甲方。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

4.TCP四次分手过程

第二次和第三次被进行了合并

1)第一次分手

某个应用进程首先调用 close，我们称该端执行主动关闭（active close)。该端的 TCP于是发送一个 FIN 分节，表示数据发送完毕，应用进程进入 FIN-WAIT-1（终止等待 1）状态。

1)第二次分手

接收到这个 FIN 的对端执行被动关闭(passive close)，发出确认报文。这个 FIN 由 TCP确认。因为 FIN 的接收意味着接收端应用进程在相应连接上再无额外数据可接收。接收端进入了CLOSE-WAIT（关闭等待）状态，这时候处于半关闭状态，即主动关闭端已经没有数据要发送了，但是被动关闭端若发送数据，主动关闭端依然要接受。这个状态还要持续一段时间，也就是整个 CLOSE-WAIT 状态持续的时间。主动关闭端收到确认报文后进入 FIN-WAIT-2

（终止等待 2）状态。

1)第三次分手

一段时间后，被动关闭的应用进程将调用 close 关闭它的套接字。这导致它的 TCP 也发送一个 FIN。

1)第四次分手

接收这个最终 FIN 的原发送端 TCP（即执行主动关闭的那一端）确认这个 FIN 发出一个确认 ACK 报文，并进入了TIME-WAIT（时间等待）状态。注意此时 TCP 连接还没有释放，必须经过 2∗MSL（最长报文段寿命/最长分节生命期 max segement lifetime，MSL 是任何 IP数据报能够在因特网中存活的最长时间，任何 TCP 实现都必须为 MSL选择一个值。RFC1122[Braden 1989]的建议值是 2 分钟，不过源自 Berkelcy 的实现传统上改用 30秒这个值。这意味着 TIME_WAIT 状态的持续时间在 1 分钟到 4 分钟之间）的时间后，当主动关闭端撤 销相应的 TCB 后，才进入CLOSED 状态

5.TCP会遇到的问题

1）TCP 的三次握手的漏洞 -SYN 洪泛攻击

TCP 三次握手中是有一个缺陷的，就是如果我们利用三次握手的缺陷进行攻击。 这个攻击就是 SYN洪泛攻击。三次握手中有一个第二次握手，服务端向客户端应答请求， 应答请求是需要客户端 IP 的，攻击者就伪造这个IP，往服务器端狂发送第一次握手的内容， 当然第一次握手中的客户端 IP 地址是伪造的，从而服务端忙于进行第二次握手但是第二次握手当然没有结果，所以导致服务器端被拖累，死机。 当然我们的生活中也有可能有这种例子，一个家境一般的 IT 男去表白他的女神被拒绝了，理由是他家里没矿，IT 男为了报复，采用了洪泛攻击，他请了很多人伪装成有钱人去表 白那位追求矿的女神，让女生每次想交往时发现表白的人不见了同时还联系不上了。 面对这种攻击，有以下的解决方案，最好的方案是防火墙。

2）为什么需要 TIME-WAIT 状态？

TIME_WAIT 状态存在的原因有两点 1、可靠的终止 TCP 连接。 2、保证让迟来的 TCP 报文有足够的时间被识别并丢弃。 根据前面的四次握手的描述，我们知道，客户端收到服务器的连接释放的 FIN 报文后， 必须发出确认。如最后这个 ACK 确认报文丢失，那么服务器没有收到这个 ACK 确认报文， 就要重发 FIN 连接释放报文，客户端要在某个状态等待这个 FIN 连接释放报文段然后回复确 认报文段，这样才能可靠的终止 TCP 连接。 在 Linux 系统上，一个 TCP 端口不能被同时打开多次，当一个TCP 连接处于 TIME_WAIT 状态时，我们无法使用该链接的端口来建立一个新连接。反过来思考，如果不存在 TIME_WAIT状态，则应用程序能过立即建立一个和刚关闭的连接相似的连接（这里的相似，是指他们具 有相同的 IP 地址和端口号）。这个新的、和原来相似的连接被称为原来连接的化身。新的 化身可能受到属于原来连接携带应用程序数据的 TCP 报文段（迟到的报文段），这显然是不 该发生的。这是 TIME_WAIT 状态存在的第二个原因。