TCP连接的各种状态

以下内容转自http://blog.csdn.net/hguisu/article/details/38700899(这篇博客也解释了很多tcp攻击的原理)

不管三次握手，还是四次握手，这是保证信息来回两个链路可达（也就是信息能从A到B，也能从B到A）的最低要求。-2018-9-17-晚上九点

　　举个打电话的例子：

　　A : 你好我是A，你听得到我在说话吗

　　B : 听到了，我是B，你听到我在说话吗

　　A : 嗯，听到了

　　建立连接，开始聊天！

为什么TCP协议终止链接要四次？

因为TCP连接是双连接，因此每个方向都必须单独进行关闭，在关闭时，都要发一个Fin包给对方，对方也要发一个ACK包表示收到，所以就是(Fin+ACK)*2=4咯

1、当主机A确认发送完数据且知道B已经接受完了，想要关闭发送数据口（当然确认信号还是可以发），就会发FIN给主机B。

2、主机B收到A发送的FIN，表示收到了，就会发送ACK回复。

3、但这是B可能还在发送数据，没有想要关闭数据口的意思，所以FIN与ACK不是同时发送的，而是等到B数据发送完了，才会发送FIN给主机A。

4、A收到B发来的FIN，知道B的数据也发送完了，回复ACK， A等待2MSL以后，没有收到B传来的任何消息，知道B已经收到自己的ACK了，A就关闭链接，B也关闭链接了。

LISTENING：侦听来自远方的TCP端口的连接请求

   首先服务端需要打开一个socket进行监听，状态为LISTEN。

    有提供某种服务才会处于LISTENING状态，TCP状态变化就是某个端口的状态变化，提供一个服务就打开一个端口，例如：提供www服务默认开的是80端口，提供ftp服务默认的端口为21，当提供的服务没有被连接时就处于LISTENING状态。FTP服务启动后首先处于侦听（LISTENING）状态。处于侦听LISTENING状态时，该端口是开放的，等待连接，但还没有被连接。就像你房子的门已经敞开的，但还没有人进来。

SYN-SENT：客户端SYN_SENT状态：

         在发送连接请求后等待匹配的连接请求:

         客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN包,请求建立一个连接.之后状态置为SYN_SENT. 
     当请求连接时客户端首先要发送同步信号给要访问的机器，此时状态为SYN_SENT，如果连接成功了就变为ESTABLISHED，正常情况下SYN_SENT状态非常短暂

SYN-RECEIVED：服务器端状态SYN_RCVD

          在收到和发送一个连接请求后等待对方对连接请求的确认

     当服务器收到客户端发送的同步信号时，将标志位ACK和SYN置1发送给客户端，此时服务器端处于SYN_RCVD状态，如果连接成功了就变为ESTABLISHED，正常情况下SYN_RCVD状态非常短暂。

ESTABLISHED：代表一个打开的连接。

     ESTABLISHED状态是表示两台机器正在传输数据，观察这个状态最主要的就是看哪个程序正在处于ESTABLISHED状态。

     服务器出现很多ESTABLISHED状态： netstat -nat |grep 9502或者使用lsof  -i:9502可以检测到。

       当客户端未主动close的时候就断开连接：即客户端发送的FIN丢失或未发送。

        这时候若客户端断开的时候发送了FIN包，则服务端将会处于CLOSE_WAIT状态；

         这时候若客户端断开的时候未发送FIN包，则服务端处还是显示ESTABLISHED状态；

          结果客户端重新连接服务器。

          而新连接上来的客户端（也就是刚才断掉的重新连上来了）在服务端肯定是ESTABLISHED; 如果客户端重复的上演这种情况，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。

         最终结果就是新的其他客户端无法连接上来，但是利用netstat还是能看到一条连接已经建立，并显示ESTABLISHED，但始终无法进入程序代码。

 

FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认

       主动关闭(active close)端应用程序调用close，于是其TCP发出FIN请求主动关闭连接，之后进入FIN_WAIT1状态./* The socket is closed, and the connection is shutting down. 等待远程TCP的连接中断请求，或先前的连接中断请求的确认 */

      如果服务器出现shutdown再重启，使用netstat -nat查看，就会看到很多FIN-WAIT-1的状态。就是因为服务器当前有很多客户端连接，直接关闭服务器后，无法接收到客户端的ACK。

FIN-WAIT-2：从远程TCP等待连接中断请求

       主动关闭端接到ACK后，就进入了FIN-WAIT-2

        这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来决定关闭这个状态。

 

CLOSE-WAIT：等待从本地用户发来的连接中断请求

         被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT. 

 

