tcp四次挥手状态(tcp四次挥手客户端状态)

两将军问题：红蓝两军作战，蓝军战斗力强大，红1军或红2军与其单独作战都打不过蓝军，所以需要红一军与红二军联合对蓝军发起进攻，红军1首先通知红军2明早10点发起总攻，如图1-1，红军2接到消息需要回复“好的红军1，我已经收到你得消息，确认明早10点发动总攻”。因为消息传递路线必须经过蓝军营地，所以双方传递消息的信使很有可能被蓝军俘获。为了确保消息的可靠性，红1、红2双方在发出一个消息之后都想得到对方的消息回执。但是这会导致消息无线循环下去，如图1-2。那么如何解决这个可靠性的问题呢，其实没有办法解决，只要保证双方各自都有一次成功的发送、回执就可以了。两将军问题也存在网络世界里，客户端、服务器建立连接不可能无限的确认下去，只要保证客户端和服务器分别对自己的收、发能力做一次确认即可，如下图。 客户端和服务器分别对自己的收、发能力做一次确认至少需要3次握手。3次握手的具体过程、状态如下：（1）首先客户端和服务器都处于CLOSED状态。（2）服务器处于LISTEN状态，具体为服务器调用Socket、bind、listen函数，进入阻塞状态。（3）客户端发送SYN（同步序列编号），发送完毕客户端进入SYN_SENT状态。（4）服务端收到SYN，发送SYN+ASK，发送完毕进入SYN_RCVD状态。（5）客户端收到服务端发来的SYN+ASK，发送服务端等待的ASK，发送完毕客户端进入ESTABLISHED状态，准备数据传输,到此客户端已经满足了对自己收发能力的一次验证。（6）服务端收到客户端发来的ASK，与客户端一样，到此服务端也已经满足了对自己收发能力的一次验证，所以也进入ESTABLISHED状态，准备数据传输。（7）准备开始传输数据TCP断开连接有两种情况或者说是场景，1 客户端先断开连接，当然也可能是服务器先断开连接，总之是一前一后。 2 双方同时发起断开连接操作。下面分别介绍两种场景：（1）客户端先发起断开连接操作，客户端向服务端发送FIN，发送完毕客户端进入FIN_WAIT_1状态。（2）服务端收到客户端发来的FIN，服务端发送ACK，发送完毕进入CLOSED_WAIT状态。（3）客户端收到服务端的ACK回复，客户端进入FIN_WAIT_2状态，如果后面服务端没有回应客户端，在TCP协议层面来讲，客户端将永远停留在这个状态了，不过还好，操作系统着这块做了处理，有一个超时时间。（4）此时TCP连接进入半关闭状态，即客户端主，服务端从的这条线路已经关闭，不过服务端主，客户端从的这条线路还处于打开状态。（5）服务端向客户端发送FIN，发送完毕，服务端进入LAST_ASK状态。（6）客户端收到服务端的FIN后回复服务端ACK，回复完毕进入TIME_WAIT状态，为什么要进入这个状态？因为第6步是客户端的最后一条回复，服务端很有可能收不到，收不到服务端就会重发，所以客户端还要等待一会。（7）服务端收到客户端的ACK回复之后，不再做响应，回到初始的CLOSED状态，在连接池中等待下一次的复用。（8）客户端保持TIME_WAIT状态，超时之后同样进入CLOSED状态。场景二（1）客户端、服务器双方同时发送FIN，双方同时进入FIN_WAIT_1状态（2）双方都接到了对方的ACK，此时双方都会进入CLOSING状态。（3）双方同时进入TIME_WAIT状态，为什么要进入这个状态而不是直接进入CLOSED状态呢？假设客户端和服务端本次是第X次建立连接、关闭连接。如果立即关闭，随后建立第X+1次连接，建立连接成功之后，第X次的丢包的数据有可能绕了一大圈又回来了，那就会出现数据错误，为了避免这种情况所以要进入TIME_WAIT状态，以保证旧连接的数据不会再回来。（4）TIME_WAIT超时之后，双双进入CLOSED状态。有了上面对TCP连接3次握手4次挥手的介绍，再来理解TCP的状态图就不困难了，无非就是对TCP连接3次握手4次挥手过程的打包概述而已。

