TCP三次握手详解及释放连接过程(“三次握手”和“四次挥手”)

蔚落 2022-05-17 13:25 180阅读 0赞

TCP三次握手详解及释放连接过程(“三次握手”和“四次挥手”)  
TCP在传输之前会进行三次沟通，一般称为“三次握手”，传完数据断开的时候要进行四次沟通，一般称为“四次挥手”。  
TCP的传输连接分为3个阶段,连接建立(三次握手),数据传送和连接释放(四次挥手)。  
TCP传输连接的管理就是使传输连接建立和释放都能正常的进行。

两个序号和三个标志位：  
（1）序号：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。  
（2）确认序号：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。  
（3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：  
（A）URG：紧急指针（urgent pointer）有效。  
（B）ACK：确认序号有效。  
（C）PSH：接收方应该尽快将这个报文交给应用层。  
（D）RST：重置连接。  
（E）SYN：发起一个新连接。  
（F）FIN：释放一个连接。

需要注意的是：  
（A）不要将确认序号ack与标志位中的ACK搞混了。  
（B）确认方ack=发起方req+1，两端配对。

TCP三次握手(重点)：  
最开始的时候,客户端和服务器都是处于关闭（CLOSED）状态,主动打开连接的是客户端,被动打开连接的是服务器。  
准备工作:  
服务器必须准备好接受外来的连接,这通常通过调用socket,bind和listen这三个函数来完成,称之为被动打开。  
TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。  
在第一次握手中，客户A通过调用connect发起主动打开，客户端向服务器发出连接请求的TCP报文段，将标志位SYN置为1，随机产生一个序列号，并将该数据包发送给服务器B；客户进入SYN\_SENT状态,等待server的确认。  
第二次握手中，服务器B收到数据包后，由标志位为1知道客户请求建立连接，服务器B将标志位SYN和ACK都置为1，随机产生一个序列号seq，将该数据包发送给服务器，服务器进入SYN\_SENT状态，等待客户的确认。  
第三条握手中，客户A收到确认消息后，检查序列号ack以及标志位ACK是否为1，若满足要求，则将该数据报发送给服务器，服务器在检查序列号ack以及标志位ACK是否为1，若满足要求，则建立连接，完成三次握手；随后服务器和客户之间就可以传输数据了。

SYN攻击：  
在三次握手过程中,Server发送SYN-ACK之后,收到Client的ACK之前的TCP连接称为半连接,此时Server处于SYN\_RCVD状态,当收到ACK后,Server转入ESTABLISHED状态,SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server回复确认包,并等待Client的确认,由于源地址是不存在的,因此,Server需要不断重发甚至超时,这些伪造的SYN包将占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络堵塞甚至系统瘫痪。  
SYN攻击是一种典型的DDOS攻击,检测SYN攻击的方式很简单,即当Server上有大量半连接状态且源地址是随机的,则可以断定遭到了SYN攻击了。

--------------------

TCP的四次挥手  
所谓的四次挥手即终止TCP连接,就是指断开一个TCP连接时,需要客户端和服务端总共发送4个包以确认连接断开,在socket编程中,这一过程由客户端或服务器端任一方执行close来触发。  
数据传输完毕,双方都可释放连接,最开始的时候,客户端和服务器端都是处于ESTABLISHED状态,然后客户端主动关闭,服务器端被动关闭。

由于TCP连接是全双工,因此,每个方向都必须要单独进行关闭,这一原则是当完成数据方任务后,发送一个FIN来终止这一方向的连接,收到一个FIN知识意味着这一方向上就没有数据流了,即不会再收到数据了,但是在这个TCP连接上 仍然能够发送数据,直到这一方向也发送了FIN,首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭。  
第一次挥手：客户端Client发送一个FIN，用来关闭客户Client到服务器Server的数据传送，客户Client进入FIN\_WAIT\_1状态。  
TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。  
第二次挥手：服务器Server收到FIN后，发送一个标志位ACK给客户Client，其确认序号ack为收到序号+1（与SYN相同，一个FIN占用一个序号），服务器Server进入CLOSE\_WAIT状态。  
TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。  
第三次挥手：客户端收到服务器的确认请求之后,此时,客户端就进入FIN\_WAIT\_2状态,等待服务器发送连接并释放报文(在这之前还需要接受服务器发送的最后的数据)，服务器Server发送一个FIN，用来关闭服务器Server到客户Client的数据传送，服务器Server进入LAST\_ACK状态。  
第四次挥手：客户Client收到FIN后，进入TIME\_WAIT状态(注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。)，接着发送一个标志位ACK给服务器Server，确认序号为收到序号+1，服务器只要收到客户端发出的确认，服务器Server进入CLOSED状态，完成四次挥手。可以看到，服务器结束TCP连接的时间要比客户端早一些。

上面是一方主动关闭,另一方被动关闭的情况,实际中还会出现同时发起主动关闭的情况,具体流程如下

--------------------

关于三次握手四次挥手的常见的面试题  
1.三次握手的流程(四次挥手的流程)  
2.为什么建立的是三次握手,关闭是四次挥手  
建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。  
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。  
3.三次握手过程中,客户端最后为什么还要发送一次确认  
主要防止已经失效的连接请求报文突然又传送到服务器,从而产生错误  
如果使用的是两次握手连接,假设客户端发送了第一个请求连接并且没有丢失,只是因为在网络节点中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接,此时从前滞留的那一次请求连接,网络通畅之后到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费  
如果采用的是三次握手,就算是那一次的失效的报文再传送过去,服务器端接收到那条失效的报文并且回复了确认报文,但是客户端不会再次发出确认,由于服务器收不到确认,就知道客户端并没有请求连接  
4.TCP的四次挥手中为什么客户端最后还要等待2MSL  
MSL(Maximum Segment Lifetime)TCP允许不同的实现可以设置不同的MSL值  
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。  
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。  
5.如果已经建立连接,但是客户端突然出现故障怎么办?  
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。