TCP三次握手和四次挥手的理解及面试题

转载：https://www.cnblogs.com/jainszhang/p/10641728.html

在了解三次握手和四次挥手前，先了解TCP报文中包含了哪些内容：

1. TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP链接。TCP在发送数据前必须建立连接，就是需要保存对方的信息(如：IP port)。
2. 报文主要段意思：

序号	表示发送的数据字节流，确保TCP传输有序，对每个字节编号
确认号	发送方期待接收的下一列序号，接收成功后的数据字节序列加1。只有ACK=1时才有效。
ACK	确认序号的标志，ACK=1表示确认序号有效，ACK=0表示报文中不含确认序号信息。
SYN	连接请求序号标志，用于建立连接，SYN=1表示请求连接。
FIN	结束标志，表示释放连接，为1表示关闭本方数据流。

三次握手过程，建立TCP连接时客户端和服务器共发送三个包：

1. 第一次：客户端发送初始序号x和syn=1请求标志。
2. 第二次：服务器发送请求标志syn，发送确认标志ACK，发送自己的序号seq=y，发送客户端确认序号ack=x+1。
3. 第三次：客户端发送ACK确认号，发送自己的序号seq=x+1，发送对方的确认号ack=y+1。

三次握手过程分析：

1. 客户端发送请求到服务器，服务器知道客户端发送，自己接收正常。syn=1，seq=x.。
2. 服务器发送给客户端，客户端知道自己发送接收正常，服务器发送接收正常。ACK=1，ack=x+1，SYN=1，seq=y。
3.  客户端发送给服务器：服务器知道客户端接收发送正常，自己接收发送正常seq=x+1，ACK=1，ack=y+1。

从上面分析可看出，握手两次达不到让双方都得出对方，自己接收发送正常的结论。

四次挥手过程：

1. 第一次挥手：客户端释放FIN=1，自己序列号seq=u，进入FIN-WAIT-1状态。
2. 第二次挥手：服务器收到客户端的信号后，发出ACK=1确认标志和客户端的确认号ack=u+1，自己的序列号seq=v，进入CLOSE-WAIT状态。
3. 第三次挥手：客户端收到服务器确认的结果后，进入FIN-WAIT-2状态。此时服务器释放发送FIN=1的信号，确认标志ACK=1，确认序号ack=u+1，自己序号seq=w，服务器进入LAST-ACK状态(最后确认态)。
4. 第四次挥手：客户端收到回复后，发送确认ACK=1，ack=w+1，自己的seq=u+1，进入TIME-WAIT。客户端经过两个最长报文段寿命后，客户端CLOSE，服务器收到确认后立刻进入CLOSE状态。

四次挥手过程分析：

• 第一次：客户端请求断开FIN，seq=u
• 第二次：服务器确认客户端的断开请求ACK，ack=u+1，seq=v
• 第三次：服务器请求断开FIN，seq=w ACK ack=u+1
• 第四次：客户端确认服务器的断开ACK，ack=w+1，seq=u+1

面试问题：

为什么三次握手和四次挥手？

• 三次握手时，服务器同时把ACK和SYN一起发送到客户端那里；
• 四次挥手时，当收到对方的FIN报文时，仅仅表示对方不在发送数据，但还能接收数据，己方是否现在关闭发送数据通道，需要上层应用来决定，因此，己方FIN和ACK一般会分开来发送。

为什么客户端wait-time需要经过2MSL(最大报文生存时间)才能返回CLOSE状态?

• 客户端需要保证最后一次发送的ACK报文到服务器，如果服务器未收到，可以请求客户端重发，这样客户端还有时间再发送，重启2MSL计时。
• 虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态，但我们必须假设网络是不可靠的，有可能最后一个ACK丢失，所以WAIT-TIME是用来重新发送丢失的ACK报文的。在client发送最后的ACK回复，但该ACK有可能丢失。SERVER如果没有收到ACK，将会不断重复发送FIN片段。所以client不能立即关闭，它必须确认SERVER收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT。Client会在发送ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2msl的时间，如果在该时间内再次收到FIN，Client会重新发送ACK，并再次等待2MSL。所谓的2MSL是两倍的MSL(Maxium Segment LifeTime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果知道2MSL，Client没有再次收到FIN，那么Client推断ACK已经被接收，则结束TCP连接。

为什么不能两次握手进行连接？

• 三次握手完成两个重要功能，既要做好双发发送数据的准备工作(双方都知道彼此已准备好)，也允许双方就序列号进行协商，这个序列号在握手的过程中被发送和确认。
• 把三次握手改成两次握手，是可能发送死锁的。ex：考虑计算机S和C之间的通信，假定C给S发送了一个请求分组，S收到了这个分组，并发送确认应答分组。按照两次握手的协定，S认为连接已经建立成功了，可以开始发送数据分组了，可是C在S应答分组在传输中被丢失的情况下，C将不知道S是否准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到了自己的连接请求分组。在这种情况下，C认为连接还未成功，将忽略S发来的任何数据分组，只等待连接确认应答分组，而S在发出的分组超时后，重复发送同样的分组，这样就形成了死锁

如果已经建立了连接，客户端突然出现了故障怎么办？

• TCP还设计了一个保活计时器，显然，客户端如果出现了故障，服务器不能一直等待下去，白白浪费资源。服务器每收到一次客户端的请求后，都会复位这个计时器，时间通常设置为2个小时，若两个小时还没收到客户端的任何数据，服务器会发送一个探测报文段，以后每隔75s发送一次，若一连发送10个没有响应，服务器就会认为客户端出现了故障，接着就会关闭连接。