共计 2790 个字符，预计需要花费 7 分钟才能阅读完成。
TCP 的三次握手
TCP 三次握手过程
假如有一个发送方计算机和一个接管方计算机，纵向为时间轴
第一次握手
假如首先是发送方被动和接管方建设连贯，所以，发送方会第一次发送一个报文（此时 SYN=1，示意这是一个连贯申请的报文，seq= x 是同步发送方本人的序列号）
第二次握手
接管方在接管到连贯申请后，也就关上 TCP 连贯，同时它也会发送一个报文，这个报文是第二次握手。报文信息中有：
- SYN=1：示意是一个连贯申请
- ACK=1：示意对序列号的确认
- ack=x+1：小写的 ack 示意的是确认号。这里的 ack=x+1，示意接受方冀望收到的是 x + 1 这个序列号的值
- seq=y：同时接管方发送的报文中也会携带本人的序列号，也就是 seq=y
第三次握手
发送方接管到报文之后，会进行回应，回应中的报文内容：
- ACK=1：示意这个报文的确认号是无效的
- seq=x+1：发送方所携带的序列号，示意的是，以后发送方发送的数据序列号是 x +1
- ack=y+1：确认号是 y +1，示意发送方冀望接管到接管方的序列号是 y + 1 的数据
通过这三次的握手，TCP 的连贯就建设起来了
三次握手中要害的信息
- 第一次和第二次握手都有SYN 标记，示意这是一个连贯的申请
- 第二次和第三次握手都有ack 标记，对于 ack 这个标记，它其实是先对连贯单方的序列号进行同步。比如说，通过两次的 ack 同步，发送方曾经晓得了接管方的 ack 是什么了，同时，接管方也晓得了发送方的 ack 是什么了，通过三次握手，它们不仅仅将连贯建设起来，并且也同步了各自的序号
在三次握手的时间轴中，不同的工夫，接管方和发送方有不同的状态
- 在接管方没有接管到数据之前，它始终处于 监听 状态（Listen）
- 发送方在第一个报文发送进来，到接管到第一个报文的响应之间，属于 同步已发送 状态（SYNC-SENT），示意曾经将 SYN 发送进来了，并且期待对方的 SYN 信息
- 从接管方发送第一个报文，到接管到第二个报文之间，属于 同步已接管状态（SYNC-RCVD），示意发送方发送给我的 SYN 信息，我曾经收到了
- 而后发送方就进入 建设连贯（ESTABLISHED）的状态了
- 对发送方来说，只有第二次握手胜利之后，发送方就建设起连贯了。然而对接管方来说，只有接管到发送方的第三次握手之后，才是 建设连贯的状态（ESTABLISHED）
单方对于建设连贯状态的工夫是不一样的，发送方只有在第二次握手胜利之后，就变成了建设连贯的状态。然而对接管方来说，只有接管到发送方的第三次握手之后，才是建设连贯的状态。单方都进入建设连贯的状态之后就能够进行数据的传输了
为什么发送方要收回第三个确认报文呢？为什么两次不行？
论断：防止曾经生效的连贯申请报文传送到对方，引起谬误
假如此时有一个发送方计算机和一个接管方计算机。首先发送方须要发送一个建设连贯的申请报文（第一次握手），假如第一次握手的报文在网络中传输很久才达到接管方，因为发送了很久，所以，发送方很久都没有收到接管方的确认音讯。发送方就会认为第一个报文曾经超时了，所以，发送方就会第二次发送同样的报文
假如第二次发送的报文，很快就达到了对方，接管方在收到第二次的连贯申请报文之后，就会进行回应，并且建设起它们之间的连贯。那么，对于发送方发送的第一次的申请报文，就应该是一个 生效的申请报文，因为它的性能曾经被第二次的连贯申请所实现了。所以，对于第一次发送的申请连贯报文，在网络中游荡了很久，其实就是一个生效的申请报文了，没有作用了
如果发送方发送的两次连贯申请都建设起连贯了会怎么样？
首先思考第二次申请的报文，这个报文是提前达到接管方的，接管方会对它进行一个回应，回应确认之后，就建设起连贯了（因为咱们是假如两次握手就建设起连贯）
当初思考第一次发送的连贯申请，如果两次握手就建设连贯的话，对于生效的申请，它也会建设起连贯，因为只有接管方回应了，就示意连贯曾经建设了
这样就会导致，同样的申请发送了两次，就会建设两个 TCP 连贯的状况。这种状况是谬误的，所以说，两次握手是不正确的
三次握手是如何解决两次握手导致的问题？
对于两次握手 ，只有接管方回应了，就示意连贯建设了。而 对于三次握手来说，第一个确认报文会首先达到发送方，而后发送方再发送一个确认报文（第三次握手），此时才算建设起连贯
当初来思考那个比较慢达到接管方的连贯申请报文，这个报文，接管方也会发送一个确认报文给发送方（第二次握手）。然而发送方曾经进行第三次握手了，因而发送方对于第二次的确认音讯会 疏忽掉，并不会进行任何的操作。这样，第一次比较慢达到的连贯申请就不会建设起连贯，这就防止了两次握手所导致的谬误
TCP 的四次挥手
TCP 四次挥手过程
还是假如这里有一个发送方结算机和一个接管方计算机，纵向为时间轴。连贯失常的时候，单方是能够始终进行数据传输的。假如数据传输实现了，此时就会进行 TCP 连贯的开释。假如发送方被动的进行了连贯的开释
第一次挥手
发送方发送第一次挥手的报文，报文内容：
FIN=1：该标记示意须要开释连贯
seq=u：同步本人的序列号给接管方
此时发送方就进入了 连贯完结的第一个期待状态（FIN-WAIT-1）
第二次挥手
接管方在收到发送方的断开连接申请之后，它也会发送一个报文去确认，确认对方给我发送的序列号我曾经收到了，确认报文内容是：
ACK=1：示意这个报文曾经确认
seq=v：同步本身的序列号
ack=u+1：确认号是 u +1，示意接管方冀望接管到接发送方的序列号是 u + 1 的数据
发送方接管到确认报文之后，就进入了 连贯完结的第二个期待状态 （FIN-WAIT-2）。而接管方在发送了第一个确认报文之后就进入了 敞开期待状态（CLOSE-WAIT）
这个时候其实接管方还是能够进行数据的发送的，因为开释连贯的申请是发送方发动的，示意说发送方的数据发送实现了，然而接管方可能还没有发送实现
第三次挥手
接管方发送完第一个确认报文之后，又会发送一个新的报文，这个报文会携带 FIN= 1 的标记，示意它也能够进行连贯开释了，并且里边会携带一个 ack，示意反复的对发送方发送的序列号进行确认，该报文中的残缺内容：
FIN=1：该标记示意须要开释连贯，是一个开释连贯的申请
ACK=1：示意确认报文曾经收到
seq=w：给发送方同步本人的序列号
ack=u+1：确认号是 u +1，示意接管方冀望接管到接发送方的序列号是 u + 1 的数据
第四次挥手
发送方接管到接管方的确认报文之后，又会发送一个确认报文，确认接管方发送的报文我曾经收到了，此时能够开释掉连贯了
在接管方发送断开连接的申请到发送方的确认报文被接管方收到这之间，接管方处于 最初确认状态 （LAST-ACK）。是为了确认发送方曾经接管到了连贯开释的报文，此时发送方进入了 期待计时器状态 （TIME-WAIT）。发送方会在这个工夫期待状态中期待一段时间，确保这段时间没有呈现任何的问题，此时才进入 敞开状态（CLOSE）
以上便是四次挥手的过程