作者：等不到的口琴\
起源：cnblogs.com/Courage129/p/14324605.html

TCP协定简介

TCP协定是五层协定中运输层的协定，上面依赖网络层、链路层、物理层，对于一个报文想发到另一台机器(假如是服务器)上对等层，每一个所依赖的层都会对报文进行包装，例如TCP协定就依赖网络层的IP协定，所以发送的报文会通过如下封装:

当这个数据包达到服务器时，服务器的网络层会对IP相干协定内容解封装、校验，而后运输层对TCP层进行解封，解封波及到一系列的步骤，例如这个数据包是要干嘛？是发给我的吗?这些操作须要依据 TCP 报文的首部信息来判断，首部蕴含以下内容：

次要通过首部信息来理解这个包是干嘛的,对于首部信息,这儿须要用到的几个如下:

  • ACK：TCP协定规定，只有ACK=1时无效，也规定连贯建设后所有发送的报文的ACK必须为1
  • SYN(SYNchronization)：在连贯建设时用来同步序号。当SYN=1而ACK=0时，表明这是一个连贯申请报文。对方若批准建设连贯，则应在响应报文中使SYN=1和ACK=1. 因而, SYN置1就示意这是一个连贯申请或连贯承受报文。
  • FIN （finis）：即完，终结的意思， 用来开释一个连贯。当 FIN = 1 时，表明此报文段的发送方的数据曾经发送结束，并要求开释连贯。

「留神」 ：·URG、ACK、PSH、PST、RST、SYN、FIN只有一位，也就是只有 0 或者 1 两种状态。

TCP协定三次握手

「第一次握手」 ：客户端先向服务端发送一个申请连贯的报文段，这个报文段SYN位设置为1,序列号Seq(Sequence Number)设置为某一值，假如为X，发送进来之后客户端进入SYN_SEND状态，期待服务器的确认；

「第二次握手」 ：服务器收到SYN报文段。服务器收到客户端的SYN报文段，须要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，本人本人还要发送SYN申请信息，将SYN地位为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

「第三次握手」 ：客户端收到服务器的SYN+ACK报文段。而后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送结束当前，客户端和服务器端都进入ESTABLISHED状态，实现TCP三次握手。

实现了三次握手，客户端和服务器端就能够开始传送数据。以上就是TCP三次握手的总体介绍。

为什么要三次握手而不是两次?

为什么非要进行三次连贯呢？两次行吗?在谢希仁的《计算机网络》中是这样说的：

为了避免已生效的连贯申请报文段忽然又传送到了服务端，因此产生谬误。如下：

“已生效的连贯申请报文段”的产生在这样一种状况下：client收回的第一个连贯申请报文段并没有失落，而是在某个网络结点长时间的滞留了，以至延误到连贯开释当前的某个工夫才达到server。原本这是一个早已生效的报文段。但server收到此生效的连贯申请报文段后，就误认为是client再次收回的一个新的连贯申请。于是就向client收回确认报文段，批准建设连贯。

假如不采纳“三次握手”，那么只有server收回确认，新的连贯就建设了。因为当初client并没有收回建设连贯的申请，因而不会理会server的确认，也不会向server发送数据。但server却认为新的运输连贯曾经建设，并始终期待client发来数据。这样，server的很多资源就白白浪费掉了。

采纳“三次握手”的方法能够避免上述景象产生。例如方才那种状况，client不会向server的确认收回确认。server因为收不到确认，就晓得client并没有要求建设连贯。”，避免了服务器端的始终期待而浪费资源。

第三次握手失败了怎么办?

在tcp三次握手中 第二次握手实现后connect 就胜利返回了 如果第三次握手的ack包丢了 此时 客户端已认为连贯是胜利的,如果没有应用层的心跳包,客户端会始终保护这个连贯 请问如何防止这种状况？

