全部博文(842)
分类: LINUX
2012-04-01 14:57:42
为什么tcp建立连接是三次握手而不是两次或四次,释放连接的时候是四次挥手
由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。客户端是主动发送连接的,服务端是被动接受连接的。
1. TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。
如果采用两次的话,会出现下面这种情况。
比如是A机要连到B机,结果发送的连接信息由于某种原因没有到达B机;
于是,A机又发了一次,结果这次B收到了,于是就发信息回来,两机就连接。
传完东西后,断开。
结果这时候,原先没有到达的连接信息突然又传到了B机,于是B机发信息给A,然后B机就以为和A连上了,这个时候B机就在等待A传东西过去。
2. 三次握手改成仅需要两次握手,死锁是可能发生
考虑计算机A和B之间的通信,假定B给A发送一个连接请求分组,A收到了这个分组,并发送了确认应答分组。按照两次握手的协定,A认为连接已经成功地建立了,可以开始发送数据分组。可是,B在A的应答分组在传输中被丢失的情况下,将不知道A是否已准备好,不知道A建议什么样的序列号,B甚至怀疑A是否收到自己的连接请求分组。在这种情况下,B认为连接还未建立成功,将忽略A发来的任何数据分组,只等待连接确认应答分组。而A在发出的分组超时后,重复发送同样的分组。这样就形成了死锁
3)为什么建立连接是三次握手,而关闭连接是四次呢?
建立连接时,服务端可以把应答ACK和同步SYN放在一个报文里进行发送。而关闭连接时,收到FIN通知仅仅表示对方没有数据发送过来了,并不表示自己的数据全部发送给了对方。所以ACK和FIN是分了两次进行发送。如果服务端收到FIN,恰恰自己也没有数据要发,是不是ACK和FIN可以一起发给客户端呢,这样就可以少一次数据流了。经典的TCP连接状态图中考虑到了这种情况,tcp关闭连接确实是只有三次数据流动,服务端将ACK和FIN放在一个包里进行发送,但四次握手这个概念却已经根深蒂固无法更改了。