首先OSI有七层模型，从上往下依次是应用层、表示层、会话层、传输层、网络层、数据链路层、物理层，而TCP/UDP则属于传输层1、TCP和UDP的区别一般我们进行网络通信时，会使用TCP/UDP进行通信，那么我们首先介绍下TCP和UDP到底有什么区别，应用场景又有什么区别？TCP是一种面向连接，可靠稳定的传输协议，建立连接需要经历三次握手，握手成功才可通信，但是速度比较慢，效率比较低，容易被DOS，DDOS攻击。UDP是一种面向无连接，不可靠的传输协议，会直接建立连接，速度快，没有三次握手的机制，所以会相对安全，但是UDP还是可能会被flood攻击，在网络不好的情况，容易发生丢包。2、那么TCP又是如何准确无误的传输数据的呢？当客户端与服务器通过三次握手建立了TCP连接过后，当数据传送完毕，相应的就要断开TCP连接了，于是就有了四次分手的步骤。TCP头部：ACK ： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1SYN：当SYN为1时，表明此数据包是一个同步包，用来表明正在请求连接。可能会形成死锁。假设客户端给服务器发送了一个连接请求报文，服务端成功接收并给客户端发送了确认应答报文，此时服务端并不能确认该应答报文是否成功到了客户端，但因为两次握手，所以这时候服务端就处于成功连接的状态了，并给客户端发送数据。如果客户端未收到服务端的应答报文，则不知道服务器是否确认好建立连接，甚至不知道自己发送给服务器的报文是否成功抵达，此时客户端会认为连接并未成功建立，会忽略服务端发送过来的任何数据。而服务端发送的数据未得到相应超时时，会重复发送同样的数据，这样就形成了死锁。（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，我们也未必全部数据都发送给对方了，所以我们不可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，我们的ACK和FIN一般都会分开发送。

为什么要三次握手 三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常所以三次握手就能确认双发收发功能都正常，缺一不可。 第四次握手：任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
只知道三次握手，A向B发送信息，B会向A返回一个收到确认的消息，A还会对这个确认消息发送一次再确认，所以一个消息要经过三次的消息交互才算发送完成，这就是三次握手

