关于网络:从序号和确认号理解TCP三次握手

49次阅读

共计 1722 个字符，预计需要花费 5 分钟才能阅读完成。

TCP 首部存储的数据和建设连贯无关，具体每个字段的用处能够参考这一篇文章，其中序号和确认号决定了发送数据的内容。

头部两头局部 ” 保留 ” 和 ” 窗口 ” 两头是标记位，会携带一些连贯的信息
序号（Sequence Number）：以后 TCP 数据局部的第一个字节编号(理论是一个十分大的值，十分大的值 – 固定值 = 小的编号，同一申请有一个固定值，固定值来源于建设连贯时 seq= 0 时)
确认号（Acknowledgment Number）：ACK= 1 时才无效，冀望对方下一次传过来的 TCP 数据局部的第一个字节编号

建设连贯的时候会有三步，也就是咱们所说的三次握手。

SYN=1，ACK=0，序号 seq=x（连贯之初的客户端固定值，简略来说就是 0），没有发任何字节，所以数据长度为 0，此时是客户端向服务器发送的建设连贯申请。
SYN=1，ACK=1，序号 seq=y（连贯之初的服务器固定值，简略来说就是 0），确认号 ack = x+1，数据长度为 0，此时是服务器向客户端发送响应，示意心愿收到客户端发送第 1 个字节的数据。
SYN=0，ACK=1，序号 seq=x+1，确认号 ack=y+1，数据局部长度为 0，此时客户端确认收到服务器的确认音讯，建设连贯实现。示意心愿收到服务器第一个字节的数据。

连贯时，存在一些状态的变动

CLOSED：client 处于敞开状态
LISTEN：server 处于监听状态，期待 client 连贯
SYN-RCVD：示意 server 承受到了 SYN 报文，当收到 client 的 ACK 报文后，它会进入到 ESTABLISHED 状态
SYN-SENT：示意 client 已发送 SYN 报文，期待 server 的第 2 次握手
ESTABLISHED：示意连贯曾经建设

抓包数据来看如下所示

那么可能有人会问，为什么须要三次握手，两次不就能够相互确认了吗？

三次握手的目标：避免 server 端始终期待，浪费资源。
如果只有两次握手，第一次发送 SYN= 1 时因网络提早没发送胜利，那么客户端会再发送一次 SYN= 1 的建设申请，此时发送胜利，客户端和服务器之间实现通信。
过了一段时间，第一次发送的 SYN= 1 音讯才发送到服务器，此时服务器认为是新的建设连贯过程，又会回复一个 SYN=1,ACK= 1 的响应。
如果只有两次连贯，服务器会认为胜利建设连贯，但实际上客户端的数据曾经获取到，不会再发送申请了，服务器就会处于始终期待的状态。
采纳三次握手就能够避免这样的状况，因为第三次申请没发送给服务器，所以它处于同步已承受状态，如果始终没有收到第三条申请则会敞开连贯。

那如果第三次握手失败了呢？

此时 server 的状态为 SYN-RCVD，若等不到 client 的 ACK，server 会从新发送 SYN+ACK 包。如果 server 多次重发 SYN+ACK 都等不到 client 的 ACK，就会发送 RST 包，强制敞开连贯。

当获取连贯后，就能够开始真正的传输数据啦

服务器发送第一条申请给客户端，SYN=0，ACK=1，seq=1，ack=583，len=1280，发送数据的序号从 1 开始，心愿对方发送数据从 583 字节开始。
服务器发送第二条申请给客户端，，SYN=0，ACK=1，seq=1281，ack=583，len=2560，因为上一次申请发送了 1280 字节的数据，所以此条数据从 1281 开始，还没有收到客户端的数据，所以确认号依然为 583。
服务器发送第三条申请给客户端，SYN=0，ACK=1，seq=3841，ack=583，len=1280，到上一次申请的数据曾经发送到了 1280+2560，所以此次从 3841 字节的数据开始。
客户端回应服务器发送的申请，SYN=0，ACK=1，seq=583，ack=3841，len=0，因为服务器心愿收到 583 字节开始的数据，所以这里序号为 583，确认号为 3841，心愿收到对方以 3841 开始的数据（这里可能上一条数据还没有收到），长度为 0 示意只是确认收到的响应。

到这里就是残缺的【建设连贯】，以及发送申请流程。对于【开释连贯】，会在下一篇文章中形容。

以上就是对于 从序号和确认号了解 TCP 三次握手 的内容，更多无关 前端 、 网络协议 的内容能够参考我其它的博文，继续更新中~

正文完