简单来说,三次握手的目的是为了让双方验证各自的接收能力和发送能力。
- 第一次握手,
A
发送SYN
到B
,B
接收到了后,能确认什么呢?显然,
B
能确认A
的发送能力和B
的接收能力; - 第二次握手,
B
发送SYNACK
到A
,A
接收到后,能确认什么呢?A
能确认B
的发送能力和A
自己的接收能力,此外,A
收到了SYNACK
,那么说明前面A
发的SYN
成功到达B
的手中,所以也能确认A
自己的发送能力和B
的接收能力;至此,A
已经确认了双方各自的发送能力和接收能力都是OK
的,因此转为ESTABLISHED
状态; - 第三次握手,A发送ACK到B,B接收后,能确认什么呢?
直接的,
B
能确认A
的发送
能力和B
的接收
能力,另外由于B
能收到ACK
说明前面发送的SYNACK
已经成功被接受了,说明能确认A
的接收
能力和B
的发送
能力。
如果使用两次握手,就不能确认上述所说的四种能力,那么就会导致问题。
假定不采用第三次报文握手,那么只要B发出确认,新的连接就建立了。
现假定一种异常情况,即A
发出的SYN
报文段并没有丢失,而是在某些网络节点长时间滞留了,以致延误到连接释放后的某个时间才到达B
。本来这是一个早已失效的报文段。但B
收到此失效的连接请求报文段后,却误以为是A
又发出一次新的连接请求,于是就向A
发出确认报文段,同意建立连接。
由于现在A
并没有发出建立连接的请求,因此不会理睬B的确认,也不会向B
发送数据,但B
却以为新的运输连接已经建立了,并一直等待A发来的数据。B
的许多资源就这样白白浪费了。