互联网中一个基础的面试问题

在学网络的这篇区域，面试中TCP/IP 基本都是必问一个环节，最长见的当属三次握手四次挥手了，绝大多数学习网络的同学可能早已熟记于心了，尤其是学习过CCNA、CCNP的同学，理解更甚，但是有没有逆向的想过，为什么要三次握手，又为什么要四次挥手呢？我猜可能还是有相当一部分同学看到这个问题有点愣住了，因为从来没想过。我就来说一下哈。

TCP为什么需要3次握手，4次断开？

“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。 client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。

（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。

（3） 服务器关闭客户端的连接，发送一个FIN给客户端。

（4） 客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

最后一次的握手，客户端会向服务器回发最后的ACK，但是客户端无法知道这个ACK有没有到达服务器，所以会等待2MSL=2 * 255s。如果这个ACK没有到达服务端，服务端会发现并且会为FIN这个消息超时重传，客户端就会再次发一个ACK，直到服务端真正收到。如果客户端没有收到服务端的FIN，说明服务端已经收到了最后的ACK，正常的关闭连接。

为什么4次断开？

因为TCP有个半关闭状态，假设A.B要释放连接，那么A发送一个释放连接报文给B，B收到后发送确认，这个时候A不发数据，但是B如果发数据A还是要接受，这叫半关闭。然后B还要发给A连接释放报文，然后A发确认，所以是4次。

在tcp连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢。原因是因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。

其实道理也很简单，仔细的想想，确实是那么回事，也就那样吧，谜团解开后是不是觉得也没啥，第一次看的就当学习，第二次+看的同学就当复习了吧。