关于TCP连接的3次握手和4次挥手

3次握手：

关键在于双方都需要确认自己的发信和收信功能正常，收信功能通过接收对方信息得到确认，发信功能需要发出信息—>对方回复信息得到确认。

举个日常例子，打电话时我们对话如下：

 

 

如上，需要第三次握手的原因在于Server端在第二次握手（发出信息）后并不知道对方是否能够接收、己方的发送功能是否正常。但此时数据的单向通道已经建立，对于Client来说，已经确认了Server端可以接收信号，因此可以单向给Server发送数据了。

 

是3次握手而不是4次或更多握手是因为，3次已经能够确认双方能够进行正常通信了，故没有4次的必要了。

 

在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不用的表述其实阐明的是同一个问题。
谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

这个例子很清晰的阐释了“三次握手”对于建立可靠连接的意义。

在Google Groups的TopLanguage中一帖讨论TCP“三次握手”觉得很有意思。贴主提出“TCP建立连接为什么是三次握手？”的问题，在众多回复中，有一条回复写道：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。这可视为对“三次握手”目的的另一种解答思路。

 

4次挥手：

首先来看一下三次握手和四次挥手的全过程：

三次握手的详细过程在上面已经详细解释过了，因此，下图为四次挥手的详细过程（图片取自百度百科）：

注意：由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。但Client和Server都可以是主动提出关闭连接的一方。

假设Client端发起中断连接请求，也就是

1. Client端首先向Server端发送FIN报文，并进入FIN_WAIT_1状态。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。

2. 所以Server端先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。

Client端收到ACK后，就进入FIN_WAIT_2状态，继续等待Server端的FIN报文。

3. 当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。

4. Client端收到FIN报文后，就知道可以关闭连接了，给Server回复确认ACK报文，并进入TIME_WAIT状态（一般为2MSL）。

Server端收到ACK后，"就知道可以断开连接了"。

Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，Client端也可以关闭连接了。

 

 

 

MSL意思是： maximum segment lifetime，最长分节生命周期。 

【问题1】为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN（synchronous同步）连接请求报文后，可以直接发送SYN+ACK报文。其中ACK（acknowledgement）报文是用来确认的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能还有数据需要发送给Client端，并不会立即关闭连接，所以只是先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，Server端才会发送FIN报文，因此不能一起发送。故需要四次挥手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：因为网络原因，主动关闭的一方发送的这个ACK包很可能延迟，从而触发被动连接一方重传FIN包。极端情况下，这一去一回，就是两倍的MSL时长。如果主动关闭的一方跳过TIME_WAIT直接进入CLOSED，或者在TIME_WAIT停留的时长不足两倍的MSL，那么当被动关闭的一方早先发出的延迟包到达后，就可能出现类似下面的问题：

1.旧的TCP连接已经不存在了，系统此时只能返回RST包 2.新的TCP连接被建立起来了，延迟包可能干扰新的连接