第二次握手服务器收到SYN包,而后收回SYN+ACK数据包确认收到并且申请建设连贯，服务器进入SYN_RECV状态。而这个时候第三次握手时客户端发送ACK给服务器失败了，服务器没方法进入ESTABLISH状态，这个时候必定不能传输数据的，不管客户端被动发送数据与否，服务器都会有定时器发送第二步SYN+ACK数据包，如果客户端再次发送ACK胜利，建设连贯。

如果始终不胜利，服务器必定会有超时（大略64s）设置，超时之后会给客户端发「RTS报文」 (连贯重置)，进入CLOSED状态，避免SYN洪泛攻打，这个时候客户端应该也会敞开连贯。

「SYN洪泛攻打：」

SYN攻打利用的是TCP的三次握手机制，攻打端利用伪造的IP地址向被攻打端发出请求，而被攻打端收回的响应 报文将永远发送不到目的地，那么「被攻打端在期待敞开这个连贯的过程中耗费了资源」 ，如果有成千上万的这种连贯，主机资源将被耗尽，从而达到攻打的目标。

TCP协定四次离别

还是这个图镇帖：

四次离别，意思是某一端（能够使客户端，也能够是服务器端）想完结会话断开连接，那么具体流程是：

「第一次离别」 ：主机1，设置序列号Seq(Sequence Number)和确认包ACK(Acknowledgment Number)，假如seq为x+2,ACK=y+1,再将FIN标记位设置为1,向主机2发送FIN报文段；之后主机1进入FIN_WAIT_1状态；这示意主机1没有数据要发送给主机2了；

「第二次离别」 ：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段(其值为接管到的FIN报文的seq值+1)；主机1进入FIN_WAIT_2状态,期待主机二的断开申请包FIN；

「第三次离别」 ：主机2向主机1发送FIN报文段，意思是我能够断开连接了,申请敞开连贯，同时主机2进入CLOSE_WAIT状态；

「第四次离别」 ：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段,值为刚刚接管到的FIN包Seq值+1，而后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段当前，就敞开连贯；此时，主机1期待2MSL后仍然没有收到回复，则证实Server端已失常敞开，那好，主机1也能够敞开连贯了。

为什么要四次挥手

TCP是全双工模式，这就意味着，当主机1收回FIN报文段时，只是示意主机1曾经没有数据要发送了，主机1通知主机2，它的数据曾经全副发送结束了；然而，这个时候主机1还是能够承受来自主机2的数据；当主机2返回ACK报文段时，示意它曾经晓得主机1没有数据发送了，然而主机2还是能够发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就示意主机2也没有数据要发送了，就会通知主机1，我也没有数据要发送了，之后彼此就会欢快的中断这次TCP连贯。如果要正确的了解四次离别的原理，就须要理解四次离别过程中的状态变动。

四次挥手状态解释

「FIN_WAIT_1」 : 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含意都是示意期待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想被动敞开连贯，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。「也就是,收回FIN包之后进入FIN_WAIT_1状态」

而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在理论的失常状况下，无论对方何种状况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态个别是比拟难见到的，而FIN_WAIT_2状态还有时经常能够用netstat看到。「也就是,收回ACK报文之后进入FIN_WAIT_2状态」

「被动方FIN_WAIT_2」 ：下面曾经具体解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，示意半连贯，也即有一方要求close连贯，但另外还通知对方，我临时还有点数据须要传送给你(ACK信息)，稍后再敞开连贯。

「被动方CLOSE_WAIT」 ：这种状态的含意其实是示意在期待敞开。怎么了解呢？当对方close一个SOCKET后发送FIN报文给本人，你零碎毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正须要思考的事件是观察你是否还有数据发送给对方，如果没有的话，那么你也就能够 close这个SOCKET，发送FIN报文给对方，也即敞开连贯。所以你在CLOSE_WAIT状态下，须要实现的事件是期待你去敞开连贯。

「被动方LAST_ACK」 : 这个状态还是比拟容易好了解的，它是被动敞开一方在发送FIN报文后，最初期待对方的ACK报文。当收到ACK报文后，也即能够进入到CLOSED可用状态了。「也就是接管到了对方的FIN包,本人收回了ACK以及FIN包之后的状态」

