Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1414388
  • 博文数量: 842
  • 博客积分: 12411
  • 博客等级: 上将
  • 技术积分: 5772
  • 用 户 组: 普通用户
  • 注册时间: 2011-06-14 14:43
文章分类

全部博文(842)

文章存档

2013年(157)

2012年(685)

分类: 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. 三次握手改成仅需要两次握手,死锁是可能发生

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

3为什么建立连接是三次握手,而关闭连接是四次呢?

建立连接时,服务端可以把应答ACK和同步SYN放在一个报文里进行发送。而关闭连接时,收到FIN通知仅仅表示对方没有数据发送过来了,并不表示自己的数据全部发送给了对方。所以ACKFIN是分了两次进行发送。如果服务端收到FIN,恰恰自己也没有数据要发,是不是ACKFIN可以一起发给客户端呢,这样就可以少一次数据流了。经典的TCP连接状态图中考虑到了这种情况,tcp关闭连接确实是只有三次数据流动,服务端将ACKFIN放在一个包里进行发送,但四次握手这个概念却已经根深蒂固无法更改了。

阅读(1181) | 评论(0) | 转发(2) |
给主人留下些什么吧!~~