TCP是面向连接的协议。传输连接是用来传送TCP报文的，TCP连接传输的三个阶段分别为：连接建立、数据传送和连接释放。TCP连接的建立采用客户服务器模式。主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段，三次握手的过程如下图所示。(2)第二次握手：服务器收到 SYN报文段后，如同意连接，则服务器会为该TCP连接分配缓存和变量，并向客户端返回确认报文段，在确认报文段中同步位 SYN = 1 和 确认位 ACK= 1，确认号 ack = x + 1，同时也为自己选择一个初始序号 seq = y。这时TCP服务器进程进入同步收到（SYN-RCVD）状态。(3)第三次握手：客户进程在收到服务器进程的确认报文后，客户端为该TCP连接分配缓存和变量，并向服务器端返回一个报文段，这个报文段是对服务器确认报文段进行确认，该报文段中 ACK = 1，确认号 seq = y + 1，而自己序号为 x + 1（即第二次握手服务器确认报文段的确认号）。客户端在发送ACK报文段后进入已建立连接（ESTABLISHED）状态，这时TCP连接已经建立。当服务器收到客户端的确认后，也进入ESTABLISHED状态。这样选择序号的目的是为了防止由于网络路由TCP报文段可能存在延迟抵达与排序混乱的问题，从而而导致某个连接的一方对它作错误的解释。下图表示了建立连接使用固定的序号存在的问题：由于一个TCP连接是被一对端点所表示的，其中包括2个IP地址和2个端口号构成的4元组，因此即便是同一个连接也会出现不同的实例，如果连接由于某个报文段长时间延迟而关闭，然后又以相同的4元组被重新打开，那么可以相信延迟的报文段又会被视为有效据重新进入新连接的数据流中，这就会导致数据乱序问题。为了避免上述的问题，避免连接实例间的序号重叠可以将风险降至最低。如前文所述，一个TCP报文段只有同时具备连接的4元组与当前活动窗口的序列号，才会在通信过程中被对方认为是正确的。然而，这也反应了TCP连接的脆弱性：如果选择合适的序列号、IP地址和端口号，那么任何人都能伪造一个TCP报文段，从而打断TCP的正常连接。所以使用初始化序号的方式（通常随机生成序号）使得序列号变得难猜，或者使用加密来避免利用这种缺点被攻击。所以，可以明白在建立TCP连接时，客户端和服务器端初始化序列号，就避免了上述的问题。前面说过，TCP序号占32位，范围是0~232- 1，并且可以重用。假如 第一次握手可以携带数据的话，如果有人使用伪TCP报文段恶意攻击服务器，那么每次都在第一次握手中的SYN报文中携带大量的数据，因为它不会理会服务器的发送和接收能力是否正常，不断地给服务器重复发送这样携带大量数据的SYN报文，这会导致服务器需要花费大量的时间和内存来接收这些报文数据，这会将导致服务器连接资源和内存消耗殆尽。所以，之所以第一次握手不能携带数据，其中的一个原因就是避免让服务器受到攻击。而对于第三次握手，此时客户端已经建立了连接，通过前两次已经知道了服务器的接收正常，并且也知道了服务器的接收能力是多少，所以可以携带数据。根据前面描述，在第一次握手，客户端向服务发送建立连接请求，第二次握手，服务器同意建立连接，并向客户端返回一个确认报文，至此客户端已经知道了服务器同意建立连接，为什么客户端还需要对服务器的允许连接报文段进行确认？第三个ACK报文段的目的简单来说主要是为了实现可靠数据传输。三次握手的目的不仅在于让通信双方了解一个连接正在建立，还在于利用数据包的选项来承载特殊的信息，交换初始序列号（Initial Sequence，ISN）。为了实现可靠传输，TCP协议通信双方，都必须维护一个序列号，以标识发送出去的数据报中，哪些是已经被对方收到的。三次握手的过程是通信双方想要告知序列号起始值，并确认已经收到序列号的必经过程。如上图，在两次握手过程中，通信双方都随机选择了自己的初始段序号，并且第二次握手的时候客户端收到了自己的确认序号，确认了自己的序列号，而服务器端还没有确认自己的序列号，没有收到确认序号， 如果这时候两次握手下就进行数据传递， 序号没有同步，数据就会乱序。即如果只是两次握手，最多只有客户端的起始序列号能被确认，而服务器断的序列号则得不到确认。在三次握手的过程中，服务器为了响应一个受到的SYN报文段，会分配并初始化连接变量和缓存，然后服务器发送一个SYNACK报文段进行响应，并等待客户端的ACK报文段。如果客户不发送ACK来完成该三次握手的第三步，最终（通常在一分多钟之后）服务器将终止该半开连接并回收资源。这种TCP连接管理协议的特性就会有这样一个漏洞，攻击者发送大量的TCP SYN报文段，而不完成第三次握手的步骤。随着这种SYN报文段的不断到来，服务器不断为这些半开连接分配资源，从而导致服务器连接资源被消耗殆尽。这种攻击就是SYN泛供攻击。为了应对这种攻击，现在有一种有效的防御系统，称为SYN cookie。SYN cookie的工作方式如下：连接释放的四次挥手过程如下图所示：(2)第二次挥手：服务器收到连接释放报文段后即发出确认，确认为ACK = 1，确认号为ack = u + 1，序号seq = v（其值是服务器前面已传送过的数据最后一个字节的序号加1），然后服务器就进入了关闭等待（CLOSE-WAIT）状态。(3)第三次挥手：如果此时服务器没有数据要发送了，此时服务器向客户端发出连接释放报文段，其FIN = 1，假设器序号为seq = w（在半关闭状态下服务器可能又发送了一些数据），服务器必须重复上次以发送的确认号ack = u + 1（因为客户端没有向服务器发送过数据，所以确认号和上次一致）。这时，服务器进入最后确认（LAST-ACK）状态，等待客户端的确认。(4)第四次挥手：客户端在收到服务器端发出的连接释放报文段后，必须对此发出确认，在确认报文段中将ACK置位1，确认号ack = w + 1，而自己的序号为seq = u + 1。之后客户端进入时间等待（TIME-WAIT）状态。在经过时间等待计时器设置的时间2MSL后，客户端才进入关闭（CLOSE）状态这是为了保证客户端发送的最后一个ACK报文段能够到达服务器端。客户端发送的ACK报文段可能丢失，因而使服务器收不到对自己已发送的释放连接报文段的确认。服务器会重传连接释放报文段，重新启动2MSL计时器，最终，客户端和服务器端都能进入CLOSE状态。在建立连接时，服务器端处于LISTEN状态时，当收到SYN报文段的建立连接请求后，它可以把ACK报文段和SYN报文段（ACK报文段起确认作用，即确认客户端的连接建立请求；SYN报文段起同步作用）放在一起发送，所以在连接建立时四次握手（即第二次握手时，服务器的ACK报文段和SYN报文段分开发送）可以合并为三次握手。而在释放连接时需要四次是因为TCP连接的半关闭造成的。由于TCP是全双工的（即数据可在两个方向上同时传递），因此，每个方向都必须要单独进行关闭，这个单方向的关闭就叫半关闭。在关闭连接时，当服务器收到客户端的FIN报文通知时，它仅仅表示客户端没有数据发送服务器了；但服务器未必将所有的数据都全部发送给了客户端，所以服务器端未必马上也要关闭连接，也即服务器端可能还需要发送一些数据给客户端之后，再发送FIN报文给客户端来表示现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的，这也是为什么释放连接时需要交换四次报文了。

