东莞个人网站制作,公众号可以做网站维护链接吗,用软件做的网站权限管理,怎么制作页面简介
接前文 协议簇#xff1a;TCP 解析: 基础#xff0c; 我们这篇文章来看看 TCP 连接建立的过程#xff0c;也就是众所周知的”三次握手“的具体流程.
系列文章
协议簇#xff1a;TCP 解析#xff1a;基础 协议簇#xff1a;TCP 解析#xff1a;建立连接 协议簇TCP 解析: 基础 我们这篇文章来看看 TCP 连接建立的过程也就是众所周知的”三次握手“的具体流程.
系列文章
协议簇TCP 解析基础 协议簇TCP 解析建立连接 协议簇TCP 解析连接断开 协议簇TCP 解析Sequence Number 协议簇TCP 解析数据传输
三次握手
最普通的 TCP 握手流程如下图 下面描述中序列号对应于上图中的行号.
初始状态时TCP A 处于连接关闭状态 TCP B 处于监听状态. 也就是通常所说的 A 时 TCP 客户段B 是服务端.A 发送 SYN 给 B 并附有 SEQ, 请求建立 TCP 连接。 A 发送 SYN 后状态切换为 SYN-SENT, B 接收到 A 发送的 SYN 后状态切换为 SYN-RECEIVED.B 收到 A 的 SYN 之后发送它的 SYN注意这里 A 和 B 的 SEQ 是相互独立的 并附上 ACK 标记用以表明 B 收到了 A 的 SYN 包。 这里注意 B 发送的 ACK 的值为 101它代表 B 收到了序列号为 100和100之前的所有字节数据并告诉 A 自己期待下一次收到序列号以101开始的数据. A 在接收到 B 的 SYN 之后状态转化为 ESTABLISHED.A 收到 B 的 SYN 之后 需要发送 ACK 给 B 告诉 B 自己收到了它的 SYN ACK 包. 这里注意A 发送的ACK的值为 301, 原因是 B 的 SYN 中的 SEQ 是 300. A 发送的 SEQ 是 101原因是上一次的请求中序列号已经增长到了 100. 下一个可用的序列号就是 101. 在B接收到 A 的 ACK 之后它的状态切换为 ESTABLSHED. 至此三次握手已经完成一个 TCP 连接已经成功建立。在这条 TCP 连接上可以进行数据传输.
在了解了基本的流程之后我们来使用 wireshark 包应用以下所学
如下图忽略其中的黑色记录一共四条记录对应于上图中的 2-5. 接下来我们详细看看每条记录
客户端 SYN
这是建立 TCP 连接三次握手中的第一次。 这张图涵盖的信息很多全部字段的含义在前文中已经描述过这里我们仅仅关注个别字段.
Flags 字段中 SYN 标记为 1. 表明当前 TCP 包是一个 SYN 包. 首先发送这个数据包的 TCP 段为请求建立 TCP 连接的端点.Sequence Number 字段的值为 2292773402. Wireshark 为了方便我们查看引入另外一个字段 relative sequence number. 这个字段的值是基于 initial sequence number 计算所得. 正如前文 TCP 基础中所说当当前 TCP 包是一个 SYN 包时Sequence number 就是 Initial Sequence Number, 因此 这里 relative sequence number 的值是 0.
服务端 SYN ACK
这是建立 TCP 连接三次握手中的第二次。
Flags 字段中 SYN 和 ACK 字段均为 1Sequence Number 字段的值为 4127119125 (前面说过客户端的 SEQ 和 服务端的 SEQ 是独立的他们之间没有联系), Relative Sequence Number 为 0.Acknowledge Number 字段的值为 2292773403. 客户段发送的 SYN 中 的 SEQ 值是 2292773402. 序列号 2292773403 告诉客户端 2292773403以及之前的所有数据已经收到。 在接收到这个响应之后 客户端便可以确信服务段收到了自己发送的 SYN 包.
客户端 ACK
这是建立 TCP 连接三次握手中的第三次。
Flags 字段 ACK 为 1Sequence Number 的值为 2292773403. 这个值于服务端发送给我们 SYNACK 包中的 ACK 值相同.Acknowledge Number 的值为 4127119126. 这里需要注意服务第发送的 SYNACK 包中的 SEQ 的值为 4127119125.
至此这个 TCP 连接成功建立。
特殊情况: 双方同时请求建立连接
在一个 TCP 建立成功之前连接双方是没有任何关于对方的信息的。因此存在一种巧合那就是双方同时发起建立TCP连接的请求. 这里我们来看一下这个特殊情况. 图中 … 用来表示该数据包正在网络上传输对方还未收到. 注意这里图中虽然对数据包进行 1-7 的编号但是对于双方任何一方都是独立的. 也就是说接收数据的先后是不确定的有可能 B 先接收到 A 的包也有可能 A 先接受到 B 的包。 这里我们并没有明确的指定哪一方为 服务端哪一方为客户端因此这里的结论都是成立的. 初始状态下双方均处于 CLOSED 状态. 存在这种可能 某一时刻双发同时发送自己的 SYN 给对方请求建立一条 TCP 连接.在某一时间点A 发送 SYN 到 B 请求建立 TCP 连接. 此时A 的状态切换为 SYN-SENTB 在未收到 A 发送的 SYN 包时发送了自己的 SYN 给 A请求建立一条连接. 此时B 的状态也切换为 SYN-SENT. 在接收到 B 发送的 SYN 之后A 的状态切换为 SYN-RECEIVED.此时A 发送的 SYN 到达 B 端。B 收到了 A 发送的 SYN 包状态切换为 SYN-RECEIVED.在第三步之后A的状态一旦变成SYN-RECEIVED 他就需要发送对应的 SYNACK 给 B以确认自己接收到了 B 发送的 SYN. 并将自己的状态切换为 ESTABLISHED. 这里注意它发送完 SYNACK 之后只是单方的进入 ESTABLISHED 状态对应状态依然为 SYN-RECEIVED.在第四步之后 B的状态一旦变成SYN-RECEIVED它也要发送 SYNACK. 并切换状态为 ESTABLISHED。B 收到 A 发送的 SYNACK。 至此双方均进入 ESTABLISHED 状态一个连接已然建立成功.
特殊情况: 旧的重复的 SYN
TCP 协议的设计为三次握手的一个很重要原因就是处理旧的重复的SYN包 RFC793 原文 The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion 这里我们就来看看它是如何处理的。
看下图的 TCP 包流程
初始状态下 A 为客户端处于 CLOSED 状态。 B 为服务端处于LISTEN状态某一时刻A 发送 SYN 给 B请求建立 TCP 连接B 在收到 A 刚刚发送的 SYN 包之前 收到了一个旧的重复的来自 A 的 SYN.对于 B 段来说在收到来自 A 的 SYN 包时它是不知道那是一个旧的重复的 SYN 包的因此它就想就受到一个普通的 SYN一样响应这个 SYN 包. 发送 SYNACK 进行确认.A 端收到来自 B 段的 SYNACK 发现其中的 ACK 字段的值不正确. 因为自己发送的 SYN 中 SEQ 值为 100响应SYNACK包中的 ACK的值应该为 101但是它收到的 SYNACK包中的ACK的值却是91. 在收到这个非法的SYNACK之后A 段发送 RST并附上错误的SEQ序列号. B 端收到A发送过来的 RST 之后便得知 A 重置了上一个SYN想要建立的TCP连接B 段重置所有关于为上一个 SYN 所记录的状态并重新回到 LISTEN 状态.对于 TCP 协议来说数据是不会丢失的也就是说 B 段迟早会收到 A 发送的 SYNSEQ100. B 端收到 A 的 RST 之后状态切换到了 LISTEN之后 A 发送 SYNSEQ100到达此时B依然回像通常情况一样. 如果 SYNSEQ100到达 B 段早于 A 发送的 RST将会是一个更复杂的情况涉及到双发均发送 RST 的场景. 这里能力有限略掉.B 在收到正确的 SYNACK之后发送自己的 SYN 给 AA 在发送自己的 SYNACK给B这样之后一个 TCP 连接成功建立. 如果剔除上述流程中 3-5我们会发现这就是一个普通的 TCP 连接的三次握手流程. 厉害的地方在于引入三次握手建立连接的机制TCP 可以优雅的处理掉由于网络不可靠所导致的非法SYN的数据包。 厉害 Half-Open connections
这里我们将 “Half-Open connection” 称作 “半连接状态的链接”.
什么是半连接状态的链接 B方链接已经关闭或者由于其他原因而奔溃掉但是A方不知道B方的情况此时 A 方持有的就是一个半连接状态的链接.
我们通过一个例子来描述半连接状态的链接
在某一时刻A段的链接崩溃掉。假设奔溃的原因是A端物理内存不足. B 端未收到任何通知在A端从错误中回复过来之后假设用户尝试发送数据从原先的 TCP 连接上A 端TCP模块会返回类似的 “connection not open”错误此时 A 端TCP状态为 CLOSED B 端不知道 A 端的情况因此状态依然为 ESTABLISHED.A 端发现 TCP 错误后尝试重新建立原先的 TCP 链接发送SYN到 B 端B 端收到 A 的 SYN 之后发现收到的 SEQ400 于自己期待的 SEQ(100) 无法匹配 因此不对这个 SYN 进行确认而是发送自已认为正确的 SEQ(100) 给 A 端.A 端收到 B 端发送的 SYNACK 之后发现收到的 SEQ(100) 与自己刚刚发送的 SYN 中的 SEQ400不一致因此得知自己的TCP状态已经与B端不一致了。因此发送 RST 重置当前的 TCP 链接.在上述步骤之后上一个 TCP 链接依然被重置双方不再维护上一个TCP链接的任何状态.这里 A 端重新发送 SYN 请求建立一个全新的 TCP 链接. 至此已经走上了正路在正常的三次握手之后一个新的 TCP 链接即将建立.
另外一种情况#####
这里还有一个更有趣的情况. 考虑下图的形况
A 端已然崩溃掉. B 端对此一无所知.此时 B 端认为链接一切正常在该TCP链接上往 A 发送数据.A 端收到这个数据之后发现这个 TCP 链接并不存在因此直接发送 RST 通知对方重置链接.
Reset
何时 TCP 会发送 RST 通常来说当 TCP 接收到一个明显不是给当前连接的数据时必须发送 RST。 当不是很明显时不应该发送 RST.
发送 RST的原则##### 当当前 TCP 连接不存在时对方发送任何数据到此除过RST我们会发送 RST. 在这种情况下如果从对方收到的数据包是包含ACK那么 RST 中的 SEQ 会被置为 ACK 中包含的 SEQ其他情况下 RST 中的 SEQ 会被置为0且 ACK 字段被置为 SEQ 接收到的数据的长度. 连接状态维持为 CLOSED. 当当前 TCP 连接处于正在建立的状态LISTENSYN-SENT 或 SYN-RECIEVED RFC中成为 非同步状态 接收到的数据却包含了非法的 ACK 值我们会发送 RST. 当当前 TCP 处于同步的状态ESTABLISHED FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, 此时收到一个非法的TCP数据包(错误的 SEQ或者错误的 ACK值), 我们应该发送一个ACK其中包含当前的发送SEQ和一个 ACK值表明我们期待收到的下一个TCP数据包的序列号. 此时维持当前 TCP 的状态不变. 这种情况的一个例子就是我们在半连接状态的连接小节中第一张图的 步骤 4.
END
