tcp二次、三次、四次握挥手

转载地址：http://blog.chinaunix.net/uid-26826958-id-3157048.html
为什么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放在一个包里进行发送，但四次握手这个概念却已经根深蒂固无法更改了。