TCP的三次握手和四次挥手实质就是TCP通信的连接和断开。 三次握手：为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。四次挥手：即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。TCP三次握手、四次挥手时序图TCP协议位于传输层，作用是提供可靠的字节流服务，为了准确无误地将数据送达目的地，TCP协议采纳三次握手策略。三次握手原理：第1次握手：客户端发送一个带有SYN（synchronize）标志的数据包给服务端；第2次握手：服务端接收成功后，回传一个带有SYN/ACK标志的数据包传递确认信息，表示我收到了；第3次握手：客户端再回传一个带有ACK标志的数据包，表示我知道了，握手结束。其中：SYN标志位数置1，表示建立TCP连接；ACK标志表示验证字段。可通过以下趣味图解理解三次握手：三次握手过程详细说明：1、客户端发送建立TCP连接的请求报文，其中报文中包含seq序列号，是由发送端随机生成的，并且将报文中的SYN字段置为1，表示需要建立TCP连接。（SYN=1，seq=x，x为随机生成数值）；2、服务端回复客户端发送的TCP连接请求报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接；3、客户端收到服务端发送的TCP建立验证请求后，会使自己的序列号加1表示，并且再次回复ACK验证请求，在服务端发过来的seq上加1进行回复。（SYN=1，ACK=y+1，seq=x+1）。由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。四次挥手原理：第1次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态；第2次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态；第3次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态；第4次挥手：客户端收到FIN后，客户端t进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。其中：FIN标志位数置1，表示断开TCP连接。可通过以下趣味图解理解四次挥手：四次挥手过程详细说明：1、客户端发送断开TCP连接请求的报文，其中报文中包含seq序列号，是由发送端随机生成的，并且还将报文中的FIN字段置为1，表示需要断开TCP连接。（FIN=1，seq=x，x由客户端随机生成）；2、服务端会回复客户端发送的TCP断开请求报文，其包含seq序列号，是由回复端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。（FIN=1，ACK=x+1，seq=y，y由服务端随机生成）；3、服务端在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，所有传输到A的数据是否已经传输完毕，一旦确认传输数据完毕，就会将回复报文的FIN字段置1，并且产生随机seq序列号。（FIN=1，ACK=x+1，seq=z，z由服务端随机生成）；4、客户端收到服务端的TCP断开请求后，会回复服务端的断开请求，包含随机生成的seq字段和ACK字段，ACK字段会在服务端的TCP断开请求的seq基础上加1，从而完成服务端请求的验证回复。（FIN=1，ACK=z+1，seq=h，h为客户端随机生成）至此TCP断开的4次挥手过程完毕。LISTEN：等待从任何远端TCP 和端口的连接请求。SYN_SENT：发送完一个连接请求后等待一个匹配的连接请求。SYN_RECEIVED：发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。ESTABLISHED：表示一个打开的连接，接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。FIN_WAIT_1：等待远端TCP 的连接终止请求，或者等待之前发送的连接终止请求的确认。FIN_WAIT_2：等待远端TCP 的连接终止请求。CLOSE_WAIT：等待本地用户的连接终止请求。CLOSING：等待远端TCP 的连接终止请求确认。LAST_ACK：等待先前发送给远端TCP 的连接终止请求的确认（包括它字节的连接终止请求的确认）TIME_WAIT：等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。TIME_WAIT 两个存在的理由：1.可靠的实现tcp全双工连接的终止；2.允许老的重复分节在网络中消逝。 CLOSED：不在连接状态（这是为方便描述假想的状态，实际不存在）。