「被动方TIME_WAIT」 : 示意收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT1状态下，收到了对方同时带FIN标记和ACK标记的报文时，能够间接进入到TIME_WAIT状态，而无须通过FIN_WAIT_2状态。

「被动方CLOSED」 : 示意连贯中断。

TCP状态图

状态图解释

  1. CLOSED：起始点，在超时或者连贯敞开时候进入此状态。
  2. LISTEN：svr端在期待连贯过去时候的状态，svr端为此要调用socket， bind,listen函数，就能进入此状态。此称为应用程序被动关上（期待客户端来连贯）。
  3. SYN_SENT:客户端发动连贯，发送SYN给服务器端。如果服务器端不能连贯，则间接进入CLOSED状态。
  4. SYN_RCVD：跟3对应，服务器端承受客户端的SYN申请，服务器端由LISTEN状态进入SYN_RCVD状态。同时服务器端要回应一个ACK，同时发送一个SYN给客户端；另外一种状况，客户端在发动SYN的同时接管到服务器端得SYN申请，客户端就会由SYN_SENT到SYN_RCVD状态。
  5. ESTABLISHED：服务器端和客户端在实现3次握手进入状态，阐明曾经能够开始传输数据了。以上是建设连贯时服务器端和客户端产生的状态转移阐明。相对来说比拟简单明了，如果你对三次握手比拟相熟，建设连贯时的状态转移还是很容易了解。接下来服务器端和客户端就进行数据传输。。。。，当然，外面也大有学识，就此打住，稍后再表。上面，咱们来看看连贯敞开时候的状态转移阐明，敞开须要进行4次单方的交互，还包含要解决一些善后工作（TIME_WAIT状态），留神，这里被动敞开的一方或被动敞开的一方不是指特指服务器端或者客户端，是绝对于谁先发动敞开申请来说的。
  6. FIN_WAIT_1:被动敞开的一方，由状态5进入此状态。具体的动作时发送FIN给对方。
  7. FIN_WAIT_2:被动敞开的一方，接管到对方的FIN ACK，进入此状态。由此不能再接管对方的数据。然而可能向对方发送数据。
  8. CLOSE_WAIT：接管到FIN当前，被动敞开的一方进入此状态。具体动作时接管到FIN，同时发送ACK。
  9. LAST_ACK：被动敞开的一方，发动敞开申请，由状态8进入此状态。具体动作时发送FIN给对方，同时在接管到ACK时进入CLOSED状态。
  10. CLOSING：两边同时发动敞开申请时，会由FIN_WAIT_1进入此状态。具体动作是，接管到FIN申请，同 时响应一个ACK。
  11. TIME_WAIT：最纠结的状态来了。从状态图上能够看出，有3个状态能够转化成它，咱们一一来剖析：
a.由FIN_WAIT_2进入此状态：在单方不同时发动FIN的状况下，    被动敞开的一方在实现本身发动的敞开申请后，接管到被动敞开一方的FIN后进入的状态。b.由CLOSING状态进入:单方同时发动敞开，都做了发动FIN的申请，    同时接管到了FIN并做了ACK的状况下，由CLOSING状态进入。c.由FIN_WAIT_1状态进入：同时承受到FIN（对方发动），ACK（自身发动的FIN回应），    与b的区别在于自身发动的FIN回应的ACK先于对方的FIN申请达到，    而b是FIN先达到。这种状况概率最小。

敞开的4次连贯最难了解的状态是TIME_WAIT，存在TIME_WAIT的 2 个理由：

  1. 牢靠地实现TCP全双工连贯的终止。
  2. 容许老的反复分节在网络中消失。

近期热文举荐：

1.1,000+ 道 Java面试题及答案整顿(2022最新版)

2.劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4.20w 程序员红包封面，快快支付。。。

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！