市场部做网站工作职责,合肥网站建设与设计,免费收录链接网,wordpress 3.8.1 下载文章目录1.确认应答机制 (ACK)2.超时重传3.1建立连接 - 三次握手 ▲3.2.断开连接 - 四次挥手 ▲1.确认应答机制 (ACK)
确认应答是可靠传输的最核心机制 接收方反馈一个应答报文(ACK)#xff0c;表示已收到
假设现在 A 想去 B 家里玩游戏#xff0c;于是 A 给 B 发消息…
文章目录1.确认应答机制 (ACK)2.超时重传3.1建立连接 - 三次握手 ▲3.2.断开连接 - 四次挥手 ▲1.确认应答机制 (ACK)
确认应答是可靠传输的最核心机制 接收方反馈一个应答报文(ACK)表示已收到
假设现在 A 想去 B 家里玩游戏于是 A 给 B 发消息若消息没有出现错误且顺序正确 结果如下所示: 但网络传输比较复杂可能存在一种情况后发先至 由于数据的长度不同或者传输网络不同先发送的数据不一定先到达接收方接收到的数据可能是乱序的如图 当 B 回复 A 的消息时若存在对应关系那么即使出现了后发先至的情况也能顺利的确立应答 上述方法虽然可以顺利的确立应答但额外的信息很多占用的带宽很多
下面如图针对发送的请求进行编号应答的时候也针对编号进行应答这样既能保证数据传输没有歧义也不会浪费太多的空间和带宽 序号和确定序号在前面 TCP报文格式中提到过
上述情况不严谨真实的 TCP 还不一样TCP 是面向字节流的此处的编号并不是按照一条两条来编的而是按照字节来编号的 (每个字节有一个编号) 确认应答是一种特殊的报文(ACK)所谓的应答报文本质上就是 ACK 字段为1 的报文此时报头中的确认序号字段才是生效的
初始序号是随机的为了防止网络攻击如果发送多个数据每个数据都会带着一个序号 接收方收到数据后是知道数据所带着的序号的根据序号给出确认序号(告诉发送方下次给我发的序号)发送给发送方发送方就知道接收方收到了哪些数据 2.超时重传
确认应答是比较理想的情况但数据在传输过程中可能是会丢包的
仍以上面例子为例A 给 B 发消息你在家嘛等了很久A 也没收到 B 的消息此时存在以下几种情况 ① B 不想回 A 的消息 ② B 没收到 A 的消息 (丢包情况1: 发的请求丢失) ③ B 回复了消息但 A 没收到 (丢包情况2: 应答的 ACK 丢失)
②③情况丢包的两种情况对于发送方来说无法确定是哪种情况因此进行统一处理当发送了一条数据之后TCP 内部就会自动启动一个定时器达到一定时间也没收到 ACK定时器就会自动触发重传消息的动作 —— 超时重传 ①情况
思考 假设第二次重发没有成功那么就存在两个超时时间 t1t2 如图所示 那么t1 和 t2 时间一样长吗 在 TCP 中t2 会比 t1 更长 TCP 抱着一种 “悲观的态度”当一次丢包重传之后TCP 就觉得大概率后面的重传也没用所以就隔一个更长的时间节省带宽
上述丢包有两种情况一种是请求丢失 —— 重传没有问题一种是 ACK 丢失重传就意味着接收方收到了相同的数据 TCP 会在内部进行数据去重 (以序号为 key 进行去重)保证应用层读到的数据不是重复数据
确认应答 和 超时重传是 TCP 可靠性中最核心的机制
3.1建立连接 - 三次握手 ▲
为什么要就建立连接 1.更好的保证可靠性: 建立连接的过程其实就是让通信双方验证各自的发送能力和接受能力是否正常 2.协商一些重要参数 (如: 序号的初始值)
具体怎样建立连接 举例A 给 B 打电话打电话同样要验证自己以及对方的话筒和听筒是否正常工作 第一次握手 刚开始A 不知道自己和 B 手机的听筒和话筒是否正常所以 A说喂你能听到吗? 第二次握手 B 听到后说明 A 的话筒和 B 的听筒正常但 B 还需进一步检查自己的话筒和 A 的听筒是否正常同时 B 把 A 话筒正常和自己听筒正常的消息传递给 A于是 B “我能听到你呢” 第三次握手 A 收到 B 的消息后就证明了 A 听筒正常B 话筒正常
以上三次握手就保证了 A、B 的听筒和话筒都正常也就保证了通话的正常这就类似于网络建立连接时的三次握手
TCP 中真实的建立连接过程 (假设主机 A 主动发起连接) 第一次握手 客户端向服务器发送 SYN 报文 (SEQxSYN1)并进入 SYN_SENT 状态等待服务器确认第二次握手 实际上是分两部分来完成的即 SYNACK (请求和确认) 报文 服务器收到了客户端的请求向客户端回复一个确认信息 (ackx1) 服务器再向客户端发送一个 SYN 包 (SEQy)建立连接的请求此时服务器进入 SYN_RECV 状态第三次握手 客户端收到服务器的回复 (SYNACK 报文0)此时客户端也要向服务器发送确认包 (ACK)此包发送完毕客户端和服务器进入 ESTABLISHED 状态完成 3 次握手
建立连接的过程相当于通信双方各自给对方发送 SYN在各自给对方发送给 ACK只不过中间的 ACK 和 SYN 合二为一了于是最后就是三次握手 几个重要的状态:
LISTEN: 正在侦听来自远方的 TCP 端口的连接请求服务端启动后处于 LISTEN 状态用于监听不同客户端的 TCP 请求并建立连接SYN_SEND / SYN_RCVD: 建立连接的中间过程若连接顺利的话(建立连接过程也可能丢包)这两个状态就一瞬消失ESTABLISHEN: 连接建立完毕 (验证了通信双方的发送和接受能力都正常)可以进行数据传输 1.两次握手可以吗 不可以 防止已失效的请求报文又传送到了服务端建立了多余的链接浪费资源两次握手只能保证单向连接是通畅的 (为了实现可靠数据传输 TCP 协议的通信双方都必须维护一个序列号以标识发送出去的数据包中哪些是已经被对方收到的三次握手的过程即是通信双方相互告知序列号起始值并确认对方已经收到了序列号起始值的必经步骤如果只是两次握手至多只有连接发起方的起始序列号能被确认另一方选择的序列号则得不到确认 . 2.为什么是三次 主要是为了建立可靠的通信通道保证客户端与服务端同时具备发送、接收数据的能力 . 3.四次握手可以吗 可以但没必要 四次握手可以验证双方的发送接收能力正常但是这样做效率比较低 . 3.2.断开连接 - 四次挥手 ▲
三次握手: 双方各自向对方发起建立连接的请求再各自给对方回应只不过中间的 SYN 和 ACK 能合并在一起 四次挥手: 双方各自向对方发起建立连接的请求再各自给对方回应只不过中间的 FIN 和 ACK 不一定能合并在一起
仍以打电话为例如下图 TCP 中真实的断开连接过程 (假设主机 A 主动断开连接)
第一次挥手: 客户端向服务器端发送断开 TCP 连接请求的 [FINACK] 报文在报文中随机生成一个序列号 SEQu表示要断开 TCP 连接 此时客户端进入FIN_WAIT_1 (终止等待1) 状态第二次挥手: 当服务器端收到客户端发来的断开 TCP 连接的请求后回复发送 ACK 报文表示已经收到断开请求。回复时随机生成一个序列号 SEQv由于回复的是客户端发来的请求所以在客户端请求序列号 SEQu 的基础上加 1得到 acku1 此时服务端就进入了CLOSE_WAIT (关闭等待) 状态客户端收到ACK后就进入FIN_WAIT_2 (终止等待2) 状态第三次挥手: 服务器端在回复完客户端的 TCP 断开请求后不会马上进行 TCP 连接的断开。服务器端会先确认断开前所有传输到客户端的数据是否已经传输完毕。确认数据传输完毕后才进行断开向客户端发送 [FINACK] 报文设置字段值为 1。再次随机生成一个序列号 SEQw由于还是对客户端发来的 TCP 断开请求序列号 SEQx 进行回复因此 ack 依然为 x1 此时服务器就进入了LAST_ACK (最后确认) 状态第四次挥手: 客户端收到服务器发来的 TCP 断开连接数据包后将进行回复表示收到断开 TCP 连接数据包。向服务器发送 ACK 报文生成一个序列号 SEQu1由于回复的是服务器所以 ACK 字段的值在服务器发来断开 TCP 连接请求序列号 SEQw 的基础上加 1得到 ackw1 此时客户端就进入了TIME_WAIT (时间等待) 状态注意此时TCP连接还没有释放必须经过2MSL (最长报文段寿命) 的时间后当客户端撤销相应的TCB后才进入CLOSED状态 两个重要的状态:
CLOSE_WAIT: 表示在等待关闭 四次挥手挥了一半了当前可能剩下的两次不挥了(接收方没调用 close 方法就会导致四次挥手只挥两次从而没有正确关闭连接)TIME_WAIT: 谁主动断开连接谁进入 TIME-WAIT 状态此时该主机已经完成了四次挥手的过程但仍不能立刻断开连接而是要以 TIME-WAIT 状态来保持连接一段时间之后再彻底释放连接 (处理最后一个 ACK 丢包之后重传的问题) 为了解决网络的丢包和网络不稳定所带来的其他问题确保连接方能在时间范围内关闭自己的连接 1.四次挥手三次挥完行不行 通常情况下不行若触发了延时应答机制就可以三次挥完 不行即上述的 ② ③ 为什么没有合并在一起 因为中间两次操作的时机不一样 ACK 是收到 FIN 之后立刻由内核返回的数据报FIN 是应用程序处理完接受缓冲区的数据之后调用的 close 方法触发的 . 2.为什么四次 因为要确保客户端和服务端的数据能够完成传输 . 3.为什么 TIME_WAIT 状态要等待 2MSL 假设网络上传输数据的最大时间为 MSL MSL 就是 ACK / FIN 从主机 A 到主机 B 的最大时间 TIME-WAIT 等待时间需要分成两个部分 ①等待 ACK 经历一个最大时间到达主机 B ②万一 ACK 丢了在等待一个最大时间主机 B 重传 FIN 到达主机 A 因此TIME_WAIT 就需要等待 2倍的MSL即2MSL 原因 确保 ACK 报文能够到达服务端从而使服务端正常关闭连接 第四次挥手时客户端第四次挥手的 ACK 报文不一定会到达服务端服务端会超时重传 FIN / ACK 报文此时如果客户端已经断开了连接那么就无法响应服务端的二次请求这样服务端迟迟收不到 FIN / ACK 报文的确认就无法正常断开连接 MSL 是报文段在网络上存活的最长时间客户端等待 2MSL 时间即「客户端 ACK 报文 1MSL 超时 服务端 FIN 报文 1MSL 传输」就能够收到服务端重传的 FIN / ACK 报文然后客户端重传一次 ACK 报文并重新启动 2MSL 计时器如此保证服务端能够正常关闭 如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端服务端则会继续超时重试直到断开连接防止已失效的连接请求报文段出现在之后的连接中 TCP 要求在 2MSL 内不使用相同的序列号客户端在发送完最后一个 ACK 报文段后再经过时间 2MSL就可以保证本连接持续的时间内产生的所有报文段都从网络中消失这样就可以使下一个连接中不会出现这种旧的连接请求报文段或者即使收到这些过时的报文也可以不处理它