CLOSED：没有任何连接状态

被动关闭端在接受到ACK包后，就进入了closed的状态

 

以下再贴另一个博客的解释就能对tcp状态的变化更加了解

   http://blog.csdn.net/apanious/article/details/51014333

 

TCP每发送一个报文段，就启动一个定时器，如果在定时器超时之后还没有收到ACK确认，就重传该报文。 如图所示，数据包由A的缓冲区发往B，B在收到数据包以后，回发一个ACK确认包给A，之后A将该数据包从缓冲区释放。因此，该数据包会一直缓存在A的缓冲区，直到一个ACK确认为止。 

发现一个规律 ACK包的seq值是请求包的ACK值,ACK包的ack值是请求包的seq值+1

在TCP/IP协议中，TCP协议提供可靠的面向连接的服务；三次握手（建立连接）和四次挥手（关闭连接）；使用滑动窗口机制进行流量控制； 
三次握手的详细图解 
所谓三次握手(Three-way Handshake)，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。如图1所示。 

图1 三次握手建立TCP连接的各状态 
（1）第一次握手：建立连接时，客户端A发送SYN包[SYN=1,seq=x]到服务器B，并进入SYN_SEND状态，等待服务器B确认。 
（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN，同时自己也发送一个SYN包，即SYN+ACK包[SYN=1,ACK=1,seq=y,ack=x+1]，此时服务器B进入SYN_RECV状态。 
（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK[ACK=1,seq=x+1,ack=y+1]，此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据。 
三次握手完成后，客户端和服务器就建立了TCP连接。这时可以调用accept函数获得此连接。三次握手的目的是连接服务器指定端口，建立TCP连接，并同步连接双方的***和确认号并交换TCP 窗口大小信息。在socket编程中，客户端执行connect()时，将会触发三次握手

  客户端的状态可以用如下的流程来表示：

        CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

          以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到SYN报文的ACK以后，客户端就打开了数据交互地连接。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历FIN_WAIT_1，FIN_WAIT_2等状态，这些状态的迁移就是前面提到的结束连接的四次握手。

 

  服务器的状态可以用如下的流程来表示：

         CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

        在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭连接则是在关闭连接的第二次握手以后（注意不是第四次）。而关闭以后还要等待客户端给出最后的ACK包才能进入初始的状态。

TCP连接的终止（四次握手释放,也就是要关闭连接需要再发起四次握手）

　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

      建立一个连接需要三次握手，而终止一个连接要经过四次握手，这是由TCP的半关闭(half-close)造成的，如图：

 

 

调用过程如下：

• 1)   当client想要关闭它与server之间的连接。client（某个应用进程）首先调用close主动关闭连接，这时TCP发送一个FIN M；client端处于FIN_WAIT1状态。

• FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认

• 2)  当server端接收到FIN M之后，执行被动关闭。对这个FIN进行确认，返回给client ACK。当server端返回给client ACK后，client处于FIN_WAIT2状态，server处于CLOSE_WAIT状态。它的接收也作为文件结束符传递给应用进程，因为FIN的接收     意味着应用进程在相应的连接上再也接收不到额外数据；

• FIN-WAIT-2：从远程TCP等待连接中断请求

         主动关闭端接到ACK后，就进入了FIN-WAIT-2

          这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于CLOSE_WAIT状态，而直到应用层来决定关闭这个状态。

  CLOSE-WAIT：等待从本地用户发来的连接中断请求

           被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT. 

•  

• 3)  一段时间之后，当server端检测到client端的关闭操作(read返回为0)。接收到文件结束符的server端调用close关闭它的socket。这导致server端的TCP也发送一个FIN N；此时server的状态为LAST_ACK。

•  

• 4)  当client收到来自server的FIN后 。 client端的套接字处于TIME_WAIT状态，它会向server端再发送一个ack确认，此时server端收到ack确认后，此套接字处于CLOSED状态。

这样每个方向上都有一个FIN和ACK。

 

1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

        这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了(这时对方处于FIN-WAIT-2,只能接受数据,不能发送数据)；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）：

一方面是可靠的实现TCP全双工连接的终止，也就是当最后的ACK丢失后，被动关闭端会重发FIN，因此主动关闭端需要维持状态信息，以允许它重新发送最终的ACK。

因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。

TCP在2MSL(MSL为最大报文段生存时间) 等待期间，定义这个连接(4元组)不能再使用，任何迟到的报文都会丢弃。设想如果没有2MSL的限制，恰好新到的连接正好满足原先的4元组，这时候连接就可能接收到网络上的延迟报文就可能干扰最新建立的连接。