TCP三次握手及释放连接详解

本文整理自：

http://blog.csdn.net/oney139/article/details/8103223

http://blog.csdn.net/webnumen/article/details/1541330

一、TCP头部简介



ACK ：即确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。TCP报文格式中的控制位由6个标志比特构成，其中一个就是ACK，ACK为1表示确认号有效，为0表示报文中不包含确认信息，忽略确认号字段。在TCP/IP协议中，如果接收方成功的接收到数据，那么会回复一个ACK数据。

SYN(SYNchronization) ： 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1. 因此,  SYN置1就表示这是一个连接请求或连接接受报文。

FIN （finis）即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。

序列号与确认号
TCP协议工作在OSI的传输层，是一种可靠的面向连接的数据流协议，TCP之所以可靠，是因为它保证了传送数据包的顺序。顺序是用一个序列号来保证的。响应包内也包括一个序列号，表示接收方准备好这个序列号的包。在TCP传送一个数据包时，它会把这个数据包放入重发队列中，同时启动计时器，如果收到了关于这个包的确认信息，便将此数据包从队列中删除，如果在计时器超时的时候仍然没有收到确认信息，则需要重新发送该数据包。另外，TCP通过数据分段中的序列号来保证所有传输的数据可以按照正常的顺序进行重组，从而保障数据传输的完整。
二、三次握手的过程


TCP建立连接，也就是我们常说的三次握手，它需要三步完成。在TCP的三次握手中，发送第一个SYN的一端执行的是主动打开。而接收这个SYN并发回下一个SYN的另一端执行的是被动打开。

这里以客户端向服务器发起连接来说明。

1)  第1步：客户端向服务器发送一个同步数据包请求建立连接，该数据包中，SYN=1 ACK=0  (请看头字段的介绍),TCP规定SYN=1时不能携带数据，但要消耗一个序号,初始序列号seq（ISN）是客户端随机产生的一个值，上图表示为seq=x;确认号是0；


2)  第2步：服务器收到这个同步请求数据包后，会对客户端进行一个同步确认。这个数据包中，序列号（ISN）是服务器随机产生的一个值，上图表示为seq=y，确认号ack是客户端的初始序列号+1；即 ack=x+1


3)  第3步：客户端收到这个同步确认数据包后，再对服务器进行一个确认。该数据包中，序列号是上一个同步请求数据包中的确认号值，即seq=x+1，确认号ack是服务器的初始序列号+1，即ack=y+1。



初始序列号（ISN）随时间而变化的，而且不同的操作系统也会有不同的实现方式，所以每个连接的初始序列号是不同的。TCP连接两端会在建立连接时，交互一些信息，如窗口大小、MSS等，以便为接着的数据传输做准备。


RFC793指出ISN可以看作是一个32bit的计数器，每4ms加1，这样选择序号的目的在于防止在网络中被延迟的分组在以后被重复传输，而导致某个连接的一端对它作错误的判断

然后连接建立，为什么要进行三次握手呢（两次确认）。

三、TCP传输数据

在TCP建立连接后，就可以开始传输数据了。TCP工作在全双工模式，它可以同时进行双向数据传输。这里为了简化，我们只谈服务器向客户端发送数据的情况，而客户端向服务器发送数据的原理和它是类似的，这里便不重复说明。
服务器向客户端发送一个数据包后，客户端收到这个数据包后，会向服务器发送一个确认数据包。

传输数据的简要过程如下：

1)  发送数据：服务器向客户端发送一个带有数据的数据包，该数据包中的序列号和确认号与建立连接第三步的数据包中的序列号和确认号相同；

2)  确认收到：客户端收到该数据包，向服务器发送一个确认数据包，该数据包中，序列号是为上一个数据包中的确认号值，而确认号为服务器发送的上一个数据包中的序列号+所该数据包中所带数据的大小。
数据分段中的序列号可以保证所有传输的数据按照正常的次序进行重组，而且通过确认保证数据传输的完整性。




四、释放连接的过程

当客户A 没有东西要发送时就要释放 A 这边的连接，A会发送一个报文（没有数据），其中 FIN 设置为1,  服务器B收到后会给应用程序一个信，这时A那边的连接已经关闭，即A不再发送信息（但仍可接收信息）。  A收到B的确认后进入等待状态，等待B请求释放连接， B数据发送完成后就向A请求连接释放，也是用FIN=1 表示， 并且用 ack = u+1(如图）， A收到后回复一个确认信息，并进入 TIME_WAIT 状态， 等待 2MSL 时间。
为什么要等待呢？
为了这种情况：  B向A发送 FIN = 1 的释放连接请求后，A向B回复确认消息，但这个消息丢失了， B没有接到确认信息， B 超时会重传，这时A在 WAIT_TIME 还能够接收到这个请求，这时再回复一个确认就行了。（A收到 FIN = 1 的请求后 WAIT_TIME会重新记时）

另外服务器B存在一个保活状态，即如果A突然故障死机了，那B那边的连接资源什么时候能释放呢？  就是保活时间到了后，B会发送探测信息， 以决定是否释放连接。