三次握手与四次挥手 tcp协议特点 tcp状态转移图 TIME_WAIT 抓包

讲解

三次握手

图示理解

三次握手发生在客户端执行 connect()的时候，该方法返回成功，则说明三次握手已经建立。三次握手示例图如下

讲解

SYN：表示请求建立一个连接

收发的都是tcp的报文

客户端执行connect的时候，执行三次握手，一旦成功，握手就结束了

listen(sockfd,5)

5表示已完成三次握手队列的大小

四次挥手

图示理解

发生在客户端或服务端执行 close()关闭连接的时候，示例图如下

理解

FIN：通知对方本端要关闭连接了

ACK是确认收到信息表示确认号是否有效

四次挥手可以划分成三次

为什么ACK和FIN没有放一起，因为收到FIN,我必须马上回复收到ACK,我也可以马上关闭，这样，我就一起发送ACK FIN

如果我不想此时关闭，不能一起发送，就要分开发送 ACK FIN,FIN不能随便发，只有执行close才能发

tcp协议特点

面向连接的可靠的流式服务

面向连接是通过三次握手建立连接，四次挥手断开连接

可靠性

应答确认超时重传发送的数据没有接收到确认信息，就一直在缓冲区留着

乱序重拍

滑动窗口流量控制

流式服务

send("ee") send("eee"),两个send放在一个缓冲区，用netstat可以查看缓冲区的数据

tcp状态转移过程

总图

三次握手主动发起者是客户端

四次挥手状态转移过程

客户端和服务器都可以，主动关闭的一端会变成TIME_WAIT状态

三次挥手状态转移过程

客户端一发FIN,服务器就发回来了FIN，会同时关闭，也是四次挥手，两边都变成了TIME_WAIT状态

谁先close，谁就是主动关闭，

connect完成就是三次握手结束，建立了连接

established就是完成了三次握手状态

四次挥手中

先关闭的一端，变成了TIME_WAIT状态，会保持两分钟时间就会消失，

TIME_WAIT状态存在的原因

TIME_WAIT状态存在的原因有两点:

可靠地终止TCP连接。

不能保证客户端最后回复给服务器的报文段7 ACK一定能到达对方，可能会丢数据，如果丢了，服务器会重新发送FIN，因此客户端需要停留在TIME_WAIT状态以处理重复收到的结束报文段（即向服务器发送确认报文段)。否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，因为它期望的是一个像TCP报文段7那样的确认报文段。

如果没丢，服务器不会发送

保证让迟来的TCP报文段有足够的时间被识别并丢弃。

在Linux系统上，一个TCP端口不能被同时打开多次（两次及以上)。当一个TCP连接处于TIME_WAIT状态时，我们将无法立即使用该连接占用着的端口来建立一个新连接。反过来思考，如果不存在TIME_WAIT状态，则应用程序能够立即建立一个和刚关闭的连接相似的连接（这里说的相似，是指它们具有相同的IP地址和端口号)。这个新的、和原来相似的连接被称为原来的连接的化身〈incarnation)。新的化身可能接收到属于原来的连接的、携带应用程序数据的TCP报文段（迟到的报文段)，这显然是不应该发生的，另外，因为TCP报文段的最大生存时间是MSL，所以坚持2MSL时间的TIME_WAIT状态能够确保网络上两个传输方向上尚未被接收到的、迟到的TCP报文段都已经消失（被中转路由器丢弃)。因此，一个连接的新的化身可以在2MSL时间之后安全地建立，而绝对不会接收到属于原来连接的应用程序数据，这就是TIME_WAIT状态要持续2MSL时间的原因。

连接状态的一个测试

只运行服务器，查看连接状态，只有一个监听套接字

与服务器建立连接,都是完成三次握手的状态

关闭服务器，查看连接状态

现在关闭客户端，挥手结束，在两分钟内查看连接状态，服务器变成了TIME_WAIT状态，

此时，再次运行服务器，bind err，因为目前还占用6000端口，等待几分钟，就能再次运行服务器。

一个面试题：

局域网内，一个客户端，一个服务器，建立了连接，拔掉网线，关闭服务器，再重启服务器，再插上网线，此时，服务器和客户端出于什么状态

分析：

拔掉网线，接收不到数据，但是，不影响连接本身，关闭服务器，就会发送FIN，由于拔掉了网线，客户端就收不到FIN,自己结束，最后，重启服务器，插入网线，从始至终，客户端没有收到服务器的任何信息，客户端仍然在完成三次握手状态，对于服务器，此时只有监听套接字，处于listen状态，如果客户端发信息，连上了网线，就能收信息，收到的序列号不对，就RST，让重新建立连接，