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并没有要求建立连接。”
![](https://images2015.cnblogs.com/blog/892393/201605/892393-20160506112043529-1744754018.png)
这个例子很清晰的阐释了“三次握手”对于建立可靠连接的意义。
在Google Groups的TopLanguage中一帖讨论TCP“三次握手”觉得很有意思。贴主提出“TCP建立连接为什么是三次握手?”的问题,在众多回复中,有一条回复写道:“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。这可视为对“三次握手”目的的另一种解答思路。
![](https://images2015.cnblogs.com/blog/892393/201605/892393-20160506163411576-114694744.gif)
![](https://images2015.cnblogs.com/blog/892393/201605/892393-20160506163506888-361967834.jpg)
【问题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连接被建立起来了,延迟包可能干扰新的连接