TCP三次握手与四次挥手

TCP特性

• ACK：TCP协议规定，只有ACK=1时有效，且连接建立后所有发送报文的ACK必须为1；
• SYN：连接建立时用来同步序号。
  • 当SYN=1，ACK=0时，表明这是一个连接请求报文，对方若同意建立连接，则应该在响应报文中使用SYN=1，ACK=1，因此，SYN=1就表示这是一个链接请求或连接接收报文；
• FIN：用来释放一个链接。当FIN=1时，表明此报文段发送方的数据已经发送完毕，并要求释放连接；

TCP面向连接的协议

TCP提供的是一种可靠的数据流服务，数据可能被拆分后发送，因此采用超时重传机制和应答确认机制是组成TCP可靠重传的关键设计；

RTT：round-trip-time，每次请求和响应的响应时间；会根据最近一段时间的实际网络情况请求响应时间计算最新的rtt；

• 序列号：序列号用来判断哪些报文需要发送，比如某次数据包被拆分为3个数据包发送，分别为包1、包2、包3，其中包1、包2服务端已经响应成功，但是在超时响应时间之后，包3一直没有响应，此时客户端会将seq_no设置为上次发送包3时的值，重新发送包3的内容，从而避免发送重复数据的目的；
• 流量控制：如果服务端处理数据能力不足时，服务端会同步给客户端在滑动窗口之内，最多可以接收多少个数据报文；客户端自己限流发送；
• 全双工：客户端和服务端同一时刻可以同时发送和接收数据；
  • mysql是应用层的半双工

TCP的三次握手

• 第一次握手：客户端向服务端发送一个请求连接的报文段，SYN=1 seq=c，客户端发送完报文之后，进入SYN_SENT状态；
• 第二次握手：服务端收到SYN报文段，会对SYN报文段进行确认校验，SYN=1 ACK=1 seq=r ack=c+1，发送响应报文后，进入SYN_RECV状态；
• 第三次握手：客户端收到服务端报文段，设置ACK=1 seq=c+1 ack=r+1，客户端发送报文后，并进入ESTABLISHED状态；
  • 服务端收到客户端第三次握手响应之后，进入ESTABLISHED状态；

为什么要设置为三次握手？

“已失效的连接请求报文段”场景：

   client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。

        假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”，防止了服务器端的一直等待而浪费资源。

TCP建立连接，通过三次握手能防止历史连接的建立，减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能保证数据包不重复，不丢序和按序传输。
不使用「两次握手」和「四次握手」的原因：

• 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
• 「四次握手」：理论上三次握手可以建立可靠的连接通道，无需再最近其他握手次数；

第三次握手失败了怎么办?

• 服务端：

第三次的ACK在网络中丢失，那么服务端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便客户端重新发送ACK包。
如果重发指定次数之后，服务端仍然未收到客户端的ACK应答，那么一段时间后(大概64s)，服务端会给客户端发送RTS报文(连接重置)，并进入CLOSED状态，防止SYN洪泛攻击，客户端收到RTS报文后，会关闭连接；

• 客户端：

客户端认为这个连接已经建立，如果客户端向服务端发送数据，服务端将以RST包（Reset，标示复位，用于异常的关闭连接）响应。此时，客户端知道第三次握手失败。

SYN洪泛攻击

• 定义：通过网络服务所在的端口发送大量伪造原地址的攻击报文，发送到服务端，造成服务端上的半开连接队列被占满，从而阻塞其他用户进行访问；
• 原理：
  • 攻击者客户端利用伪造的IP地址向服务端发送请求(第一次握手)，而服务端的响应(第二次握手)的报文将永远没有真实的客户端进行响应，此时服务端会持续等待伪造的客户端发送回来的响应(第三次握手)，实际上因为这些伪造的第一次握手请求，都是伪造的，根本不会有第三次握手响应，但是服务端在等待这种半开连接过程中消耗了实际处理资源，如果有大量的这种链接，服务端资源将会被耗尽，从而达到攻击目的；
• 解决方案：
  • 无效链接监控释放
  • 延缓TCB分配
  • 防火墙：防火墙确认IP是有效的才会将链接发送后后端；

TCP四次挥手

• 定义：某一端(客户端或服务端)需要结束断开连接，需要进行四次分手；

为什么需要四次挥手？

TCP是双全工(即客户端和服务端可以互相发送和接收请求)，所有需要双方都确认关闭连接；

• 当主机1发出FIN报文时，表示主机1已经没有数据要发送了，主机1通知主机2，它的数据全部发送完毕；此时主机1还是可以接收来自主机2的数据；
• 当主机2返回ACK报文段时，表示主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1；
• 当主机2也发送了FIN报文段时，表示主机2也没有数据要发送了，就会通知主机1，它也没有数据要发送了；
• 之后主机1和主机2就会关闭当前TCP连接；

连接问题

有很多的 IOT 设备与服务端建立连接，当增加设备并发请求变多，TCP连接数在接近1024个时，可用TCP连接数会降到200左右并且无法建立新连接，而且分析应用服务的GC和内存情况均未发现异常？

TCP 三次握手，给我长脸了噢-腾讯云开发者社区-腾讯云