计算机网络基础学习——三次握手和四次挥手

很多人一看，唏嘘不已，这么简单的问题，可能不知道吗。但是要全面地解决这个问题还真不是简单的意见事情。大多数人能把三次握手和四次挥手的过程说出来，这个不难（这也是我停留好久的状态，惭愧惭愧）；如果面试官问得深一点，要求把各个时候的状态说出来，那可能要难倒一片求职者了；如果再问，为什么四次挥手的最后还要再等待2MSL，那又有几个人能答上来呢；其实还有一个最终问题，为什么建立连接的时候是三次握手，而关闭连接时候却是四次挥手呢。能把这些问题都答上来才是让面试官满意的求职者。

三次握手过程

• 第一次握手：Client产生一个seq = J，将SYN置为1，将该数据包发送给Serve，然后客户端进入SYN发送状态（SYN_SENT），等待服务端的确认。（客户端什么都不确认，服务端确认了对方发送正常）
• 第二次握手，Serve收到SYN = 1，知道客户端请求建立连接，服务器将SYN和ACK都置为1，发送给客户端，确认号ack = J+1，并且随机产生sep = K，将该数据包发送给客户端以确认连接请求，客户机进入SYN收到状态（SYN_RCVD）。（客户端确认了自己发送、接收正常，对方发送、接收正常；服务端确认了自己接收正常，对方发送正常）
• 第三次握手，客户端收到确认后，检查ack（对应连接编号）是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务端，服务端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务端进入ESTABLISHED状态，完成三次握手，随后客户端和服务端之间可以开始传输数据了。（客户端确认了自己发送、接收正常，对方发送、接收正常；服务端确认了自己发送、接收正常，对方发送、接收正常）

三次握手考点：丢包问题
在TIME_WAIT状态中，如果TCP client端最后一次发送的ACK丢失了，它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭，并且所有的资源(包括端口号)都被释放。

四次挥手过程

• 第一次挥手：客户端发送一个FIN = M，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态。
• 第二次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态。
• 第三次挥手：服务端发送一个FIN = N，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态。
• 第四次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。

1. 深入理解四次挥手过程
   由于TCP连接是全双工的，因此每个方向都必须单独进行关闭（美团面试原题）。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。 TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。

2. 四次挥手考点：为什么最后还要等待2MSL（最大报文段生存时间）
   1、保证TCP协议的全双工连接能够可靠关闭。（因为如果最后一个ACK丢失了的话，B会重传，而此时A已经关闭了，所以导致不能正常关闭连接）
   2、保证所有数据从网络中消失。（TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失）

扩展题：
为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

相关的一些面试题

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

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

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

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

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