TCP连接的建立 (三次握手) 和释放 (四次握手)

转载于：http://blog.csdn.net/honeybees/article/details/6755335

TCP报文段首部格式：

序号：本报文段所发送的数据的第一个字节的序号。

确认号ack：期待收到对方下一个报文段的第一个数据字节的序号

确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。

              若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。

终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

 

三次握手（三次联络）

CLOSED : 进程处于关闭状态。

SYN-SENT : 客户进程进入同步已发送状态。

ESTAB-LISHEND : 进程已经入已建立连接状态，之后可以传送数据了。

LISTEN : 服务器进程处于收听状态。

SYN-RCVD : 服务器进程进入同步收到状态。

----------------------------------------------------

需要三次握手（还要再发送一次确认）的原因：

为了防止已失效的连接请求报文段突然又传到了服务器B，导致服务器误认为客户端想请求连接而发生连接的错误。

产生错误的场景：

在两次握手的前提下，A发出连接请求，但因为丢失了，故而不能收到B的确认。于是A重新发出请求，然后收到确认，建立连接，数据传输完毕后，释放连接，A发了2个，一个丢掉，一个到达，没有“已失效的报文段”。

但是，某种情况下，A发出的第一个连接请求在某个节点滞留了，延误到达B。假设此时B已经释放连接，那么B在收到此实现的连接请求后，就误认为A又发出一次连接请求，在两次握手的情况下（A发生请求，B接受请求并确认），B就认为A又发出一次新连接请求。此时B就又给A发生一个确认，表示同意建立连接。因为是两次握手，A收到后，也不再次发出确认连接。此时B会等待A发送的数据，而A本来就没有要求发送数据，肯定也无动于衷。此时B的资源就被浪费了。

为什么三次握手能够处理这个错误场景？

采用三次握手的话，A收到B的确认后，由于A本来就不想发送数据，所以A就不发送确认，而B收不到确认，也就知道A并没有要求建立连接。

四次握手（两个二次握手）

 

----------------------------------------------------------------

ESTAB-LISHEND : 进程已经入已建立连接状态，可以传送数据。

FIN-WAIT1 : 客户端进程进入终止等待1的状态。

FIN-WAIT2 : 客户端进程进入终止等待2的状态。

TIME-WAIT: 客户端进程进入时间等待（服务器的重传）的状态。

CLOSED : 进程处于关闭状态。

CLOSED-WAIT: 服务器进程进入关闭等待状态。

LAST-ACK: 服务器进行最后一次关闭确认。

注意两个状态：

<1> CLOSED-WAIT: 服务器进程进入关闭等待状态。

服务器等待关闭状态：服务器接收到客户端关闭连接的请求，而自身还未想客户端发送关闭连接请求的这段时间。

通常情况下，CLOSE_WAIT状态的持续时间应该很短，但是如果服务器有很多数据需要传输或读写时，就不能关闭连接，此时就会出现连接长时间处于CLOSE_WAIT状态的情况。

<2> TIME-WAIT: 客户端进程进入时间等待（服务器的重传）的状态。

<客户端完全关闭状态>：客户端收到服务器断开连接的请求后，会向服务器确认收到分组，表示自己已经收到，你可以关闭连接了。但是该确认分组可能由于网络问题收不到，而出现重传的情况。所以客户端必须要等待一会。此时客户端等待完全关闭的时间就为TIME-WAIT时期。

---------------------------------------------------------------

B收到连接释放报文段后就立即发送确认，然后就进入close-wait状态，此时TCP服务器进程就通知高层应用进程，因而从A到B的连接就释放了。此时是“半关闭”状态。即A不可以发送给B，但是B可以发送给A。

此时，若B没有数据报要发送给A了，其应用进程就通知TCP释放连接，然后发送给A连接释放报文段，并等待确认。

A发送确认后，进入time-wait，注意，此时TCP连接还没有释放掉，然后经过时间等待计时器设置的2MSL后，A才进入到close状态。

为什么要等待呢?

①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失，那么B会超时重传，然后A再一次确认，同时启动2MSL计时器，如此下去。如果没有等待时间，发送完确认报文段就立即释放连接的话，B就无法重传了（连接已被释放，任何数据都不能出传了），因而也就收不到确认，就无法按照步骤进入CLOSE状态，即必须收到确认才能close。

②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL，那些在这个连接持续的时间内，产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点，但是呢，经过2MSL这些无效报文段就肯定可以发送到目的地，不会滞留在网络中。这样的话，在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。

可以看出：B结束TCP连接的时间比A早一点，因为B收到确认就断开连接了，而A还得等待2MSL.