关于三次握手与四次挥手你要知道这些

Posted 2022-10-17 mseddl

TCP的整个连接过程

如果没有基础的话，直接看这张图或者网络上各种文字描述，十分生涩，所以先看懂接下来的握手挥手的图，理解之后，再看这个有限状态机就感觉原来如此简单。

三次握手

握手过程

第一次握手：主机A发送位码为syn＝1，随机产生seq number=x的数据包到服务器，客户端进入SYN_SEND状态，等待服务器的确认；主机B由SYN=1知道A要求建立连接。

第二次握手：主机B收到请求后要确认连接信息，向A发送ack number(主机A的seq+1)、syn=1、ack=1，随机产生seq=y的包，此时服务器进入SYN_RECV状态。

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number(主机B的seq+1)、ack=1，主机B收到后确认seq值与ack=1则连接建立成功。客户端和服务器端都进入ESTABLISHED状态。

三次握手的必要性

1. 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
   
2. 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
   
3. 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收能力，服务器自己的发送能力也正常。

至此，客户端和服务端可以确定双方的接收和发送能力均正常。

第三次握手的必要性

这主要是为了防止已失效的连接请求报文段突然又传送到了服务器端，从而减少服务端的开销。
如果只有两次握手就建立连接会出现这种情况：客户端发出的连接请求报文段在某些网络节点长时间滞留了，以致延误到连接释放以后的某个时间才能到达服务端。本来这是一个早已失效的报文段，但服务端收到此失效的连接请求报文段后，就误认为客户端又发出了一次新的连接请求。于是向客户端发出确认报文段，同意建立连接。由于现在客户端并没有发出建立连接的请求，因此不会处理服务端的确认，也不会向服务端发送数据。但服务端却以为新的连接已经建立了，并一直等待客户端发来数据。 服务端会因此浪费很多了。

如果第三次握手丢失了，客户端服务端会如何处理？

服务端：
该TCP连接的状态为SYN_RECV,并且会根据TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。而Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5。如果重发指定次数之后，仍然未收到客户端的ACK应答，那么一段时间后，服务端自动关闭这个连接。
客户端：
客户端在接收到SYN+ACK包，它的TCP连接状态就为ESTABLISHED（已连接），表示该连接已经建立。那么如果第三次握手中的ACK包丢失的情况下，客户端向服务端发送数据，服务端将以RST包(reset重置)响应，才能感知到服务端的错误。

什么是syn flood攻击

syn flood是一种经典的ddos攻击手段，这里面用到了TCP三次握手存在的漏洞。当服务端接收到SYN后进入SYN-RECV状态，此时的连接称为半连接，同时会被服务端写入一个半连接队列。如果攻击者在短时间内不断的向服务端发送大量的SYN包而不响应，那么服务器的半连接队列很快会被写满，从而导致无法工作。 实现syn flood 的手段，可以通过伪造源IP的方式，这样服务器的响应就永远到达不了客户端(握手无法完成)；当然，通过设定客户端防火墙规则也可以达到同样的目的。对syn flood实现拦截是比较困难的，可以通过启用 syn_cookies 的方式实现缓解，但这通常不是最佳方案。最好的办法是通过专业的防火墙来解决，基本上所有的云计算大 都具备这个能力。

四次挥手

挥手过程

第一次挥手：主机A（可以是客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机B发送一个FIN报文段；此时，主机A进入FIN_WAIT_1状态；这表示主机A没有数据要发送给主机B了。
第二次挥手：主机B收到了主机A发送的FIN报文段，向主机A回一个ACK报文段，Acknowledgment Number为Sequence Number加1，主机A进入FIN_WAIT_2状态；主机B告诉主机A，我也没有数据要发送了，可以进行关闭连接了。
第三次挥手：主机B向主机A发送FIN报文段，请求关闭连接，同时主机B进入CLOSE_WAIT状态。
第四次挥手：主机A收到主机B发送的FIN报文段，向主机B发送ACK报文段，然后主机A进入TIME_WAIT状态；主机B收到主机A的ACK报文段以后，就关闭连接；此时，主机A等待2MSL后依然没有收到回复，则证明主机B已正常关闭，那好，主机A也可以关闭连接了。

主机B发送了FIN-ACK之后，会立即启动超时重传计时器
主机A在发送最后一个ACK之后，会立即启动时间等待计时器

挥手为什么需要四次？

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

RST是什么，为什么会出现

RST 是一个特殊的标记，用来表示当前应该立即终止连接。以下这些情况都会产生RST：

• 向一个未被监听的端口发送数据
• 对方已经调用 close 关闭连接
• 存在一些数据未处理(接收缓冲区)，请求关闭连接时，会发送RST强制关闭
• 某些请求发生了超时

为什么服务器会有大量closewait

半关闭的状态下的服务器连接会处于closewait状态，直到服务器发送了FIN。 那么在应用层则是调用socket.close()会执行FIN的发送，如果服务器出现大量CLOSE_WAIT状态的连接，那么有可能的原因：

• 服务器压力过大，根本来不及调用close
• 存在连接泄露问题(Bug)，服务器未及时关闭连接

四次挥手释放连接时，等待2MSL的意义

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。我们都知道IP头部中有个TTL字段，TTL是time to live的缩写，可译为“生存时间”，这个生存时间是由源主机设置初始值代表一个IP数据包可以经过的最大路由数，每经过一个路由器，它的值就减1，当此值为0则数据报被丢弃，同时发送ICMP报文通知源主机。RFC793中规定MSL为2分钟，但这完全是从工程上来考虑，对于现在的网络，常用值30秒或1分钟。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。

最后，限于笔者经验水平有限，欢迎读者就文中的观点提出宝贵的建议和意见。如果想获得更多的学习资源或者想和更多的是技术爱好者一起交流，可以关注我的公众号『全菜工程师小辉』后台回复关键词领取学习资料、进入前后端技术交流群和程序员副业群。同时也可以加入程序员副业群Q群：735764906?一起交流。