TCP建立，释放连接

TCP建立，释放连接 

http://blog.chinaunix.net/uid-26413668-id-3376762.html

TCP(Transmission Control Protocol)　传输控制协议

TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:

SYN(synchronous建立联机) 

ACK(acknowledgement 确认) 

PSH(push传送) 

FIN(finish结束) 

RST(reset重置) 

URG(urgent紧急)

Sequence number(顺序号码) 

Acknowledge number(确认号码)

TCP报文头部

TCP建立连接

如上图所示 TCP建立连接的过程。 A是主动打开服务的,B是被动打开服务的

   1.B的TCP服务器进程先创建传输控制块TCB（Transmission Control Block 存储了每个连接中的一些重要信息，如：TCP连接表，到发送和接收缓存的指针，到重传队列的指针，当前的发送和接受序号，等）,准备接收客户进程的连接请求，然后服务器进程就处于LISTEN状态,等待客户的连接请求.如有,就做出响应.

    A的TCP客户进程也是先创建传输控制块,然后向B发出连接请求报文段,这时候首部中的同步位SYN=1,同时选择一个初始序号 seq=x。TCP规定,SYN报文段(SYN=1的报文段) 不能携带数据,但要消耗一个序号.这时,TCP客户进程进入SYN-SENT状态.

 

    2.B收到连接请求报文段后,如同意建立连接,则向A发送确认.在确认报文段中,应把SYN和ACK位都置1,确认号是ack=x+1，同时也为自己选择一个初始序号seq=y。这个报文段也不能携带数据,同样要消耗一个序号.这时TCP服务器进程进入SYN-RCVD(同步收到)状态.

 

    3.TCP客户进程收到B的确认后,还要向B给出确认。确认报文段的ACK置1，确认号ack=y+1，而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是seq=x+1。这时，TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。

    当B收到A的确认后，也进入ESTABLISHED状态。

为什么要有第三次确认?

    这主要是为了防止已失效的连接请求报文段突然又传送到了B,因而产生错误.

    假设没有客户端的第三次确认。A发送连接请求，但连接请求丢失而未收到B的确认，于是A重新发出了一次请求连接，后来B收到了请求，发出确认建立了连接，在完成通信后连接释放，成功完成一次通信。A虽发送了两次连接请求,但第一次丢失,第二次成功,所以此时不存在已失效的连接请求报文。现假设A第一次发送的连接请求报文因为网络问题长时间滞留了，到第二次通信完成释放连接后才到达B,这就是一个已失效的报文,但此时B以为是A的又一次连接请求,于是发出了确认,若没有第三次确认,连接就成功建立了。由于A现在并没有发出建立请求,所以B回复的确认A不理睬,所以不与B进行通信,然而B就一直等着A发数据给他,就这样,B傻乎乎的等了很久,白白浪费了自己的青春(B的资源)。

 

 

TCP释放连接

      1.数据传输结束后，通信双方都可释放连接。现在A,B都处于ESTABLISHED状态。A先发送连接释放报文段，并停止在发送数据，主动关闭TCP连接。A把连接释放报文段首部离得FIN置1，其序号seq=u，u等于前面已发送的数据的最后一个字节的序号加1.这是A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。TCP规定，FIN报文段即使不携带数据，也消耗一个序号。

       2.B收到连接释放报文段后即发出确认，确认号是ack=u+1,而这个报文段自己的序号是v，等于B前面已发送的数据的最后一个字节的序号加1.然后B进入CLOSE-WAIT(关闭等待)状态。至此A->B的连接就释放了，这时TCP连接处于半关闭（half-close）状态，即A已经没有数据要发送了，但B若发送数据，A仍然接收。

        3.A收到B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文段。若B已经没有数据要发给A，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1.假定B的序号是w（在半关闭状态B可能又发送了一些数据）。B还必须从夫上次已发送过的确认号ack=u+1。这时B进入LAST-ACK状态，等待A确认。

        4.A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置1，确认号ack=w+1，自己的序号为seq=u+1（前面发送的FIN报文段要消耗一个序号）。然后进入TIME-WAIT（时间等待）状态。现在TCP连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A才进入到CLOSED状态。（MSL：Maximum Segment Lifetime 最长报文段寿命）

为什么在TIME-WAIT要等待呢？

     1.为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段可能丢失，因而使处在LAST-ACK状态的B收不到确认。B会超时重传FIN+ACK报文段，A就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重启计时器。最好，AB都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是再犯送完ACK报文后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会在发送一次确认报文。这样，B就无法按照正常步骤进入CLOSED状态。

     2.防止 已失效的连接请求报文出现在本连接中。

TCP链接协议概述

建立TCP需要三次握手才能建立，而断开连接则需要四次握手。整个过程如下图所示：
  

建立连接的过程

首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。

断开连接的过程

断开连接端可以是Client端，也可以是Server端。假设Client端发起中断连接请求，就先发送FIN报文。Server端接到FIN报文后，但是如果还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以服务器端先发送ACK，告诉Client端：请求已经收到了，但是我还没准备好，请继续等待停止的消息。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，告诉Client端：服务器这边数据发完了，准备好关闭连接了。Client端收到FIN报文后，就知道可以关闭连接了，但是他还是不相信网络，所以发送ACK后进入TIME_WAIT状态， Server端收到ACK后，就知道可以断开连接了。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，最后，Client端也可以关闭连接了至此，TCP连接就已经完全关闭了！关闭连接的过程如下图所示：